Created attachment 126554 [details] Attachments as a zip Hello, when using the latest 4.8.0 kernel and drm-intel-nightly branch, and also on the 4.6.3 kernel, (in both cases using Linux Mint 18 Cinnamon) the internal display on this computer is corrupted, and only the upper half of the physical display is used to display the output (the entire display output is squashed into the top half). The lower half of the display contains vertical lines. See the attached screenshots. Changing the resolution or scaling makes no difference. If KMS is disabled using nomodeset on the kernel command line, the display is rendered as expected using the full physical screen, using the generic vesa driver (although obviously at a lower resolution of 1024x768). However the vertical line corruption is still visible on the lower half of the display. The lower half screen corruption appears to become less prominent over time, but do not disappear entirely. The internal display is connected via eDP and is a 1920x1080 6-bit panel reported as Hewlett-Packard [Unknown Model: HWP0060]. See hp_hwinfo.log for details of the system's hardware. On kernel 4.4.0 (Ubuntu GNOME 16.10 Beta 1), using the i915_bpo driver, the internal display on eDP1 is reported as disconnected and the internal display is non-functional. An external monitor connected via DisplayPort works as expected (the errant behaviour of the internal display is unchanged) Debug dmesg logs: dmesg.txt: From boot. Note there is an external Dell monitor attached and xrandr is set to disable the internal display. dmesg2.txt: Internal display reenabled via xrandr Thank you for any help! Antony
Seeing the same problem on the same hardware. Any help or pointers as to what might cause the issue would be appreciated.
We have the expect same issue, tried many different kernels. But never got it work properly in Linux. The "funny" thing is that after the split screen problem in linux. The line that stays visible for a while, stays on the display whenever Windows is booted afterwards too... But then slowly disappears. Have you found any other solution besides using nomodeset?
(In reply to Antony from comment #0) > Created attachment 126554 [details] > Attachments as a zip Please *always* attach the plain files, without packing or zipping.
Created attachment 126841 [details] Screenshot 1
Created attachment 126842 [details] Screenshot 2
Created attachment 126843 [details] dmesg
Created attachment 126844 [details] xrandr
At a glance, the screenshots look like the image is vertically scaled to half. Is that right? Is the image all right at boot and in the bios and grub screens? If so, please grab the tools/intel_reg tool from intel-gpu-tools [1], and provide 'intel_reg dump' output for 1) when i915 has not been loaded yet, and 2) after i915 has loaded.
We tested the non-touch model of the HP EliteOne 800 G2 AIO, and that one works correclty. I will get the intel_reg dump output in a few minutes.
Created attachment 126846 [details] intel_reg dump with i915 module loaded
Created attachment 126847 [details] intel_reg dump without i915 module loaded
Created attachment 126848 [details] intel_reg dump with i915 module loaded and nomodeset
i just tried loading the saved edid.bin from the working non-touch model (HP EliteOne 800 G2 23-in AIO) but this gives the same result.
(In reply to Jani Nikula from comment #8) > At a glance, the screenshots look like the image is vertically scaled to > half. Is that right? > > Is the image all right at boot and in the bios and grub screens? > > If so, please grab the tools/intel_reg tool from intel-gpu-tools [1], and > provide 'intel_reg dump' output for 1) when i915 has not been loaded yet, > and 2) after i915 has loaded. Yes the image is all right at boot and in the bios and grub screens.
(In reply to r.r.arends from comment #14) > (In reply to Jani Nikula from comment #8) > > At a glance, the screenshots look like the image is vertically scaled to > > half. Is that right? > > > > Is the image all right at boot and in the bios and grub screens? > > > > If so, please grab the tools/intel_reg tool from intel-gpu-tools [1], and > > provide 'intel_reg dump' output for 1) when i915 has not been loaded yet, > > and 2) after i915 has loaded. > > Yes the image is all right at boot and in the bios and grub screens. What if you add i915.fastboot=1 module parameter? (If it works, it'll work for the boot, but I expect it to fail after the first modeset or suspend/resume.)
(In reply to Jani Nikula from comment #15) > (In reply to r.r.arends from comment #14) > > (In reply to Jani Nikula from comment #8) > > > At a glance, the screenshots look like the image is vertically scaled to > > > half. Is that right? > > > > > > Is the image all right at boot and in the bios and grub screens? > > > > > > If so, please grab the tools/intel_reg tool from intel-gpu-tools [1], and > > > provide 'intel_reg dump' output for 1) when i915 has not been loaded yet, > > > and 2) after i915 has loaded. > > > > Yes the image is all right at boot and in the bios and grub screens. > > What if you add i915.fastboot=1 module parameter? (If it works, it'll work > for the boot, but I expect it to fail after the first modeset or > suspend/resume.) Same result, it fails to the halfsize split screen.
(In reply to r.r.arends from comment #16) > (In reply to Jani Nikula from comment #15) > > (In reply to r.r.arends from comment #14) > > > (In reply to Jani Nikula from comment #8) > > > > At a glance, the screenshots look like the image is vertically scaled to > > > > half. Is that right? > > > > > > > > Is the image all right at boot and in the bios and grub screens? > > > > > > > > If so, please grab the tools/intel_reg tool from intel-gpu-tools [1], and > > > > provide 'intel_reg dump' output for 1) when i915 has not been loaded yet, > > > > and 2) after i915 has loaded. > > > > > > Yes the image is all right at boot and in the bios and grub screens. > > > > What if you add i915.fastboot=1 module parameter? (If it works, it'll work > > for the boot, but I expect it to fail after the first modeset or > > suspend/resume.) > > Same result, it fails to the halfsize split screen. A video of the boot: https://www.youtube.com/watch?v=_g65etG_Vak
Any ideas?
(In reply to r.r.arends from comment #18) > Any ideas? I just tried the just released 4.8 kernel without success, i get the same issue...
The only significant difference I see is the timings. The BIOS uses: "1920x1080" 60 143978 1920 2016 2080 2176 1080 1088 1092 1100 0x40 0x5 But the VBT gives us: "1920x1080" 60 133100 1920 1952 1980 2004 1080 1088 1092 1107 0x8 0xa So it's looking like another case of invalid panel type :( Please attach a copy of /sys/kernel/debug/dri/0/i915_opregion
Created attachment 127068 [details] i915_opregion
(In reply to Ville Syrjala from comment #20) > The only significant difference I see is the timings. The BIOS uses: > "1920x1080" 60 143978 1920 2016 2080 2176 1080 1088 1092 1100 0x40 0x5 > > But the VBT gives us: > "1920x1080" 60 133100 1920 1952 1980 2004 1080 1088 1092 1107 0x8 0xa > > So it's looking like another case of invalid panel type :( > > Please attach a copy of /sys/kernel/debug/dri/0/i915_opregion Yeh the only difference between de non-touch and the touch is the usb touchdevice and the panel itself. :(. I've attached the /sys/kernel/debug/dri/0/i915_opregion Can we work around this badpanel?
Created attachment 127069 [details] i915_opregion_nontouch_workingone as a comparison i've also attached the i915_opregion from the working non-touch system. When i compare them i get the following difference, but i have no clue what this is :) $ diff -u i915_opregion.hex i915_opregion_nontouch_workingone.hex --- i915_opregion.hex 2016-10-06 16:30:29.828540260 +0200 +++ i915_opregion_nontouch_workingone.hex 2016-10-06 16:30:41.284374997 +0200 @@ -47,8 +47,8 @@ 000002e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000002f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000300: 0100 0000 0000 0000 0200 0000 0000 0000 ................ -00000310: ff00 0080 0600 0080 6400 0080 2b80 408a ........d...+.@. -00000320: 5594 6a9e 7fa8 95b2 aabc bfc6 d4d0 e9da U.j............. +00000310: ff00 0080 0600 0080 6400 0080 3180 458a ........d...1.E. +00000320: 5a94 6e9e 83a8 98b2 acbc c1c6 d5d0 eada Z.n............. 00000330: ffe4 0000 0000 0000 0000 0000 0000 0000 ................ 00000340: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000350: 0000 0000 0000 0000 0000 0000 0000 0000 ................
So looks like a lot of panel types have the timing the BIOS used. I pushed a hack to git://github.com/vsyrjala/linux.git panel_type_modparam so pleas grab that and try passing i915.vbt_sdvo_panel_type=0 onto the kernel command line. That should at least tell us if using better timings would fix the display problem. After that we still have the problem of figuring out how we're supposed to deduce the correct panel type automagically.
Oh and could you also try git://github.com/vsyrjala/linux.git acpi_edid on the off chance that the machine might have an actual EDID hiding inside the firmware...
(In reply to Ville Syrjala from comment #24) > So looks like a lot of panel types have the timing the BIOS used. I pushed a > hack to > git://github.com/vsyrjala/linux.git panel_type_modparam > so pleas grab that and try passing i915.vbt_sdvo_panel_type=0 onto the > kernel command line. That should at least tell us if using better timings > would fix the display problem. > > After that we still have the problem of figuring out how we're supposed to > deduce the correct panel type automagically. Thank you so much, your workaround works! This is amazing, thanks for the quick responses and quick patch! I will test the acpi_edid branch in a bit.
(In reply to Ville Syrjala from comment #25) > Oh and could you also try > git://github.com/vsyrjala/linux.git acpi_edid > on the off chance that the machine might have an actual EDID hiding inside > the firmware... this doesn't work, i get a black screen with this, or do i need to use any kernel options?
(In reply to r.r.arends from comment #27) > (In reply to Ville Syrjala from comment #25) > > Oh and could you also try > > git://github.com/vsyrjala/linux.git acpi_edid > > on the off chance that the machine might have an actual EDID hiding inside > > the firmware... > > this doesn't work, i get a black screen with this, or do i need to use any > kernel options? Nope. It should just work (tm) if the system supports the _DDC ACPI method. Well, assuming I've implemented it correctly. Can't actually be sure of that since I've not yet found a machine where it works.
(In reply to Ville Syrjala from comment #28) > (In reply to r.r.arends from comment #27) > > (In reply to Ville Syrjala from comment #25) > > > Oh and could you also try > > > git://github.com/vsyrjala/linux.git acpi_edid > > > on the off chance that the machine might have an actual EDID hiding inside > > > the firmware... > > > > this doesn't work, i get a black screen with this, or do i need to use any > > kernel options? > > Nope. It should just work (tm) if the system supports the _DDC ACPI method. > Well, assuming I've implemented it correctly. Can't actually be sure of that > since I've not yet found a machine where it works. Oke uhm, anything i can debug for you? Although maybe the acpi method just doesn't work on this model... I'm already very happy that i know have a working option with i915.vbt_sdvo_panel_type=0 though, again many many many thanks!
Hmm. So the answer I got from some Windows folks is that they always expect to have an EDID for eDP panels. That would mean that the real problem is somewhere in out i2c-over-aux handling since we clearly are unable to read the EDID from the panel. Please try this branch and attach the resulting dmesg (w/ drm.debug=0xe): git://github.com/vsyrjala/linux.git dp_i2c_stuff
Hmm. I guess one weird possibility would be that the EDID would be at some alternate address. I can't recall if that's allowed by the spec, but IIRC in the distant past there were a few addresses that could house the EDID. Please run something like this as root so we can probe the entire i2c address range: modprobe i2c-dev ; i2cdetect `grep DPDDC-A /sys/class/i2c-dev/*/name | cut -d '/' -f 5 | cut -d '-' -f 2`
Created attachment 127091 [details] dmesg drm.debug=0xe from kernel dp_i2c_stuff dmesg drm.debug=0xe from kernel dp_i2c_stuff
(In reply to Ville Syrjala from comment #31) > Hmm. I guess one weird possibility would be that the EDID would be at some > alternate address. I can't recall if that's allowed by the spec, but IIRC in > the distant past there were a few addresses that could house the EDID. > > Please run something like this as root so we can probe the entire i2c > address range: > modprobe i2c-dev ; i2cdetect `grep DPDDC-A /sys/class/i2c-dev/*/name | cut > -d '/' -f 5 | cut -d '-' -f 2` root@fuckeduphp:~# modprobe i2c-dev ; i2cdetect `grep DPDDC-A /sys/class/i2c-dev/*/name | cut -d '/' -f 5 | cut -d '-' -f 2` WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 -- -- -- -- 35 -- -- 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77
(In reply to r.r.arends from comment #32) > Created attachment 127091 [details] > dmesg drm.debug=0xe from kernel dp_i2c_stuff > > dmesg drm.debug=0xe from kernel dp_i2c_stuff [ 5.576119] [drm:drm_dp_i2c_do_msg [drm_kms_helper]] I2C nack (result=1, size=1) [ 5.576283] [drm:drm_dp_i2c_do_msg [drm_kms_helper]] I2C nack (result=0, size=0) still nacks :(
(In reply to r.r.arends from comment #33) > (In reply to Ville Syrjala from comment #31) > > Hmm. I guess one weird possibility would be that the EDID would be at some > > alternate address. I can't recall if that's allowed by the spec, but IIRC in > > the distant past there were a few addresses that could house the EDID. > > > > Please run something like this as root so we can probe the entire i2c > > address range: > > modprobe i2c-dev ; i2cdetect `grep DPDDC-A /sys/class/i2c-dev/*/name | cut > > -d '/' -f 5 | cut -d '-' -f 2` > > root@fuckeduphp:~# modprobe i2c-dev ; i2cdetect `grep DPDDC-A > /sys/class/i2c-dev/*/name | cut -d '/' -f 5 | cut -d '-' -f 2` > WARNING! This program can confuse your I2C bus, cause data loss and worse! > I will probe file /dev/i2c-3. > I will probe address range 0x03-0x77. > Continue? [Y/n] Y > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f > 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f > 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > 30: 30 -- -- -- -- 35 -- -- 38 39 3a 3b 3c 3d 3e 3f > 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f > 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- > 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f > 70: 70 71 72 73 74 75 76 77 That... looks totally crazy. So it seems to be acking almost all addresses, except the ones we might actually care about.
hmm, do you want me to try the same thing on the non-touch model which works?
(In reply to r.r.arends from comment #36) > hmm, do you want me to try the same thing on the non-touch model which works? Can't hurt. At least it will tell us is the panel on it behaves differently.
I pushed another random idea [1] to the dp_i2c_stuff branch. Please test again with that. [1] commit 63899aa66e081e3dcb9a06f9808c55b6f9a75c1d Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Oct 7 15:11:09 2016 +0300 drm/dp: Try to read the entire edid block if the single byte probe fails
(In reply to Ville Syrjala from comment #38) > I pushed another random idea [1] to the dp_i2c_stuff branch. Please test > again with that. > > [1] > commit 63899aa66e081e3dcb9a06f9808c55b6f9a75c1d > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > Date: Fri Oct 7 15:11:09 2016 +0300 > > drm/dp: Try to read the entire edid block if the single byte probe fails No luck :( get the split screen
(In reply to Ville Syrjala from comment #37) > (In reply to r.r.arends from comment #36) > > hmm, do you want me to try the same thing on the non-touch model which works? > > Can't hurt. At least it will tell us is the panel on it behaves differently. By the way, on the non-touch version i get the exact same output
Another crazy idea pushed to dp_i2c_stuff: drm/edid: Ignore NACK for the DDC offset write drm/dp: Implememnt support for I2C_IGNORE_NAK in the i2c-over-aux code Please attach the dmesg again w/ drm.debug=0xe
Created attachment 127106 [details] dmesg_i2c_ignore_nak with drm.debug=0xe
(In reply to r.r.arends from comment #42) > Created attachment 127106 [details] > dmesg_i2c_ignore_nak with drm.debug=0xe That didn't come out as I expected. Looks like I fumbled the patch a bit. I pushed an additonal fix [1], please re-test. [1] drm/dp: Fix IGNORE_NAK
Created attachment 127167 [details] dmesg_fix_ignore_nak sorry for the delay... dmesg_fix_ignore_nak
(In reply to r.r.arends from comment #44) > Created attachment 127167 [details] > dmesg_fix_ignore_nak > > sorry for the delay... dmesg_fix_ignore_nak Yeah still nack all over. No good :( I pushed another random idea [1], though I'm not really expecting much from this one TBH. [1] drm/i915/skl: Implement DP Aux Mutex framework
Created attachment 127221 [details] attachment-2363-0.html Compiling, let you know in a bit From: bugzilla-daemon@freedesktop.org [mailto:bugzilla-daemon@freedesktop.org] Sent: dinsdag 11 oktober 2016 18:31 To: Arends, R.R. (René) <r.r.arends@hr.nl> Subject: [Bug 97822] Split screen/display corruption issue on HP EliteOne 800 G2 23-in Touch AIO Comment # 45<https://bugs.freedesktop.org/show_bug.cgi?id=97822#c45> on bug 97822<https://bugs.freedesktop.org/show_bug.cgi?id=97822> from Ville Syrjala<mailto:ville.syrjala@linux.intel.com> (In reply to r.r.arends from comment #44<show_bug.cgi?id=97822#c44>) > Created attachment 127167 [details]<attachment.cgi?id=127167> [details]<attachment.cgi?id=127167&action=edit> > dmesg_fix_ignore_nak > > sorry for the delay... dmesg_fix_ignore_nak Yeah still nack all over. No good :( I pushed another random idea [1], though I'm not really expecting much from this one TBH. [1] drm/i915/skl: Implement DP Aux Mutex framework ________________________________ You are receiving this mail because: * You are on the CC list for the bug.
Created attachment 127223 [details] dmesg_Implement_DP_Aux_Mutex_framework dmesg_Implement_DP_Aux_Mutex_framework
Can access this model at the moment. Vanilla 4.8.11 fails the very same way. 4.8.11 + cherry-picked 8f6bd6297a9c62f03aa3ff3855ff4a159fddd55a from git://github.com/vsyrjala/linux.git (as per comment 24) with i915.vbt_sdvo_panel_type=0 works fine on this panel indeed. Jani, any more ideas to test or info to gather/provide for a proper fix?
Hi All, I just stumbled upon this as I'm having the same issue with the screen, however I have the "Non-touch" version of the hardware. Still a relative Linux newbie so I am reading all posts and trying to get my head around them. Has anyone got any updates as last comment was a month ago? Appreciate for any info anyone can provide on this. Rob
(In reply to Rob from comment #49) > Still a relative Linux newbie so I am reading all posts and trying to get my > head around them. You might concentrate on comment 24. > Has anyone got any updates as last comment was a month ago? I've just released ALT starterkits with a few flavours (namely gnome3/systemd, icewm/sysvinit, and rescue) having a kernel with this hack applied, so you can at least pass "i915.vbt_sdvo_panel_type=0" to the livecd kernel and boot (should one choose to install such an image, editing /etc/sysconfig/grub2 and running update-grub would become requisite): http://en.altlinux.org/starterkits
We implemented the same workaround 'hack' from #24 in our in house kiosk netboot image, hopefully a permanent solution will be found and reach mainline some day.
Ok thanks both. I was looking at comment 24 but couldn't get to:git://github.com/vsyrjala/linux.git acpi_edid Sorry if i'm being stupid.... Regards
I couldn't test this at the moment, but something like this: git clone git://github.com/vsyrjala/linux.git cd linux git checkout acpi_edid and then compile the kernel.... (In reply to Rob from comment #52) > Ok thanks both. I was looking at comment 24 but couldn't get > to:git://github.com/vsyrjala/linux.git acpi_edid > Sorry if i'm being stupid.... > Regards
Created attachment 128434 [details] workaround patch we used I can't seem to find the right commit anymore, but i just looked up the patch we used that worked for us.
Created attachment 128436 [details] [review] [PATCH] drm/i915/hack: Abuse i915.vbt_sdvo_panel_type also for LVDS/eDP/DSI Here's that 4.8 commit (tried backporting it to 4.4 but failed being no real kernel developer, heh).
So sorry guys - I thought git://github.com/vsyrjala/linux.git panel_type_modparam was a link and was trying to resolve it in my browser! Anyway I now have the kernel compiled. Not entirely sure what to do with: "[PATCH] drm/i915/hack: Abuse i915.vbt_sdvo_panel_type also for LVDS/eDP/DSI" or "i915.vbt_sdvo_panel_type=0"
That commit was extracted from "panel_type_modparam" branch of git repository you referenced above (so if you built the code from that branch you don't need to apply the patch anyore); still needs a kernel cmdline parameter to make any difference though, see comment 24. In the meanwhile, I second Rene's comment 51 :)
Hello all, we have same problem and I have found following thread on 01.org (intel open source): https://01.org/linuxgraphics/forum/graphics-installer-discussions/it-driver-problem Dorian Petit reports the same problem, but he has the problem on 50% of PCs. With HP support he has found that the problem is only on PCs with LG panels. PCs with Samsung panel work correctly. I have tried now to read EDID to find out what panel do we have, but the build-in panel/monitor on eDP-1 reports no EDID (neither xrandr --prop nor get-edid shows any edid). External monitor on DP-1 reports his EDID correctly. Does anyone any idea how could I found out the panel manufacturer? Thank you for answers. BTW: Our monitors have label Bang&Olufsen - is this LG monitor or something else? For G1 model, there are items "Backlight cable for use with Samsung display panels" and "Backlight cable for use with LG and BOE display panels" in spare parts list. Is there maybe the same for G2? Is the BOE display panel the Bang&Olufsen? That would mean there are three different possible panels - Samsung, LG and BOE. LG and BOE have this problem and Samsung has no problem. I hope this information help you too. Regards, Robert Wolf.
One more note. As workaround we use VESA mode (we have disabled KMS and installed VESA Xorg driver), but the default timings are so low, so X can start only in 1024x768. I have created /etc/X11/xorg.conf.d/monitor.conf file with content: Section "Screen" Identifier "Default Screen Section" Monitor "default monitor" EndSection Section "Monitor" Identifier "default monitor" HorizSync 70000 Option "MaxClock" "143978000" VertRefresh 60 EndSection and now X can start in 1920x1080 in VESA mode. But we cannot activate DP-1 on external monitor with xrandr in this VESA mode. Probably with BIOS 2.10 the DP-1 was activated on boot, but with 2.18 is not. And we can now downgrade BIOS only to 2.17, older BIOS "is denied by system policy". Regards, Robert Wolf.
(In reply to Robert Wolf from comment #58) > BTW: Our monitors have label Bang&Olufsen Should relate to audio (speakers).
Thanks for posting this Robert. I am going to see if I can get our test pc replaced with one with a Samsung panel and then if that works, see if I can get all future ones we order with the Samsung panel.
We are gonna try the same, my colleague will contact HP support tomorrow. :) We have about 15 of those broken ones.... Currently working correct and in production with the kernel workaround patch from on of the above comments though.
Hello all, I have big news for all of you with the same problem. We have opened ticket by HP and they wanted from us to install Windows and run some diagnostic tool. My colleague did that and sent the diag result to HP. HP answered to update some drivers and BIOS (we have downgraded BIOS to try if that helps) and they have noticed too, that the windows has been installed with Legacy Support Enabled. They have told us to disabled Legacy Support and reinstall Windows. We have opened this ticket because of other problem. Because I have configured Xorg to use VESA driver, I cannot use xrandr. But we need to switch external output with duplicated image. This was not possible. As soon as colleague has disabled Legacy Support to install Windows correctly, the external monitor has shown the duplicated image (as expected). I have installed my linux image a few years ago for older PCs with BIOS, therefore I was still using old boot method - PXEboot and grub from MBR from disk. Now I have prepared (U)EFI netboot, because of disabled Legacy Support. As we wanted to test if the duplicated image on external monitor works with UEFI boot, we have started Ubuntu 16.10 from USB flash as UEFI. We have not disabled i915 KMS and we expected that the image will be shown again only on upper half. But the image was displayed on whole screen! We have enabled Legacy Support and the image was again only on upper half. Then again Legacy Support disabled and image was again OK. So we have coincidentally found the BUG in this BIOS - if the Legacy Support is enabled, (1) image is not by default cloned to connected external output, (2) with standard Linux i915 KMS and xorg-intel video drivers the image is squeezed to upper half of screen on internal output, even if the resolution is correct. If Legacy Support is disabled, everything works fine - image is duplicated to external monitor right after switch on (even the HP logo is duplicated) and image is displayed correctly on internal output even with i915 KMS and xorg intel driver. Could some please verify our findings and post the results? Thank you very much. We will test other two PCs today afternoon, this time without Windows and any Windows update drivers and/or firmwares. We keep only BIOS on the newest version 2.18. I have made a few images to describe this problem to HP Support too. If I could not attach images here, you can find them on Google Drive https://drive.google.com/drive/folders/0B5Ft-0qGPraicHZDVWw3WDdkTEk?usp=sharing Regards, Robert Wolf.
Created attachment 129023 [details] External output in BIOS does not work if Legacy Support enabled
Created attachment 129024 [details] Linux console squeezed to upper half if Legacy Support enabled
Created attachment 129025 [details] Xorg image squeezed to upper half if Legacy Support enabled
Created attachment 129026 [details] External output in BIOS works if Legacy Support disabled
Created attachment 129027 [details] Linux console on whole screen if Legacy Support disabled
Created attachment 129028 [details] Xorg image on whole screen if Legacy Support disabled
Hi Robert, Thanks for your updates, appreciate it! Anyway I have just disabled legacy boot and now I can confirm that I get the display on the whole screen etc. I've not installed or changed anything in Windows on the pc or changed the bios version. I'll have a look in a minute to confirm bios version
Mine was on 2.06
(In reply to Robert Wolf from comment #63) > I have installed my linux image a few years ago for older PCs with BIOS, > therefore I was still using old boot method - PXEboot and grub from MBR from > disk. Now I have prepared (U)EFI netboot, because of disabled Legacy > Support. As we wanted to test if the duplicated image on external monitor > works with UEFI boot, we have started Ubuntu 16.10 from USB flash as UEFI. > We have not disabled i915 KMS and we expected that the image will be shown > again only on upper half. But the image was displayed on whole screen! We > have enabled Legacy Support and the image was again only on upper half. Then > again Legacy Support disabled and image was again OK. So we have > coincidentally found the BUG in this BIOS - if the Legacy Support is > enabled, (1) image is not by default cloned to connected external output, > (2) with standard Linux i915 KMS and xorg-intel video drivers the image is > squeezed to upper half of screen on internal output, even if the resolution > is correct. If Legacy Support is disabled, everything works fine - image is > duplicated to external monitor right after switch on (even the HP logo is > duplicated) and image is displayed correctly on internal output even with > i915 KMS and xorg intel driver. This is not a surprising find. If the machine ships Windows with UEFI boot, that's likely the only combo that was ever tested.
(In reply to Jani Nikula from comment #72) > This is not a surprising find. If the machine ships Windows with UEFI boot, > that's likely the only combo that was ever tested. *** Hmmm, this PC was shipped with FreeDOS. I am not surprised now (HP tester: "It boots Windows with UEFI, so I pack it and we can sell it"), but I was surprised, when I was found the reason for this screen-problem:-)
(In reply to Rob from comment #70) > Hi Robert, Thanks for your updates, appreciate it! > Anyway I have just disabled legacy boot and now I can confirm that I get the > display on the whole screen etc. I've not installed or changed anything in > Windows on the pc or changed the bios version. I'll have a look in a minute > to confirm bios version *** Thank you for your confirmation. We have confirmed the solution "disabled Legacy Support" on other PC without Windows and updating any driver/firmware too. It is really Legacy Support, what makes the image problem. Even BIOS version does not matter. We had the problem just after buying this PC with default BIOS. Then we have updated BIOS to version 2.10 (I must say the BIOS update over net works great - no stupid usb, cd, windows execs). In the first Jan week we have upgraded BIOS to 2.18. Still the same problem. We will report this problem to HP and maybe they provide fix for this bug in new BIOS (or whatever) version. But now we are happy, our problems are solved. Regards, Robert Wolf.
(In reply to Robert Wolf from comment #74) > But now we are happy, our problems are solved. With that, I'm closing the bug. Thanks for the report, please reopen if you believe there are issues in the driver, or file new bugs for any other issues.
(In reply to Robert Wolf from comment #63) > If Legacy Support is disabled, everything works fine It's under F10 > BIOS Setup > Advanced > Secure Boot Configuration, right?
(In reply to Michael Shigorin from comment #76) > (In reply to Robert Wolf from comment #63) > > If Legacy Support is disabled, everything works fine > It's under F10 > BIOS Setup > Advanced > Secure Boot Configuration, right? *** Yes, exactly. We use "Legacy Support Disabled and Secure Boot Disabled". Does it help for you too or not? Important is to have Legacy Support Disabled. It is not enough just boot from UEFI and have Legacy Support enabled - it must be disabled (and then the only way to boot is UEFI). Regards, Robert Wolf.
Hello all, We have received response from HP support (included below) to this problem. Translated to english for those who does not understand german: ================================================== Dear Mr. NNNNNN, thank you for your request at our Support. Below I have included the link which could help you to troubleshoot. HP Elite 800 G2 Series Buisness Desktop - Quick Specs: http://www8.hp.com/h20195/v2/GetPDF.aspx/c04818335.pdf You can find the list of supported operating systems on the page 26. ... ================================================== And the page 26 shows: ================================================== OPERATING SYSTEMS Preinstalled Windows 10 Pro 64* Windows 10 Home 64* Windows 8.1 Pro 64** Windows 8.1 64** Windows 7 Professional 64 (available through downgrade rights from Windows 10 Pro)*** Windows 7 Professional 32 (available through downgrade rights from Windows 10 Pro)*** Windows 7 Professional 64** Windows 7 Professional 32** Pre-installed (Other) FreeDOS 2.0 Web-supported Windows 10 Pro 64 Windows 10 Home 64 Windows 8.1 Pro 64 Windows 8.1 64 Windows 7 Professional 64 Windows 7 Professional 32 Windows 10 Enterprise 64 Windows 8.1 Enterprise 64 Windows 7 Enterprise 64 Windows 7 Enterprise 32 ================================================== So I think HP support will not make any progress, until someone finds some bug on Windows caused by this BIOS issue. But even then, they tell you first disable Legacy Support so all problems disappears. Instead "Legacy Support", there should be written "System with bugs":-) So next time, we will sure ask for Linux support before buying any device. Otherwise I will refuse install there Linux. Just warning for other Linux fans. Regards, Robert Wolf. ================================================== Von: HPSupport_Global <wfm@g9u1421c.houston.hp.com> An: <nnnnnnnnnnnnn@ddddddddd> Gesendet: 19.01.2017 16:45 Betreff: <CASE:4781361553> Sehr geehrter Herr Natter, vielen Dank für Ihre Anfrage bei unserem Support. Hiermit geben wir Ihnen einen Link an, der Ihnen bei der Problemlösung helfen sollte: HP Elite 800 G2 Series Buisness Desktop - Quick Specs: http://www8.hp.com/h20195/v2/GetPDF.aspx/c04818335.pdf Unterstützte betriebsysteme finden Sie auf die Seite 26. Bei Fragen erreichen Sie uns telefonisch unter den Hotline-Nummern in der Fussnote oder schriftlich, indem Sie diese E-Mail beantworten. Um auf diese E-Mail zu antworten klicken Sie einfach auf die Antwortfunktion Ihres E-Mail Programms. Bitte ändern Sie nichts an der Adresse und lassen am Betreff nur das orginale Thema (FW:, AW: bitte löschen). Wir hoffen, Ihnen mit diesen Auskünften geholfen zu haben und verbleiben mit freundlichen Grüßen, Anna Pasztor HP Computing Support ==================================================
(In reply to Robert Wolf from comment #78) > So I think HP support will not make any progress, until someone finds some > bug on Windows caused by this BIOS issue. But even then, they tell you first > disable Legacy Support so all problems disappears. Instead "Legacy Support", > there should be written "System with bugs":-) Again, completely unsurprising. Did you ask if they actually support "Legacy Support" with any operating system? If not, there really is no point in trying to use it with Linux. > So next time, we will sure ask for Linux support before buying any device. > Otherwise I will refuse install there Linux. They way OEMs seem to operate, if they supported Linux, I think they would have listed a specific version of a specific distro. Would that have helped you?
(In reply to Robert Wolf from comment #77) > > It's under F10 > BIOS Setup > Advanced > Secure Boot Configuration, right? > *** Yes, exactly. We use "Legacy Support Disabled and Secure Boot Disabled". > Does it help for you too or not? Finally got my hands on 800G2EONA (G4400) again -- yes it does!
Created attachment 129790 [details] /sys/kernel/debug/dri/0/i915_vbt for bios and uefi mode
Comment on attachment 129790 [details] /sys/kernel/debug/dri/0/i915_vbt for bios and uefi mode I have an HP EliteOne 800 G2 23-in Non-Touch All-in-One PC which also has the Bang & Olufsen logo at the top left of the screen. I have the exact same problem as described with the graphics. When I switch from BIOS mode (default) on the computer to UEFI mode the graphics started to work as expected. I am now running Ubuntu 16.04.2 LTS with kernel 4.8.0-36-generic. In case anyone would like to try figure out why the graphic is not working in BIOS mode I got the suggestion of providing /sys/kernel/debug/dri/0/i915_vbt for both modes so I did "cat /sys/kernel/debug/dri/0/i915_vbt > /tmp/i915_vbt-mode" and have attached tar.gz of those two files. Best regards, Eric
Created attachment 129793 [details] diff between VBT dumps for BIOS and UEFI boots The BIOS provides us with a different Video BIOS Table (VBT) depending on legacy vs. UEFI boot. There are differences in the panel type (really just an index in the tables), device type, timings. It's ridiculous that there are differences to begin with, as if the display hardware required different handling depending on the boot mode. I'm not sure which change (if any) explain the change in behaviour.
Now here's something to try, not for the faint of heart! 1) Grab /sys/kernel/debug/dri/0/i915_vbt from the working boot mode (UEFI), place it under /lib/firmware 2) Grab kernel from drm-tip branch of https://cgit.freedesktop.org/drm-tip 3) Apply all patches from https://patchwork.freedesktop.org/series/20016/ on top 4) Boot in the failing boot mode (legacy), make sure it still fails ;) 5) Add module parameter i915.vbt_firmware=i915_vbt, cross fingers, and boot in the legacy mode, see what happens Disclaimer, the last patch hasn't been tested, I don't think it'll eat your kittens, but no warranties either. ;)
Hi, we have a case open with HP to see if they will fix the BIOS timing table. Will report back if they do. Same issue occurs on the HP ProOne 600 G2 by the way. Did also come across this: https://lab.nexedi.cn/kirr/linux/commit/5a1e5b6c460dccfd189c7e962281c8cce75da728 I'm not sure if it's relevant. Mostly this part might apply: Judging by comments in the BIOS, if the SDVO LVDS option h40 is enabled, then we are supposed to query the real panel type via Int15. We don't do this and so for the Sony Vaio VGC-JS210J which has otherwise default values, we choose the wrong mode.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.