[igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Simon Ser]

Quoting Imre from the bug comments:

> If unplugging a DP-alt display while there is an active modeset on it, and
> then replugging the DP-alt display, the HW/FW/driver won't signal the
> corresponding plug-in hotplug event until the mode is disabled.
>
> The failing tests do this:
>
> - <have the output enabled>
> - unplug the display, keeping the output enabled
> - wait/poll for the disconnect status -> success
> - replug the display, while the output is still enabled
> - wait/poll for the connect status -> fail
>
> This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> dongle), as I described above.

This patch changes reset_state to disable the output before unplugging the
connector (via chamelium_reset).

Signed-off-by: Simon Ser <simon.ser@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
---

This is just a RFC to check that the root issue is what we think it is.

 tests/kms_chamelium.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
index b749b5598c1d..f538ad394480 100644
--- a/tests/kms_chamelium.c
+++ b/tests/kms_chamelium.c
@@ -216,6 +216,13 @@ static void
 reset_state(data_t *data, struct chamelium_port *port)
 {
 	int p;
+	drmModeConnector *connector;
+	igt_output_t *output;
+
+	connector = chamelium_port_get_connector(data->chamelium, port, false);
+	output = igt_output_from_connector(&data->display, connector);
+	igt_output_set_pipe(output, PIPE_NONE);
+	igt_display_commit2(&data->display, COMMIT_ATOMIC);

 	chamelium_reset(data->chamelium);

--
2.22.0

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Daniel Vetter]

On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
>
> Quoting Imre from the bug comments:
>
> > If unplugging a DP-alt display while there is an active modeset on it, and
> > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > corresponding plug-in hotplug event until the mode is disabled.
> >
> > The failing tests do this:
> >
> > - <have the output enabled>
> > - unplug the display, keeping the output enabled
> > - wait/poll for the disconnect status -> success
> > - replug the display, while the output is still enabled
> > - wait/poll for the connect status -> fail
> >
> > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > dongle), as I described above.
>
> This patch changes reset_state to disable the output before unplugging the
> connector (via chamelium_reset).
>
> Signed-off-by: Simon Ser <simon.ser@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> ---
>
> This is just a RFC to check that the root issue is what we think it is.

Yeah we can't merge this, this would completely break the hotunplug
usecase, which is:
1. user yanks cable
2. desktop reacts to hotunplug and shuts down the screen

If the hw can't do a hotunplug while there's an active mode, then we
have a chicken&egg situation, and we need to resort to some form of
polling (hooray). Hotunplug better work if the display is on.

Historical aside: Polling is disabled on may old VGA outputs because
the polling can result in screen flickering/corruption. But hw got
better, so even VGA managed to handle hotunplug correctly. No DE (or
user fwiw) assumes nowadays that hotunplug is broken.
-Daniel

>  tests/kms_chamelium.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> index b749b5598c1d..f538ad394480 100644
> --- a/tests/kms_chamelium.c
> +++ b/tests/kms_chamelium.c
> @@ -216,6 +216,13 @@ static void
>  reset_state(data_t *data, struct chamelium_port *port)
>  {
>         int p;
> +       drmModeConnector *connector;
> +       igt_output_t *output;
> +
> +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> +       output = igt_output_from_connector(&data->display, connector);
> +       igt_output_set_pipe(output, PIPE_NONE);
> +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
>
>         chamelium_reset(data->chamelium);
>
> --
> 2.22.0
>
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Ser, Simon]

On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > Quoting Imre from the bug comments:
> > 
> > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > corresponding plug-in hotplug event until the mode is disabled.
> > > 
> > > The failing tests do this:
> > > 
> > > - <have the output enabled>
> > > - unplug the display, keeping the output enabled
> > > - wait/poll for the disconnect status -> success
> > > - replug the display, while the output is still enabled
> > > - wait/poll for the connect status -> fail
> > > 
> > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > dongle), as I described above.
> > 
> > This patch changes reset_state to disable the output before unplugging the
> > connector (via chamelium_reset).
> > 
> > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > ---
> > 
> > This is just a RFC to check that the root issue is what we think it is.
> 
> Yeah we can't merge this, this would completely break the hotunplug
> usecase, which is:
> 1. user yanks cable
> 2. desktop reacts to hotunplug and shuts down the screen

