Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back > Forums > Linux Forums > Linux - Desktop
User Name
Linux - Desktop This forum is for the discussion of all Linux Software used in a desktop context.


  Search this Thread
Old 01-16-2009, 05:31 PM   #1
LQ Newbie
Registered: Jan 2009
Posts: 3

Rep: Reputation: 0
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">
<match key="input.product" contains="3Dconnexion">
<remove key="input.x11_driver"></remove>

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"

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?
Old 01-16-2009, 10:46 PM   #2
LQ Newbie
Registered: Jan 2009
Posts: 3

Original Poster
Rep: Reputation: 0
Found a bit more on this...
I should mention software versions:

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...
Old 01-20-2009, 07:35 PM   #3
LQ Newbie
Registered: Jan 2009
Posts: 3

Original Poster
Rep: Reputation: 0
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...

Last edited by stuartnlevy; 01-20-2009 at 08:10 PM.
Old 01-20-2009, 10:03 PM   #4
David the H.
Bash Guru
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Debian + kde 4 / 5
Posts: 6,834

Rep: Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976
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.
Old 01-23-2009, 05:17 AM   #5
David the H.
Bash Guru
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Debian + kde 4 / 5
Posts: 6,834

Rep: Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976Reputation: 1976
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.

Section "InputDevice"
    Identifier "dummy"
    Driver "void"
    Option "Device" "/dev/input/mice"

And add the following line your your "ServerLayout":

InputDevice "dummy"
I found it on a page that describes setting up evtouch touchscreen devices.
Old 07-30-2009, 12:31 PM   #6
LQ Newbie
Registered: Jul 2009
Posts: 1

Rep: Reputation: 0
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 :
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
        <match key="info.product" contains="3Dconnexion">
            <remove key="input.x11_driver"/>

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 :-)
Old 01-24-2012, 05:06 PM   #7
LQ Newbie
Registered: Jan 2012
Posts: 1

Rep: Reputation: Disabled
Sorry for bumping this old thread.

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


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
startx --> (EE) xf86OpenSerial: Cannot open device /dev/input/mice No such device. TB2 Linux - Software 2 04-04-2007 06:11 PM
permission to access /dev/input/mice in C++ alexandre_fs Programming 4 11-15-2006 08:00 AM
xwindows trouble -no /dev/mouse /dev/input/mice fatblueduck Linux - General 2 06-06-2005 12:03 AM
/dev/input/mice desappeared Hitan Debian 10 04-03-2004 07:58 AM
/dev/input/mice doesn't work Bogdan29 Linux - Newbie 3 05-08-2003 12:19 AM > Forums > Linux Forums > Linux - Desktop

All times are GMT -5. The time now is 03:24 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration