On Thu, 02 Feb 2023 12:15:06 +1100 "wirelessduck+debian@???" <wirelessduck+debian@???> wrote:
> Package: xserver-xorg-core
> Version: 2:21.1.6-1devuan1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>

>    * What led up to the situation?
> Install newer version of xserver-xorg-core to test libseat1 elogind support without seatd
> ...
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?

>
> Login to VC1 as root.
> Install libseat1 and newer versions of xserver-xorg-core and xserver-common.
> Logout and login to VC1 as normal user.
> Run startx to start openbox on VC1.
>
> Switch to VC2 (ctrl+alt+f2) and login again as normal user.
> Run startx to start openbox on VC2.
>
> Switch to VC3 (ctrl+alt+f3) and login again as normal user.
> Run startx to start openbox on VC3.
>
> Switch back to VC1 (ctrl+alt+f1).
> Mouse and keyboard are now unresponsive. After unplug/replug mouse and keyboard they become responsive again.
>
> Continue switching between VC1/2/3. The mouse/keyboard will become unresponsive each time until the usb plugs are unplug/replug again.

At this time, there should have been separate Xorg log files by the
user(s) that started X. Ideally it should be different non-root users
in each VC, and then each of them would gain a log file; probably
saved in their respective ~/.local/share/xorg/ directory. It's thus
good to clean out those directories before the test session, or at
least clean out each before running startx.

Further, the non-root users should not be in groups tty or input, but
need to be in group video.

And, it would be really useful with a snap of the Xorg log for the VC
in focus exactly when the problem is discovered, and before remedy
actions have been taken.

To be able do that, you might need a separate machine with an ssh (or
otherwise remote) login to the test machine, and then snapshot that
log file via that remote login before changing VC or unplug/plug
devices on that problem machine.

Or otherwise, make sure that the user actions are well separated in
the log, eg by waiting some 5 minutes between user actions. Such time
gaps in the log are good as "markers" between the various user
actions.

>
> I then downgraded both xorg packages back to daedalus version and confirmed the issue did not occur under daedalus package versions.
>

That was good :)

> I then re-installed the newer testing versions of both xorg packages and repeated the testing but was unable to reproduce the problem.

Hmm. That is very confusing! It almost sounds like something ended up
differently in the device handling packages with the downgrad + upgrade.

It would however be really good if you could re-confirm the test
scenario with 3 different VC and non-root users (not in groups tty or
input) each running startx, and then shifting successfully between the
VC,

> Hopefully something in the xorg log file might provide some clue to what happened.

Though, isn't that log file from the latest session, when things
worked?

Also, it looks like X was started by root in all cases?

> ...