drm fails to accept edid version 2.4

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/

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.

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.

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.

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

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

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.

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.

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.

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).

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

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

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?

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

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.

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

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.

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

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

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

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

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.

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...

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?

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?

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...

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

and attach the edid there

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

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

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