Menu
▾
▴
linuxconsole-dev
|
From: Johann D. <jo...@do...> - 2002-04-08 12:30:22
|
Fabien Brachere wrote: > Hello, Hi, > I'm new to the list, and I'm working on a Microsoft Sidewinder Force > Feedback 2 driver (Product ID=0x001b, Vendor ID=0x045e). > I started to study USB, HID and PID protocols and the joystick seems to > follow PID specification. > I implemented a skeleton driver (with latest development kernel 2.5.7) > which do the following things: > when insmod'ed : reset device, adjust gain, upload an arbitrary effect > (sort of machine-gun effect sniffed from the Windows test of the > joystick) and play it, and it works ! > when rmmod'ed : stop effect, reset device. That sounds really interesting. > For the moment, no IOCTL and no relation with evdev except for position > of joystick and buttons. > > The theory of operations: > the driver uses 4 flow of data with the device: control in (for "block > load report" and "pid pool report": see pid spec.), control out (for > "create new effect report") , interrupt in (for joystick state (axes, > buttons, power, optical switch)) and interrupt out for all other > commands (set effect report, set envelope report, device gain report, > pid device control , ....) > > I've not release yet any file, because it's in early alpha stage and > it's very dirty code, must clean up before all, implement correct data > structures to follow PID spec... There really is no reason to be ashamed of dirty code. I don't think any hacker really cares about dirtyness at such early development stages. Several people already started to work on this subject, and I believe the amount of code we have seen does not reflect the total amount of time spent on it. Furthermore, if you have an heart attack today, what I don't wish you, we lose all your work. > I think in a few weeks (depend on the time I have), I put all of that on > a Web site. > > I've a problem with this driver: I can't insert it without rmmod hid, I > think it's the fault of hid-input who register the device, so I can't > register it twice. Any idea ? (without modify hid code). > This is how I did for the Logitech WingMan Cordless Rumble Pad: I slightly modified hid.h, hid-core.c and hid-input.c to add new function entries. Then I added a file called hid-ff.c where the code for force feedback goes. It's available in linuxconsole's CVS on sourceforge. I designed the framework so that other protocols could be added. Please have a look. If you like the way it's done, please use the existing framework. If you don't, please explain why so that we can improve it ;) By the way, I think we should have discussions about drivers on the linuxconsole mailing list, and discussions about the userland force feedback library on libff-devel. -- Johann Deneux |
|
From: Fabien B. <fab...@fr...> - 2002-04-10 12:19:24
|
Johann Deneux wrote : > > There really is no reason to be ashamed of dirty code. I don't think any > hacker really cares about dirtyness at such early development stages. > Several people already started to work on this subject, and I believe > the amount of code we have seen does not reflect the total amount of > time spent on it. > Furthermore, if you have an heart attack today, what I don't wish you, > we lose all your work. > Ok, I didn't have an heart attack, and I put all this stuff on a very minimal web site: http://madfab.free.fr/ff/index.html Fabien Brachere |
|
From: Fabien B. <fab...@fr...> - 2002-04-11 09:32:00
|
Rodrigo Damazio wrote : > Fabien Brachere wrote: > > > > >Ok, I didn't have an heart attack, and I put all this stuff on a very > >minimal web site: http://madfab.free.fr/ff/index.html > > > >Fabien Brachere > > > Nicely done...perhaps you'd like to help with the PID code? > Instead of registering itself for specific USB device IDs, it's a > subclass of the HID class, so whenever a HID device is detected, it > checks if it's also PID-compliant, and if it is then you can use force > feedback calls on it(this also allows us to not worry at all about > reading the axes input, since HID does that already)...the structs for > these calls are the very same that are used for I-Force, the only > difference is how we generate and send packets to the device... I know that the Sidewinder is registered by the HID module, but I'm not satisfy with this: the joydev module report 24 buttons and 10 axes (it's a big joystick but not so big ...), the only quick solution I found is to short-cut hid by specifying USB device IDs, it's just for development, I think we can see this later. The first important thing is to implement correct upload effect to the device memory, once uploaded it's trivial to play it. > It's a reasonably big set of commands to implement, so I > estimate it should take about a month or two for it to be 100% > working...the Sidewinder will work sooner though, 'cause it has its own > memory management...but we'll have to implement memory management for > devices that don't have it...that'll be a hassle, specially since we > don't have a good way to debug the device's internal memory...but let's > leave that for later and get the Sidewinder working first... > > Rodrigo > I'm OK with this, when the sidewinder will work, we can add memory management in a sub-structure. Fabien |
|
From: Rodrigo D. <cu...@uo...> - 2002-04-11 17:40:45
|
Fabien Brachere wrote: >Rodrigo Damazio wrote : > >>Fabien Brachere wrote: >> >>>Ok, I didn't have an heart attack, and I put all this stuff on a very >>>minimal web site: http://madfab.free.fr/ff/index.html >>> >>>Fabien Brachere >>> >> Nicely done...perhaps you'd like to help with the PID code? >>Instead of registering itself for specific USB device IDs, it's a >>subclass of the HID class, so whenever a HID device is detected, it >>checks if it's also PID-compliant, and if it is then you can use force >>feedback calls on it(this also allows us to not worry at all about >>reading the axes input, since HID does that already)...the structs for >>these calls are the very same that are used for I-Force, the only >>difference is how we generate and send packets to the device... >> > >I know that the Sidewinder is registered by the HID module, but I'm not >satisfy with this: the joydev module report 24 buttons and 10 axes (it's >a big joystick but not so big ...), the only quick solution I found is >to short-cut hid by specifying USB device IDs, it's just for >development, I think we can see this later. > That's indeed true...I wonder why that happens - is it the joystick that reports itself as having all that, or is it a bug in the HID code? I think it's too small of a thing to re-create the driver though, it can probably be fixed... >The first important thing is to implement correct upload effect to the >device memory, once uploaded it's trivial to play it. > I know...that's what I'm working on...these last days I merged parts of the code from Bjorn and added missing parts to it, so it already detects all FF capabilities of the joystick... Rodrigo -- * Rodrigo Damazio * cu...@uo.../rod...@po.../rda...@ls... * ICQ: #3560450 Homepage: http://www.vros.com/cuddly/ * Engenharia da Computação / Laboratório de Sistemas Integráveis(LSI) * Escola Politécnica - USP - São Paulo |
|
From: Vojtech P. <vo...@su...> - 2002-04-12 08:55:22
|
On Thu, Apr 11, 2002 at 11:48:07AM -0300, Rodrigo Damazio wrote: > Fabien Brachere wrote: > > >Rodrigo Damazio wrote : > > > >>Fabien Brachere wrote: > >> > >>>Ok, I didn't have an heart attack, and I put all this stuff on a very > >>>minimal web site: http://madfab.free.fr/ff/index.html > >>> > >>>Fabien Brachere > >>> > >> Nicely done...perhaps you'd like to help with the PID code? > >>Instead of registering itself for specific USB device IDs, it's a > >>subclass of the HID class, so whenever a HID device is detected, it > >>checks if it's also PID-compliant, and if it is then you can use force > >>feedback calls on it(this also allows us to not worry at all about > >>reading the axes input, since HID does that already)...the structs for > >>these calls are the very same that are used for I-Force, the only > >>difference is how we generate and send packets to the device... > >> > > > >I know that the Sidewinder is registered by the HID module, but I'm not > >satisfy with this: the joydev module report 24 buttons and 10 axes (it's > >a big joystick but not so big ...), the only quick solution I found is > >to short-cut hid by specifying USB device IDs, it's just for > >development, I think we can see this later. > > > That's indeed true...I wonder why that happens - is it the > joystick that reports itself as having all that, or is it a bug in the > HID code? I think it's too small of a thing to re-create the driver > though, it can probably be fixed... Most likely some of the PID stuff gets assigned as buttons/axes, because no better match can be found - there are fallbacks in the input<->hid mapping code. > >The first important thing is to implement correct upload effect to the > >device memory, once uploaded it's trivial to play it. > > > I know...that's what I'm working on...these last days I merged > parts of the code from Bjorn and added missing parts to it, so it > already detects all FF capabilities of the joystick... -- Vojtech Pavlik SuSE Labs |
|
From: Johann D. <jo...@do...> - 2002-04-11 08:24:01
|
Rodrigo Damazio wrote: > Johann Deneux wrote: > >> Rodrigo Damazio wrote: >> >>> [...] btw, I'm attaching a few minor but necessary fixes to >>> linux-console 2.5.7 code...also on line 749 of hid-core.c, you forgot >>> to change the parameters to hiddev_hid_event...I'm not exactly sure >>> how it expects the uref struct to be populated, so I'm leaving that >>> one to you... >>> >> >> Neither do I. I will in turn leave this one to James. > > > Seems like he corrected it already =c) > Well, I actually fixed it after sending the mail (which never reached the list anyway, because of a mistyped address). The point is that it seems we are having several versions of the hid code. The version in Greg KH tree contained the right code. I hope Dave Jones, Linus, Greg and us are not going to end up with different versions. I fear the same problem applies to the rest of the code in our CVS. >> >>> ------------------------------------------------------------------------ >>> >>> diff -ru ruby/linux/drivers/char/consolemap.c >>> linux/drivers/char/consolemap.c >>> --- ruby/linux/drivers/char/consolemap.c Wed Mar 7 01:42:27 2001 >>> +++ linux/drivers/char/consolemap.c Mon Apr 8 18:17:22 2002 >>> @@ -397,7 +397,7 @@ >>> >>> extern u8 dfont_unicount[]; /* Defined in consolemap_deftbl.c */ >>> extern u16 dfont_unitable[]; >>> -extern u16 dfont_num; >>> +u16 dfont_num; >> >> >> >> This one shouldn't be necessary. dfont_num is indeed defined in >> consolemap_deftbl.c (a file generated by conmakehash). > > > I see...but for some reason it would compile, but at link time > it'd complain about not finding that symbol... > Are we using the same kernel version ? I do have link-time errors too, but not the same ones. In my case, handle_scancode isn't defined in any object linked to bzImage. I was using Linus' 2.5.7 with files from the linuxconsole CVS in this attempt. -- Johann Deneux |
|
From: James S. <jsi...@tr...> - 2002-04-12 17:45:16
|
> The point is that it seems we are having several versions of the hid > code. The version in Greg KH tree contained the right code. I hope Dave > Jones, Linus, Greg and us are not going to end up with different > versions. I fear the same problem applies to the rest of the code in our > CVS. Only the USB code because it is so dynamic. I think the current approach is tetsing new hid code is done here. Then passed to the USB guys which then pass it up to Linus. > Are we using the same kernel version ? I do have link-time errors too, > but not the same ones. In my case, handle_scancode isn't defined in any > object linked to bzImage. > I was using Linus' 2.5.7 with files from the linuxconsole CVS in this > attempt. handle_scancode. That shouldn't be used anymore. You wouldn't by change be enabling keybdev.c in drivers/input. For ruby we don't need it anymore. |
|
From: Johann D. <joh...@la...> - 2002-04-20 15:59:13
|
James Simmons wrote: > >>Are we using the same kernel version ? I do have link-time errors too, >>but not the same ones. In my case, handle_scancode isn't defined in any >>object linked to bzImage. >>I was using Linus' 2.5.7 with files from the linuxconsole CVS in this >>attempt. >> > > handle_scancode. That shouldn't be used anymore. You wouldn't by change be > enabling keybdev.c in drivers/input. For ruby we don't need it anymore. > Indeed, I was enabling keybdev.c. But if I don't, the only way to access the keyboard is through /dev/event, then ? I guess none of my applications do that. The current behaviour (with keybdev disabled) is that I can't log-in (in text mode), neither can I when X is running. In both cases, the keyboard is non-responsive. -- Johann Deneux |
×
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