Hi, erm, my driver seems to be escaping into the wild, probably time to check in and get some things right before it gets too far... honest, I just put it on my website without any effort at advertising for people to find on their own, but this morning someone pointed out that it was on openchallenge.org, I e-mailed the site and now I hear I might get more traffic....
* device: Synaptics cPad, esentially a 3-button touchpad with a backlit LCD. only seen on Toshiba Satellite 510x laptops thus far. * see the driver: currently at http://www.janerob.com/rob/ts5100/cPad though I am intending to get the 0.3 version up this evening (GMT), this time even with comments in the source code :-) I know I could post it here, but it is ~1300 lines and mostly looks like usb_skeleton.c + usbmouse.c (+ a bit of wacom.c graphics tablet). this was developed for/with 2.4.18, yes I know it is old, yes I know it won't build for 2.5 and the person who told me about the 2.5 issues volunteered to sort it out soon-ish. * things I'm particularly worried about: (1) I just 'grabbed' ioctls 'U' 0x71-0x79 (77-79 in the 0.3 ver at home). I tried e-mailing the person in the kernel docs about ioctl numbering and assignments, he replied that he's given up tracking them. (2) I just 'grabbed' minor device number 200 (major=180) [... oh blow, my 'mknod' instructions have it backwards, guess that's another tweak for tonight.] yes, used devfs, reverted back trying to get something else to work, figured this would work for users not yet using devfs. I e-mailed the person listed in the kernel docs relevant to dev major/minor numbers, haven't heard back. --> didn't mean to step on any toes or cause any conflicts, I will happily change now, tell me what to change to or who to ask ? * thing to improve: (the one on my mind, probably you will see many more) from sniffing the other team's driver while putting an image bitmap on the display, I see a block of 4096 bytes written, followed by 1 read, followed by another ~1024 byte write, and another read. the cPad is set up to take 32 byte messages, such that byte 0 selects the LCD controller, byte 1 is the controller command to 'write at current cursor position', and the remaining 30 bytes are 240 pixels of bitmap (and the display is 160 lines vertical). in other words, the other system writes a bunch of these 32 byte messages all (apparently) in 1 URB, does 1 read, then sends 1 more URB with the remaining messages. my driver, following usb_skeleton, only writes out dev->bulk_out_size (32) bytes at a time, and each time I send such an URB it seems I need to read one back for everything to be happy. as you may guess, the proprietary version writes the images perceptibly quicker. I would like to do something more like the 1- or 2-shot messages, some relevant thoughts are: (1) actually the 30 bytes after the LCD controller command are -reversed- relative to what's in the datasheet, my driver sorts this out so still it is useful to only work with 32 bytes at a time (2) probably this is something like the 'bulk queueing' I see being discussed currently on the list. (3) this code/interface also appears to be changing in 2.5 (4) f* it, it isn't -that- slow given all that other great stuff I have to do.... --> thoughts/comments/sugestions ? * why did I do it this way: I started out (as some readers may remember) trying to get the middle mouse button working. this required setting an alternate interface (1 or 2) from the default (0). I had hoped that I could somehow slip in this tweak past HID and have it all magically work; not. even if I could get HID to let me change this while it posessed the device, the mouse movement data from these interfaces comes in absolute (as opposed to relative) coordinates. the abs coords for the cPad are slightly different from what I see in the wacom driver, it is not clear to me if there is a standard here. once I did get it working, it was apparent that most people want a relative mouse anyway. with the rest of the usb_skeleton code though I was able to play with the bulk writes, and realised that I could put images on the LCD. never got very far with 2.5 as the closed source X server for my laptop doesn't work with it (though I've since heard that the XFree one does what I need, haven't got back to it). * future: "no new devices in 2.4", so far my driver just hangs out on the web for anyone who wants to use it. I'd be overjoyed to have it added to the kernel source, but not certain if I can handle too much maintenance load (I'm on my way to Nigeria for a couple of years, no more broadband for one thing...). I will continue to pay for the web hosting. guess that's the update, thanks for any feedback, rob. -- rob miller x4647 Inpharmatica Ltd ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