Would disabling the screen after the drmModeConnector says it's
disconnected be better?

> If the hw can't do a hotunplug while there's an active mode, then we
> have a chicken&egg situation, and we need to resort to some form of
> polling (hooray). Hotunplug better work if the display is on.

TBH I'm not sure why it's so important to have all tests keep the mode
active during an unplug-replug sequence.

> Historical aside: Polling is disabled on may old VGA outputs because
> the polling can result in screen flickering/corruption. But hw got
> better, so even VGA managed to handle hotunplug correctly. No DE (or
> user fwiw) assumes nowadays that hotunplug is broken.
> -Daniel
> 
> >  tests/kms_chamelium.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > index b749b5598c1d..f538ad394480 100644
> > --- a/tests/kms_chamelium.c
> > +++ b/tests/kms_chamelium.c
> > @@ -216,6 +216,13 @@ static void
> >  reset_state(data_t *data, struct chamelium_port *port)
> >  {
> >         int p;
> > +       drmModeConnector *connector;
> > +       igt_output_t *output;
> > +
> > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > +       output = igt_output_from_connector(&data->display, connector);
> > +       igt_output_set_pipe(output, PIPE_NONE);
> > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > 
> >         chamelium_reset(data->chamelium);
> > 
> > --
> > 2.22.0
> > 
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Daniel Vetter]

On Thu, Jul 11, 2019 at 2:47 PM Ser, Simon <simon.ser@intel.com> wrote:
>
> On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > > Quoting Imre from the bug comments:
> > >
> > > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > > corresponding plug-in hotplug event until the mode is disabled.
> > > >
> > > > The failing tests do this:
> > > >
> > > > - <have the output enabled>
> > > > - unplug the display, keeping the output enabled
> > > > - wait/poll for the disconnect status -> success
> > > > - replug the display, while the output is still enabled
> > > > - wait/poll for the connect status -> fail
> > > >
> > > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > > dongle), as I described above.
> > >
> > > This patch changes reset_state to disable the output before unplugging the
> > > connector (via chamelium_reset).
> > >
> > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > > ---
> > >
> > > This is just a RFC to check that the root issue is what we think it is.
> >
> > Yeah we can't merge this, this would completely break the hotunplug
> > usecase, which is:
> > 1. user yanks cable
> > 2. desktop reacts to hotunplug and shuts down the screen
>
> Would disabling the screen after the drmModeConnector says it's
> disconnected be better?

I guess depends what you want to test. If it's the hotunplug event
itself, then that should arrive without userspace doing anything at
all. If you don't care for the uevent, not sure why you'd poll
connector status ...

> > If the hw can't do a hotunplug while there's an active mode, then we
> > have a chicken&egg situation, and we need to resort to some form of
> > polling (hooray). Hotunplug better work if the display is on.
>
> TBH I'm not sure why it's so important to have all tests keep the mode
> active during an unplug-replug sequence.

That's another use-case, at least for !DP-MST: We re-train on replug
to make sure a quick cable yank doesn't result in disappointment and
black screens. MST is a bit different in this regard, but iirc Lyude
has been thinking about making that happen even for mst. So also
something that would be nice to test.
-Daniel

>
> > Historical aside: Polling is disabled on may old VGA outputs because
> > the polling can result in screen flickering/corruption. But hw got
> > better, so even VGA managed to handle hotunplug correctly. No DE (or
> > user fwiw) assumes nowadays that hotunplug is broken.
> > -Daniel
> >
> > >  tests/kms_chamelium.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > index b749b5598c1d..f538ad394480 100644
> > > --- a/tests/kms_chamelium.c
> > > +++ b/tests/kms_chamelium.c
> > > @@ -216,6 +216,13 @@ static void
> > >  reset_state(data_t *data, struct chamelium_port *port)
> > >  {
> > >         int p;
> > > +       drmModeConnector *connector;
> > > +       igt_output_t *output;
> > > +
> > > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > > +       output = igt_output_from_connector(&data->display, connector);
> > > +       igt_output_set_pipe(output, PIPE_NONE);
> > > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > >
> > >         chamelium_reset(data->chamelium);
> > >
> > > --
> > > 2.22.0
> > >
> > > _______________________________________________
> > > igt-dev mailing list
> > > igt-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >
> >



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Imre Deak]

