session/logind: keep active for pause_device gone #1696
Conversation
This appears to be a quick fix for compositors freezing when a dock is disconnected. Disconnection of the dock is causing `pause_device` for the DRM devices associated with the dock. Since these devices major number is `DRM_MAJOR`, the session was being set to inactive. This just makes it so the session is not set to inactive when the device's state is `gone`.
| @@ -274,7 +274,7 @@ static int pause_device(sd_bus_message *msg, void *userdata, | |||
| goto error; | |||
| } | |||
|
|
|||
| if (major == DRM_MAJOR) { | |||
| if (major == DRM_MAJOR && strcmp(type, "gone") != 0) { | |||
There was a problem hiding this comment.
Maybe we should only set active = false if strcmp(type, "pause") == 0?
There was a problem hiding this comment.
I can test that tonight if you want
There was a problem hiding this comment.
Yeah, please do.
We might want to destroy the sub-backend if the device is gone.
There was a problem hiding this comment.
Your way seems to work as well, the following log has some debug code from @RedSoxFan as well.
There was a problem hiding this comment.
Maybe we should only set active = false if
strcmp(type, "pause") == 0?
Looking at the documentation at https://www.freedesktop.org/wiki/Software/systemd/logind/ (sorry can't link to an anchor since the id's are not unique...), it looks like there are three values: force, pause, and gone. force is an asynchronous notification that the device was paused, pause is a synchronous notification the device is being paused, and gone is a notification that the device has been removed.
Based on that, I think that the condition is correct as-is. Thoughts?
We might want to destroy the sub-backend if the device is gone.
How would I go about doing that? I haven't really touched wlroots much
There was a problem hiding this comment.
Based on that, I think that the condition is correct as-is. Thoughts?
Indeed, you're right!
How would I go about doing that? I haven't really touched wlroots much
wlr_backend_destroy will probably do the trick. Ah, expect we don't have access to the sub-backend here?
Let's just leave it for another PR then.
There was a problem hiding this comment.
So, this pr is invalid because it's correct as is? What should be done to address the lock up issue then?
This appears to be a quick fix for compositors freezing when a dock is
disconnected. Disconnection of the dock is causing
pause_deviceforthe DRM devices associated with the dock. Since these devices major
number is
DRM_MAJOR, the session was being set to inactive. This justmakes it so the session is not set to inactive when the device's state
is
gone.