Bug 110954 - USB Type-C monitor flashes once when play a video file after unplug and re-plug the monitor
Summary: USB Type-C monitor flashes once when play a video file after unplug and re-pl...
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev, Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-21 16:26 UTC by Chintan Patel
Modified: 2019-09-15 03:02 UTC (History)
2 users (show)

See Also:
i915 platform: CFL, KBL
i915 features: display/Other


Attachments
dmesg logs on Chromebook with drm-tip logs enabled with 0x1e (194.70 KB, text/plain)
2019-06-21 16:26 UTC, Chintan Patel
no flags Details
dmesg logs on Chrome OS Kernel (707.64 KB, text/plain)
2019-06-21 16:30 UTC, Chintan Patel
no flags Details
Exact dmesg logs when flash happens after connecting monitor (243.46 KB, text/plain)
2019-06-21 22:59 UTC, Chintan Patel
no flags Details
dmesg marked with "play audio and flash" (142.51 KB, text/plain)
2019-08-16 22:34 UTC, Nathan Ciobanu
no flags Details
for comment #10 (96.34 KB, text/plain)
2019-08-16 22:55 UTC, Nathan Ciobanu
no flags Details
video file used to reproduce the bug (238.48 MB, video/mp4)
2019-08-19 16:47 UTC, Nathan Ciobanu
no flags Details
attachment-15818-0.html (2.50 KB, text/html)
2019-08-23 17:32 UTC, Chintan Patel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chintan Patel 2019-06-21 16:26:55 UTC
Created attachment 144604 [details]
dmesg logs on Chromebook with drm-tip logs enabled with 0x1e

Steps to reproduce this issue:
1. Boot chromebook/Ubuntu 16.04 to OS.
2. Connect type-c cable to laptop.
3. Plug DP to MST Display
4. Switch sound output to speaker.
5. Play a local video or music (not suggested Youtube). OR "speaker_test" from command line 
6. Close the player.
7. Unplug type-c cable then plug cable in about 5~10s.
8. Play a local video or music again.
9. MST monitor will flash once when playing multimedia. <------issue

Steps to reproduce on Ubuntu 16.04 OS:
1. Boot Ubuntu OS
2. Connect Display with Solomon Dock
3. Make sure to select HDMI from audio settings ==> Check if issue happens??
4. Play video ==> Check if issue happens??


Issue happens on KBL/WHL as well as with SST monitor, although reproduction rate is low. High reproduction rate(90%) if done using S2718D and Solomon dock.

Issue happens with drm-tip SH1 034e3ac6a2d1 also.