On Thu, Jul 11, 2019 at 03:14:48PM +0200, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 2:47 PM Ser, Simon <simon.ser@intel.com> wrote:
> >
> > On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> > > On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > > > Quoting Imre from the bug comments:
> > > >
> > > > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > > > corresponding plug-in hotplug event until the mode is disabled.
> > > > >
> > > > > The failing tests do this:
> > > > >
> > > > > - <have the output enabled>
> > > > > - unplug the display, keeping the output enabled
> > > > > - wait/poll for the disconnect status -> success
> > > > > - replug the display, while the output is still enabled
> > > > > - wait/poll for the connect status -> fail
> > > > >
> > > > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > > > dongle), as I described above.
> > > >
> > > > This patch changes reset_state to disable the output before unplugging the
> > > > connector (via chamelium_reset).
> > > >
> > > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > > > ---
> > > >
> > > > This is just a RFC to check that the root issue is what we think it is.
> > >
> > > Yeah we can't merge this, this would completely break the hotunplug
> > > usecase, which is:
> > > 1. user yanks cable
> > > 2. desktop reacts to hotunplug and shuts down the screen
> >
> > Would disabling the screen after the drmModeConnector says it's
> > disconnected be better?
> 
> I guess depends what you want to test. If it's the hotunplug event
> itself, then that should arrive without userspace doing anything at
> all. If you don't care for the uevent, not sure why you'd poll
> connector status ...
> 
> > > If the hw can't do a hotunplug while there's an active mode, then we
> > > have a chicken&egg situation, and we need to resort to some form of
> > > polling (hooray). Hotunplug better work if the display is on.

Hot unplug with an active mode does work and the corresponding uevent
will be sent by the driver, it's just the replug uevent that won't be
delivered until the active mode gets disabled (which should happen
anyway as part of the normal unplug uevent processing by user space).

> >
> > TBH I'm not sure why it's so important to have all tests keep the mode
> > active during an unplug-replug sequence.
> 
> That's another use-case, at least for !DP-MST: We re-train on replug
> to make sure a quick cable yank doesn't result in disappointment and
> black screens. MST is a bit different in this regard, but iirc Lyude
> has been thinking about making that happen even for mst. So also
> something that would be nice to test.
> -Daniel
> 
> >
> > > Historical aside: Polling is disabled on may old VGA outputs because
> > > the polling can result in screen flickering/corruption. But hw got
> > > better, so even VGA managed to handle hotunplug correctly. No DE (or
> > > user fwiw) assumes nowadays that hotunplug is broken.
> > > -Daniel
> > >
> > > >  tests/kms_chamelium.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > > index b749b5598c1d..f538ad394480 100644
> > > > --- a/tests/kms_chamelium.c
> > > > +++ b/tests/kms_chamelium.c
> > > > @@ -216,6 +216,13 @@ static void
> > > >  reset_state(data_t *data, struct chamelium_port *port)
> > > >  {
> > > >         int p;
> > > > +       drmModeConnector *connector;
> > > > +       igt_output_t *output;
> > > > +
> > > > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > > > +       output = igt_output_from_connector(&data->display, connector);
> > > > +       igt_output_set_pipe(output, PIPE_NONE);
> > > > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > > >
> > > >         chamelium_reset(data->chamelium);
> > > >
> > > > --
> > > > 2.22.0
> > > >
> > > > _______________________________________________
> > > > igt-dev mailing list
> > > > igt-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > >
> > >
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Daniel Vetter]

