[PATCH] Support filtering of hotplugged input devices

[Dan Nicholson]

On Mon, Oct 26, 2009 at 11:57 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Mon, Oct 26, 2009 at 02:33:49PM -0700, Dan Nicholson wrote:
>> On Sat, Oct 24, 2009 at 9:29 AM, Ilia K. <mail4ilia at gmail.com> wrote:
>> > Hi all.
>> > I've just filled X.Org Bug 24712
>> > <http://bugs.freedesktop.org/show_bug.cgi?id=24712> and attached a
>> > patch to fix the issue.
>> > Follows a copy of bug/fix description I added to bug report.
>> >
>> > The usual deployment of multiseat environment involves running several
>> > instances of X server simultaneously. If hotplugging is enabled, all
>> > keyboards/mice are detected and used by all X servers, which makes multiseat
>> > environment practically unusable. A traditional workaround for this issue was
>> > disabling hotplugging with
>> >  Option  "AutoAddDevices" "false"
>> > However, this workaround misses all the advantages of hotplugging.
>> > Particularly, changing a physical keyboard/mouse requires X server restart.
>> > This is especially annoying when some low-end keyboards/mice/usb hubs "blink"
>> > (go off, then immediately on) due to EMI or something like that.
>> >
>> > A possible solution is to allow hotplugging but "filter out" new input device
>> > notifications for unnecessary devices.
>> >
>> > Attached patch implements the fix.
>> > A user is able to attach x11_layout option to the device which is matched
>> > against current server layout id. If x11_layout option is missing, is "*"
>> > or equals to server layout id, the device is added. Otherwise it's ignored.
>> >
>> > Assume that in xorg.conf AutoAddDevices option is set to true (which is a
>> > default) and two ServerLayout sections are present:
>> > Section "ServerLayout"
>> >        Identifier     "Seat0"
>> >        Screen      0  "Screen0" 0 0
>> > EndSection
>> > Section "ServerLayout"
>> >        Identifier     "Seat1"
>> >        Screen      0  "Screen1" 0 0
>> > EndSection
>> >
>> > Than the following file can be added as
>> > /etc/hal/fdi/policy/30-multiseat_input.fdi :
>> >
>> > <?xml version="1.0" encoding="UTF-8"?>
>> > <!-- define which keyboard/mouse should be used by which instance of X server
>> > -->
>> >
>> > <deviceinfo version="0.2">
>> >  <device>
>> >    <!-- Seat 0 uses usb hub 1-7 only -->
>> >    <match key="info.category" string="input">
>> >      <match key="linux.sysfs_path"
>> > contains="/sys/devices/pci0000:00/0000:00:02.1/usb1/1-7/">
>> >        <merge key="input.x11_options.x11_layout" type="string">Seat0</merge>
>> >      </match>
>> >    </match>
>> >
>> >    <!-- Seat 1 uses usb hub 1-8 only -->
>> >    <match key="info.category" string="input">
>> >      <match key="linux.sysfs_path"
>> > contains="/sys/devices/pci0000:00/0000:00:02.1/usb1/1-8/">
>> >        <merge key="input.x11_options.x11_layout" type="string">Seat1</merge>
>> >      </match>
>> >    </match>
>> >
>> >    <!-- input devices which don't match above rules will be added to all X
>> > instances -->
>> >  </device>
>> > </deviceinfo>
>> >
>> > I've tested the patch (and actually I'm using it right now) on
>> > xorg-server-1.6.0 under Ubuntu 9.04.
>>
>> That seems nice, but how will this work in the future of ConsoleKit
>> multiseat? I'm not crazy about about adding options that are only
>> available through an undocumented hal key, [...]
>
> same with me, I thought CK was the way of the future and we don't have to
> put hacks in like this. If the CK solution is to fill in this key, then OK,
> but otherwise I'd rather not have an option that will soon be either hardly
> supported (because underused) and deprecated one release after its
> introduction.

I'm not actually a multiseat user, but I've ran the scenario through
my mind a couple times. I don't actually know how ConsoleKit currently
handles the input devices besides changing the ACLs. But nothing is
happening to prevent Xorg from opening the devices as root. I think if
this is ever to be handled properly, Xorg would ask CK if the device
it wants to open is on the seat it's representing. Probably need to
ask the CK people how they envision this working.

I would really like this more if it was a documented xorg.conf option
like Layout "Seat1". But I don't think it could even be used until
some other things get fixed up.

--
Dan