Menu
▾
▴
Re: Linuxconsole-dev digest, Vol 1 #99 - 4 msgs
|
From: Antoine M. <an...@go...> - 2000-07-21 10:07:12
|
lin...@li... wrote: > Send Linuxconsole-dev mailing list submissions to > lin...@li... > > To subscribe or unsubscribe via the web, visit > http://lists.sourceforge.net/mailman/listinfo/linuxconsole-dev > or, via email, send a message with subject or body 'help' to > lin...@li... > You can reach the person managing the list at > lin...@li... > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Linuxconsole-dev digest..." > > Today's Topics: > > 1. Re: USB, HID, unexpected disappearances (Franz Sirl) > 2. Asian keyboards and input.h KEY_* defines (Franz Sirl) > 3. RE: [linux-usb-devel] Re: USB, HID, unexpected disappearances (Dunlap, Randy) > 4. RE: [linux-usb-devel] Re: USB, HID, unexpected disappearances (Franz Sirl) > > --__--__-- > > Message: 1 > Date: Thu, 20 Jul 2000 12:36:58 +0200 > To: lin...@li... > From: Franz Sirl <Fra...@la...> > Subject: Re: USB, HID, unexpected disappearances > Cc: Linux console project <lin...@li...> > > 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. I have never contributed to this list, but I have followed it regularly in the last 3 months and here's my 2p: applications should not know about all these low level connection stuff, I much prefer the idea of the userland deamon. > > > 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... > > --__--__-- > > Message: 2 > Date: Thu, 20 Jul 2000 16:07:52 +0200 > To: Linux console project <lin...@li...> > From: Franz Sirl <Fra...@la...> > Subject: Asian keyboards and input.h KEY_* defines > > Hi, > > I have a hard time thinking about a reasonable mapping for the 4 extra keys > available on a Apple japanese USB and ADB keyboards (and this can only get > worse as more asian keyboards layouts will be supported). The Apple version > correctly uses international and language keys as defined in the HUT spec > 1.1, one of them is currently already mapped to KEY_JPN in hid.c, but the > others... > > So I suggest to add defines for KEY_INTL1-9 and KEY_LANG1-9 in input.h, > with a comment that they should be used as specified in the HUT. This would > in turn make KEY_JPN superfluous. > > Franz. > > --__--__-- > > Message: 3 > From: "Dunlap, Randy" <ran...@in...> > To: "'lin...@li...'" > <lin...@li...> > Cc: Linux console project <lin...@li...> > Subject: RE: [linux-usb-devel] Re: USB, HID, unexpected disappearances > Date: Thu, 20 Jul 2000 09:49:28 -0700 > charset="iso-8859-1" > > > From: Franz Sirl [mailto: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. > > Sounds like a cable/device problem to me. > > > >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. > > Is the device disconnected and dropped, or just > dropped without being disconnected (as far as the > USB stack knows)? If the USB stack does a disconnect > for the device and then another connect happens, > the connected device will be assigned the same > device number. Or is this happening too quickly > for that to 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. > > So linux-console discusses USB also? Man, I have too much > email already. :( > > ~Randy > > --__--__-- > > Message: 4 > Date: Thu, 20 Jul 2000 19:28:54 +0200 > To: Linux console project <lin...@li...> > From: Franz Sirl <Fra...@la...> > Subject: RE: [linux-usb-devel] Re: USB, HID, unexpected disappearances > Cc: "'lin...@li...'" <lin...@li...> > .com> > > At 18:49 20.07.00, Dunlap, Randy wrote: > > > From: Franz Sirl [mailto:Fra...@la...] > > > > > > At 08:30 20.07.00, Alexander Perry wrote: > > > >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. > > > >Is the device disconnected and dropped, or just > >dropped without being disconnected (as far as the > >USB stack knows)? If the USB stack does a disconnect > >for the device and then another connect happens, > >the connected device will be assigned the same > >device number. Or is this happening too quickly > >for that to happen? > > That's why I moved the discussion to linuxconsole-dev, this is an input > layer problem, not a USB problem (hopefully Linus will move that stuff over > to drivers/input before 2.4). It will probably get assigned the same USB > ID, but if the application still holds eg. /dev/input/js0 open, it will now > be assigned to /dev/input/js1 :-(. And the application won't notice at all. > > >So linux-console discusses USB also? Man, I have too much > >email already. :( > > Heh, then move the input drivers from drivers/usb to drivers/input where > they belong. With a README file somewhere, the probability that > bugs/problems will get reported to the right list should be somewhat higher > :-). > > Franz. > > --__--__-- > > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linuxconsole-dev > > End of Linuxconsole-dev Digest |
