17 Apr, 2009

1 commit

  • Add Product Id 0xc299 for the Logitech G25 force feedback wheel
    The Logitech G25 force feedback wheel, is first recognize by the kernel
    with the product id "0xc294". In this mode, we can't use all the axes
    and buttons of the wheel.

    Using a userland utility, it is possible to make the wheel switch to native
    mode -- http://svn.vdrift.net/viewvc.cgi/trunk/tools/G25manage/?root=VDrift
    In native mode, the wheel change its id number to "0xc299".

    The packet that needs to be sent to the wheel to swtich to native mode and
    change its PID is

    { 0xf8, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00 }

    Signed-off-by: Christophe Borivant
    Signed-off-by: Jiri Kosina

    Christophe Borivant
     

30 Mar, 2009

1 commit

  • This removal was scheduled and there is no problem with later
    distros to adapt for the new bus, thanks to aliases.

    module-init-tools map files are deprecated nowadays, so that
    the patch which introduced hid ones into the m-i-t won't be
    accepted and hence there is no reason for leaving compat stuff in.

    Signed-off-by: Jiri Slaby
    Cc: Jiri Kosina
    Signed-off-by: Jiri Kosina

    Jiri Slaby
     

04 Jan, 2009

1 commit

  • This patch (as1146c) makes usbhid automatically call usbhid_set_leds()
    for any device that supports the keyboard boot protocol.

    In theory this should be perfectly safe. BIOSes send the LED output
    report as part of their normal device initialization, so any keyboard
    device supporting the boot protocol has to be able to handle it.

    As a side effect, the hid-dell and hid-bright drivers are no longer
    needed, and the Logitech keyboard driver can be removed from hid-lg.

    CC: Mauro Carvalho Chehab
    Signed-off-by: Alan Stern
    Signed-off-by: Jiri Kosina

    Alan Stern
     

17 Oct, 2008

1 commit

  • This reverts commit 740f370dc61dc478d891d7d47660bb3ae39ddb4f.

    It turned out to be correct in the first place: a positive value should
    be sent when the wheel is moved to the right, and a negative value when
    moved to the left. This is the behavior expected by the Xorg evdev
    driver. I must have had a remapping somewhere else in my system when
    originally testing this. Testing on another system shows that the
    unpatched kernel is correct.

    Here is a bug report from Mandriva that brought the problem to my
    attention:

    https://qa.mandriva.com/show_bug.cgi?id=44309#c19

    Signed-off-by: Dan Nicholson
    Signed-off-by: Jiri Kosina

    Dan Nicholson
     

15 Oct, 2008

1 commit