HAL vs Xserver (/dev/input/mice?): convincing X to *not* use a given input device?
 

On an otherwise ordinary desktop Fedora 9 machine,
I'm plugging in a 6-degree-of-freedom joystick (3dconnexion SpacePilot). HAL promptly detects it, but unfortunately so does the X server, which assumes that joystick events should also drive the mouse cursor.

Why? Because /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi
sees that the SpacePilot offers an "input.mouse" capability, and tags it with the "input.x11_driver" => "evdev" property. The X server then looks for input devs with that x11_driver property and autoattaches to them.

By adding an entry under /etc/hal/fdi/policy
I can get partway there:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="input.product" contains="3Dconnexion">
<remove key="input.x11_driver"></remove>
</match>
</device>
</deviceinfo>

This is enough to get the X server to not hold the /dev/input/event<N> device open -- it allows a spacepilot-specific driver to talk to it, so I can read joystick and button actions. Good...

BUT, X still somehow receives joystick nudges
and turns them into mouse motions. /var/log/Xorg.0.log
does not mention having opened the SpacePilot's
/dev/input/event<N> device. The ones it does open are
event<N> for the actual mouse, *AND* /dev/input/mice.

Next guess: maybe any object tagged with info.capability of "input.mouse" gets added to /dev/input/mice automagically? Hoping to end that, I added to the above:

<remove key="info.capabilities"
type="strlist">input.mouse</remove>

This changes the final HAL config for the SpacePilot,
so that "info.capabilities" just lists "input",
but somehow X still receives mouse events.

Re xorg.conf, It doesn't matter whether I omit all InputDevice sections, or use one that mentions "evdev" and the usual mouse conditions.

...
I *can* avoid the problem by disabling HAL altogether,
and using traditional static config of X input devices. But that disables all hotplugging systemwide -- a heavy price to pay. And maybe breaks other things too.

Anyone have a clue where X gets these events from, or how to make it completely ignore them?

Found a bit more on this...
I should mention software versions:
xorg-x11-server-Xorg-1.5.2-3.fc9
xorg-x11-drv-evdev-2.0.8-1.fc9
hal-0.5.11-2.fc9

Disabling HAL doesn't even help.
I need to autoconfigure a USB mouse
and *not* autoconfigure another device, which (falsely, I claim)
tells the USB subsystem that it's another mouse.

Situation seems to be:

- Xorg by default uses HAL-detected (input.x11_driver = "evdev")
devices. But *also*,
- Xorg by default uses /dev/input/mice. The kernel mouse driver,
drivers/input/mousedev.c, constructs the union of all
mouse devices (as detected by the *kernel*, not filtered by HAL)
and merges all their inputs together.

I can't un-merge the blasted SpacePilot's events from /dev/input/mice
without hacking the kernel. I don't want to do that -- this machine
is going far away, and I don't want to simply tell them
to never do another kernel update.

Instead, a partial answer: to Xorg.conf's ServerLayout
(or ServerFlags) section, add:
Option "AutoAddDevices" "false"

This prevents Xorg from swallowing /dev/input/mice. OK.

Then, include an InputDevice section describing the real mouse.
Problem is, I need to have a fixed Device name (like "/dev/input/event4").
Under evdev 1.5, it was possible to write
Option "Name" "*Mouse*"
but this has been removed in evdev 2.0. Feh.

I'm trying to do this now with a HAL fdi callout
(info.callouts.add) to a script which symlinks
the mouse to something with a fixed name, like /dev/ChosenMouse.
It's not working yet...

Ha. Found that a solution (to getting /dev/input/mice or other concentrators to ignore a specific device) had been added to the linux kernel years ago: EVIOCGRAB. E.g.

int grab = 1;
fd = open("/dev/input/event<N>", O_RDWR);
ioctl(fd, EVIOCGRAB, &grab);

This is already used, I guess, by the X server to grab the keyboard away from the console handler while X is active, so that e.g. pressing ctrl-C doesn't send an interrupt to X itself!

The freeware "spacenavd" SpacePilot/etc. driver doesn't use EVIOCGRAB, but it was easy to add that. Works great. Now I just let X autoconfigure input devices (including /dev/input/mice), and run the spacenavd daemon, and all's well. Still under Fedora 9.

Remaining minor problem: if you unplug/replug the Space{Pilot/etc.} USB device, you must restart the spacenavd daemon for it to detect the new device, as currently written. Hmm. For non-root-enabled users this problem won't be minor -- they'll have to reboot.

To be continued, I bet...

You can use ivman to restart services or run other commands when you plug the device back in. I use an a/b switch to switch my trackball back and forth between two systems, and the kde mouse settings (left-handedness and speed) always get lost, so I set up a script to set them manually via xinput each time. Works well.

You can run the ivman daemon either as root or as a regular user, in which case you should be able to set up a sudo command for it.

You might also look into reconfiguring the udev rule for your device. You can set it up to execute external commands on detection as well.

I finally relocated something I remembered seeing recently, but couldn't find when I posted the other day. It appears you can use a dummy "void" driver in xorg.conf. I'm not entirely sure if it will work in the way you want, or with the hal hotplugging. I just thought I'd mention it as a possibility.

I found it on a page that describes setting up evtouch touchscreen devices.

Configure Spacenavigator for Ubuntu 9.04 in this case and Secondlife
 

I came at this post while searching for the same problem, and i did not like the solution to patch the driver. So i researched a bit more and found a more elegant solution.

@David De H : .. the evtouch solution does not work anymore with the hal taking over the X configuration and was meant to do the opposite anyway. (disable all mice).

The trick i found is tell hal to remove the X11 imput device property on auto detecting the Spacenavigator in the hal.

The trick was documented at the faq of the driver of this device :
spacenavd at sourceforge


All what is needed is make a file named : spacenav.fdi
in the directory : /etc/hal/fdi/policy/
with the contents :
After next detection the Space navigator does not push the mouse cursor around anymore.

n.b. the spacenavd device driver for ubuntu is in the Synaptec list :-)

Sorry for bumping this old thread.

Since hal is deprecated, have you come up with a new solution to this?