tests/kms_chamelium: disable output when resetting state
RFC PATCH 1/1 tests/kms_chamelium: disable output when resetting state
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis 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).
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(+)
tests/kms_chamelium.c +7 -0
@@ -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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 18 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
Quoted 8 lines
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>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
Quoted 28 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-1@@ -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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 25 lines · Daniel Vetter
Quoted 24 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
---
Quoted 6 lines
Quoted 1 line
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?
Quoted 3 lines
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.
Quoted 27 lines
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
Quoted 21 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-0@@ -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);
Quoted 9 lines
Quoted 7 lines
--
2.22.0_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 29 lines · Simon
Quoted 27 lines · Daniel Vetter
Quoted 25 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>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.
Quoted 7 lines
Quoted 4 lines
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 screenWould 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 ...
Quoted 6 lines
Quoted 3 lines
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
Quoted 37 lines
Quoted 37 lines
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
Quoted 28 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-1@@ -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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 35 lines · Daniel Vetter
Quoted 34 lines · Simon
Quoted 31 lines · Daniel Vetter
Quoted 17 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
Quoted 8 lines
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>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
Quoted 11 lines
Quoted 2 lines
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 ...
Quoted 3 lines
Quoted 3 lines
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).
Quoted 42 lines
Quoted 3 lines
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.
-DanielQuoted 31 lines
Quoted 31 lines
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
Quoted 24 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-1@@ -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
Quoted 17 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-devSignature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 44 lines · Imre Deak
Quoted 43 lines · Daniel Vetter
Quoted 29 lines · Simon
Quoted 27 lines · Daniel Vetter
Quoted 25 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>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.
Quoted 7 lines
Quoted 4 lines
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 screenWould 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 ...
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 60 lines
Quoted 60 lines
Quoted 4 lines
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.
-DanielQuoted 37 lines
Quoted 37 lines
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
Quoted 28 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-1@@ -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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-devSignature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 34 lines · Daniel Vetter
Quoted 33 lines · Simon
Quoted 31 lines · Daniel Vetter
Quoted 17 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
Quoted 8 lines
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>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
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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?
Quoted 27 lines
Quoted 27 lines
Quoted 27 lines
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
Quoted 21 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-0@@ -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);
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
--
2.22.0_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 25 lines · Daniel Vetter
Quoted 24 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
---
Quoted 6 lines
Quoted 1 line
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.)
Quoted 31 lines
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
Quoted 21 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-0@@ -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);
Quoted 9 lines
Quoted 7 lines
--
2.22.0_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 33 lines · Simon
Quoted 25 lines · Daniel Vetter
Quoted 24 lines · Simon Ser
Quoting Imre from the bug comments:
Quoted 6 lines
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:
Quoted 8 lines
- <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 -> failThis sequence is not supported with DP-alt sinks (like the USB-C to HDMI dongle), as I described above.
This patch changes
reset_stateto disable the output before unplugging the connector (viachamelium_reset).Signed-off-by Simon Ser <[email protected]>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111045
---Quoted 6 lines
Quoted 1 line
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
Quoted 7 lines
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.
Quoted 34 lines
Quoted 34 lines
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
Quoted 24 lines
tests/kms_chamelium.c | 7 +++++++ 1 file changed, 7 insertions(+)tests/kms_chamelium.c +7
-1@@ -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
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Patchwork
CI[igt-dev] ✗ Fi.CI.BAT: failure for tests/kms_chamelium: disable output when resetting state
In reply to Simon Ser== Series Details ==
== 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@[email protected]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-skl-6700k2/igt@[email protected]
- 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@[email protected]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7567u/igt@[email protected]
* 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@[email protected]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-cml-u2/igt@[email protected]
* 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@[email protected]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@[email protected]
- 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@[email protected]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7500u/igt@[email protected]
#### 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@[email protected]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-kbl-7500u/igt@[email protected]
- 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@[email protected]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@[email protected]
- 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@[email protected]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-cml-u2/igt@[email protected]
#### 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@[email protected]
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@[email protected]
* 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@[email protected]
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@[email protected]
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@[email protected]
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-blb-e6850/igt@[email protected]
* 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@[email protected]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u3/igt@[email protected]
* 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@[email protected]
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u2/igt@[email protected]
#### 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@[email protected]
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-icl-u4/igt@[email protected]
* 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@[email protected]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3257/fi-hsw-peppy/igt@[email protected]
{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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev