Menu
▾
▴
linuxconsole-dev
|
From: Dunlap, R. <ran...@in...> - 2000-07-20 16:49:36
|
> 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 |
|
From: Franz S. <Fra...@la...> - 2000-07-20 17:29:14
|
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. |
|
From: Dunlap, R. <ran...@in...> - 2000-07-20 21:10:35
|
> 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). Linus isn't likely to move them without a patch file. > >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 Is Vojtech Pavlik working with linux-console on this? (Yes, he's listed at http://linuxconsole.sourceforge.net/.) And does the input layer belong with linux-console? That's not at all clear to me. However, I don't claim that it belongs inside drivers/usb either (clearly they can work together, but a logical input layer should be separate from the physical USB drivers). ~Randy |
|
From: Franz S. <Fra...@la...> - 2000-07-20 21:39:26
|
At 23:09 20.07.00, Dunlap, Randy wrote: > > 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). > >Linus isn't likely to move them without a patch file. I have done that last Friday, didn't show up yet until test5-pre3. My immediate reason is that I would like to use the input layer for the CONFIG_ADB stuff, even if CONFIG_USB is not set and moving the input drivers in their own dir seems to be the cleanest solution. > > >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 > >Is Vojtech Pavlik working with linux-console on this? >(Yes, he's listed at http://linuxconsole.sourceforge.net/.) > >And does the input layer belong with linux-console? >That's not at all clear to me. Well, all links I followed so far point to there in the end, and the input layer CVS is hosted there too. >However, I don't claim that it belongs inside drivers/usb >either (clearly they can work together, but a logical >input layer should be separate from the physical USB >drivers). Agreed. And that setup is already realized in the input layer CVS, so doing the move now would greatly simplify further input driver additions/merges during the 2.4 cycle. Franz. |
|
From: Dunlap, R. <ran...@in...> - 2000-07-20 22:13:58
|
> >Linus isn't likely to move them without a patch file. > > I have done that last Friday, didn't show up yet until test5-pre3. My > immediate reason is that I would like to use the input layer for the > CONFIG_ADB stuff, even if CONFIG_USB is not set and moving the input > drivers in their own dir seems to be the cleanest solution. I'm using test5-pre3 and I don't see any such change. Or you just mean that it's not there yet (?). > > > >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 > > > >Is Vojtech Pavlik working with linux-console on this? > >(Yes, he's listed at http://linuxconsole.sourceforge.net/.) > > > >And does the input layer belong with linux-console? > >That's not at all clear to me. > > Well, all links I followed so far point to there in the end, > and the input layer CVS is hosted there too. That's not a very convincing argument that input belongs to linux-console IMO. And there's nothing at http://linuxconsole.sourceforge.net/ under Charter, Objectives, Deliverables about a generic input layer. I'm not fighting you for the input layer, but I would like it to be clear where it belongs, even if that's by itself. According to its web page, linux-console is about terminal emulation (I would argue: no joysticks, tablets, etc. here), multiple video cards, frame buffers, console scrolling, fonts, keymaps (aha, input!, but only keyboard), text modes, and Unicode. So is linux-console a client of the input layer or the provider of the input layer? > >However, I don't claim that it belongs inside drivers/usb > >either (clearly they can work together, but a logical > >input layer should be separate from the physical USB > >drivers). > > Agreed. And that setup is already realized in the input layer > CVS, so doing > the move now would greatly simplify further input driver > additions/merges during the 2.4 cycle. > > Franz. ~Randy |
|
From: Franz S. <Fra...@la...> - 2000-07-22 12:38:38
|
On Fri, 21 Jul 2000, Dunlap, Randy wrote: > > >Linus isn't likely to move them without a patch file. > > > > I have done that last Friday, didn't show up yet until test5-pre3. My > > immediate reason is that I would like to use the input layer for the > > CONFIG_ADB stuff, even if CONFIG_USB is not set and moving the input > > drivers in their own dir seems to be the cleanest solution. > > I'm using test5-pre3 and I don't see any such change. > Or you just mean that it's not there yet (?). It's not there yet :-(, but at least no reject yet :-). I'm quite blocked here, cause I don't want to change too much in the PPC kernel trees until this is in 2.4.0-test. I don't want to hack usb/Config.in and usb/Makefile just to have support for ADB input driver devices in a place where it doesn't belong. > > Well, all links I followed so far point to there in the end, > > and the input layer CVS is hosted there too. > > That's not a very convincing argument that input belongs > to linux-console IMO. And there's nothing at > http://linuxconsole.sourceforge.net/ under Charter, Objectives, > Deliverables about a generic input layer. I think they just merged recently and the webpages are not updated yet. But honestly, I don't know for sure. > I'm not fighting you for the input layer, but I would like > it to be clear where it belongs, even if that's by itself. > According to its web page, linux-console is about terminal > emulation (I would argue: no joysticks, tablets, etc. here), > multiple video cards, frame buffers, console scrolling, fonts, > keymaps (aha, input!, but only keyboard), text modes, and Unicode. > > So is linux-console a client of the input layer or the provider > of the input layer? Hmm, maybe read http://www.suse.cz/development/input/ ? Franz. |
|
From: Vojtech P. <vo...@su...> - 2000-07-22 22:17:16
|
On Thu, Jul 20, 2000 at 03:03:24PM -0700, Dunlap, Randy wrote: > I'm not fighting you for the input layer, but I would like > it to be clear where it belongs, even if that's by itself. > According to its web page, linux-console is about terminal > emulation (I would argue: no joysticks, tablets, etc. here), > multiple video cards, frame buffers, console scrolling, fonts, > keymaps (aha, input!, but only keyboard), text modes, and Unicode. > > So is linux-console a client of the input layer or the provider > of the input layer? More like two cooperating and deeply intertwined projects. Namely in the keyboard part, yes. -- Vojtech Pavlik SuSE Labs |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X