Bug 220940 - Usb steering wheel stopped working
Usb steering wheel stopped working
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-12-29 04:42 EST by mo.ucina
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-22 12:49:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description mo.ucina 2006-12-29 04:42:53 EST
Description of problem:

Hello Guys,

Today , after a recent software upgrade I have noticed that my Logitech MOMO
steering wheel has stopped working (in Fedora 6 , works ok in win XP) . While
checking it out in Torcs and Racer , I can not set up any analogue features :
steering left and right and accel and brake . The digital settings ( on , off
type ) seem to be ok .

Has there been any changes to usb drivers or perhaps steering wheel specific
drivers in recent software updates ?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

My system is PC with 3.0G P4 hyperthreading , FC6 with latest software and
latest kernel as of today from stable repos - not using any testing or
development versions.
Comment 1 Pete Zaitcev 2006-12-29 14:14:33 EST
Have you kept old kernels around? Please verify with "rpm -q kernel".
In that case we can find the one which worked.
Comment 2 mo.ucina 2006-12-29 20:05:21 EST
My current kernel is kernel-2.6.18-1.2868.fc6

I do not have any old ones left , I deleted them as soon as the current new was
installed . Every thing was working ok on previous one , I think it was 2849.fc6 .

Comment 3 mo.ucina 2006-12-30 04:09:06 EST
Just confirmed the fault . I loaded back only kernel 2849 and nothing else (no
other software ) , steering wheel started working again .
Comment 4 Pete Zaitcev 2007-01-02 19:40:21 EST
Awesome! Much easier.

BTW, could you attach the /proc/bus/usb/devices?
Comment 5 Pete Zaitcev 2007-01-02 21:16:37 EST
I compared kernels 2.6.18-1.2849.fc6 and 2.6.18-1.2868.fc6 and I see no
difference which might account for this. Seriously, no difference at all.
Checked real configs too, from installed kernels. Something is fishy...
Are we sure the versions are right?

So, after /proc/bus/usb/devices I'd like to see dmesg from working and
non-working kernels (please do not drop into comments box, attach them
as files).
Comment 6 mo.ucina 2007-01-16 07:43:57 EST
Hello Pete,

Sorry I have not responded in a while , I have been upgrading the kernel to
2.6.18-1.2869.fc6 . While doing that I noticed two things :

1st - USB steering wheel works perfectly with this new kernel .
2nd - while upgrading yum removed the old 2.6.18-1.2868.fc6 kernel , so now I
have  2.6.18-1.2849.fc6 and new one installed . Since the "faulty" one has been
I have not had the opportunity to switch back and forth . 
And I guess it really does not matter any more if the new kernel has fixed things .
Comment 7 mo.ucina 2007-01-22 05:59:39 EST
Hello Pete,
After doing some more digging , I agree with you that something is fishy .
Namely it is win XPpro . What I have noticed is that after using the wheel under
win , and then going to linux , windows corrupts the settings in the wheel .
These corrupted settings can survive a pc restart because the wheel has its own
power . So to flush out the wheel , I turned off the pc , then unplugged the
wheel power for a minute , then started linux , and all ok with all kernels . So
my apologies , there was nothing wrong with any kernels to start with . It is
just necessary to flush the wheel every time operating system is changed .

Best Regards 
Comment 8 Pete Zaitcev 2007-01-22 12:49:56 EST
I see. Thanks for letting me know. It's really surprising that it survives
the port reset, and unfortunate too, because there's no other official way
to clear a device. Windows probably knows a way... I think I better close
the bug for now, because I don't think I can help much with it.

In theory, there may be a way forward. If somehow SnoopyPro was booted
before drivers and thus the initial trace on reboot was gotten from Windows,
someone could reverse-engineer the transactions, then maybe fix our driver.
But it's a lot of work and requires Windows knowledge.

Note You need to log in before you can comment on or make changes to this bug.