drm fails to accept edid version 2.4

[Rich Drewes]

Booting very new laptop hardware (ASUS Zenbook UX431FA) from 18.04 usb install (also 18.10, also 19.04 daily) leads to black screen. Adding "nomodeset" to kernel boot parameter gives 800x600 video only and permits installing OS to disk. Applying updates and hardware enablement packages does not solve problem: the system will still only boot with nomodeset kernel option, and X is limited to using fbdev module at 800x600 resolution.

The "modesetting" driver appears to be loaded and then unloaded during X startup. Trying to force intel module from xserver-xorg-video-intel by setting up 20-intel.conf file in /usr/share/X11/xorg.conf.d/ does not help.

The PCI id for the graphics device appears to be 3ea0 and the place where that might be relevant is the i915 module.

This problem occurs with every other Linux release I have tried including Fedora 29, Elementary OS latest, Mint 19.1, Manjaro latest. The one open source OS that I have found where it might be fixed is DragonFlyBSD (see https://bugs.dragonflybsd.org/issues/3167). I have verified that the patch referenced in that bug report does make DragonFlyBSD boot past the video problem which I think is the same problem I experience with every Linux OS I have tried including Ubuntu.

guest@guest-ZenBook-UX431FA:~$ lsb_release -rd
Description: Ubuntu 18.04.2 LTS
Release: 18.04

guest@guest-ZenBook-UX431FA:~$ dpkg -l | grep hwe | egrep "linux|fbdev"
ii linux-generic-hwe-18.04 4.18.0.16.66 amd64 Complete Generic Linux kernel and headers
ii linux-headers-generic-hwe-18.04 4.18.0.16.66 amd64 Generic Linux kernel headers
ii linux-image-generic-hwe-18.04 4.18.0.16.66 amd64 Generic Linux kernel image
ii linux-signed-generic-hwe-18.04 4.18.0.16.66 amd64 Complete Signed Generic Linux kernel and headers (dummy transitional package)
ii xserver-xorg-video-fbdev-hwe-18.04 1:0.5.0-1ubuntu1~18.04.1 amd64 X.Org X server -- fbdev display driver

Expected result: Video at 1920x1080
Actual result: Video limited to 800x600

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-16-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 24 10:36:51 2019
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
 Intel Corporation Device [8086:3ea0] (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:17d1]
InstallationDate: Installed on 2019-03-24 (0 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
MachineType: ASUSTeK COMPUTER INC. ZenBook UX431FA
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-16-generic root=UUID=e6ae272a-49f0-491b-99b6-2a3785a7679e ro nomodeset vt.handoff=1
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/14/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX431FA.205
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX431FA
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX431FA.205:bd12/14/2018:svnASUSTeKCOMPUTERINC.:pnZenBookUX431FA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX431FA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.family: ZenBook
dmi.product.name: ZenBook UX431FA
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.95-1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core N/A
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

[Kai-Heng Feng (kaihengfeng)]

Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v5.1-rc2 kernel [0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed”, and attach dmesg.

Thanks in advance.

[0] https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1-rc2/

[Rich Drewes (drewes)]

Thanks for your help.

Unfortunately, no change after installing v5.1-rc2: Still stuck in 800x600 after booting with nomodeset kernel option.

Added kernel-bug-exists-upstream and marked confirmed.

dmesg output attached.

[Rich Drewes (drewes)]

Also: booting without nomodeset kernel option for v5.1-rc2 kernel leads to black screen, just as before. At that point the system cannot even be switched to text console with ctrl-alt-Fn.

[Rich Drewes (drewes)]

Based on a lead from an Arch Linux blog post, I tried adding the i915 module to the initramfs. This could possibly lead to earlier initialization of the graphics device and it also seems consistent with the DragonFlyBSD "probe early" patch I linked to in my initial bug report which may have fixed the graphics problem in DragonFlyBSD (I cannot tell for certain if the graphics problem was fixed there due to another, unrelated problem, but the fix definitely allowed the boot to proceed further and the text did seem to switch to full screen resolution).

The update-initramfs operation failed on the v5.1-rc2 kernel because of two missing firmware files.

The update-initramfs operation succeeded on the 4.x kernels I had installed, one of which is the hwe kernel (I believe). I verified the presence of the i915 module in the initramfs for those kernels using lsinitramfs. Unfortunately, booting with i915 in the initramfs on the 4.x kernels and without nomodeset did not solve the problem.

[Timo Aaltonen (tjaalton)]

That pci-id should be known by all components of the stack on 19.04, so it should work with X just fine. If it doesn't, it's likely a bug in the kernel module. You could try with a mainline build of the drm-intel-next branch:

https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/

install linux-image-unsigned and linux-modules for amd64, then boot without nomodeset

[Timo Aaltonen (tjaalton)]

note that having 800x600 with nomodeset is perfectly normal, and expected...

[Rich Drewes (drewes)]

I installed kernel and modules and headers from https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ and rebooted without nomodeset option. Same behavior: after the "loading initramfs" message the screen blanks and never comes back.

[Rich Drewes (drewes)]

Just in case my addition of i915 to initramfs was causing a problem with drm-intel-next, I removed i915 from initramfs and repeated the test. The result was the same, no video after a certain point in the boot process with nomodeset using the drm-intel-next kernel as in #8.

[Rich Drewes (drewes)]

I tried booting 4.18.0-16-generic (which i believe is the hwe kernel) with kernel option drm.debug=0xff. When the system came up of course it had no video but I could ssh in and grab the dmesg output, which is attached to this message. dmesg had many drm-related debugging messages and i915-related messages, but none of it was particularly helpful to me yet.

[Rich Drewes (drewes)]

Is it known whether any machines with Intel Graphics 620 with pci id 0x3ea0 have functioning graphics with any version of Ubuntu?

This is relatively new hardware, but it seems unlikely that I am the only one in the world who has tried this combination, and if other people with different machines with the same 0x3ea0 pci id do have working graphics then that would suggest that the problem is some quirk of my particular ASUS UX431FA (perhaps some initialization timing quirk or hardware/design bug that is worked-around for the Windows 10 installation that came with the system).

[Rich Drewes (drewes)]

Progress! Based on information in dmesg, pasted in at the end of this message, I thought maybe the graphics device was found OK but the laptop was trying to drive an external monitor instead of the onboard display. Sure enough, when I boot without nomodeset option and with an external HDMI monitor attached the system does display to the external monitor with proper 1920x1080 resolution.

What does the "EDID is invalid:" message mean? Why is the driver/module expecting EDID major version 2 and getting 1? Does this have to do with the version of kbl_dmc firmware loaded to the graphics device?

----
guest@guest-ZenBook-UX431FA:~$ dmesg | egrep "drm|i915"
[ 3.196687] fb: switching to inteldrmfb from EFI VGA
[ 3.196881] [drm] Replacing VGA console driver
[ 3.210304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.210306] [drm] Driver supports precise vblank timestamp query.
[ 3.212814] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 3.214857] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[ 3.228865] [drm] EDID has major version 2, instead of 1
[ 3.236620] [drm] EDID has major version 2, instead of 1
[ 3.240878] [drm] EDID has major version 2, instead of 1
[ 3.244590] [drm] EDID has major version 2, instead of 1
[ 3.244595] i915 0000:00:02.0: eDP-1: EDID is invalid:
[ 3.244597] [drm] EDID has major version 2, instead of 1
[ 3.290049] [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0
[ 3.326674] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 3.356268] fbcon: inteldrmfb (fb0) is primary device
[ 4.724973] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

[Rich Drewes (drewes)]

Correction: last message should read "Why is the driver/module expecting EDID major version *1* and getting *2*?

[Rich Drewes (drewes)]

I think the problem is that the laptop's onboard LCD panel is reporting EDID data with version 2 and the i915 driver can only deal with version 1 at the moment. How can this be fixed?

[Rich Drewes (drewes)]

Below is the EDID information from the onboard panel. Why can't drm/i915 deal with it?

----
guest@guest-ZenBook-UX431FA:~$ sudo get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
1 potential busses found: 5
128-byte EDID successfully retrieved from i2c bus 5
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
 Identifier ""
 ModelName ""
 VendorName "NCP"
 # Monitor Manufactured week 1 of 2018
 # EDID version 2.4
 # Digital Display
 DisplaySize 310 170
 Gamma 2.20
 Option "DPMS" "false"
 Modeline "Mode 0" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
EndSection

[Rich Drewes (drewes)]

I was able to get the onboard LCD panel working, finally, as follows:

First I extracted the edid file from the LCD panel using get-edid and putting that in /lib/firmware/edid/ncp.bin, and then forcing the kernel to take that using the kernel boot option drm.edid_firmware=edid/ncp.bin. This failed, and dmesg said that the ncp.bin file had a "bad block 0". Possibly that means that nothing within Linux can accept edid version 2.4?

Then I grabbed a generic 1920x1080.bin edid file from edid-generator github and put that one in /lib/firmware/edid/ and used that one with drm.edid_firmware and the display worked for the first time!

I am still unsure why Linux couldn't accept the version 2.4 edid data from the LCD panel.

[Rafael Lopes Conde dos Reis (condereis)]

I was able to reproduce your solution, but now my external monitor is not recognized. Have you worked this out?

[Rich Drewes (drewes)]

I was able to display on an external monitor, or the internal monitor, but not both simultaneously. I didn't spend too much time trying to solve the problem and now the laptop is with a family member at another location. If you work on this issue and find a solution please post it here.

[JJJ (jeremy-fan)]

I'm able to display on both the internal monitor and an external one, by specifying the connector name in the edid firmware kernel boot option:

drm.edid_firmware=eDP-1:edid/1920x1080.bin

[Vojtěch Nezdara (vojthor)]

JJJ (jeremy-fan): Could you please describe exact walkthrough? I'm clearly doing something wrong as its not working with this...

[Rafael Lopes Conde dos Reis (condereis)]

JJJ, that worked, but now my audio does not work, any idea why?

[James Parris (parri0923)]

Does Linux plan of patching this issue since 18.04 is an LTS? Anyone know?

[Rich Drewes (drewes)]

I'm not sure this is a Linux problem. It may be that the panel is reporting bad EDID data. I haven't investigated enough to say for sure. In any case none of the more recent Linux releases fixed the problem in my tests. Also no other open source OSs were able to deal with the onboard LCD panel either. (That may have changed since I tested.)

If you were interested, you might be able to patch the firmware on the onboard panel to provide different EDID information. I looked into doing this and there are some tutorials out there. However, it's possible you could do something wrong and end up worse than you were before. If you learn something new, please post it here. In particular if you find some open source OS that can configure this display properly at full resolution without resorting to forcing EDID information please say so here.

[James Parris (parri0923)]

Our company just purchased these laptops and we could really use a fix for
them. Would you mind sharing the edid files you created to get the displays
functioning?

On Tue, Jul 9, 2019 at 17:50 Rich Drewes <email address hidden> wrote:

> I'm not sure this is a Linux problem. It may be that the panel is
> reporting bad EDID data. I haven't investigated enough to say for sure.
> In any case none of the more recent Linux releases fixed the problem in
> my tests. Also no other open source OSs were able to deal with the
> onboard LCD panel either. (That may have changed since I tested.)
>
> If you were interested, you might be able to patch the firmware on the
> onboard panel to provide different EDID information. I looked into doing
> this and there are some tutorials out there. However, it's possible you
> could do something wrong and end up worse than you were before. If you
> learn something new, please post it here. In particular if you find some
> open source OS that can configure this display properly at full
> resolution without resorting to forcing EDID information please say so
> here.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1821533
>
> Title:
> drm fails to accept edid version 2.4
>
> Status in linux-hwe package in Ubuntu:
> Confirmed
> Status in xorg-server package in Ubuntu:
> Confirmed
>
> Bug description:
> Booting very new laptop hardware (ASUS Zenbook UX431FA) from 18.04 usb
> install (also 18.10, also 19.04 daily) leads to black screen. Adding
> "nomodeset" to kernel boot parameter gives 800x600 video only and
> permits installing OS to disk. Applying updates and hardware
> enablement packages does not solve problem: the system will still only
> boot with nomodeset kernel option, and X is limited to using fbdev
> module at 800x600 resolution.
>
> The "modesetting" driver appears to be loaded and then unloaded during
> X startup. Trying to force intel module from xserver-xorg-video-intel
> by setting up 20-intel.conf file in /usr/share/X11/xorg.conf.d/ does
> not help.
>
> The PCI id for the graphics device appears to be 3ea0 and the place
> where that might be relevant is the i915 module.
>
> This problem occurs with every other Linux release I have tried
> including Fedora 29, Elementary OS latest, Mint 19.1, Manjaro latest.
> The one open source OS that I have found where it might be fixed is
> DragonFlyBSD (see https://bugs.dragonflybsd.org/issues/3167). I have
> verified that the patch referenced in that bug report does make
> DragonFlyBSD boot past the video problem which I think is the same
> problem I experience with every Linux OS I have tried including
> Ubuntu.
>
> guest@guest-ZenBook-UX431FA:~$ lsb_release -rd
> Description: Ubuntu 18.04.2 LTS
> Release: 18.04
>
> guest@guest-ZenBook-UX431FA:~$ dpkg -l | grep hwe | egrep "linux|fbdev"
> ii linux-generic-hwe-18.04 4.18.0.16.66
> amd64 Complete Generic Linux kernel and headers
> ii linux-headers-generic-hwe-18.04 4.18.0.16.66
> amd64 Gen...

[James Parris (parri0923)]

Our company just purchased these laptops and we could really use a fix for them. Would you mind sharing the edid files you created to get the displays functioning?

[Rich Drewes (drewes)]

As I wrote earlier, the EDID file I used came from edid-generator github and it is called 1920x1080.bin . You want me to google that for you?

[Jiri Krticka (krticka)]

I had the same problem and a new Fedora solved this for me. On the other hand, I am experiencing some problems with wifi now...

[Timo Aaltonen (tjaalton)]

if current drm-intel-next mainline build or 5.3rc doesn't work, then this bug should be filed upstream at bugs.freedesktop.org, DRI: drm/intel

[Timo Aaltonen (tjaalton)]

and attach the edid there

[Vit Hrachovy (flaska)]

Thanks for help with edid! Works for me both for internal LCD and external HDMI monitor on ASUS Zenbook UX431FA with 18.04.

[Xavier Le Cunff (johnberd)]

Thank you so much for your help.
I created a script for anyone facing the same issue.

https://github.com/JohnBerd/asus-blackscreen