Opened 5 years ago
Last modified 2 years ago
#15396 in-progress bug
Screen content shifted horizontally in pure UEFI mode
Reported by: | miqlas | Owned by: | rudolfc |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Graphics/intel_extreme/haswell | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
- Machine: Lenovo T440s
- OS: Haiku x86_64 hrev53523
- VGA: 8086, 0a16: Haswell-ULT Integrated Graphics Controller
Booting Haiku:
- in legacy mode: bootlogo OK, desktop OK
- in UEFI+CSM: bootlogo OK, desktop OK
- in UEFI without CSM: bootlogo OK, desktop shifted horizontally, see the attached screenshot.
Attachments (13)
Change History (52)
by , 5 years ago
Attachment: | syslog_UEFI_without_CSM.txt added |
---|
by , 5 years ago
Attachment: | syslog_UEFI_with_CSM.txt added |
---|
by , 5 years ago
Attachment: | syslog_Legacy.txt added |
---|
by , 5 years ago
Attachment: | listdev.txt added |
---|
by , 5 years ago
Attachment: | sysinfo.txt added |
---|
by , 5 years ago
Attachment: | shifted-screen-content.jpg added |
---|
comment:1 by , 5 years ago
Component: | Drivers/Graphics/intel_extreme → Drivers/Graphics/intel_extreme/haswell |
---|---|
Owner: | changed from | to
comment:2 by , 3 years ago
comment:3 by , 3 years ago
Hi Rudolf, thanks but i use explicitly 64 bit Haikus. Could xou provide a 64 bit version or the sources to build it myself?
comment:4 by , 3 years ago
Another option would be you just place a 32bit image on a USB stick and place the driver on that, so you don't have to touch your existing Haiku install.
Would that be workable for you? I'm not ready yet to publish the modification and I currently only have a 32bit system to compile. Also, the 32bit version gives more options to test since on 64bit you will not be able to switch modes in VESA mode from the desktop: and that might very well be needed.
comment:5 by , 3 years ago
Oh, BTW, what would happen if you change the refreshrate on your current install? try lowering (or increasing) it in say 0.5Hz steps. The driver you have on the 64bit version might respond to that with increasing/decreasing horizontal shifts.
I'd be curious to know if that indeed happens as well :-)
comment:6 by , 3 years ago
Hmm: another test: If on the UEFI-nonCSM (what is that CSM? I have no idea.. sorry) setup the display is OK: what happens if you do 0.5Hz refreshrate changes there?
- Can you introduce the horizontal shift there then?
- Hmm: or does changing the refresh not change the refresh on your screen? IF that function fails this test is at this moment impossible to do..
comment:7 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
comment:8 by , 3 years ago
For your info, I am going to push the pixelPLL changes to git. As a second test you can repeat (or firstly do if currently not yet possible) the refreshrate steps change test.
see hrev55115.
comment:9 by , 3 years ago
Hi miqlas, could you please test the driver I just uploaded? 64bit is included now..
comment:10 by , 3 years ago
BTW: question, in UEFI without CSM: is the bootlogo screen different from the other options? I mean: same resolution and refresh in use mostly? Since not all gfxcard items are programmed yet, that might be the reason for no correct desktop. That would possibly be 'fixed' by finding out which resolution is used in UEFI no CSM and also set that resolution for your desktop..
The V4 driver does program more stuff so it might be that it will have fixed the UEFI no CSM 'by itself'..
comment:11 by , 3 years ago
Yes, in CSM mode, a 'safe' resolution is set. Ithink 800x600 or 1024x768. Otherwise it should set native resolution.
comment:12 by , 3 years ago
Just tested the v4 driver from non-packaged. Nothing changed, the results are the same as in the ticket above.
what happens if you do 0.5Hz refreshrate changes there?
No change.
Can you introduce the horizontal shift there then?
I see no change in any boot-mode. I can't manually introduce the shifted display bug.
Hmm: or does changing the refresh not change the refresh on your screen? IF that function fails this test is at this moment impossible to do..
Maybe. I have no way to see if the refresh-rate setting actually changes anything at all.
comment:14 by , 3 years ago
Hello again! Could you please test hrev55168 or later and tell me if there are behaviour changes in the driver? And could you please upload the resulting syslog from /var/log/? Thank you!
comment:15 by , 3 years ago
Hello, Could you please test hrev55189 or later for me? I'd like to get a general status update from you so to speak :-) And of course, also a syslog or two uploaded here ;-)
Thank you!
comment:16 by , 3 years ago
in legacy mode: bootlogo OK, desktop OK in UEFI+CSM: bootlogo OK, desktop OK in UEFI without CSM: bootlogo OK, desktop shifted horizontally
Will add syslogs, i just forgot to save them.
by , 3 years ago
Attachment: | syslog_legacy.txt added |
---|
by , 3 years ago
Attachment: | syslog_UEFI_CSM.txt added |
---|
by , 3 years ago
Attachment: | syslog_UEFI.txt added |
---|
comment:18 by , 3 years ago
Thanks for the update! this is interesting, I'll have a closer look asap.
comment:19 by , 3 years ago
OK, you've got a rather basic problem: you are not running the current driver, but an old one.
Please download a very recent and fresh nightly (with all the updates for intel_extreme), put it on a USB stick and boot from that if possible.
The way you are testing now does not work unfortunately: how are you testing? Please note that this is probably not your fault BTW, but Haiku's. I have created a ticket indicating a problem you might be encountering.. (driver not loaded when in user unpackaged hierarchy)
All 3 logs are with an old version of the driver, and all 3 logs indicate trouble. All 3 versions try to set 1920x1200 mode, but your panel is 1920x1080 I think when I lookup your laptop specs on internet. Since UEFI boot handles the booticons screen differently that would explain why you see different results. In the other two cases the before-boot mode more closely resembles your panel, and the driver does not actually program anything for you that's relevant here.
So, questions I have for you:
- Please confirm your panel type
- Please explain how you were testing the newest intel_Extreme driver
- please create a fresh nightly bootable USB stick (or install fresh on internal disk of course ;-) and retry.
- please upload syslogs again, along with your comments, preferably for all 3 boot types you already tried (non-UEFI and UEFI, legacy).
Since you are one of the few people testing with this generation card, and since I have specific plans to do some work on your type, I hope you are willing to do some more tests later on: PLL programming is still missing for your card (also on the newest driver). For the internal panel that could/should be OK, but not if you are going to test with external screen(s), which I hope you can do as well later on.
OK, long story.. Please let me know how you feel about all this and if at all possible please continue testing! I'd love to see better results for you :-)
comment:20 by , 3 years ago
This is interesting and might show a problem with UEFI. My guess is graphics drivers are packaged in the bootloader, which would explain this, the problem with unpackaged boot drivers.
comment:21 by , 3 years ago
Hi tqh, if you have any idea how to fix that I would most certainly love that. It's been holding me back a lot already developing on/for UEFI systems. So, the user unpackaged hierarchy -is- published, only to late for app_Server to see the driver when it scans for it..
comment:22 by , 3 years ago
And it happens on UEFI BIOS systems, independant of booting in compatibility, CSM, UEFI, 32 or 64 bit mode. Always trouble.
comment:23 by , 3 years ago
Sorry, my mistake, i had an intel_extreme driver in non-packaged folder structure. Removing the driver solved the problem, the screen not shifted with the current and actual driver.
You can close this ticket.
comment:24 by , 3 years ago
Super! Can you still upload a syslog then and tell me if you can set different resolutions successfully?
Thanks!
comment:25 by , 3 years ago
Oh, and could you also test with an external screen? With a few resolutions..
comment:26 by , 3 years ago
Tested again, syslogs follows. Screen res change works ok in legacy mode, other booting modes untested.
by , 3 years ago
Attachment: | syslog_legacy.2.txt added |
---|
by , 3 years ago
Attachment: | syslog_UEFI_CSM.2.txt added |
---|
by , 3 years ago
Attachment: | syslog_UEFI.2.txt added |
---|
comment:28 by , 3 years ago
Hello miqlas,
Can you try version hrev55712 or later and upload a syslog again? one method is enough. I am hoping that the driver can now find the internal panel's native resolution: it did not before.
comment:35 by , 2 years ago
It looks like there is a setting with 1920x1200. Could you try to remove it?
comment:37 by , 2 years ago
The EDID is found with a native mode 1920x1080. But the app_server insists on setting 1920x1200.
EDIT: the settings file is named config/settings/system/app_server/workspaces
comment:38 by , 2 years ago
Oh! I always tought 1980x1200 is the native resolution (it is the highest resolution proposed by the Screen preflet) because the screen content is sharp, but i checked and this machine was sold with 1920x1080 screen. Setting this resolution solved the problem. Thanks :)
comment:39 by , 2 years ago
Nice. This is weird though, as the EDID with the default screen only includes one resolution. Could you send a screenshot of the Screen Preferences resolutions menu? and possibly a syslog.
Hi, could be that the misaligned screen is solved in a 32bit testversion of the driver, which you can download here:
https://discuss.haiku-os.org/t/graphics-on-dell-laptop-in-vesa-mode-only/10583/64
I'd be interested in the results of a quick test with it, both if it works and if it does not work..