On Fri, Jul 12, 2019 at 04:12:04PM +0300, Imre Deak wrote:
> On Thu, Jul 11, 2019 at 03:14:48PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 2:47 PM Ser, Simon <simon.ser@intel.com> wrote:
> > >
> > > On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> > > > On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > > > > Quoting Imre from the bug comments:
> > > > >
> > > > > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > > > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > > > > corresponding plug-in hotplug event until the mode is disabled.
> > > > > >
> > > > > > The failing tests do this:
> > > > > >
> > > > > > - <have the output enabled>
> > > > > > - unplug the display, keeping the output enabled
> > > > > > - wait/poll for the disconnect status -> success
> > > > > > - replug the display, while the output is still enabled
> > > > > > - wait/poll for the connect status -> fail
> > > > > >
> > > > > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > > > > dongle), as I described above.
> > > > >
> > > > > This patch changes reset_state to disable the output before unplugging the
> > > > > connector (via chamelium_reset).
> > > > >
> > > > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > > > > ---
> > > > >
> > > > > This is just a RFC to check that the root issue is what we think it is.
> > > >
> > > > Yeah we can't merge this, this would completely break the hotunplug
> > > > usecase, which is:
> > > > 1. user yanks cable
> > > > 2. desktop reacts to hotunplug and shuts down the screen
> > >
> > > Would disabling the screen after the drmModeConnector says it's
> > > disconnected be better?
> > 
> > I guess depends what you want to test. If it's the hotunplug event
> > itself, then that should arrive without userspace doing anything at
> > all. If you don't care for the uevent, not sure why you'd poll
> > connector status ...
> > 
> > > > If the hw can't do a hotunplug while there's an active mode, then we
> > > > have a chicken&egg situation, and we need to resort to some form of
> > > > polling (hooray). Hotunplug better work if the display is on.
> 
> Hot unplug with an active mode does work and the corresponding uevent
> will be sent by the driver, it's just the replug uevent that won't be
> delivered until the active mode gets disabled (which should happen
> anyway as part of the normal unplug uevent processing by user space).

I think that's ok as a limitation. Not pretty (since it means the DE
really has to automatically handle hot(un)plug), but good enough.
-Daniel

> 
> > >
> > > TBH I'm not sure why it's so important to have all tests keep the mode
> > > active during an unplug-replug sequence.
> > 
> > That's another use-case, at least for !DP-MST: We re-train on replug
> > to make sure a quick cable yank doesn't result in disappointment and
> > black screens. MST is a bit different in this regard, but iirc Lyude
> > has been thinking about making that happen even for mst. So also
> > something that would be nice to test.
> > -Daniel
> > 
> > >
> > > > Historical aside: Polling is disabled on may old VGA outputs because
> > > > the polling can result in screen flickering/corruption. But hw got
> > > > better, so even VGA managed to handle hotunplug correctly. No DE (or
> > > > user fwiw) assumes nowadays that hotunplug is broken.
> > > > -Daniel
> > > >
> > > > >  tests/kms_chamelium.c | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > > > index b749b5598c1d..f538ad394480 100644
> > > > > --- a/tests/kms_chamelium.c
> > > > > +++ b/tests/kms_chamelium.c
> > > > > @@ -216,6 +216,13 @@ static void
> > > > >  reset_state(data_t *data, struct chamelium_port *port)
> > > > >  {
> > > > >         int p;
> > > > > +       drmModeConnector *connector;
> > > > > +       igt_output_t *output;
> > > > > +
> > > > > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > > > > +       output = igt_output_from_connector(&data->display, connector);
> > > > > +       igt_output_set_pipe(output, PIPE_NONE);
> > > > > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > > > >
> > > > >         chamelium_reset(data->chamelium);
> > > > >
> > > > > --
> > > > > 2.22.0
> > > > >
> > > > > _______________________________________________
> > > > > igt-dev mailing list
> > > > > igt-dev@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > > >
> > > >
> > 
> > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Ser, Simon]

