[systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0

[Pekka Paalanen]

On Thu, 9 Apr 2020 13:01:56 +0200
Michał Zegan <webczat_200 at poczta.onet.pl> wrote:

> W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze:
> > On Thu, 9 Apr 2020 09:46:08 +0200
> > Lennart Poettering <lennart at poettering.net> wrote:
> >   
> >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaalanen at gmail.com) wrote:
> >>  
> >>>> 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?    
> >>
> >> There are ioctls for that in the input layer if iirc, but i don't
> >> remember how precisely this works. You are hacking on a compositor, you
> >> should know ;-)  
> > 
> > Hi,
> > 
> > while hacking on a compositor, I have never needed to stop specific
> > input devices from being routed to the VT system while allowing others.
> > If a compositor runs on seat0, it will disable the whole VT input side
> > (among other things) with one VT ioctl IIRC. In this case that is not
> > wanted, because seat0 is intended to be used with the VT text mode and
> > VT input, so disabling all VT input would stop also the wanted input.  
> Not sure if it's related and I don't know details, but some software
> like brltty or a fenrir console screenreader are routinely taking
> control over single input devices in text mode. The whole point is that
> they take control over all real keyboards, and have some uinput device
> that is still wired to vt, so that I can send keypresses not supported
> by terminals like insert+something, and these that do not map to
> screenreader would be injected to the uinput and appear on vt.
> I thought display servers also take exclusive control over specific
> input devices... hmm. If they do then this behavior should likely not be
> happening as they still are in control of the devices.

Hi,

I have heard of the evdev grab ioctl, which does pretty much what you
describe. I seem to recall there to be a reason why display servers
should not use it, but I have forgot. Maybe it is exactly because of
the kind of use cases you describe though: some special software that
wants to intercept some very specific input devices. If the display
server itself used that same mechanism, then the special software
cannot do its job.

Peter, would you know?


Thanks,
pq

> > 
> > Also a display server that runs on non-seat0 seat should never touch
> > anything about VTs AFAIU. I would expect it to not have the permissions
> > to do that even if it wanted to.
> > 
> > Like you said it being a kernel or logind bug, this is something that
> > needs to be taken care of below the compositor, automatically keyed by
> > the input device seat assignments.
> > 
> > 
> > Thanks,
> > pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200409/7be471ec/attachment.sig>