Multiseat support for swayidle
emersion opened this issue · 8 comments
swayidle only supports one seat.
If I understand it correctly, after #77, swayidle supports any one named seat. But the restriction of one seat at a time, set at launch, remains.
Right. I'd say requiring one swayidle instance per seat is reasonable.
Hm, what does it mean then to have one swayidle instance per seat? Does this mean any seat-user can lock the device such that only the same seat-user can unlock it later? If so, I can think of a few issues…
An example: I'm imagining a pair-programming setup where two users are sitting at the same desktop, each using different keyboards and keyboard layouts. If user A leaves for dinner and user B continues working, user B will soon be locked out of the session due to user A's timer. If user B can't type in user A's keyboard layout, or doesn't have physical access to the seat for whatever reason, then user B will be locked out for good.
Since the password is the information required to unlock the device, my intuition says that, by default, any seat should be able to input that information.
If separate instances are desirable for some other reason, there would at least need to be a way for the instances to communicate with each other to avoid this sort of thing.
Just some ideas 🙂
Locking from one seat doesn't prevent other seats from unlocking.
If you have multiple seats at the same time and both of them have swayidle running, despite you being active on one seat, swayidle will still trigger suspend on another seat. So I'm not sure if there's a proper multiseat support?
Each seat has independent idle state, yes. This is by design.
Either it's flawed by design or it shouldn't tick when seat is inactive.