On Thu, 2019-07-11 at 15:14 +0200, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 2:47 PM Ser, Simon <simon.ser@intel.com> wrote:
> > On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> > > On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > > > Quoting Imre from the bug comments:
> > > > 
> > > > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > > > corresponding plug-in hotplug event until the mode is disabled.
> > > > > 
> > > > > The failing tests do this:
> > > > > 
> > > > > - <have the output enabled>
> > > > > - unplug the display, keeping the output enabled
> > > > > - wait/poll for the disconnect status -> success
> > > > > - replug the display, while the output is still enabled
> > > > > - wait/poll for the connect status -> fail
> > > > > 
> > > > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > > > dongle), as I described above.
> > > > 
> > > > This patch changes reset_state to disable the output before unplugging the
> > > > connector (via chamelium_reset).
> > > > 
> > > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > > > ---
> > > > 
> > > > This is just a RFC to check that the root issue is what we think it is.
> > > 
> > > Yeah we can't merge this, this would completely break the hotunplug
> > > usecase, which is:
> > > 1. user yanks cable
> > > 2. desktop reacts to hotunplug and shuts down the screen
> > 
> > Would disabling the screen after the drmModeConnector says it's
> > disconnected be better?
> 
> I guess depends what you want to test. If it's the hotunplug event
> itself, then that should arrive without userspace doing anything at
> all. If you don't care for the uevent, not sure why you'd poll
> connector status ...

Note that we already have a test (test_basic_hotplug) that unplugs and
waits for the uevent.

> > > If the hw can't do a hotunplug while there's an active mode, then we
> > > have a chicken&egg situation, and we need to resort to some form of
> > > polling (hooray). Hotunplug better work if the display is on.
> > 
> > TBH I'm not sure why it's so important to have all tests keep the mode
> > active during an unplug-replug sequence.
> 
> That's another use-case, at least for !DP-MST: We re-train on replug
> to make sure a quick cable yank doesn't result in disappointment and
> black screens. MST is a bit different in this regard, but iirc Lyude
> has been thinking about making that happen even for mst. So also
> something that would be nice to test.

After discussion on IRC, it seems that maybe the unplug-replug scenario
shouldn't work if userspace doesn't listen to uevents.

I'd really like most Chamelium tests to "do the right thing" (disable
outputs on unplug). We could always have some "legacy tests" that are
not run on DP-MST and USB-C and try to keep the connector active. I
don't see any value in duplicating all tests for both legacy and
hotplug-aware: once we know keeping the pipe active while unplugging-
replugging works, we should be fine.

Thoughts?

> > > Historical aside: Polling is disabled on may old VGA outputs because
> > > the polling can result in screen flickering/corruption. But hw got
> > > better, so even VGA managed to handle hotunplug correctly. No DE (or
> > > user fwiw) assumes nowadays that hotunplug is broken.
> > > -Daniel
> > > 
> > > >  tests/kms_chamelium.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > > index b749b5598c1d..f538ad394480 100644
> > > > --- a/tests/kms_chamelium.c
> > > > +++ b/tests/kms_chamelium.c
> > > > @@ -216,6 +216,13 @@ static void
> > > >  reset_state(data_t *data, struct chamelium_port *port)
> > > >  {
> > > >         int p;
> > > > +       drmModeConnector *connector;
> > > > +       igt_output_t *output;
> > > > +
> > > > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > > > +       output = igt_output_from_connector(&data->display, connector);
> > > > +       igt_output_set_pipe(output, PIPE_NONE);
> > > > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > > > 
> > > >         chamelium_reset(data->chamelium);
> > > > 
> > > > --
> > > > 2.22.0
> > > > 
> > > > _______________________________________________
> > > > igt-dev mailing list
> > > > igt-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Ser, Simon]

On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > Quoting Imre from the bug comments:
> > 
> > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > corresponding plug-in hotplug event until the mode is disabled.
> > > 
> > > The failing tests do this:
> > > 
> > > - <have the output enabled>
> > > - unplug the display, keeping the output enabled
> > > - wait/poll for the disconnect status -> success
> > > - replug the display, while the output is still enabled
> > > - wait/poll for the connect status -> fail
> > > 
> > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > dongle), as I described above.
> > 
> > This patch changes reset_state to disable the output before unplugging the
> > connector (via chamelium_reset).
> > 
> > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > ---
> > 
> > This is just a RFC to check that the root issue is what we think it is.
> 
> Yeah we can't merge this, this would completely break the hotunplug
> usecase, which is:
> 1. user yanks cable
> 2. desktop reacts to hotunplug and shuts down the screen

What about:

1. Disconnecting the port from the Chamelium
2. Waiting for the connector to become disconnected
3. Disabling the connector

(We could have this as a separate test if it takes too long.)

