> On 3 Feb 2023, at 09:08, Ralph Ronnquist <rrq@???> wrote:
>
> 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?
>
>> ...

Thanks for the pointers. I’ll get back onto testing this again as soon as the dreaded covid and associated brain fog has passed through my system. I didn’t realise there were xorg log files in home directory so anything I provided would have been from /var/log. I will setup multiple user accounts for the next test.