| Message ID | 4B3B16CD.1050700@physik.uni-muenchen.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Is there any progress on this driver? Johannes seems to of gotten it working from what I have read. I own a Cyborg Evo Force but I would like the force feedback driver to be committed to the mainline so that it can be released with future Linux distributions. As of today, I cant see any mention of the Saitek Cyborg Evo Force in the IForce driver in Linux 3.0 rc2's source. What seems to be the roadblock to committing it to mainline? On 30 December 2009 11:32, Johannes Ebke <johannes.ebke@physik.uni-muenchen.de> wrote: > Dmitry Torokhov wrote: >> On Wed, Dec 30, 2009 at 10:01:01AM +0100, Johannes Ebke wrote: >>> Dmitry Torokhov wrote: >>>> On Tue, Dec 29, 2009 at 02:40:21PM -0800, Dmitry Torokhov wrote: >>>>> Dec 29, 2009, at 4:46 AM, Johannes Ebke >>>>> <johannes.ebke@physik.uni-muenchen.de> wrote: >>>>> >>>>>> Dmitry Torokhov wrote: >>>>>>> On Sun, Dec 20, 2009 at 11:44:19PM -0800, Dmitry Torokhov wrote: >>>>>>>> On Sun, Dec 20, 2009 at 12:36:23AM +0100, Johannes Ebke wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> It seems that the force feedback works well, I have ported >>>>>>>>> the force >>>>>>>>> feedback for my favorite game to linux now, and it works well. >>>>>>>>> >>>>>>>>> What does not work is updating effects - there just nothing >>>>>>>>> happens, and >>>>>>>>> the old event is played. I have circumvented this by >>>>>>>>> deleting/re-uploading the effect, but this should probably >>>>>>>>> been made to >>>>>>>>> work. Does it work well with other hardware? >>>>>>>>> >>>>>>>>> Thirdly, I have re-discovered one kernel oops that occurs if the >>>>>>>>> joystick is unplugged if some process still has the event >>>>>>>>> device open. >>>>>>>>> Steps to reproduce: >>>>>>>>> * plug joystick in >>>>>>>>> * fftest /dev/input/eventXX >>>>>>>>> * unplug joystick >>>>>>>>> >>>>>>>>> (kern.log extract attached) >>>>>>>>> >>>>>>>>> Sometimes this just gives an oops, sometimes it escalates >>>>>>>>> into a kernel >>>>>>>>> panic. >>>>>>>>> >>>>>>>> Hmm, it looks like iforce unbinding is completely busted: >>>>>>>> >>>>>>>> static void iforce_usb_disconnect(struct usb_interface *intf) >>>>>>>> { >>>>>>>> struct iforce *iforce = usb_get_intfdata(intf); >>>>>>>> int open = 0; /* FIXME! iforce->dev.handle->open; */ >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> >>>>>>>> usb_set_intfdata(intf, NULL); >>>>>>>> if (iforce) { >>>>>>>> iforce->usbdev = NULL; >>>>>>>> input_unregister_device(iforce->dev); >>>>>>>> >>>>>>>> if (!open) { >>>>>>>> iforce_delete_device(iforce); >>>>>>>> kfree(iforce); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Any chance you could fix that FIXME ;) ? >>>>>>>> >>>>>>> Actually, does the below fixes it for you? >>>>>>> >>>>>> This fixes the kernel oops - thanks! However it also disables FF, >>>>>> unless >>>>>> I remove "usb_kill_urb(iforce->out);" from iforce_close. >>>>> >From some debug statements I found that iforce_close is called >>>>>> twice if >>>>>> you just plug in the joystick, so the effect is immediate. >>>>> I still believe that usb_kill_urb is needed however we need to wait >>>>> for packet disabling FF to complete. >>>>> >>>> Does the patch below (on top of the unmodofied previous one) fixes the >>>> issue for you? >>>> >>>> Thanks. >>>> >>> This fixes it completely, both the FF and the clean shutdown on >>> unexpected disconnect! Thank you very much! >> >> Ah, great! >> >>> Finally, for correct orientation of the rudder axis, I have attached one >>> small change to packets - this makes it work for me if i remove the old >>> configuration. >> >> Hmm, that might break some other users though (or does it only kick in >> for Cyborg? > > This is in the part that only kicks in for the Cyborg, or perhaps other > devices as well (if(HI(cmd)==6)..) > >> >>> One other question: Since the USB HID driver can actually discover the >>> joystick buttons and axis ranges sucessfully, would it not be easier to >>> use that for generic input and only add force-feedback in iforce, or is >>> that just too much overhead? >> >> We do prefer to have HID driver handle the devices and have only >> non-HID-compliant devices use specialized drivers. Iforce is an older >> driver though, working with both USB devices and devices attached to >> serial ports. >> >> Does your joystick works well with HID driver (sans FF)? >> > > Yes, with one grievance: Since the "dead man switch" is not physically > present on the cyborg but logically present and "always on", some > applications like the flightgear joystick calibration "fgjs" cannot be used. > However, I am not sure how the information "this is a dead man switch" > can be published to userspace most efficiently, and the application > should probably deal with it anyway (stuck key in old joystick, etc...) > > Cheers, > Johannes > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Input: iforce - flip initial RUDDER orientation to correct one Remove the inversion from the data acqisition routine Signed-off-by: Johannes Ebke <johannes.ebke@physik.uni-muenchen.de> --- diff -ru drivers/input/joystick/iforce_dmitry/iforce-packets.c drivers/input/joystick/iforce/iforce-packets.c --- drivers/input/joystick/iforce_dmitry/iforce-packets.c 2009-12-30 09:42:22.000000000 +0100 +++ drivers/input/joystick/iforce/iforce-packets.c 2009-12-30 09:32:34.000000000 +0100 @@ -193,7 +193,7 @@ if (HI(cmd) == 6) { input_report_abs(dev, ABS_THROTTLE, data[4]); if (LO(cmd) >= 8 && test_bit(ABS_RUDDER ,dev->absbit)) - input_report_abs(dev, ABS_RUDDER, 255 - data[7]); + input_report_abs(dev, ABS_RUDDER, data[7]); } else { input_report_abs(dev, ABS_THROTTLE, 255 - data[4]); if (LO(cmd) >= 8 && test_bit(ABS_RUDDER ,dev->absbit))