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 |
From: Mike A. H. <mh...@me...> - 2000-07-21 10:59:41
|
On Fri, 21 Jul 2000, Antoine Martin wrote: >Date: Fri, 21 Jul 2000 11:01:34 +0100 >From: Antoine Martin <an...@go...> >To: lin...@li... >Subject: Re: Linuxconsole-dev digest, Vol 1 #99 - 4 msgs > >lin...@li... wrote: > JESUS!!!! Did you have to quote the ENTIRE digrest of messages, just to add 3 lines of comments? DELETE the thing before replying. I don't need 5 copies of every letter posted here. If it was a mistake, then no problem, you're forgiven, shit happens.. but PLEASE, for the love of the source, don't do it again... Sorry for calling you Jesus.. had to get off the steam.. ;o) It'll never happen again - promise. Now go back to your regularly scheduled program. TTYL -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate ... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4. |
From: James S. <jsi...@ac...> - 2000-07-22 23:55:51
|
> > 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. Per device. > > /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. That would be alot more complex than you think. The best thing to so is set it up to send a EV_STATUS to the app and it can responded. This way the app knows it no longer has the device. KISS. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
From: Vojtech P. <vo...@su...> - 2000-07-23 08:45:53
|
On Sat, Jul 22, 2000 at 08:03:38PM -0400, James Simmons wrote: > > > /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. > > That would be alot more complex than you think. The best thing to so is > set it up to send a EV_STATUS to the app and it can responded. This way > the app knows it no longer has the device. KISS. I agree here. Plus try to connect the device back if the app has it still open and the device appears again. (temporary disconnect on usb due to line noise). Send the app EV_STATUS, ST_CONNECT message in that case. -- Vojtech Pavlik SuSE Labs |