Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
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: James S. <jsi...@ac...> - 2000-07-22 23:27:21
|
> I'd suggest first converting the busmouse drivers (already done in the > CVS), and then adding the serial mouse driver, Linus used to be strongly > against serial mouse protocols being in kernel. But when it'll all fit > nicely together, I think he'll see the cleanliness of the approach. I sent in patch that creates a drivers/input directory for 2.4.X for linus. I hope he takes it. It's very big. We can send a second patch for the busmouse. I think he will take the serial mouse driver since it does make for a unified mouse protocol. I guess the only think that will not go in are the keyboard drivers. I also see new keyboard driver where added recently (scan_keyb.c and hp600_keyb.c). 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-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 |
|
From: Vojtech P. <vo...@su...> - 2000-07-22 22:13:24
|
On Thu, Jul 20, 2000 at 04:07:52PM +0200, Franz Sirl wrote: > 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. I'd suggest KEY_INTL1 or KEY_LANG1 be the number KEY_JPN has now. What do you think? -- Vojtech Pavlik SuSE Labs |
|
From: Vojtech P. <vo...@su...> - 2000-07-22 21:53:07
|
On Fri, Jul 14, 2000 at 08:07:05PM +0200, Christoph Hellwig wrote: > > Should I first try to send Linus a patch to create drivers/input and > > move the input stuff over from drivers/usb? Doing nothing else to the code, > > just a pure move and Config.in/Makefile.in adjustment? > > seems like a good ide to me > - first create drivers/input and move the stuff from drivers/usb and > drivers/char/joystick over, then > - add your adb stuff, then > - add the serial mouse driver, and then maybe > - convert the busmouse drivers > > That's a real <de>Salami-Taktik</de>. I'd suggest first converting the busmouse drivers (already done in the CVS), and then adding the serial mouse driver, Linus used to be strongly against serial mouse protocols being in kernel. But when it'll all fit nicely together, I think he'll see the cleanliness of the approach. -- Vojtech Pavlik SuSE Labs |
|
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: Franz S. <Fra...@la...> - 2000-07-22 12:20:19
|
On Thu, 20 Jul 2000, Franz Sirl wrote: > 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. I have done a patch now for this. Please note that evtest.c and input.h disagree on their understanding of keycode 179 and 180. Franz. |
|
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: 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: 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-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 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 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 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 14:08:07
|
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. |
|
From: Franz S. <Fra...@la...> - 2000-07-20 10:37:25
|
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... |
|
From: James S. <jsi...@ac...> - 2000-07-18 19:44:38
|
> > Certainly I would prefer to > > get a separate drivers/input/ in 2.4 (it's the much cleaner solution), but > > I fear it might not be accepted... Anyone already talked to Linus about > > that? > > /me not Sent email to kernel list to see if this could happen. I could generate a patch for this. I will see the response for this. > seems like a good ide to me I also like the idea. > - first create drivers/input and move the stuff from drivers/usb and > drivers/char/joystick over, then > - add your adb stuff, then > - add the serial mouse driver, and then maybe > - convert the busmouse drivers That's what should be done. 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: James S. <jsi...@ac...> - 2000-07-18 19:41:45
|
On Fri, 14 Jul 2000, Christoph Hellwig wrote: > On Fri, Jul 14, 2000 at 01:15:57PM +0200, Franz Sirl wrote: > > - the input layer drivers are not built if CONFIG_USB=n, can that please be > > changed in 2.4? > > This is really a good idea. In 2.4 the joystick driver use the input layer, too. > IMHO we should move all input drivers to drivers/input and maybe add the > serial mouse driver and convert the busmouse drivers to the input layer. > > This would give linux 2.4 a coherent mouse interface without too much work. I like to see this changed as well. I have been using a serial mouse for quite sometime with the input layer from our CVS. It works quite nicely. The only thing I can't see for 2.4.X converting all the keyboards to the input layer since 2.4.0 final is so close. Everything could be converted over. 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: Christoph H. <chh...@gm...> - 2000-07-14 18:12:19
|
On Fri, Jul 14, 2000 at 08:00:33PM +0200, Franz Sirl wrote: > Maybe already too invasive for Linus right now, that's why I kept my > request to a minimum, it would only require a small reshuffle of > drivers/usb/Config.in and drivers/usb/Makefile. Ok. > Certainly I would prefer to > get a separate drivers/input/ in 2.4 (it's the much cleaner solution), but > I fear it might not be accepted... Anyone already talked to Linus about > that? /me not > Should I first try to send Linus a patch to create drivers/input and > move the input stuff over from drivers/usb? Doing nothing else to the code, > just a pure move and Config.in/Makefile.in adjustment? seems like a good ide to me - first create drivers/input and move the stuff from drivers/usb and drivers/char/joystick over, then - add your adb stuff, then - add the serial mouse driver, and then maybe - convert the busmouse drivers That's a real <de>Salami-Taktik</de>. Christoph -- Always remember that you are unique. Just like everyone else. |
|
From: Franz S. <Fra...@la...> - 2000-07-14 18:01:09
|
At 14:37 14.07.00, Christoph Hellwig wrote: >On Fri, Jul 14, 2000 at 01:15:57PM +0200, Franz Sirl wrote: > > - the input layer drivers are not built if CONFIG_USB=n, can that > please be > > changed in 2.4? > >This is really a good idea. In 2.4 the joystick driver use the input >layer, too. >IMHO we should move all input drivers to drivers/input and maybe add the >serial mouse driver and convert the busmouse drivers to the input layer. > >This would give linux 2.4 a coherent mouse interface without too much work. Maybe already too invasive for Linus right now, that's why I kept my request to a minimum, it would only require a small reshuffle of drivers/usb/Config.in and drivers/usb/Makefile. Certainly I would prefer to get a separate drivers/input/ in 2.4 (it's the much cleaner solution), but I fear it might not be accepted... Anyone already talked to Linus about that? Should I first try to send Linus a patch to create drivers/input and move the input stuff over from drivers/usb? Doing nothing else to the code, just a pure move and Config.in/Makefile.in adjustment? Franz. |
|
From: Christoph H. <chh...@gm...> - 2000-07-14 15:44:54
|
On Fri, Jul 14, 2000 at 01:15:57PM +0200, Franz Sirl wrote: > - the input layer drivers are not built if CONFIG_USB=n, can that please be > changed in 2.4? This is really a good idea. In 2.4 the joystick driver use the input layer, too. IMHO we should move all input drivers to drivers/input and maybe add the serial mouse driver and convert the busmouse drivers to the input layer. This would give linux 2.4 a coherent mouse interface without too much work. Christoph -- Always remember that you are unique. Just like everyone else. |
|
From: Franz S. <Fra...@la...> - 2000-07-14 11:16:26
|
Hi, the move to the input layer on PPC with the 2.2 USB backport works quite well so far, the problems remaining so far are: - the input layer drivers are not built if CONFIG_USB=n, can that please be changed in 2.4? So we can get these built if CONFIG_ADB is set? I'll take care to call input_init_module() in adb.c if CONFIG_USB=n then. This is quite important for us, since we could completely convert ADB to the input layer in 2.4 already. - keyboard problems with japanese keyboards, on both USB and ADB some keys are not recognized yet: <Hiragana_Katakana> key aka kana (KEY_JPN?), USB 0x90, ADB 0x68 <Eisu> key aka "english" (KEY_?), USB 0x91, ADB 0x66 _ key, underscore (KEY_?), USB 0x87, ADB 0x5e |\ key, bar+backslash (KEY_?), USB 0x89, ADB 0x5d see http://developer.apple.com/technotes/tn/tn1152.html#JISKeyboards for a picture of the keyboard. I'll get a list of the ADB keycodes soon, so probably I can overlap the _ and the |\ key with existing KEY_* mappings, that are present on ANSI/ISO keyboards, but not on JIS keyboards. For the "kana" key, the choice is pretty obvious, or? Don't know what to do with the "eisu" one yet... - one button mouse support: this requires small changes in keybdev.c and mousedev.c, all wrapped into CONFIG_MAC_EMUMOUSEBTN. Any objections to include that? Franz. |
|
From: James S. <jsi...@ac...> - 2000-07-13 13:47:47
|
Hi! I'm going to be away until next week tuesday. The current is against a test4-pre3. Unfortunely the standard kernel has problems. Since I will be away I can update it against a test4-pre6 kernel which I heard actually compiles. Vojtech if you have spare time could you synce up the CVS with pre6. Thank you. 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: James S. <jsi...@ac...> - 2000-07-13 00:06:23
|
Hi! I just up dated the kernel to test4-pre3. Go test it. Especially if you have a multihead setup. 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: James S. <jsi...@ac...> - 2000-07-12 15:03:07
|
Hi!
I bought a new adapter for my second keyboard. The old one died. So I
had two keyboard hooked up to my computer. Fixes a few bugs. Now if you
have two displays and two keyboards text will displayed to a specific
screen. Since I have only one vga card and no mda but 2 keyboards I can
only use the one keyboard. then I tested the /dev/input interface and both
keyboards showed up and I could use both of them :-) I just updated the
cvs to test3 but discovered the default kernel is broken. Will have to
update again. By tonight. The fix for the timer bug is
--- v2.4.0-test3/linux/kernel/timer.c Mon Jul 10 16:47:27 2000
+++ linux/kernel/timer.c Tue Jul 11 09:25:36 2000
@@ -577,7 +577,7 @@
p->counter = 0;
p->need_resched = 1;
}
- if (p->priority < DEF_PRIORITY)
+ if (p->nice > 0)
kstat.cpu_nice += user_tick;
else
kstat.cpu_user += user_tick;
Your kernel will compile then for now. Go test it :)
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
|
1998 messages has been excluded from this view by a project administrator.
