linux-kernel - [Fwd: Re: [PATCH 1/3] hid: Add report descriptor for Logitech Driving Force wheel]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 3 Feb 2013 20:52:04 -0500
From:	simon@...gewell.org
To:	"Paul Sbarra" <sbarra.paul@...il.com>, jkosina@...e.cz,
	simon@...gewell.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [Fwd: Re: [PATCH 1/3] hid: Add report descriptor for Logitech
 Driving Force wheel]

Resending as I missed adding linux-input to the receiptants,
Simon

---------------------------- Original Message ----------------------------
Subject: Re: [PATCH 1/3] hid: Add report descriptor for Logitech Driving
Force wheel
From:    simon@...gewell.org
Date:    Sun, February 3, 2013 8:30 pm
To:      "Paul Sbarra" <sbarra.paul@...il.com>
Cc:      simon@...gewell.org
--------------------------------------------------------------------------

>> Interesting, I hadn't realized the newer models were also reporting with
> that product id.  I suppose that's going to add some complexity, but at
> least the background helps explain that chunk of code.
>
>
>> So a couple of questions:
>> 1) Are you sure you have a "Driving Force"?
>
> Yes.

There is another detail which 'we' previously decided; that when a 900
degree wheel was left in simple (1st connect) mode we would leave the
acc/brake combined.

This would happen if 'lg4ff' was not enabled, or the wheel was not
recognized for the 'special' command. (Note the special command causes the
wheel rotation to be unlocked to the full 900 degrees).

This obviously is not appropriate for your wheel and patching the report
descriptor will need to be done. I'd just like to ensure that we're not
breaking another wheel in the process.

Rather than using just the USBID and the size, can we also check the BCD
revision number before patching the report descriptor - similar to what we
do in lg4ff to decide what magic command to use?
ie.
--
udesc = &(hid_to_usb_dev(hid)->descriptor);
bcdDevice = le16_to_cpu(udesc->bcdDevice);
rev_maj = bcdDevice >> 8;
rev_min = bcdDevice & 0xff;
--

I've attached the report descriptor and lsusb for the DFP and DFW, which
both show a combine acc/brake in this mode. I won't have access to my G27
till midweek.

Q. In 'simple' mode should all wheels present a seperate acc and brake
(when they can)?

My DFW wheel is broken, so I can't test patching that descriptor... but if
anyone else has this wheel I can provide code to test.

>
> 2) Does the ForceFeedback work for you?
>>
>
> I'm unsure of the best way to test FF

Since we are using 'ffmemless' we're limited to constant force, although
other modes are know. It'll be a lot of work to move away from ffmemless,
for not much gain and I suspect very few games support the other modes.

You can confirm operation with 'ffcfstress'.

Cheers,
Simon.

View attachment "lsusb_dfw_pre.txt" of type "text/plain" (2363 bytes)

View attachment "descriptor_dfw_pre.txt" of type "text/plain" (712 bytes)

View attachment "jstest_dfw_pre.txt" of type "text/plain" (2777 bytes)

View attachment "descriptor_dfp_pre.txt" of type "text/plain" (705 bytes)

View attachment "lsusb_dfp_pre.txt" of type "text/plain" (2359 bytes)