Re: All non-seat0 input devices leak into VT if no display server on seat0

[nerdopolis <bluescreen_avenger@xxxxxxxxxxx>]

On Wednesday, April 8, 2020 3:35:08 AM EDT Pekka Paalanen wrote:
> On Tue, 07 Apr 2020 23:03:52 -0400
> nerdopolis <bluescreen_avenger@xxxxxxxxxxx> wrote:
> 
> > On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote:
> > > On Thu, 02 Apr 2020 22:59:25 -0400
> > > nerdopolis <bluescreen_avenger@xxxxxxxxxxx> wrote:
> > >   
> 
> ...
> 
> > > > One thing I did notice though is that (as far as leaking input)
> > > > 
> > > > - if run Display Servers on the secondary seat (one, or more than one)
> > > > - On seat0, I chvt to a text-mode TTY
> > > > - Continuing to use the secondary seat, all keyboard and mouse (gpm) input
> > > >   gets sent to the TTY (and the actual display server)
> > > > - Switching back to a TTY with a display server, and the seats behave separate
> > > >   again
> > > > 
> > > > 
> > > > My (maybe bad) guess is that it would need to be addressed in the kernel though
> > > > And the CanMultiSession attribute on non-seat0 doesn't matter when the problem 
> > > > is all input from all devices gets sent to seat0 when seat0 is in a text mode
> > > > TTY
> > > > 
> > > > ..and even if you have some kmscon like thing installed, there could still be 
> > > > text mode TTYs  
> > > 
> > > Hi,
> > > 
> > > that is both an excellent and horrifying observation. And it makes
> > > perfect sense to me why that happens, just like you think: seat
> > > assignments happen in userspace as udev properties. Someone would have
> > > to explicitly tell the kernel about it too to fix this, e.g. remove
> > > non-seat0 devices from the VT machinery.
> > > 
> > > I wonder if such kernel interface even exists?
> > > 
> > > The reason why display servers do not cross their input streams like
> > > that is that display servers do not use the VT for input. But VT gets
> > > its input assigned directly inside the kernel.
> > > 
> > > 
> > > Thanks,
> > > pq  
> > Hi
> > 
> > I'm not sure, but I am not an expert there. haha. However, I am just 
> > remembering as far as gpm goes,that one runs in userspace, as root so it's 
> > also not obeying seats, but THAT part is not the fault of the kernel. 
> 
> Yeah, a program running as root can do whatever it chooses to. So that
> part is a GPM bug or lack of configuration, I don't know which.
> 
yeah gpm appears to be old. some of the files not modified in 12 years, which
is older than logind I think. So forget I said anything about gpm. Sorry about
that.
> > Maybe a utility could be made like gpm that grabs the keyboard input, but only
> > forwards the keys to the TTY, if the device is in seat0. But like, I am
> > guessing here, and I guess it would be a possibility for the hypothetical
> > utility to crash, and then all input would get sent to the TTY anyway.
> 
> That would seem like strange architecture as the VT is implemented in
> the kernel, but you would route the input events through userspace.
> 
> Instead of that, I'd promote CONFIG_VT=n and run something like kmscon
> to replace the VTs. I expect that to need effort to make work though,
> since I haven't heard anything from that direction in years. That is,
> disable the kernel VT sub-system completely, and use userspace programs
> to offer similar functionality while leveraging logind and other modern
> technologies.
> 
> But if people want to keep CONFIG_VT=y, then I don't see any other way
> than telling the kernel which input devices belong with the VT and
> which do not. Perhaps logind should do that.
> 
yeah, that is probably a ways out maybe, and systems that have an older card
that doesn't support mode-setting or a framebuffer will probably not have a way
to display a console without CONFIG_VT, right? Unless a generic KMS VESA driver
exists or something.


Maybe udev could set some new sysfs attribute on devices or something if they
are in seat0 or not. But I don't know how the vt subsystem works, if it can
even exclude a particular keyboard like that or not.
> > So I'm not sure, also should we change the name of the thread since I think my
> > original question is answered now?
> 
> Done. I hope this attracts more attention.
> 
Thanks. 
> 
> Thanks,
> pq




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel