Created attachment 140473 [details] Full dmesg log with drm.debug=0xe Hi, We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel i5-8250U), X530UN (intel i7-8550U) share the same problem, which is the HDMI connector status stays connected even the HDMI cable has been unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for checking the status while plug/unplug the HDMI, it shows "disconnected" before plug in HDMI cable, then switch to "connected" after plugin, and still stay "connected" after unplug. This would cause the audio output path cannot correctly switch from HDMI to internal speaker after unplugging the HDMI. I then try to verify with the latest kernel 4.18.0-rc3+, the bug still present. The full "dmesg" attached. The HDMI cable is plugged in at ~26th second. "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support" then unplug the HDMI at ~73th second. "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support" Please advise what I can do to fix this. Thanks
Created attachment 140474 [details] 'xrandr --verbose' before unplugging HDMI
Created attachment 140475 [details] output of 'xrandr --current --verbose' after unplugging HDMI
http://marc.info/?i=CAB4CAwfQxrfRF=MaJZqagtRyPfJOdHjcS32GTqyG8cOg5=UgKw@mail.gmail.com On Fri, 06 Jul 2018, Chris Chiu <chiu@endlessm.com> wrote: > On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: >> On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote: >>> Please advise what I can do to fix this. Thanks >> >> Pull the cable out faster? >> >> I presume this is the same old case of hpd disconnecting slightly >> before ddc and we still manage to read the EDID when processing >> the hpd irq. We kinda tried to fix that with the live status >> check but that thing failed spectacularly. > > Thanks for the suggestion. I tried pulling the cable out faster, the status > shows correctly. I also tried branch drm-tip of > https://cgit.freedesktop.org/drm/drm-tip > but the symptom persists. > > Anything I can help here? Or any old commit/patch I can try to do some > experiments?
Presumably we just want to kick off a delayed work (2s?) from a hotplug event if the status remains unchanged (and it's not a long pulse etc etc).
Yes, without looking at the code, doing some kind of debounce delay before handling the hotplug interrupt sounds like a clear solution here. We're ready to test any patches...
I also encountered this bug on ThinkPad T440. In fact, I think this's a regression: I never seen this bug on 4.14. It only appeared when I upgraded to 4.16, and it didn't go away after I upgraded to 4.17. The most prominent side effect is that systemd-logind fails to suspend on lid close, believing that there's external screen attached. Interestingly, although `grep . /sys/class/drm/*/status` will say that monitor is connected, on my machine, simply running `xrandr` will unstuck the status (and the grep command will now correctly report "disconnected" as well).
Another thing that I noticed is that `xrandr --output HDMI-1 --off` no longer turns the monitor off, but merely turns it black. I'm absolutely sure that the command used to actually turn the screen off. Not sure if it's related to this bug, though.
Created attachment 140946 [details] [review] patch to recheck connector state after 2s I added a patch which solves the issue for the driver used on Genode. Please feel free to test and adjust to your needs on vanilla Linux. The patch is against 4.16.3 Some background: we encountered the issue on our port of the Intel graphic driver to Genode and believed long it is due to some porting issues. Then I stumbled over this bug report and the hint about the 2s delay work. So, implemented a patch and we could resolve the issue with the HDMI disconnect reliable for us - thanks.
Thanks. I verified the attached patch on the problematic X705FD/X560UD. It works fine on both.
(In reply to Alexander Boettcher from comment #8) > Created attachment 140946 [details] [review] [review] > patch to recheck connector state after 2s Is this patch is in upstream?
Please try http://patchwork.freedesktop.org/patch/msgid/20180925071836.24711-1-jani.nikula@intel.com
Hi Jani, Will your patch go upstream? Or is there any patch that is a good upstream candidate for approval?
Gentle ping. Any better idea for the next step?
Created attachment 143814 [details] HDMI connection removed slowly I see similar issue on Chromebook with native HDMI port. When HDMI connection gets removed slowly (wiggling) issue is easily reproducible. (Issue happens with drm-tip also). Attaching the logs for the same. Any update on when upstream fix will be available?
(In reply to Chris Chiu from comment #12) > Hi Jani, > Will your patch go upstream? Or is there any patch that is a good > upstream candidate for approval? Chris, Any feedback from comment 11? Do you still have the issue after applying the patch?
(In reply to Lakshmi from comment #15) > (In reply to Chris Chiu from comment #12) > > Hi Jani, > > Will your patch go upstream? Or is there any patch that is a good > > upstream candidate for approval? > > Chris, Any feedback from comment 11? Do you still have the issue after > applying the patch? No problem with Jani's patch. It's working fine unless a very tricky pull out of HDMI cable (pull out the HDMI cable gentle and slow, with each move of a few millimeters).
(In reply to Jani Nikula from comment #11) > Please try > http://patchwork.freedesktop.org/patch/msgid/20180925071836.24711-1-jani. > nikula@intel.com Issue is not reproducible with this patch.
@Jani, How to proceed further?
*** Bug 110835 has been marked as a duplicate of this bug. ***
We need to get this fixed. It's a real issue, and it's been open for too long. The starting points of the relevant patch/mail threads are: http://mid.mail-archive.com/20180925071836.24711-1-jani.nikula@intel.com http://mid.mail-archive.com/1538543556-31778-1-git-send-email-guang.bai@intel.com http://mid.mail-archive.com/1543439893-27350-1-git-send-email-guang.bai@intel.com
Copy-pasting what I've written before, and was pasted to bug 110835 too: --- We get a hotplug interrupt before the plug is completely out, while ddc communication still works with the display, and we conclude we are still connected. Moreover, the live status bits on the hotplug state have been notoriously unreliable in the past, we've tried using them like three times in the past, leading to regressions and reverts every time. You can come up with all sorts of pathological slow plug/unplug/wiggle cases. If you have a concrete requirement how slow needs to be okay, or better yet write a test case for igt and chamelium, we can work with that. We've proposed fixes in the past but they stalled because some undisclosed unquantified test case still failed. --- Presumably we're getting the issues because we've improved our hotplug and/or ddc code to not have too much inherent delays. The actual user reported bugs apparently get fixed by all of the proposed solutions. The failures in undisclosed tests only get fixed by Guang Bai's patches, but IMO that's a moot point as long as we don't have access to the tests and can't verify the tests make sense. Finally, any solution resorting to using hotplug live status (including Guang Bai's patches) *absolutely* *must* dig through the sad history of it, commit by commit in git logs, and explain in excruciating detail why it failed several times before, and why it would be different this time. I'm not accepting anything with roundabout "it should just work" statements.
We expect that this is fixed by new commits: drm/i915: Add support for retrying hotplug drm/i915: Enable hotplug retry However we no longer have any affected harware to confirm. I'm closing the bug accordingly.
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.