Re: USB, HID, unexpected disappearances

[Franz S. <Fra...@la...>]

At 08:30 20.07.00, Alexander Perry wrote:
>If someone jiggles the USB cables while a USB
>joystick is in active use, the stack may detect
>this as the device being dropped and reattached.
>
>In this case, we have no idea whether it is the
>same device, so we naturally take the next free
>device number.  That's fine by me; I see it happen.
>
>Unfortunately, the FD that is reading the existing
>device number doesn't generate any errors, and simply
>keeps repeating the old data back indefinitely.
>The application has no reason to suspect anything
>has gone wrong, and cheerfully lets the game
>continue running with frozen user controls.
>
>If an error would be returned, at least the application
>might be able to act (even if only to abort the game
>in progress).  In the case of FlightGear, I was planning
>to have it search for new joysticks so that it can find
>the new device number and continue to accept input data.
>There might be a fraction of a second glitch in the
>control response while this occurs, but that would be
>much less irritating that the existing behavior.
>
>Is the lack of an error a consequence of a spec that
>we're obeying, or can it easily be changed please ?

I noticed that too, and there was a short discussion recently on the 
linuxconsole-dev list about that. It seems EV_STATUS messages like 
EV_CONNECT/EV_DISCONNECT is an idea they liked. I don't know yet if it's 
better to have these per device or a seperate /dev/input/eventstatus or both.
I'm not convinced each application should do the same work though. Maybe we 
should create an "eventd" userland daemon with a config file that 
attaches/detaches event devices onto a new class of devices, eg. 
/dev/input/eventmixX, based on the EV_STATUS messages and the rules in the 
config file. That way most applications do not even need to know that this 
can happen and can just keep on reading the FD.
My interest in here, I think it would be nice to attach more than one 
device to a eventmixX device, eg. all mice or all keyboards (or both?), 
similar to /dev/input/mice. That would make it a lot easier to port 
applications to the input layer.

Franz.

PS. Can someone please turn off this useless [linux-usb-*] subject header 
corruption? When the lists moved away from Suse, I was happy cause I 
thought this was a Suse specific setup and the new list welcome message 
didn't have the header munging :-). But then I got the first real 
message... :-(( I feel like being treated as a windummy...