[prev in list] [next in list] [prev in thread] [next in thread] 

List:       devuan-dev
Subject:    [devuan-dev] bug#740: bug#740: xserver-xorg-core: keyboard/mouse lockup after switching VC1/2/3
From:       wirelessduck () gmail ! com
Date:       2023-02-22 11:42:11
Message-ID: 51B7F5CA-E134-47BE-A951-6D1B2F0E01EB () gmail ! com
[Download RAW message or body]



> On 3 Feb 2023, at 09:08, Ralph Ronnquist <rrq@mail.rrq.id.au> wrote:
> 
> On Thu, 02 Feb 2023 12:15:06 +1100 "wirelessduck+debian@gmail.com" \
> <wirelessduck+debian@gmail.com> 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. \
_______________________________________________ devuan-dev internal mailing list
devuan-dev@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev


[prev in list] [next in list] [prev in thread] [next in thread]