I know I can target individual mice and keyboards with [hid] but is there a way to keep the linux Xserver from using them as input?

I don't want a secondary or third mouse to move the screen cursor I only want to access it through [hid].

if you were using win, glovepie would do exacly what you want. unluckily its not available for linux as far as i know...i found this
http://lifehacker.com/5042254/operate-your-computer-with-wii-controllers

it says
Linux: Many modern distributions carry their own preferred Wii-interfacing tools in their repositories. Ubuntu, for example, offers the command line tool Wminput, amongst others. I used Wminput and this guide to control the Elisa media center with a Wiimote, and it worked flawlessly—though it obviously required some terminal work. Wminput is actually a re-packaging of the Cwiid project, the closest GlovePIE equivalent for Linux, offering a GUI for mapping controls, a testing panel, and open-ended functionality.

so if you can map multiple mouses with this (as possible with glovepie) and send them to pd via osc it could be a possibility.

it's not so much a wiimote I need to synch... I just would like to target more than 1 mouse through [hid] but only have one mouse control the cursor. As it stands now if I have 3 mice connected, they all control the cursor. Maybe I can try the MPX multipoint Xserver so each mouse has it's own cursor...

glovepie is not only for wii's. it can also read out multiple usb mice and define wichone to use as cursor, while sending coordinates of the others to pd via osc.

I might be wrong, but in attempting to attach a Rock Band guitar, I came across controllermate which might work for your purposes. I don't know which OSs it's available for, outside of Mac however...

@atarikai said:

I know I can target individual mice and keyboards with [hid] but is there a way to keep the linux Xserver from using them as input?

Old thread, I know, but for anyone else who stumbles upon it...

I think what you want is the `xinput` command. First, find out what devices you have:

$ xinput list
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB Trackball                    id=8    [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8 eraser                  id=9    [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8 cursor                  id=10   [slave  pointer  (2)]
⎜   ↳ Wacom Intuos3 6x8                         id=11   [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ Unicomp  Endura Keyboard                    id=13   [slave  keyboard (3)]

You can detach the device, preventing it from controlling the X pointer/keyboard, by using `xinput float`, e.g.

$ xinput float "Logitech USB Trackball"

(or use its numeric ID.) The control stream will still come through via HID. In fact, you can use `xinput` to access the control stream as formatted text as well:

$ xinput test "Logitech USB Trackball"
motion a[0]=1176 a[1]=607 
motion a[0]=1177 a[1]=608 
motion a[0]=1177 a[1]=609 
motion a[0]=1177 a[1]=610 
button press   1 
button release 1

The `xidump` command from the Linux Wacom Project can be used in a similar way.

To reattach the floated device and regain control of the X pointer:

$ xinput reattach "Logitech USB Trackball" "Virtual core pointer"

You can detach keyboard devices as well, but watch for the Enter key getting (virtually) stuck!