[ltp] Kernel 2.6 and two mice

[Edi Weitz]

On Tue, 25 May 2004 19:26:32 +0000, James Hawtin <oolon@ankh.org> wrote:

> No that is as it should be mice is the unified device for all (USB)
> mice on the system, mouse1 one mouse currently plugged in. If you
> unplug it, mouse1 stops being a valid mouse device, when you plug it
> back it is a new mouse, and is assigned the the first available
> mouse device mouse1. Just because it was assigned the same device it
> does not mean that all programs have to keep working with it. It
> could have been a completely different mouse...
>
> Think of it this way if you tail -f a file then delete the file then
> create a new file with the same name, tail -f does not magically
> pick up the new file it just stops.... The same is true of mouse1
> the name may be the same but its a different device. "mice" a
> special device to unify mice on the system and to be aways present.

OK, that sounds reasonable to me and would explain why the X server
"loses" the mouse. Two questions remain, though:

1. If I do

     - cat /dev/input/mouse1
     - move mouse
     - unplug mouse
     - plug mouse back in
     - cat /dev/input/mouse1
     - move mouse

   where I really issue a new 'cat' command /after/ I've re-plugged
   the mouse, 'cat' should pick up the /new/ device /dev/input/mouse1
   and show something if I move the mouse, shouldn't it? I don't
   expect the first 'cat' to show anything because it's still
   observing the 'old' device (so to say), but a newly started 'cat'
   should see something, I think.

2. If I have to live with the fact that I can only use /dev/input/mice
   how can I achieve the behaviour that I previously had? (See the
   email that started this thread.) This worked with kernel 2.4
   because /dev/input/mice only bundled the USB mice but now the PS/2
   mouse also goes through the 'unified' device. Does that mean I
   can't have both - separate configurations for two different mouse
   types /and/ the ability to hotplug? Looks like 2.6 is a step
   backwards in this regard... :(

Thanks,
Edi.