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