> If the hw can't do a hotunplug while there's an active mode, then we
> have a chicken&egg situation, and we need to resort to some form of
> polling (hooray). Hotunplug better work if the display is on.
> 
> Historical aside: Polling is disabled on may old VGA outputs because
> the polling can result in screen flickering/corruption. But hw got
> better, so even VGA managed to handle hotunplug correctly. No DE (or
> user fwiw) assumes nowadays that hotunplug is broken.
> -Daniel
> 
> >  tests/kms_chamelium.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > index b749b5598c1d..f538ad394480 100644
> > --- a/tests/kms_chamelium.c
> > +++ b/tests/kms_chamelium.c
> > @@ -216,6 +216,13 @@ static void
> >  reset_state(data_t *data, struct chamelium_port *port)
> >  {
> >         int p;
> > +       drmModeConnector *connector;
> > +       igt_output_t *output;
> > +
> > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > +       output = igt_output_from_connector(&data->display, connector);
> > +       igt_output_set_pipe(output, PIPE_NONE);
> > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > 
> >         chamelium_reset(data->chamelium);
> > 
> > --
> > 2.22.0
> > 
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH RFC i-g-t] tests/kms_chamelium: disable output when resetting state

[Ser, Simon]

On Wed, 2019-08-14 at 12:27 +0000, Ser, Simon wrote:
> On Thu, 2019-07-11 at 14:40 +0200, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 1:11 PM Simon Ser <simon.ser@intel.com> wrote:
> > > Quoting Imre from the bug comments:
> > > 
> > > > If unplugging a DP-alt display while there is an active modeset on it, and
> > > > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > > > corresponding plug-in hotplug event until the mode is disabled.
> > > > 
> > > > The failing tests do this:
> > > > 
> > > > - <have the output enabled>
> > > > - unplug the display, keeping the output enabled
> > > > - wait/poll for the disconnect status -> success
> > > > - replug the display, while the output is still enabled
> > > > - wait/poll for the connect status -> fail
> > > > 
> > > > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > > > dongle), as I described above.
> > > 
> > > This patch changes reset_state to disable the output before unplugging the
> > > connector (via chamelium_reset).
> > > 
> > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
> > > ---
> > > 
> > > This is just a RFC to check that the root issue is what we think it is.
> > 
> > Yeah we can't merge this, this would completely break the hotunplug
> > usecase, which is:
> > 1. user yanks cable
> > 2. desktop reacts to hotunplug and shuts down the screen
> 
> What about:
> 
> 1. Disconnecting the port from the Chamelium
> 2. Waiting for the connector to become disconnected
> 3. Disabling the connector
> 
> (We could have this as a separate test if it takes too long.)

Bleh, missed my 1-month old reply. Sorry about that, please disregard.