Attaching the logs with Chrome OS Kernel as well as with drm-tip.
Comment 1 Chintan Patel 2019-06-21 16:30:04 UTC
Created attachment 144605 [details]
dmesg logs on Chrome OS Kernel
Comment 2 Chintan Patel 2019-06-21 22:59:09 UTC
Created attachment 144607 [details]
Exact dmesg logs when flash happens after connecting monitor
Comment 3 Lakshmi 2019-06-26 09:09:29 UTC
(In reply to Chintan Patel from comment #0)
> Created attachment 144604 [details]
> dmesg logs on Chromebook with drm-tip logs enabled with 0x1e
> 
> Steps to reproduce this issue:
> 1. Boot chromebook/Ubuntu 16.04 to OS.
> 2. Connect type-c cable to laptop.
> 3. Plug DP to MST Display
> 4. Switch sound output to speaker.
> 5. Play a local video or music (not suggested Youtube). OR "speaker_test"
> from command line 
> 6. Close the player.
> 7. Unplug type-c cable then plug cable in about 5~10s.
> 8. Play a local video or music again.
> 9. MST monitor will flash once when playing multimedia. <------issue
> 
After step 9, is audio working as expected? only issue is monitoring flashing?
Comment 4 Nathan Ciobanu 2019-06-26 20:48:23 UTC
(In reply to Lakshmi from comment #3)
> (In reply to Chintan Patel from comment #0)
> > Created attachment 144604 [details]
> > dmesg logs on Chromebook with drm-tip logs enabled with 0x1e
> > 
> > Steps to reproduce this issue:
> > 1. Boot chromebook/Ubuntu 16.04 to OS.
> > 2. Connect type-c cable to laptop.
> > 3. Plug DP to MST Display
> > 4. Switch sound output to speaker.
> > 5. Play a local video or music (not suggested Youtube). OR "speaker_test"
> > from command line 
> > 6. Close the player.
> > 7. Unplug type-c cable then plug cable in about 5~10s.
> > 8. Play a local video or music again.
> > 9. MST monitor will flash once when playing multimedia. <------issue
> > 
> After step 9, is audio working as expected? only issue is monitoring
> flashing?

Yes audio recovers after the flash and works fine.
Comment 5 Lakshmi 2019-07-17 07:52:47 UTC
Considering the issue happens only in a specific scenario and to a particular Solomon dock(90% repro), setting the priority to Medium.
Comment 6 Nathan Ciobanu 2019-08-08 15:47:45 UTC
This bug can also be reproduced with two daisy-chained monitors (DP MST). It is harder but the bug is there even without the Dell dock. I hope this helps setting the priority higher than Medium.
Comment 7 Jani Nikula 2019-08-09 10:58:57 UTC
Please indicate precisely in the dmesg where the flashing occurs. It's not obvious.

You can even log it yourself in the dmesg, using for example:

$ sudo bash -c "echo play audio > /dev/kmsg"

and 

$ sudo bash -c "echo end audio > /dev/kmsg"
Comment 8 Stanislav Lisovskiy 2019-08-16 08:46:43 UTC
Does it also flash, if you play video with sound device being disabled?
Comment 9 Nathan Ciobanu 2019-08-16 22:34:48 UTC
Created attachment 145081 [details]
dmesg marked with "play audio and flash"

I took another log on a Chromebook with drm-tip and drm.debug=0xe. I also marked the spot where I start playing the video with "play audio and flash". 

You'll then see the spurious which get printed during the video playback.
[drm:skl_update_scaler] scaler_user index 0.0: staged scaling request for 1920x1080->1724x970 scaler_users = 0x1
[drm:intel_atomic_setup_scalers] Attached scaler id 0.0 to PLANE:31"

It is during the video playback time that the flash occurs.

The one interesting thing I found is that we restart probing for connectors at this point:
[ 3980.917229] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1]
which is triggered by an ioctl call from user space. For some reason the userspace needs to reprobe and I'm not sure what causes this. 

Another finding from my previous investigation was that if you wait for the this reprobing to finish and then play the video the flash will not occur.
Comment 10 Nathan Ciobanu 2019-08-16 22:54:36 UTC
(In reply to Stanislav Lisovskiy from comment #8)
> Does it also flash, if you play video with sound device being disabled?

No if I blacklist snd_hda_intel module to disable audio the bug is not reproducible. 
The reprobe is still there though, but without audio there is no flash. 

[  718.086179] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off
[  718.086313] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x80000008 PP_CONTROL: 0x00000067
[  725.108202] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1]
Comment 11 Nathan Ciobanu 2019-08-16 22:55:48 UTC
Created attachment 145082 [details]
for comment #10

This is the log I referred to in comment 10 where audio is disabled.
Comment 12 Stanislav Lisovskiy 2019-08-19 13:25:33 UTC
What do you mean by "that if you wait for the this reprobing to finish and then play the video the flash will not occur"? 

So it does not happen once you start playback, but at some point before this?
Comment 13 Nathan Ciobanu 2019-08-19 16:29:15 UTC
(In reply to Stanislav Lisovskiy from comment #12)
> What do you mean by "that if you wait for the this reprobing to finish and
> then play the video the flash will not occur"? 
> 
> So it does not happen once you start playback, but at some point before this?

The flash happens if you play the video (with audio) before the reprobe, If you play the video after reprobe it doesn't occur.
Comment 14 Nathan Ciobanu 2019-08-19 16:47:01 UTC
Created attachment 145102 [details]
video file used to reproduce the bug
Comment 15 Stanislav Lisovskiy 2019-08-20 10:02:48 UTC
(In reply to Nathan Ciobanu from comment #13)
> (In reply to Stanislav Lisovskiy from comment #12)
> > What do you mean by "that if you wait for the this reprobing to finish and
> > then play the video the flash will not occur"? 
> > 
> > So it does not happen once you start playback, but at some point before this?
> 
> The flash happens if you play the video (with audio) before the reprobe, If
> you play the video after reprobe it doesn't occur.

But when does reprobe occur? Does it occur on its own or after you replug it or some other action?
Comment 16 Nathan Ciobanu 2019-08-20 19:51:10 UTC
On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=110954
> 
> --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> (In reply to Nathan Ciobanu from comment #13)
> > (In reply to Stanislav Lisovskiy from comment #12)
> > > What do you mean by "that if you wait for the this reprobing to finish and
> > > then play the video the flash will not occur"? 
> > > 
> > > So it does not happen once you start playback, but at some point before this?
> > 
> > The flash happens if you play the video (with audio) before the reprobe, If
> > you play the video after reprobe it doesn't occur.
> 
> But when does reprobe occur? Does it occur on its own or after you replug it or
> some other action?
It always occurs regardless of my actions.

> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 17 Stanislav Lisovskiy 2019-08-21 08:26:34 UTC
(In reply to Nathan Ciobanu from comment #16)
> On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org
> wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > 
> > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > (In reply to Nathan Ciobanu from comment #13)
> > > (In reply to Stanislav Lisovskiy from comment #12)
> > > > What do you mean by "that if you wait for the this reprobing to finish and
> > > > then play the video the flash will not occur"? 
> > > > 
> > > > So it does not happen once you start playback, but at some point before this?
> > > 
> > > The flash happens if you play the video (with audio) before the reprobe, If
> > > you play the video after reprobe it doesn't occur.
> > 
> > But when does reprobe occur? Does it occur on its own or after you replug it or
> > some other action?
> It always occurs regardless of my actions.

That is weird then. It should occur only once you do hotplug/change display configuration. It should not happen on its own, probably that might be origin of this issue.

> 
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.
Comment 18 Nathan Ciobanu 2019-08-23 17:32:27 UTC
On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=110954
> 
> --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> (In reply to Nathan Ciobanu from comment #16)
> > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org
> > wrote:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > > 
> > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > > (In reply to Nathan Ciobanu from comment #13)
> > > > (In reply to Stanislav Lisovskiy from comment #12)
> > > > > What do you mean by "that if you wait for the this reprobing to finish and
> > > > > then play the video the flash will not occur"? 
> > > > > 
> > > > > So it does not happen once you start playback, but at some point before this?
> > > > 
> > > > The flash happens if you play the video (with audio) before the reprobe, If
> > > > you play the video after reprobe it doesn't occur.
> > > 
> > > But when does reprobe occur? Does it occur on its own or after you replug it or
> > > some other action?
> > It always occurs regardless of my actions.
> 
> That is weird then. It should occur only once you do hotplug/change display
> configuration. It should not happen on its own, probably that might be origin
> of this issue.
That is my suspicion as well. I don't know how hda behaves in MST situations but maybe it isn't "ready" right away when the displays finish training but may become "ready" a few seconds later and thus trigger a reprobe. To prove this which register do I need to print?

Thanks,
Nathan
> 
> > 
> > > 
> > > -- 
> > > You are receiving this mail because:
> > > You are on the CC list for the bug.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 19 Chintan Patel 2019-08-23 17:32:36 UTC
Created attachment 145147 [details]
attachment-15818-0.html

I will be OOO on Oct 05 and Oct 08. Please expect dealy in email responses.


Thanks,
Chintan
Comment 20 Stanislav Lisovskiy 2019-08-26 09:33:04 UTC
(In reply to Nathan Ciobanu from comment #18)
> On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org
> wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > 
> > --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > (In reply to Nathan Ciobanu from comment #16)
> > > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org
> > > wrote:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > > > 
> > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > > > (In reply to Nathan Ciobanu from comment #13)
> > > > > (In reply to Stanislav Lisovskiy from comment #12)
> > > > > > What do you mean by "that if you wait for the this reprobing to finish and
> > > > > > then play the video the flash will not occur"? 
> > > > > > 
> > > > > > So it does not happen once you start playback, but at some point before this?
> > > > > 
> > > > > The flash happens if you play the video (with audio) before the reprobe, If
> > > > > you play the video after reprobe it doesn't occur.
> > > > 
> > > > But when does reprobe occur? Does it occur on its own or after you replug it or
> > > > some other action?
> > > It always occurs regardless of my actions.
> > 
> > That is weird then. It should occur only once you do hotplug/change display
> > configuration. It should not happen on its own, probably that might be origin
> > of this issue.
> That is my suspicion as well. I don't know how hda behaves in MST situations
> but maybe it isn't "ready" right away when the displays finish training but
> may become "ready" a few seconds later and thus trigger a reprobe. To prove
> this which register do I need to print?
> 
> Thanks,
> Nathan
> > 
> > > 
> > > > 
> > > > -- 
> > > > You are receiving this mail because:
> > > > You are on the CC list for the bug.
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.

The dmesg log looks flooded with hpd irq events like this "gen8_de_irq_handler] hotplug event received, stat 0x00400000, dig 0x10101110, pins 0x00000040, long 0x00000000", I don't think this is even related to hda, most likely there is some issue with DP MST itself. The flash probably just happens as a result of constant reprobing and simultaneous modeset. 
Userspace starts reprobing after it gets uevent sent by the driver in response to hpd irq.
Comment 21 Nathan Ciobanu 2019-09-15 03:02:07 UTC
On Mon, Aug 26, 2019 at 09:33:04AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=110954
> 
> --- Comment #20 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> (In reply to Nathan Ciobanu from comment #18)
> > On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org
> > wrote:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > > 
> > > --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > > (In reply to Nathan Ciobanu from comment #16)
> > > > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org
> > > > wrote:
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954
> > > > > 
> > > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> ---
> > > > > (In reply to Nathan Ciobanu from comment #13)
> > > > > > (In reply to Stanislav Lisovskiy from comment #12)
> > > > > > > What do you mean by "that if you wait for the this reprobing to finish and
> > > > > > > then play the video the flash will not occur"? 
> > > > > > > 
> > > > > > > So it does not happen once you start playback, but at some point before this?
> > > > > > 
> > > > > > The flash happens if you play the video (with audio) before the reprobe, If
> > > > > > you play the video after reprobe it doesn't occur.
> > > > > 
> > > > > But when does reprobe occur? Does it occur on its own or after you replug it or
> > > > > some other action?
> > > > It always occurs regardless of my actions.
> > > 
> > > That is weird then. It should occur only once you do hotplug/change display
> > > configuration. It should not happen on its own, probably that might be origin
> > > of this issue.
> > That is my suspicion as well. I don't know how hda behaves in MST situations
> > but maybe it isn't "ready" right away when the displays finish training but
> > may become "ready" a few seconds later and thus trigger a reprobe. To prove
> > this which register do I need to print?
> > 
> > Thanks,
> > Nathan
> > > 
> > > > 
> > > > > 
> > > > > -- 
> > > > > You are receiving this mail because:
> > > > > You are on the CC list for the bug.
> > > 
> > > -- 
> > > You are receiving this mail because:
> > > You are on the CC list for the bug.
> 
> The dmesg log looks flooded with hpd irq events like this "gen8_de_irq_handler]
> hotplug event received, stat 0x00400000, dig 0x10101110, pins 0x00000040, long
> 0x00000000", I don't think this is even related to hda, most likely there is
> some issue with DP MST itself. The flash probably just happens as a result of
> constant reprobing and simultaneous modeset. 
> Userspace starts reprobing after it gets uevent sent by the driver in response
> to hpd irq.
Does this point to the dock as a possible soure of the hpd interrupts? Do you think the dock may have an issue? Any register we can dump to prove this? 

Thanks,
Nathan
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.


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.