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. 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
Attachment:
pgp5oABY17pSS.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
