Date: Wed, 18 Sep 2013 17:04:22 +0300 From: Vitaly Magerya <vmagerya@gmail.com> To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@FreeBSD.org> Cc: x11@FreeBSD.org Subject: Re: X.Org devd backend for input devices Message-ID: <5239B2E6.3010002@gmail.com> In-Reply-To: <52399A7D.6070106@FreeBSD.org> References: <522DC3EB.4060607@freebsd.org> <522DE093.9080504@freebsd.org> <5236C259.3020100@gmail.com> <20130916090354.GW33103@ithaqua.etoilebsd.net> <5236F136.5030905@gmail.com> <5238B133.70707@FreeBSD.org> <5238EF64.8080602@gmail.com> <52399A7D.6070106@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/18/2013 15:20, Jean-Sébastien Pédron wrote: > I'm not talking about my particular case; I only have a laptop with > builtin keyboard and USB mouse. For any user, that would be nice to > finally be able to plug multiple keyboards and mices with a specific > configuration for each of them. That would indeed be nice, I agree. I've looked at how it works with Linux: the reason it works there is because multiple clients can open any of the /dev/input/* devices simultaneously, and each one will see exactly the same data coming out. This way all Xorg instances and the console can freely share any input device, no matter who else uses it. As you already know, this is impossible on FreeBSD, since here Xorg is expected to access raw device files, making sharing impossible. What should happen, is FreeBSD should grow an evdev-like layer on top of raw input devices, so they could be safely shared. Until that time, I'm afraid users are stuck with either using moused and have one combined mouse device in X, or giving up on mouse in console. (I would not recommend detaching keyboards from kbdmux, not unless there's a 100% guarantee they'll be attached back: having no mouse in console is an inconvenience -- having no keyboard is a disaster). > You're right, that's not good. We would need an event sent when a > vt-switch occurs, which we can use to make the console grab/release > input devices. I don't know if we have something like that currently. On Xorg side of things, the decision to open or close device files lies entirely on Xorg drivers, and most of them do not have the ability to close a device temporarily; neither can they gracefully handle open(2) errors. What may be possible is to destroy all X input devices on vt switch out, and re-create them on vt switch in, but this will mean that any adjustments done during runtime (like mouse sensitivity change made from GNOME settings panel) will be undone, and applications that like to scan the device tree during startup (e.g. Gimp and Mypaint) will break. So yeah, it can work (given "vt switch" event exists), but it'll be quite a kludge. >>> Regarding the restart of devd, I don't think there's an issue here, >>> because backends should check if an input device is already present in >>> X.Org before adding it again. There's no need to maintain a regular file. >> >> I'm not sure we're on the same page here, but this point can be >> discussed later. > > You mean you would prefer to not check against duplicate input devices > in X.Org and that the script never sends an "add" event if an identical > event was previouly delivered? What I meant was that restarts of devd are a problem for the currently submitted devd backend, because /var/run/devd.pipe will be closed and recreated upon a restart, but the backend won't try to re-open it. There will be no duplicate devices in this case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5239B2E6.3010002>