On Fri, 1 Sep 2023 13:13:12 +0200 Christian Pernegger <pernegger@xxxxxxxxx> wrote: > Alright. I only played around with it in the hopes that it would help > me get some VTs (and VT switching) on seat1. So far, no luck on that > front. The funny thing there is that the kernel, where the VT is implemented, has no idea of any seat assignments. Seat management is completely a userspace invention. This can have some wild (security) consequences: https://gitlab.freedesktop.org/wayland/weston/-/issues/434 IOW, if seat0 is running only VT, you might have keyboards from *any* seat type into that VT *in addition* to any session running on that other seat. It's also common to assume, that only the default seat (seat0) can even have VTs. I don't see how you could have VTs on multiple seats, when the kernel simply has no concept of a seat. There is only one VT system, and that either takes input or does not (there is an ioctl for that). Individual input devices can only be excluded from the VT by opening and grabbing them, meaning nothing else can get them either. It would be best to forget the kernel VTs completely, and implement the equivalent in userspace, which can then be seat-aware and much more featureful (fonts, input methods) than the in-kernel VT can ever be. E.g. kmscon: https://wiki.archlinux.org/title/KMSCON Unfortunately looks like the original repository has been untouched for a decade now. Arch seems to be using this instead: https://github.com/Aetf/kmscon/ You might even want to aim for CONFIG_VT=n, in which case https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/?rdt=37727 might be interesting. Thanks, pq
Attachment:
pgpzeJT_zhy8y.pgp
Description: OpenPGP digital signature
