On Wednesday, April 8, 2020 3:35:08 AM EDT Pekka Paalanen wrote: > On Tue, 07 Apr 2020 23:03:52 -0400 > nerdopolis <bluescreen_aven...@verizon.net> wrote: > > > On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote: > > > On Thu, 02 Apr 2020 22:59:25 -0400 > > > nerdopolis <bluescreen_aven...@verizon.net> wrote: > > > > > ... > > > > > One thing I did notice though is that (as far as leaking input) > > > > > > > > - if run Display Servers on the secondary seat (one, or more than one) > > > > - On seat0, I chvt to a text-mode TTY > > > > - Continuing to use the secondary seat, all keyboard and mouse (gpm) > > > > input > > > > gets sent to the TTY (and the actual display server) > > > > - Switching back to a TTY with a display server, and the seats behave > > > > separate > > > > again > > > > > > > > > > > > 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? > > > > > > The reason why display servers do not cross their input streams like > > > that is that display servers do not use the VT for input. But VT gets > > > its input assigned directly inside the kernel. > > > > > > > > > Thanks, > > > pq > > Hi > > > > I'm not sure, but I am not an expert there. haha. However, I am just > > remembering as far as gpm goes,that one runs in userspace, as root so it's > > also not obeying seats, but THAT part is not the fault of the kernel. > > Yeah, a program running as root can do whatever it chooses to. So that > part is a GPM bug or lack of configuration, I don't know which. > yeah gpm appears to be old. some of the files not modified in 12 years, which is older than logind I think. So forget I said anything about gpm. Sorry about that. > > Maybe a utility could be made like gpm that grabs the keyboard input, but > > only > > forwards the keys to the TTY, if the device is in seat0. But like, I am > > guessing here, and I guess it would be a possibility for the hypothetical > > utility to crash, and then all input would get sent to the TTY anyway. > > That would seem like strange architecture as the VT is implemented in > the kernel, but you would route the input events through userspace. > > Instead of that, I'd promote CONFIG_VT=n and run something like kmscon > to replace the VTs. I expect that to need effort to make work though, > since I haven't heard anything from that direction in years. That is, > disable the kernel VT sub-system completely, and use userspace programs > to offer similar functionality while leveraging logind and other modern > technologies. > > But if people want to keep CONFIG_VT=y, then I don't see any other way > than telling the kernel which input devices belong with the VT and > which do not. Perhaps logind should do that. > yeah, that is probably a ways out maybe, and systems that have an older card that doesn't support mode-setting or a framebuffer will probably not have a way to display a console without CONFIG_VT, right? Unless a generic KMS VESA driver exists or something.
Maybe udev could set some new sysfs attribute on devices or something if they are in seat0 or not. But I don't know how the vt subsystem works, if it can even exclude a particular keyboard like that or not. > > So I'm not sure, also should we change the name of the thread since I think > > my > > original question is answered now? > > Done. I hope this attracts more attention. > Thanks. > > Thanks, > pq _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
