Opened 3 years ago
Last modified 3 years ago
#17451 assigned bug
Doubled screen with new intel GPU driver
Reported by: | rjzak | Owned by: | rudolfc |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Graphics/intel_extreme/coffeelake | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
Running hrev55687 on my System 76 Oryx Pro 5 (which has both the 9th-gen Intel GPU and Nvidia RTX) shows double with the intel driver.
Not sure if it's intel_810 or intel_extreme.
Attachments (17)
Change History (37)
by , 3 years ago
Attachment: | haiku_syslog added |
---|
by , 3 years ago
Attachment: | haiku_intel_screen_2.png added |
---|
comment:1 by , 3 years ago
I rebooted the machine in "integrated graphics mode" which is supposed to disable the Nvidia GPU, and it didn't change the output.
comment:2 by , 3 years ago
Please make sure to upload both syslog and syslog.old together. Otherwise the boot phase is missing somehow.
comment:4 by , 3 years ago
KERN: intel_extreme: intel_set_display_mode(1024x768, virtual: 1024x768)
there is no edid information. the Halo GT2 IDs are both marked as mobile. If there was VBT information, it would be used, but it doesn't look like it was found.
comment:5 by , 3 years ago
Hi, assuming this is generation 9.5, there is a new DDI port in the hardware. I just added it here: hrev55689
Could you test it and upload a new syslog? Could be the panel is seen, but probably without specs yet.
by , 3 years ago
Attachment: | haiku_screen_3.png added |
---|
hrev55687 screen resize does help, but dimension goes beyond screen size, boot artifacts gone, right size still doubled
by , 3 years ago
Attachment: | haiku_screen_4.png added |
---|
hrev55687 screen resize also shows some artifact lines
comment:6 by , 3 years ago
Thank you. Still please test the latest version.. I guess a new nightly tomorrow. The behaviour you now see is expected because no display is detected still. That might change with the next nightly..
comment:7 by , 3 years ago
With hrev55692 (missed 89), the initial resolution was beyond the size of the screen. But I was able to pull up the Screen preference and set the resolution to 1280x1024, which properly fits the desktop background to the size of the screen. Changing the refresh rate seems to work, but I don't know how to verify. Also, the brightness slider doesn't do anything.
comment:8 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Thank you. Still no display found unfortunately. The new port is not scanned, I'll have a second look at it.
At this time the driver only works in boot/native mode for you, you should be able to set colordepth and virtual size, but refresh will not work yet, and resolution will also not work yet.
comment:9 by , 3 years ago
I'm glad that driver not working doesn't result in a panic or blank screen. Good job with failing gracefully, as seems to be the situation.
comment:10 by , 3 years ago
What does work btw. is that -some- memory content is found in the mapped BIOS range. I am updating a bit of the search code in that BIOS to see if we can locate info about your panel.
If indeed the nvidia card is disabled, chances are the BIOS mapped is the intel one, not the nvidia. (I think I saw the intel_extreme driver still maps the compat range (below 1Mb) for the image, instead of directly mapping it itself, which would mean we could be looking at the wrong BIOS)
I'll get back to you on this part as soon as I have something to be tested (probably in the nightly at some point)
Thanks!
comment:11 by , 3 years ago
Just committed a patch for the BIOS scan for panel info: hrev55712.
Can you run a nightly with that included and upload syslog again? The driver probably doesn't work yet, but hopefully we now have your panel data from the BIOS..
by , 3 years ago
Attachment: | hrev55720.syslog added |
---|
by , 3 years ago
Attachment: | hrev55720.syslog.old added |
---|
comment:12 by , 3 years ago
comment:13 by , 3 years ago
There can be more commits on one day, while just one nightly per day is generated, so if you miss revisions that can actually be a good sign (busy @ work ;-)
Anyhow, the BIOS is scanned but no signature is found, while there really is -something- at the legacy adress range. So I am assuming for now we are not looking at the right ROM. I'll have a further look at this and I'll let you know when I have new things to test..
Thanks again!
comment:14 by , 3 years ago
Hi again,
Just committed hrev55845. Could you try this revision (or a later one) and upload a syslog again? The BIOS will probably not be found yet as it should be, but there is chance that EDID info is available now (in your case fetched from the boot), at least if your BIOS provides this at boot.
You're testing 64bit on a UEFI BIOS I think? If so, you could also see if you can boot a 32bit image as there's a chance that EDID is found then only. I've seen these situations over here at least..
Thank you!
comment:15 by , 3 years ago
I was able to test hrev55845 on my system, though 64-bit EFI only. It seems my laptop doesn't support legacy boot, as the 32-bit USB thumb drive wasn't detected by the boot menu (I tried a few times, different ports, no change). I'll attach the requested syslogs. Also, the driver still causes a kernel panic when trying to free memory when unloading before reboot/shutdown.
by , 3 years ago
Attachment: | syslog.old_hrev55845_64bit_uefi added |
---|
by , 3 years ago
Attachment: | syslog_hrev55845_64bit_uefi added |
---|
by , 3 years ago
Attachment: | syslog.old_hrev55845_64bit_uefi_nvidia_disabled added |
---|
by , 3 years ago
Attachment: | syslog_hrev55845_64bit_uefi_nvidia_disabled added |
---|
comment:16 by , 3 years ago
The laptop also has an Nvidia 2070 GPU, which I had forgotten to disable when testing (hence the logs with/without "nvidia_disabled" in the name).
Also interesting, shutting down with nvidia disabled didn't produce a kernel panic, and the system actually powered off (normally, it hangs at the shutting down box, waiting forever). Restarting with nvidia disabled still caused a kernel panic.
Finally, the Screen system preference still reports the same Coffee Lake GPU regardless of the nvidia card being activated, and still can change the resolution. And the nvidia GPU is enabled/disabled using the System 76 power controls in Pop_OS, which seem to make a change to the BIOS, as a reboot is required for a GPU (de)activate to take affect, so disabling it in Linux should mean it really really is disabled when rebooting into Haiku.
comment:17 by , 3 years ago
Hi there rjzak, could you please try hrev55928 or later? This time the internal panel's native resolution should be found by the driver. That could mean modesetting now works as well.
Can you upload a new syslog from the attempt?
Thank you!
comment:18 by , 3 years ago
Unfortunately the kernel panic at shutdown is back, same place: intel_extreme_uninit()
comment:19 by , 3 years ago
Component: | Drivers/Graphics/intel_810 → Drivers/Graphics/intel_extreme/coffeelake |
---|
Could you please check with a current nightly and attach a syslog? thanks
comment:20 by , 3 years ago
System seems to work fine on hrev56107, syslog attached. Screen
shows the display as Intel (CoffeeLake Halo GT2)
and says the display is ALFA 16"
(it is a 16" display, not sure about the Alfa part, maybe the display manufacturer?).
Brightness also works.
syslog