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

[Peter Hutterer <peter.hutterer@xxxxxxxxx>]

On Thu, Apr 09, 2020 at 02:28:13PM +0300, Pekka Paalanen wrote:
> On Thu, 9 Apr 2020 13:01:56 +0200
> Michał Zegan <webczat_200@xxxxxxxxxxxxxx> wrote:
> 
> > W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze:
> > > On Thu, 9 Apr 2020 09:46:08 +0200
> > > Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> > >   
> > >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaalanen@xxxxxxxxx) 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?

EVIOCGRAB is the ioctl, takes a boolean and when a grab is active it allows
for only one consumer of the evdev events. However: this 'one consumer'
policy includes in-kernel consumers of those events. We used to grab the
device unconditionally the evdev xorg driver 10-ish years ago and it stops
things like rfkill from working correctly [1]. so eventually we fixed all
the server bits that we didn't need the grab anymore.

the synaptics driver did it for a long time too because it was harmless and
was the cheap way to avoid duplicate events if the same device was added
twice which was a bit of a problem back then.

There's a legitimate reason for the grabs and that is basically the use-case
of redirecting a device. You *could* work around that now with
LIBINPUT_IGNORE_DEVICE on the original device but that's not as flexible as
a run-time grab.

These cases also prevent the display server from grabbing a device, if say
libinput had an EVIOCGRAB on all devices you couldn't run brltty anymore. or
at least not *after* libinput started up.

Cheers,
   Peter

[1] and things like /dev/input/mice but don't quote me on that, I'd have to
test this but it doesn't matter much anymore anyway.


> > > 
> > > 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


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