With commit 484c66c400daa76bd6840f195e8effa9d39dfb3c, the following change (among others) was introduced in the file drivers/gpu/drm/via/via_hdmi.c: @@ -432,8 +433,8 @@ via_ddc_read_bytes_by_hdmi(struct drm_via_private *dev_priv, unsigned char *bloc if (status) status = via_check_hdmi_i2c_status(dev_priv, 0x0008, true); - /* Offset - always read at start of buffer */ - temp = 0; + /* Offset */ + temp = offset; temp <<= 16; temp |= VIA_READ(0xC0B4) & 0xFF00FFFF; VIA_WRITE(0xC0B4, temp); This breaks KMS on my VX900, the (1920x1080 HDMI) display goes blank/into standby mode immediately after the module was loaded (from initrd). Changing the line temp = offset; back to temp = 0; fixes the problem (but of course this renders the offset parameter of the function useless). My guess is that line 525 in the same file needs to be changed from offset = (valid_extensions + 1) * EDID_LENGTH; to offset = (valid_extensions) * EDID_LENGTH; I haven't tested this, though.
That commit fixed most HDMI monitors. The first EDID block contains the standard data for the monitor resolution and the later blocks have CEA additional data for HDMI type monitors. Before the commit that is causing you problems only the first block was ever used. Can you add to kernel boot parameters drm.debug=225 and send me your dmesg output. Also can you collect your edid and send it to me. cat /sys/class/drm/card0-HDMI-A-1/edid > edid.data This way I can simulate the problem.
Created attachment 84251 [details] cat /sys/class/drm/card0-DVI-D-1/edid > edid.data Sorry that I didn't answer earlier, but somehow I must have overlooked the notification mail about your response. :/ /sys/class/drm/card0-HDMI-A-1/edid is empty on my machine (0 bytes), but /sys/class/drm/card0-DVI-D-1/edid contains something that looks more or less legit (at least it contains my display's model number), so I've attached that one. /sys/class/drm/card0-VGA-1/edid is obviously empty (0byte) as well because the ZBOX doesn't have a VGA port. I've done this EDID dump using a kernel *with* my patch so I can see what I do on the machine. Please tell me if you need an EDID dump with an unpatched drm-openchrome kernel. I'd have to recompile it, which takes several hours, and then log into the machine via SSH with my smartphone or something, so I prefer asking *before* taking *that* effort. :)
Created attachment 84325 [details] dmesg.txt Finally got around to do reboot and add "drm.debug=225" to the cmdline. I've xxxed out a few things like MAC addresses and so on, but they shouldn't matter anyhow.
It should have been drm.debug=255 for full verbosity. There is no EDID in your dmesg, I guess changing from 225 to 255 should help with this.
Created attachment 84367 [details] dmesg (with drm.debug=255 on the cmdline) Et voilà :)
Can you please retry with latest git master ? James fixed some bug and said this should fix the issue you're seeing.
Nope, still needs my patch. Without my patch, the screen switches into standby mode immediately after loading the via module.
(the "nope" obviously means "still doesn't work" - I've of course tried with the latest git version 6a605817398ae7584f8afbd273ded9ec3f86d036)
Ok, thanks for testing. Can you provide the dmesg from the unpatched kernel with drm.debug=255 please ?
Created attachment 84722 [details] via_hdmi.c (patched to make HDMI work on VX900 and thrown in a few DRM_INFO() calls to ease debugging This is via_hdmi.c with my patch added (see line 435) to make HDMI work. I've also thrown in some DRM_INFO() calls to ease debugging. Interestingly, this patch makes the HDMI port be treated as a DVI port - at least as far as /sys/class/drm/card0-*/edid is concerned. Please do also note that the EDID seems to change depending on my patch being applied or not. With my patch, I get a different EDID record from /sys/class/drm/card0-DVI-D-1/edid than I get without the patch from /sys/class/drm/card0-HDMI-A-1/edid. The screen also works with my patch applied, as described in the bug report, so I had to use ssh to get the dmesg and the EDID while running the unpatched module (see following attachments).
Created attachment 84723 [details] dmesg (with drm.debug=255) while running the "unpatched" module (with just a few DRM_INFO() calls added) Lines containing the string "[drm] hardfalcon-debug:" come from the DRM_INFO() calls I've added in via_hdmi.c. Line 435 was however *not* patched for this module version, so you can safely regard is as "vanilla".
Created attachment 84725 [details] dmesg (with drm.debug=255) while running the "patched" module (with a few DRM_INFO() calls added *AND* line 435 patched) This is a dmesg done while running the module compiled *with* my patch, i.e. via_hdmi.c being the version from attachment #8422 [details] [review]. Once again, all lines containing the string "[drm] hardfalcon-debug:" come from the DRM_INFO() calls I've added in via_hdmi.c.
Created attachment 84727 [details] /sys/class/drm/card0-HDMI-A-1/edid (while running "unpatched" module) This EDID comes from the same session as attachment #84723 [details]. Both /sys/class/drm/card0-DVI-D-1/edid and /sys/class/drm/card0-VGA-1/edid where empty (0 bytes long).
Created attachment 84728 [details] /sys/class/drm/card0-DVI-D-1/edid (while running "patched" module) This EDID comes from the same session as attachment #84725 [details]. Both /sys/class/drm/card0-HDMI-A-1/edid and /sys/class/drm/card0-VGA-1/edid where empty (0 bytes long).
Created attachment 84729 [details] /sys/class/drm/card0-DVI-D-1/edid (while running "patched" module) Resubmitted attachment #84728 [details], this time with the correct MIME type. This EDID comes from the same session as attachment #84725 [details]. Both /sys/class/drm/card0-HDMI-A-1/edid and /sys/class/drm/card0-VGA-1/edid where empty (0 bytes long).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/10.
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.