Hi! Here go some doc updates ... -- Vojtech Pavlik SuSE Labs
diff -urN linux-2.3.99-pre3-old/Documentation/usb/acm.txt linux/Documentation/usb/acm.txt --- linux-2.3.99-pre3-old/Documentation/usb/acm.txt Wed Jan 5 01:12:59 2000 +++ linux/Documentation/usb/acm.txt Sat Apr 1 14:06:18 2000 @@ -1,94 +1,138 @@ -The ACM driver works with modems and ISDN TAs that use the USB Abstract -Control Model standard. - -**************************** -Test it: -Watch out, the driver is not stable and tested. Sync often, make backups, -most importand: don't blame me... - -Create device files: -mknod /dev/ttyACM0 c 166 0 -mknod /dev/ttyACM1 c 166 1 -mknod /dev/ttyACM2 c 166 2 -mknod /dev/ttyACM3 c 166 3 -Compile a kernel with support for your host controller (uhci only for now!) -and support for ACM. Boot this kernel. If you connect your device to the -USB bus you should see messages like the following: - -Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1 -Jul 19 20:14:29 office kernel: Found 02:09 -Jul 19 20:14:29 office kernel: Found 04:09 -Jul 19 20:14:29 office kernel: Found 05:07 -Jul 19 20:14:29 office last message repeated 2 times -Jul 19 20:14:29 office kernel: parsed = 39 len = 67 -Jul 19 20:14:29 office kernel: Expected descriptor 04/09, got 02/09 - skipping -Jul 19 20:14:29 office kernel: 0 09 -Jul 19 20:14:29 office kernel: 1 02 -Jul 19 20:14:29 office kernel: 2 43 -Jul 19 20:14:29 office kernel: 3 00 -Jul 19 20:14:29 office kernel: 4 02 -Jul 19 20:14:29 office kernel: 5 02 -Jul 19 20:14:29 office kernel: 6 04 -Jul 19 20:14:29 office kernel: 7 60 -Jul 19 20:14:29 office kernel: 8 00 -Jul 19 20:14:29 office kernel: Found 04:09 -Jul 19 20:14:29 office kernel: Found 02:09 -Jul 19 20:14:29 office kernel: Found 04:09 -Jul 19 20:14:29 office kernel: Found 05:07 -Jul 19 20:14:29 office kernel: Found 04:09 -Jul 19 20:14:29 office kernel: Found 05:07 -Jul 19 20:14:29 office kernel: Found 05:07 -Jul 19 20:14:29 office kernel: parsed = 67 len = 0 -Jul 19 20:14:29 office kernel: getstringtable -Jul 19 20:14:29 office kernel: acm_probe -Jul 19 20:14:29 office kernel: USB ACM found - -Watch out for the line: -Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1 -and the line: -Jul 19 20:14:29 office kernel: USB ACM found -These two lines show that the device was seen by the usb host controller and -then recognized by the acm driver as a valid device. - -If you use a terminal emulation software like minicom with /dev/ttyACM0 you -should be able to send AT commands to your device and get responses. I've -been able to do zmodem downloads to another pc. However downloads from one -ISDN TA to another ISDN TA connected to the same PC didn't work. Don't -know why. Flow control is not finised after all and i'd guess there might -be problems on heavily loades PCs. I also did some tests with ppp but i'm -not finised with this. There might be a chance to get it working. However -i'd like to know if your device is recognized as an ACM device. I'm also -interested if the thing is stable or if it crashes. -(should i say how it crases?) - -You should be able to add and remove devices from the bus. The driver will -always try to fill up unused ttys. This means if you hotplug devices their -order may have changed after reboot. This is not the behaviour Linus liked -to see but it's ok for now. (I hope ;-) - -Please report your experiences to me: [EMAIL PROTECTED] - -*************************** -I've tested it with: -3Com ISDN Pro TA. - -It should work with (That means i know these devices conform to ACM): -3Com Office Connect Modem -3Com Sportster USB (I think that's what it's called) - -*************************** -Many thanks to 3Com which did not only support me with hardware but also -with technical support in USB questions. They also allowed me to do tests in -their lab. Great! - -*************************** -Known bugs: -Flow control not tested (likely not to work) -Some tty function calls not implemented (putchar, etc...) -Huge amounts of debug output (compile in [*] Magic SysRq key and press ALT+PRTSCR+0 ) -Not all mem is freed at close (need terminate irq in hcd) - -*************************** -Have fun, - Armin Fuerst + Linux ACM driver v0.16 + (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]> + Sponsored by SuSE +---------------------------------------------------------------------------- + +0. Disclaimer +~~~~~~~~~~~~~ + This program is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by the Free +Software Foundation; either version 2 of the License, or (at your option) +any later version. + + This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +more details. + + You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., 59 +Temple Place, Suite 330, Boston, MA 02111-1307 USA + + Should you need to contact me, the author, you can do so either by e-mail +- mail your message to <[EMAIL PROTECTED]>, or by paper mail: Vojtech Pavlik, +Ucitelska 1576, Prague 8, 182 00 Czech Republic + + For your convenience, the GNU General Public License version 2 is included +in the package: See the file COPYING. + +1. Usage +~~~~~~~~ + The drivers/usb/acm.c drivers works with USB modems and USB ISDN terminal +adapters that conform to the Universal Serial Bus Communication Device Class +Abstract Control Model (USB CDC ACM) specification. + + Many modems do, here is a list of those I know of: + + 3Com OfficeConnect 56k + 3Com Voice FaxModem Pro + 3Com Sportster + MultiTech MultiModem 56k + Zoom 2986L FaxModem + Compaq 56k FaxModem + ELSA Microlink 56k + + I know of one ISDN TA that does work with the acm driver: + + 3Com USR ISDN Pro TA + + Unfortunately many modems and most ISDN TAs use proprietary interfaces and +thus won't work with this drivers. Check for ACM compliance before buying. + + The driver (with devfs) creates these devices in /dev/usb/acm: + + crw-r--r-- 1 root root 166, 0 Apr 1 10:49 0 + crw-r--r-- 1 root root 166, 1 Apr 1 10:49 1 + crw-r--r-- 1 root root 166, 2 Apr 1 10:49 2 + + And so on, up to 31, with the limit being possible to change in acm.c to up +to 256, so you can use up to 256 USB modems with one computer (you'll need +three USB cards for that, though). + + If you don't use devfs, then you can create device nodes with the same +minor/major numbers anywhere you want, but either the above location or +/dev/usb/ttyACM0 is preferred. + + To use the modems you need these modules loaded: + + usbcore.o + usb-[uo]hci.o or uhci.o + acm.o + + After that, the modem[s] should be accessible. You should be able to use +minicom, ppp and mgetty with them. + +2. Verifying that it works +~~~~~~~~~~~~~~~~~~~~~~~~~~ + The first step would be to check /proc/bus/usb/devices, it should look +like this: + +T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 +D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 +P: Vendor=0000 ProdID=0000 Rev= 0.00 +S: Product=USB UHCI Root Hub +S: SerialNumber=6800 +C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub +E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms +T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 +D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 +P: Vendor=04c1 ProdID=008f Rev= 2.07 +S: Manufacturer=3Com Inc. +S: Product=3Com U.S. Robotics Pro ISDN TA +S: SerialNumber=UFT53A49BVT7 +C: #Ifs= 1 Cfg#= 1 Atr=60 MxPwr= 0mA +I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm +E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms +C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr= 0mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms +I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm +E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + +The presence of these three lines (and the Cls= 'comm' and 'data' classes) +is important, it means it's an ACM device. The Driver=acm means the acm +driver is used for the device. If you see only Cls=ff(vend.) then you're out +of luck, you have a device with vendor specific-interface. + +D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 +I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm +I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm + +In the system log you should see: + +usb.c: USB new device connect, assigned device number 2 +usb.c: kmalloc IF c7691fa0, numif 1 +usb.c: kmalloc IF c7b5f3e0, numif 2 +usb.c: skipped 4 class/vendor specific interface descriptors +usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3 +usb.c: USB device number 2 default language ID 0x409 +Manufacturer: 3Com Inc. +Product: 3Com U.S. Robotics Pro ISDN TA +SerialNumber: UFT53A49BVT7 +acm.c: probing config 1 +acm.c: probing config 2 +ttyACM0: USB ACM device +acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 +acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 +usb.c: acm driver claimed interface c7b5f3e0 +usb.c: acm driver claimed interface c7b5f3f8 +usb.c: acm driver claimed interface c7691fa0 + +If all this seems to be OK, fire up minicom and set it to talk to the ttyACM +device and try typing 'at'. If it responds with 'OK', then everything is +working.
diff -urN linux-2.3.99-pre3-old/Documentation/usb/hid.txt linux/Documentation/usb/hid.txt --- linux-2.3.99-pre3-old/Documentation/usb/hid.txt Wed Jan 5 01:12:59 2000 +++ linux/Documentation/usb/hid.txt Thu Jan 1 01:00:00 1970 @@ -1,162 +0,0 @@ - Linux HID driver v0.8 - (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]> - (c) 1999 Andreas Gal <[EMAIL PROTECTED]> - Sponsored by SuSE ----------------------------------------------------------------------------- - -0. Disclaimer -~~~~~~~~~~~~~ - This program is free software; you can redistribute it and/or modify it -under the terms of the GNU General Public License as published by the Free -Software Foundation; either version 2 of the License, or (at your option) -any later version. - - This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY -or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for -more details. - - You should have received a copy of the GNU General Public License along -with this program; if not, write to the Free Software Foundation, Inc., 59 -Temple Place, Suite 330, Boston, MA 02111-1307 USA - - Should you need to contact me, the author, you can do so either by e-mail -- mail your message to <[EMAIL PROTECTED]>, or by paper mail: Vojtech Pavlik, -Ucitelska 1576, Prague 8, 182 00 Czech Republic - - For your convenience, the GNU General Public License version 2 is included -in the package: See the file COPYING. - -1. Introduction -~~~~~~~~~~~~~~~ - This is a driver for USB devices conforming to the USB HID (Human Input -Device) standard. These devices include namely keyboards, mice and -joysticks. - - However many other devices (monitors, speakers, UPSs ...) also communicate -through the same protocol, which makes its specification somewhat bloated. -This isn't a problem, though, because the driver doesn't need to know about -all the possible devices it can control, and can just parse the protocol and -leave the rest of the job (for example understanding what the UPS wants to -say) to the userland. - - Because of this, the USB HID driver has two interfaces. One is via the -proc filesystem, allowing userland applications send and read arbitrary -reports to and from a connected USB device. The other is via a very simple -yet generic input device driver, which dispatches input events (keystrokes, -mouse or joystick movements) to specific, backward compatible userland -interfaces. This way a PS/2 mouse, an AT keyboard or a Linux joystick driver -interface are emulated, and allow applications to immediately work with USB -mice, USB keyboards and USB joysticks without any changes. - - The input driver is aimed for a little more than USB device handling in -the future, though. It's generic enough so that it can be used for any -mouse, keyboard or joystick (and more, of course). A PS/2 mouse driver, a -serial mouse, Sun mouse, and most of the busmouse drivers were rewritten to -use this as well as the AT keyboard and Sun keyboard drivers. This will -hopefully allow conversion of all Linux keyboard and mouse and joystick -drivers to this scheme. - - This effort has it's home page at: - - http://www.suse.cz/development/input/ - -You'll find both the latest HID driver and the complete Input driver there. -There is also a mailing list for this: - - [EMAIL PROTECTED] - -Send "subscribe linux-joystick Your Name" to subscribe to it. - -2. Usage -~~~~~~~~ - Since the driver comes with recent 2.3 kernels, all that's needed to use -it is to enable it either as a module or compiled-in into the kernel. - - After that, after reboot (and possibly also inserting the USB and HID -modules) the following will happen: - -* If you selected keyboard support, all USB keystrokes will be also routed - to the Linux keyboard driver as if being input through the ordinary system - keyboard. - -* If you selected mouse support, there will be (one or more) simulated PS/2 - mouse devices on major 10, minor 32, 33 and more. These simulated mice can - in addition to a standard 3-button PS/2 mouse behave like MS Intellimice, - with a wheel. If you want to use the wheel, just specify '-t imps2' to gpm - and 'Protocol "ImPS/2"' to X, and it will work. A single emulated mouse - device can be open by any number of processes (unlike the /dev/psaux), and - for each of them the emulation is separate, each can use a different mode. - The mousedev driver, which emulates the mice, can also emulate a Genius - NewScroll 5 buttons-and-a-wheel mouse, if you set it to a Genius PS/2 - mode ('-t netmouse' 'Protocol "NetMousePS/2"'). However, not gpm, nor X - can decode the 5 buttons yet, so this isn't very useful right now. - -* If you selected joystick support, the driver will take over major 15, the - joystick major number, and will emulate joysticks on it. This means the - normal joystick driver can't be used together with it (now, after the - normal joystick drivers are converted to the input scheme, all will work - nicely together). Also, you'll probably need to calibrate your joystick - manually ('man jscal') to be able to use it, because the USB - autocalibration is far from perfect yet. - -* If you selected event device support, there will be devices on major 10, - minors 64, 65 and more for each input device connected through this - driver. These devices output raw events the input driver dispatches. Each - has a timestamp. This hopefully will be THE way X will talk to keyboard - and mice, because it's hardware independent, and not limited by existing - de-facto standards. - -3. Verifying if it works -~~~~~~~~~~~~~~~~~~~~~~~~ - Typing a couple keys on the keyboard should be enough to check that a USB -keyboard works and is correctly connected to the kernel keyboard driver. - - Doing a cat /dev/hidmouse (c, 10, 32) will verify that a mouse is also -emulated, characters should appear if you move it. - - You can test the joystick emulation with the 'jstest' utility, available -in the joystick package (see Documentation/joystick.txt). - - You can test the event devics with the 'evtest' utitily available on the -input driver homepage (see the URL above). - -4. FAQ -~~~~~~ -Q: Why aren't any questions here yet? -A: Because none were frequent enough yet. - -5. Event interface -~~~~~~~~~~~~~~~~~~ - Should you want to add event device support into any application (X, gpm, -svgalib ...) I ([EMAIL PROTECTED]) will be happy to provide you any help I -can. Here goes a description of the current state of things, which is going -to be extended, but not changed incompatibly as time goes: - - You can use blocking and nonblocking reads, also select() on the -/dev/inputX devices, and you'll always get a whole number of input events on -a read. Their layout is: - -struct input_event { - struct timeval time; - unsigned short type; - unsigned short code; - unsigned int value; -}; - - 'time' is the timestamp, it returns the time at which the event happened. -Type is for example EV_REL for relative momement, REL_KEY for a keypress or -release. More types are defined in include/linux/input.h. - - 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete -list is in include/linux/input.h. - - 'value' is the value the event carries. Either a relative change for -EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for -release, 1 for keypress and 2 for autorepeat. - -6. Proc interface -~~~~~~~~~~~~~~~~~ - For HID-specific devices there is also the /proc interface. It isn't -present in this release yet, though, so it's description will appear here -together with the code in the driver. diff -urN linux-2.3.99-pre3-old/Documentation/usb/input.txt linux/Documentation/usb/input.txt --- linux-2.3.99-pre3-old/Documentation/usb/input.txt Thu Jan 1 01:00:00 1970 +++ linux/Documentation/usb/input.txt Sat Apr 1 12:50:03 2000 @@ -0,0 +1,294 @@ + Linux Input drivers v0.9 + (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]> + Sponsored by SuSE +---------------------------------------------------------------------------- + +0. Disclaimer +~~~~~~~~~~~~~ + This program is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by the Free +Software Foundation; either version 2 of the License, or (at your option) +any later version. + + This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +more details. + + You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., 59 +Temple Place, Suite 330, Boston, MA 02111-1307 USA + + Should you need to contact me, the author, you can do so either by e-mail +- mail your message to <[EMAIL PROTECTED]>, or by paper mail: Vojtech Pavlik, +Ucitelska 1576, Prague 8, 182 00 Czech Republic + + For your convenience, the GNU General Public License version 2 is included +in the package: See the file COPYING. + +1. Introduction +~~~~~~~~~~~~~~~ + This is a collection of drivers that is designed to support all input +devices under Linux. However, in the current kernels, although it's +possibilities are much bigger, it's limited to USB devices only. This is +also why it resides in the drivers/usb subdirectory. + + The center of the input drivers is the input.o module, which must be +loaded before any other of the input modules - it serves as a way of +communication between two groups of modules: + +1.1 Device drivers +~~~~~~~~~~~~~~~~~~ + These modules talk to the hardware (for example via USB), and provide +events (keystrokes, mouse movements) to the input.o module. + +1.2 Event handlers +~~~~~~~~~~~~~~~~~~ + These modules get events from input.o and pass them where needed via +various interfaces - keystrokes to the kernel, mouse movements via a +simulated PS/2 interface to GPM and X and so on. + +2. Simple Usage +~~~~~~~~~~~~~~~ + For the most usual configuration, with one USB mouse and one USB keyboard, +you'll have to load the following modules (or have them built in to the +kernel): + + input.o + mousedev.o + keybdev.o + usbcore.o + usb-[uo]hci.o + hid.o + + After this, the USB keyboard will work straight away, and the USB mouse +will be available as a character device on major 13, minor 32: + + crw-r--r-- 1 root root 13, 32 Mar 28 22:45 mouse0 + + This device, has to be created, unless you use devfs, in which case it's +created automatically. The commands to do that are: + + cd /dev + mkdir input + mknod input/mouse0 c 13 32 + + After that you have to point GPM (the textmode mouse cut&paste tool) and +XFree to this device to use it - GPM should be called like: + + gpm -t ps2 -m /dev/input/mouse0 + + And in X: + + Section "Pointer" + Protocol "ImPS/2" + Device "/dev/input/mouse0" + ZAxisMapping 4 5 + EndSection + + When you do all of the above, you can use your USB mouse and keyboard. + +3. Detailed Description +~~~~~~~~~~~~~~~~~~~~~~~ +3.1 Device drivers +~~~~~~~~~~~~~~~~~~ + Device drivers are the modules that generate events. The events are +however not useful without being handled, so you also will need to use some +of the modules from section 3.2. + +3.1.1 hid.c +~~~~~~~~~~~ + Hid.c is the largest and most complex driver of the whole suite. It +handles all HID devices, and because there is a very wide variety of them, +and because the USB HID specification isn't simple, it needs to be this big. + + Currently, it handles USB mice, joysticks, gamepads, steering wheels +keyboards, trackballs and digitizers. + + However, USB uses HID also for monitor controls, speaker controls, UPSs, +LCDs and many other purposes. + + The monitor and speaker controls should be easy to add to the hid/input +interface, but for the UPSs and LCDs it doesn't make much sense. The driver +doesn't support these yet, and a new, non-event interface should be designed +for them. If you have any of these devices (I don't), feel free to design +something and if it's good, it'll get into the driver. + + The usage of the hid.o module is very simple, it takes no parameters, +detects everything automatically and when a HID device is inserted, it +detects it appropriately. + + However, because the devices vary wildly, you might happen to have a +device that doesn't work well. In that case #define DEBUG at the beginning +of hid.c and send me the syslog traces. + +3.1.2 usbmouse.c +~~~~~~~~~~~~~~~~ + For embedded systems, for mice with broken HID descriptors and just any +other use when the big hid.c wouldn't be a good choice, there is the +usbmouse.c driver. It handles USB mice only. It uses a simpler HIDBP +protocol. This also means the mice must support this simpler protocol. Not +all do. If you don't have any strong reason to use this module, use hid.c +instead. + +3.1.3 usbkbd.c +~~~~~~~~~~~~~~ + Much like usbmouse.c, this module talks to keyboards with a simpplified +HIDBP protocol. It's smaller, but doesn't support any extra special keys. +Use hid.c instead if there isn't any special reason to use this. + +3.1.4 wacom.c +~~~~~~~~~~~~~ + This is a driver for Wacom Graphire and Intuos tablets. Not for Wacom +PenPartner, that one is handled by the HID driver. Although the Intuos and +Graphire tablets claim that they are HID tablets as well, they are not and +thus need this specific driver. + +3.1.5 wmforce.c +~~~~~~~~~~~~~~~ + A driver for the Logitech WingMan Force joysticks, when connected via the +USB port. It works quite well, but there is no force feedback support yet, +because the interface to do that is a trade secret of Immersion Corp, and +even Logitech can't disclose it. + + Support for Logitech WingMan Force Wheel isn't present in this driver, but +if someone has the device, and is willing to cooperate, it should be a +matter of a couple days to add it. + +3.2 Event handlers +~~~~~~~~~~~~~~~~~~ + Event handlers distrubite the events from the devices to userland and +kernel, as needed. + +3.2.1 keybdev.c +~~~~~~~~~~~~~~~ + Keybdev is currently a rather ugly hack that translates the input events +into architecture-specific keyboard raw mode (Xlated AT Set2 on x86), and +passes them into the handle_scancode function of the keyboard.c module. This +works well enough on all architectures that keybdev can generate rawmode on, +other architectures can be added to it. + + The right way would be to pass the events to keyboard.c directly, best if +keyboard.c would itself be an event handler. This is done in the input +patch, available on the webpage mentioned below. + +3.2.2 mousedev.c +~~~~~~~~~~~~~~~~ + Mousedev is also a hack to make programs that use mouse input work. It +takes events from either mice or digitizers/tablets and makes a PS/2-style +(a la /dev/psaux) mouse device available to the userland. Ideally, the +programs could use a more reasonable interface, for example evdev.c + + Mousedev devices in /dev/input (as shown above) are: + + crw-r--r-- 1 root root 13, 32 Mar 28 22:45 mouse0 + crw-r--r-- 1 root root 13, 33 Mar 29 00:41 mouse1 + crw-r--r-- 1 root root 13, 34 Mar 29 00:41 mouse2 + crw-r--r-- 1 root root 13, 35 Apr 1 10:50 mouse3 + +and so on, up to mouse31. Each is assigned to a single mouse or digitizer, +unless CONFIG_INPUT_MOUSEDEV_MIX is set. In that case all mice and +digitizers share a single character device, mouse0, and even when none are +connected, mouse0 is present. This is useful for hotplugging USB mice, so +that programs can open the device even when no mice are present. + + CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are the size +of your screen (in pixels) in XFree86. This is needed if you want to use +your digitizer in X, because it's movement is sent to X via a virtual PS/2 +mouse. + + Mousedev.c will generate either PS/2, ImPS/2 (microsoft intellimouse) or +GenPS/2 (genius netmouse/netscroll) protocols, depending on what the program +wishes. You can set GPM and X to any of these. You'll need ImPS/2 if you +want to make use of a wheel on a USB mouse and GenPS/2 if you want to use +extra (up to 5) buttons. I'm not sure how much is GenPS/2 supported in X, +though. + +3.2.3 joydev.c +~~~~~~~~~~~~~~ + Joydev implements v0.x and v1.x Linux joystick api, much like +drivers/char/joystick/joystick.c. See joystick-api.txt in the Documentation +subdirectory for details. Joydev does it on top of the input subsystem, +though. As soon as any USB joystick is connected, it can be accessed in +/dev/input on: + + crw-r--r-- 1 root root 13, 0 Apr 1 10:50 js0 + crw-r--r-- 1 root root 13, 1 Apr 1 10:50 js1 + crw-r--r-- 1 root root 13, 2 Apr 1 10:50 js2 + crw-r--r-- 1 root root 13, 3 Apr 1 10:50 js3 + +And so on up to js31. + +3.2.4 evdev.c +~~~~~~~~~~~~~ + Evdev is the generic input event interface. It passes the events generated +in the kernel straight to the program, with timestamps. The API is still +evolving, but should be useable now. It's described in section 5. + + This should be the way for GPM and X to get keyboard and mouse mouse +events. It allows for multihead in X without any specific multihead kernel +support. The event codes are the same on all architectures and are hardware +independent. + + The devices are in /dev/input: + + crw-r--r-- 1 root root 13, 64 Apr 1 10:49 event0 + crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1 + crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2 + crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3 + +3. Contacts +~~~~~~~~~~~ + This effort has it's home page at: + + http://www.suse.cz/development/input/ + +You'll find both the latest HID driver and the complete Input driver there. +There is also a mailing list for this: + + [EMAIL PROTECTED] + +Send "subscribe linux-input" to subscribe to it. + +4. Verifying if it works +~~~~~~~~~~~~~~~~~~~~~~~~ + Typing a couple keys on the keyboard should be enough to check that a USB +keyboard works and is correctly connected to the kernel keyboard driver. + + Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse is also +emulated, characters should appear if you move it. + + You can test the joystick emulation with the 'jstest' utility, available +in the joystick package (see Documentation/joystick.txt). + + You can test the event devics with the 'evtest' utitily available on the +input driver homepage (see the URL above). + +5. Event interface +~~~~~~~~~~~~~~~~~~ + Should you want to add event device support into any application (X, gpm, +svgalib ...) I <[EMAIL PROTECTED]> will be happy to provide you any help I +can. Here goes a description of the current state of things, which is going +to be extended, but not changed incompatibly as time goes: + + You can use blocking and nonblocking reads, also select() on the +/dev/inputX devices, and you'll always get a whole number of input events on +a read. Their layout is: + +struct input_event { + struct timeval time; + unsigned short type; + unsigned short code; + unsigned int value; +}; + + 'time' is the timestamp, it returns the time at which the event happened. +Type is for example EV_REL for relative momement, REL_KEY for a keypress or +release. More types are defined in include/linux/input.h. + + 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete +list is in include/linux/input.h. + + 'value' is the value the event carries. Either a relative change for +EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for +release, 1 for keypress and 2 for autorepeat.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