> > If the hw can't do a hotunplug while there's an active mode, then we
> > have a chicken&egg situation, and we need to resort to some form of
> > polling (hooray). Hotunplug better work if the display is on.
> > 
> > Historical aside: Polling is disabled on may old VGA outputs because
> > the polling can result in screen flickering/corruption. But hw got
> > better, so even VGA managed to handle hotunplug correctly. No DE (or
> > user fwiw) assumes nowadays that hotunplug is broken.
> > -Daniel
> > 
> > >  tests/kms_chamelium.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > index b749b5598c1d..f538ad394480 100644
> > > --- a/tests/kms_chamelium.c
> > > +++ b/tests/kms_chamelium.c
> > > @@ -216,6 +216,13 @@ static void
> > >  reset_state(data_t *data, struct chamelium_port *port)
> > >  {
> > >         int p;
> > > +       drmModeConnector *connector;
> > > +       igt_output_t *output;
> > > +
> > > +       connector = chamelium_port_get_connector(data->chamelium, port, false);
> > > +       output = igt_output_from_connector(&data->display, connector);
> > > +       igt_output_set_pipe(output, PIPE_NONE);
> > > +       igt_display_commit2(&data->display, COMMIT_ATOMIC);
> > > 
> > >         chamelium_reset(data->chamelium);
> > > 
> > > --
> > > 2.22.0
> > > 
> > > _______________________________________________
> > > igt-dev mailing list
> > > igt-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✗ Fi.CI.BAT: failure for tests/kms_chamelium: disable output when resetting state

[Patchwork]

== Series Details ==

Series: tests/kms_chamelium: disable output when resetting state
URL   : https://patchwork.freedesktop.org/series/63557/
State : failure

== Summary ==

CI Bug Log - changes from IGT_5094 -> IGTPW_3257
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_3257 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_3257, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/63557/revisions/1/mbox/

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_3257:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-skl-6700k2:      [PASS][1] -> [CRASH][2] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-skl-6700k2/igt@kms_chamelium@common-hpd-after-suspend.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-skl-6700k2/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-kbl-7567u:       [PASS][3] -> [CRASH][4] +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-hpd-fast:
    - fi-cml-u2:          [PASS][5] -> [CRASH][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-cml-u2/igt@kms_chamelium@dp-hpd-fast.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-cml-u2/igt@kms_chamelium@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-icl-u2:          [PASS][7] -> [CRASH][8] +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
    - fi-kbl-7500u:       [PASS][9] -> [CRASH][10] +1 similar issue
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
#### Warnings ####

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-7500u:       [DMESG-WARN][11] ([fdo#102505] / [fdo#103558] / [fdo#105079] / [fdo#105602]) -> [CRASH][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-kbl-7500u/igt@kms_chamelium@common-hpd-after-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7500u/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-icl-u2:          [DMESG-WARN][13] ([fdo#102505] / [fdo#110390]) -> [CRASH][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
    - fi-cml-u2:          [DMESG-WARN][15] ([fdo#102505]) -> [CRASH][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-cml-u2/igt@kms_chamelium@common-hpd-after-suspend.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-cml-u2/igt@kms_chamelium@common-hpd-after-suspend.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_chamelium@common-hpd-after-suspend:
    - {fi-icl-u4}:        [DMESG-WARN][17] ([fdo#102505]) -> [CRASH][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u4/igt@kms_chamelium@common-hpd-after-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - {fi-icl-u4}:        [FAIL][19] ([fdo#111045]) -> [CRASH][20] +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html

  
Known issues
------------

  Here are the changes found in IGTPW_3257 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [PASS][21] -> [INCOMPLETE][22] ([fdo#107718])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  * igt@kms_addfb_basic@unused-handle:
    - fi-icl-u3:          [PASS][23] -> [DMESG-WARN][24] ([fdo#107724])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u3/igt@kms_addfb_basic@unused-handle.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u3/igt@kms_addfb_basic@unused-handle.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-icl-u2:          [PASS][25] -> [FAIL][26] ([fdo#109635 ])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u2/igt@kms_chamelium@hdmi-crc-fast.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@kms_chamelium@hdmi-crc-fast.html

  
#### Possible fixes ####

  * igt@i915_selftest@live_contexts:
    - fi-skl-iommu:       [INCOMPLETE][27] ([fdo#111050]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-skl-iommu/igt@i915_selftest@live_contexts.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-skl-iommu/igt@i915_selftest@live_contexts.html

  * igt@i915_selftest@live_execlists:
    - fi-bwr-2160:        [DMESG-WARN][29] -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-bwr-2160/igt@i915_selftest@live_execlists.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-bwr-2160/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_hangcheck:
    - fi-bwr-2160:        [DMESG-FAIL][31] -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - {fi-icl-u4}:        [FAIL][33] ([fdo#111045] / [fdo#111046 ]) -> [PASS][34] +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-icl-u4/igt@kms_chamelium@hdmi-crc-fast.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@kms_chamelium@hdmi-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [DMESG-WARN][35] ([fdo#102614]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5094/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
  [fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046 
  [fdo#111050]: https://bugs.freedesktop.org/show_bug.cgi?id=111050


Participating hosts (53 -> 46)
------------------------------

  Missing    (7): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus 


Build changes
-------------

  * IGT: IGT_5094 -> IGTPW_3257

  CI_DRM_6458: fe4d1459b31768c40f907bb859f25197e1af2d07 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3257: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/
  IGT_5094: d7f140b5b02d054183a74842b4579cf7f5533927 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev