linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Fix autocentering command in hid-lgff driver
@ 2011-06-14 20:42 Michal Malý
  2011-06-14 21:20 ` simon
       [not found] ` <1908821.jaYXT1Nn2e@qosmio-x300>
  0 siblings, 2 replies; 13+ messages in thread
From: Michal Malý @ 2011-06-14 20:42 UTC (permalink / raw)
  To: jkosina; +Cc: linux-input

Hello,

this patch fixes two issues with autocentering in lgff driver. Current implementation incorrectly assumes that the saturation force is always 0x80 which is 
inconsistent with behavior of the official driver. It also makes it impossible to disable autocentering on some wheels - at least Logitech Formula Force RX is 
the case. Values of stiffness coefficient were also calculated incorrectly. Formula used in this patch appears to generate the same commands as the official 
Logitech drivers. The patch also fixes two minor coding style issues.

Regards, Michal.


Signed-off-by: Michal Malý <madcatxster@gmail.com>
---
 drivers/hid/hid-lgff.c |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-lgff.c b/drivers/hid/hid-lgff.c
index 088f850..3d30a8e 100644
--- a/drivers/hid/hid-lgff.c
+++ b/drivers/hid/hid-lgff.c
@@ -129,18 +129,24 @@ static void hid_lgff_set_autocenter(struct input_dev *dev, u16 magnitude)
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
 	struct hid_report *report = list_entry(report_list->next, struct hid_report, list);
 	__s32 *value = report->field[0]->value;
-	magnitude = (magnitude >> 12) & 0xf;
+	u8 saturation_force = magnitude >> 8;
+	u8 stiffness_coeff;
+	if (magnitude <= 32768)
+		stiffness_coeff = saturation_force / 10;
+	else
+		stiffness_coeff = (saturation_force / 62) + 11;
+
 	*value++ = 0xfe;
 	*value++ = 0x0d;
-	*value++ = magnitude;   /* clockwise strength */
-	*value++ = magnitude;   /* counter-clockwise strength */
-	*value++ = 0x80;
+	*value++ = stiffness_coeff;   /* clockwise strength */
+	*value++ = stiffness_coeff;   /* counter-clockwise strength */
+	*value++ = saturation_force;
 	*value++ = 0x00;
 	*value = 0x00;
 	usbhid_submit_report(hid, report, USB_DIR_OUT);
 }
 
-int lgff_init(struct hid_device* hid)
+int lgff_init(struct hid_device *hid)
 {
 	struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
@@ -180,7 +186,7 @@ int lgff_init(struct hid_device* hid)
 	if (error)
 		return error;
 
-	if ( test_bit(FF_AUTOCENTER, dev->ffbit) )
+	if (test_bit(FF_AUTOCENTER, dev->ffbit))
 		dev->ff->set_autocenter = hid_lgff_set_autocenter;
 
 	pr_info("Force feedback for Logitech force feedback devices by Johann Deneux <johann.deneux@it.uu.se>\n");
-- 
1.7.5.4


--
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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-14 20:42 [PATCH] Fix autocentering command in hid-lgff driver Michal Malý
@ 2011-06-14 21:20 ` simon
  2011-06-14 22:26   ` Michal Malý
       [not found] ` <1908821.jaYXT1Nn2e@qosmio-x300>
  1 sibling, 1 reply; 13+ messages in thread
From: simon @ 2011-06-14 21:20 UTC (permalink / raw)
  To: "Michal Malý"; +Cc: jkosina, linux-input

> Hello,
>
> this patch fixes two issues with autocentering in lgff driver. Current
> implementation incorrectly assumes that the saturation force is always
> 0x80 which is
> inconsistent with behavior of the official driver. It also makes it
> impossible to disable autocentering on some wheels - at least Logitech
> Formula Force RX is
> the case. Values of stiffness coefficient were also calculated
> incorrectly. Formula used in this patch appears to generate the same
> commands as the official
> Logitech drivers. The patch also fixes two minor coding style issues.

Hi Michal,
Can you elaborate more on the difference between stiffness and saturation?
And how these might work in the Linux FF system which only accounts a
single parameter.

On my reverse engineering of the Wii Wheel (1) I noticed that the
AutoCentre consisted of 3 variables, but did realise the precise details.
Perhaps I can factor in a similar adjustment....

BTW - I also discovered some other modes of feedback beyond AutoCentre and
CF which might be applicable to other Logitech wheels. (2)

Simon

1.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/hid/hid-lg4ff.c;h=fa550c8e1d1bc639bd3e9c34a299903391bca44a;hb=3a2289a4a317e0290a8bc7af28c62c9830cb12e5#l72

2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-14 21:20 ` simon
@ 2011-06-14 22:26   ` Michal Malý
  2011-06-14 23:16     ` simon
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Malý @ 2011-06-14 22:26 UTC (permalink / raw)
  To: simon; +Cc: jkosina, linux-input

On Tuesday 14 of June 2011 17:20:52 you wrote:
> > Hello,
> > 
> > this patch fixes two issues with autocentering in lgff driver. Current
> > implementation incorrectly assumes that the saturation force is always
> > 0x80 which is
> > inconsistent with behavior of the official driver. It also makes it
> > impossible to disable autocentering on some wheels - at least Logitech
> > Formula Force RX is
> > the case. Values of stiffness coefficient were also calculated
> > incorrectly. Formula used in this patch appears to generate the same
> > commands as the official
> > Logitech drivers. The patch also fixes two minor coding style issues.
> 
> Hi Michal,
> Can you elaborate more on the difference between stiffness and saturation?
> And how these might work in the Linux FF system which only accounts a
> single parameter.
> 
> On my reverse engineering of the Wii Wheel (1) I noticed that the
> AutoCentre consisted of 3 variables, but did realise the precise details.
> Perhaps I can factor in a similar adjustment....
> 
> BTW - I also discovered some other modes of feedback beyond AutoCentre and
> CF which might be applicable to other Logitech wheels. (2)
> 
> Simon
> 
> 1.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=dr
> ivers/hid/hid-lg4ff.c;h=fa550c8e1d1bc639bd3e9c34a299903391bca44a;hb=3a2289a4
> a317e0290a8bc7af28c62c9830cb12e5#l72
> 
> 2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel

Sure, but please don't take it like I have some inside knowledge of Logitech FF implementation. I've been given few bits of useful information, the rest I 
figured out from sniffed USB communication.

Centering force seems to be modeled as a spring effect. Force created by a spring can be calculated as "F = -k*x" where F = force, k = stiffness coefficient 
and x = deflection from centre. The higher the k is, the faster the centering force increases when the wheel is turned. Saturation force seems to be the limit 
centering force, so when kx > saturation_force => F = saturation_force.
Logitech driver has a slider which sets the centering force from 0 % to 150 % (it's actually from 0 % to 200 %, at least the values in the command suggest 
so) and both the stiffness coeff and saturation force increase gradually with the centering force according to the formula I provide in the patch, so just the 
magnitude value is enough. It looks like the stiffness coeff actually wraps around, because 0 = no stiffness, 7 = max stiffness, 8 = low stiffness, 15 = max 
stiffness. It'd be interesting to see if you can observe the same behavior on the Wii wheel.

As for the other FF effects, I guess these are things like "rumble" etc. I'm planning to look into it more when I'll have some extra free time.

Regards, Michal.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-14 22:26   ` Michal Malý
@ 2011-06-14 23:16     ` simon
  2011-06-15  0:03       ` Michal Malý
       [not found]       ` <4429494.nOUqc25rPl@qosmio-x300>
  0 siblings, 2 replies; 13+ messages in thread
From: simon @ 2011-06-14 23:16 UTC (permalink / raw)
  To: "Michal Malý"; +Cc: simon, jkosina, linux-input


>> 2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel
>
> Sure, but please don't take it like I have some inside knowledge of
> Logitech FF implementation. I've been given few bits of useful
> information, the rest I figured out from sniffed USB communication.

Of course, we're all in the same boat of trying to figure it out. Our only
help is that Engineers are lazy and often reuse stuff they've done before.


> It looks like the stiffness coeff actually
> wraps around, because 0 = no stiffness, 7 = max stiffness, 8 = low
> stiffness, 15 = max
> stiffness. It'd be interesting to see if you can observe the same behavior
> on the Wii wheel.

Yes the Wii Wheel only does 0-7 and then loops too...

I actually meant to quantify the force produced and purchased a torque
meter, but its range wasn't low enough to be useful so I took it back. I
think I can do something with a 'luggage scale' pulling at a tangent to
the wheel so will give that a try.

My reverse engineer technique had a python-hid script so that I could
throw packets directly at the wheel to produce specific force setups. I
need to port this to python-libusb (as python-hid is dead), but that
should be relatively simple and can forward off list to anyone who wants a
copy.

>
> As for the other FF effects, I guess these are things like "rumble" etc.
> I'm planning to look into it more when I'll have some extra free time.

If you figure codes out, I'd love to try them against my Wheel. I did have
a PS3 Driving Force Wireless, but fried it's micro whilst I was hooking
the BusPirate up to it.

This would work under Windows and playback various effects in test mode as
you pushed buttons - if anybody can grab some USB logs of this I can
attempt to parse them for the codes....

Simon


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-14 23:16     ` simon
@ 2011-06-15  0:03       ` Michal Malý
       [not found]       ` <4429494.nOUqc25rPl@qosmio-x300>
  1 sibling, 0 replies; 13+ messages in thread
From: Michal Malý @ 2011-06-15  0:03 UTC (permalink / raw)
  To: simon; +Cc: jkosina, linux-input

On Tuesday 14 of June 2011 19:16:37 simon@mungewell.org wrote:
> My reverse engineer technique had a python-hid script so that I could
> throw packets directly at the wheel to produce specific force setups. I
> need to port this to python-libusb (as python-hid is dead), but that
> should be relatively simple and can forward off list to anyone who wants a
> copy.
>
You might want to check out Michael Bauer's LTWheelConf [1]. It's written in C so it's not the niftiest thing to use for 
playing around with the wheel, but adding support for the Wii wheel is a matter of 30 seconds. It uses libusb and I'm sure 
it can be easily modified to send whatever data you want to the wheel.

> This would work under Windows and playback various effects in test mode as
> you pushed buttons - if anybody can grab some USB logs of this I can
> attempt to parse them for the codes....
That's kind of my plan. I'll try to write some simple "effect generator" app using DirectInput and sniff the commands. By 
the way, I've been provided with the anti-center spring command description for my Driving Force Pro which I use to set 
the wheel's range. Is it accepted by the Wii wheel as well?

As I read the source of all lgff drivers, I wonder if all Logitech wheels shouldn't be handled in the lg4ff driver. I'm worried 
that further patching of lgff could break functionality with some older joysticks it's been originally meant to work with.

81 0B 19 E6 FF 4A FF:
 8* - set effect number 4, *1 - start effect command
 0B - effect type: spring
 19 - left hand ramp start (MSB)
 E6 - right hand ramp start (MSB)
 F* - RH stiffness (0xF:max), *F - LH stiffness (0xF:max)
 4* - RH ramp start (LSB) , LSbit is RH stiffness sign (0:+ 1:-)
 *A - LH ramp start (LSB), LSbit is LH stiffness sign (0:+ 1:-)
 FF - saturation level for spring force (0xFF = max)

In above example the wheel soft stops are set to
0x19A and 0xE64 or 410 and -412 where 0x7FF or 2047 corresponds to half a rotation range or 450 degrees. Therefore 
the wheel soft stops are set to +-360 degrees - the boundaries are calculated from the outsite.(410 / 2047 * 450)

(Description provided by lbondar, original can be found here [2])

[1] https://github.com/TripleSpeeder/LTWheelConf
[2] http://www.lfsforum.net/showthread.php?p=1603971#post1603971

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
       [not found]       ` <4429494.nOUqc25rPl@qosmio-x300>
@ 2011-06-15 21:56         ` Michal Malý
  0 siblings, 0 replies; 13+ messages in thread
From: Michal Malý @ 2011-06-15 21:56 UTC (permalink / raw)
  To: linux-input; +Cc: jkosina

After some followup discussion with Simon we figured that there might be a
better and more thorough solution. We'll submit the patch again when it's
ready.

Michal.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
       [not found]     ` <201106262207.23918.michael@m-bauer.org>
@ 2011-06-27 16:15       ` simon
  2011-06-27 20:58         ` Michal Malý
  0 siblings, 1 reply; 13+ messages in thread
From: simon @ 2011-06-27 16:15 UTC (permalink / raw)
  To: Michael Bauer; +Cc: linux-input, "Michal Malý"

Hi Guys,
Just to summerise the situation as I see it, and try to get a feel where
we should/could go.

Michael B. has figured out all of the 'compatible->native' commands, which
cause the wheels to renegoiate their USB ID's and have extended features
(up to 900' turn) to made available.

Michal M. wrote up a little C script to exercise the various effects that
we have found (FF_AUTOCENTER, FF_CONSTANT, FF_SPRING, FF_FRICTION,
FF_INTERIA). I had to modify this a little to work with the Wii wheel and
haven't had confirmation that it still works with the other wheels.

I think that we need to build a list/matrix and confirm that _all_ wheels
are OK with a single set of commands (autocenter for the FX excluded).


I think that the way forward is to move all of the wheels to 'lg4ff' and
change that for a more complete FF support. I suggest that we drop the
link to 'ff-memless' and implement our own system to register effects into
1 of the 4 available slots as they are requested.

'lg4ff' could also take on the role of managing the switch between
'compat->native' as it should know the range (<200' or >200') for
correctly setting the spring location.

A resent patch (https://patchwork.kernel.org/patch/921052/) for the
WiiMote gives a good example how to implement '/sys/' files and we could
use these to control the wheel's modes, such as:

/sys/bus/hid/drivers/lg4ff/<dev>/native - write 1 to switch to native,
read to get current state
/sys/bus/hid/drivers/lg4ff/<dev>/range - write angular range, read to get
current range

(rampspeed, autocenter, gain should be handled within FF framework)

Q. Do we need the ability to switch between split/combined pedals?


I think that all of the above is relatively simple to implement and can't
see that it would cause any existing users a problem. So what do you guys
think?

Simon



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-27 16:15       ` simon
@ 2011-06-27 20:58         ` Michal Malý
  2011-06-29  9:28           ` Michael Bauer
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Malý @ 2011-06-27 20:58 UTC (permalink / raw)
  To: simon; +Cc: Michael Bauer, linux-input, peter

> I think that we need to build a list/matrix and confirm that _all_ wheels
> are OK with a single set of commands (autocenter for the FX excluded).
I've tested your modded script and it worked fine with DFP. Peter who asked to be CC'ed too (I added him to CC) tried it 
out in G27 and reported that all was OK.

> I think that the way forward is to move all of the wheels to 'lg4ff' and
> change that for a more complete FF support. I suggest that we drop the
> link to 'ff-memless' and implement our own system to register effects into
> 1 of the 4 available slots as they are requested.
I have mixed feelings about dropping ff-memless. Currently the ff-memless driver does all the dirty job for us, it also does 
some simple maths like calculating X and Y force strength for FF_CONSTANT effect so we'd be duplicating code here.
On the other hand there are Logitech-specific features that ff-memless can't possibly handle like the effect reset, range 
setting, even the leds on G27 are controlled by some sort of custom FF command. Can you foreshadow how we could 
drop the ff-memless without creating any unnecessary mess in the force feedback stack?

> 'lg4ff' could also take on the role of managing the switch between
> 'compat->native' as it should know the range (<200' or >200') for
> correctly setting the spring location.
> 
> A resent patch (https://patchwork.kernel.org/patch/921052/) for the
> WiiMote gives a good example how to implement '/sys/' files and we could
> use these to control the wheel's modes, such as:
> 
> /sys/bus/hid/drivers/lg4ff/<dev>/native - write 1 to switch to native,
> read to get current state
> /sys/bus/hid/drivers/lg4ff/<dev>/range - write angular range, read to get
> current range
> Q. Do we need the ability to switch between split/combined pedals?
> 
I guess I answered that above, I'd absolutely love to get this into the kernel. Using /sys sounds like the best way to me. 
There are two issues I can think of. First wheels actually simulate reconnect when they're switched to the native mode, 
so I guess we'd have to be careful and not cause any memory leaks and stuff. Second all Logitech wheels short of 
G25/27 need a replaced HID descriptor to get separate pedals working, so unless there's a reasonable way how to read 
the anonymous fields reported in the original descriptor, I say keep the pedals always separate for now.

To sum it up, I think we have a plan.

Michal

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-27 20:58         ` Michal Malý
@ 2011-06-29  9:28           ` Michael Bauer
  2011-06-29 15:23             ` Michael Bauer
  2011-06-29 15:50             ` simon
  0 siblings, 2 replies; 13+ messages in thread
From: Michael Bauer @ 2011-06-29  9:28 UTC (permalink / raw)
  To: Michal Malý; +Cc: simon, linux-input, peter

Am 27.06.2011 22:58, schrieb Michal Malý:
>> I think that we need to build a list/matrix and confirm that _all_ wheels
>> are OK with a single set of commands (autocenter for the FX excluded).
> I've tested your modded script and it worked fine with DFP. Peter who asked to be CC'ed too (I added him to CC) tried it
> out in G27 and reported that all was OK.
DFP, G25 and Momo Racing also worked fine on my side.

>> A resent patch (https://patchwork.kernel.org/patch/921052/) for the
>> WiiMote gives a good example how to implement '/sys/' files and we could
>> use these to control the wheel's modes, such as:
>>
>> /sys/bus/hid/drivers/lg4ff/<dev>/native - write 1 to switch to native,
>> read to get current state
>> /sys/bus/hid/drivers/lg4ff/<dev>/range - write angular range, read to get
>> current range
Yes, i also vote for something like this. Just keep in mind that we 
still need to find a reliable way to identify exactly the correct wheel, 
as they all register initially with the same VID/PID but need different 
commands for native mode and range.
This might be possible using the revision number - I am trying to get 
this implemented in ltwheelconf soon to have some more users test if it 
works.

>> Q. Do we need the ability to switch between split/combined pedals?
I am not sure on this - on the one hand i would love to provide all 
options to the user.
On the other hand i am not sure how this could be done. I do not think 
it is possible to change the report descriptor of a connected device on 
the fly without (not necessarily physically) reconnecting it?
And from my understanding the combined axes are just some kind of legacy 
stuff to support really old games which can not handle the separate axes.
So from my opinion we should at least initially just provide separate 
axes and don't try to implement complicated stuff to allow switching to 
combined mode.

> I guess I answered that above, I'd absolutely love to get this into the kernel. Using /sys sounds like the best way to me.
> There are two issues I can think of. First wheels actually simulate reconnect when they're switched to the native mode,
> so I guess we'd have to be careful and not cause any memory leaks and stuff. Second all Logitech wheels short of
> G25/27 need a replaced HID descriptor to get separate pedals working, so unless there's a reasonable way how to read
> the anonymous fields reported in the original descriptor, I say keep the pedals always separate for now.
I agree as stated above :-)

Best regards
Michael
--
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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-29  9:28           ` Michael Bauer
@ 2011-06-29 15:23             ` Michael Bauer
  2011-06-29 15:50             ` simon
  1 sibling, 0 replies; 13+ messages in thread
From: Michael Bauer @ 2011-06-29 15:23 UTC (permalink / raw)
  To: Michal Malý; +Cc: simon, linux-input, peter

Hi,

another small note:
>>> /sys/bus/hid/drivers/lg4ff/<dev>/native - write 1 to switch to native,
>>> read to get current state
Is there any reason the switch to native mode should not be done 
automatically by the driver? I would prefer to have it working 
out-of-the-box instead of having to wait for userspace interaction. 
(This could be done by some udev rule(s), but then this would need to be 
adopted by all distributions...)

I do not see any point in using the wheel in restricted mode when native 
mode is possible...

Best regards
Michael

> --
> 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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-29  9:28           ` Michael Bauer
  2011-06-29 15:23             ` Michael Bauer
@ 2011-06-29 15:50             ` simon
  2011-06-29 21:37               ` Michal Malý
  2011-07-05 23:04               ` Michal Malý
  1 sibling, 2 replies; 13+ messages in thread
From: simon @ 2011-06-29 15:50 UTC (permalink / raw)
  To: Michael Bauer; +Cc: "Michal Malý", simon, linux-input, peter


>>> Q. Do we need the ability to switch between split/combined pedals?

> I am not sure on this - on the one hand i would love to provide all
> options to the user.

> On the other hand i am not sure how this could be done. I do not think
> it is possible to change the report descriptor of a connected device on
> the fly without (not necessarily physically) reconnecting it?

> And from my understanding the combined axes are just some kind of legacy
> stuff to support really old games which can not handle the separate axes.

Can you (someone?) clarify which wheels do not have a command to switch
into 'native mode' (which causes a USB ID change) and do these wheels use
a unified brake/acc.?

Do any wheels have a 'native mode' which stay with the generic USB ID?

Wouldn't the device descriptor only be re-written for the new USB ID's in
'native' mode.

Note: The Wii wheel does not have a 'native' command/mode, but has a
unique ID which is always used.


> Is there any reason the switch to native mode should not be done
> automatically by the driver? I would prefer to have it working
> out-of-the-box instead of having to wait for userspace interaction.
> (This could be done by some udev rule(s), but then this would need to be
> adopted by all distributions...)

> I do not see any point in using the wheel in restricted mode when native
> mode is possible...

If we force the 'native command' to be issued then we might affect/prevent
any 'old game' play.

Note 2: At present the re-writing of descriptor is done in 'hid-lg.c'
(based on USB ID), whereas we are proposing the 'native' command to be
issued by 'hid-lg4ff.c' which might not be complied/enabled.

Perhaps disabling/blacklisting 'hid-lg4ff' is a sufficient workaround to
get older games working... or a module option of 'no-native' could prevent
the command being sent.



Also I noticed that the second part of the 'DFP native command', is very
similar to a strong spring set to slot 4....

Simon


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-29 15:50             ` simon
@ 2011-06-29 21:37               ` Michal Malý
  2011-07-05 23:04               ` Michal Malý
  1 sibling, 0 replies; 13+ messages in thread
From: Michal Malý @ 2011-06-29 21:37 UTC (permalink / raw)
  To: simon; +Cc: Michael Bauer, linux-input, peter

> Can you (someone?) clarify which wheels do not have a command to switch
> into 'native mode' (which causes a USB ID change) and do these wheels use
> a unified brake/acc.?
> Do any wheels have a 'native mode' which stay with the generic USB ID?
To my knowledge all wheels except original Driving Force and Formula Force 
have the fallback and native mode. Every Logitech wheel in fallback mode 
reports PID 0x294 which is the PID of the original Driving Force wheel. If 
DFP/G25/G27/DFGT receives specific command, it simulates reconnect and reports 
its "real" PID upon reconnection. 

> Wouldn't the device descriptor only be re-written for the new USB ID's in
> 'native' mode.
DF/DFP/FEX hides the separate throttle and brake axes in the original 
descriptor so we definitely need to replace it. G25/27 don't need such a hack, 
I don't know how about DFGT or Momo, I'll try to find that out.
IMHO we need to replace the descriptor only if the wheel has PID 0x294 and is 
either DF or FEX. DFP has PID 0x298 and needs a fixed descriptor too.

> If we force the 'native command' to be issued then we might affect/prevent
> any 'old game' play.
Problem is that not all wheels actually have the native mode as I mentioned 
above, but all support separate pedal axes. Unless we somehow read the 
anonymous fields reported by the original descriptor, I guess we'll have to 
decide whether to have separate or combined pedal axes.
Another (rather hackish) way around this would be a "combined" value in /sys 
interface. When set to 1, we'd trigger reconnection (can we do that?) and not 
replace the descriptor (or replace it in case of G25/27).


I've given some thought bypassing the ff-memless driver and I don't think it's 
necessary. We can patch ff-memless and add support for the missing effects. I 
guess that passing the device-specific commands like effect reset, G27 leds and 
range setting could be done via /sys interface too.
However that's just a thought...

Michal

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] Fix autocentering command in hid-lgff driver
  2011-06-29 15:50             ` simon
  2011-06-29 21:37               ` Michal Malý
@ 2011-07-05 23:04               ` Michal Malý
  1 sibling, 0 replies; 13+ messages in thread
From: Michal Malý @ 2011-07-05 23:04 UTC (permalink / raw)
  To: simon; +Cc: Michael Bauer, linux-input, peter

Hello everone,

I challenged myself a bit so there is a preliminary version of reworked lg4ff driver. It has basic implementation of the sysfs 
interface and it can be used to change wheel's range. Currently only DFP is supported but adding the G2x/DFGT 
command will be a piece of cake.
It applies to 3.0-rc5 and depends Michael B.'s DFP descriptor patch. At also depends on a trivial patch which adds 
support for DFGT (included). I wonder if the driver handles multiple devices properly. If I understand it correctly it should 
be OK, but I can't test it myself.

Things to do are:
- Add range setting for G2x/DFGT
- Add wheel identification based on revision number
- Add native/fallback switching
- Clean up the code, make it more unified
- Add the rest of FF effects, will most likely need a patched ff_memless

Regards, Michal.

>From 65d77958097fa4b1e71f033822dbcdc441999bb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20Mal=C3=BD?= <madcatxster@gmail.com>
Date: Mon, 4 Jul 2011 14:18:07 +0200
Subject: [PATCH 2/3] Added Driving Force GT product ID.

---
 drivers/hid/hid-ids.h |    1 +
 drivers/hid/hid-lg.c  |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index a756ee6..79ba659 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -433,6 +433,7 @@
 #define USB_DEVICE_ID_LOGITECH_MOMO_WHEEL	0xc295
 #define USB_DEVICE_ID_LOGITECH_DFP_WHEEL	0xc298
 #define USB_DEVICE_ID_LOGITECH_G25_WHEEL	0xc299
+#define USB_DEVICE_ID_LOGITECH_DFGT_WHEEL	0xc29a
 #define USB_DEVICE_ID_LOGITECH_G27_WHEEL	0xc29b
 #define USB_DEVICE_ID_LOGITECH_WII_WHEEL	0xc29c
 #define USB_DEVICE_ID_LOGITECH_ELITE_KBD	0xc30a
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index a15ce9e..52e8d65 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -452,6 +452,8 @@ static const struct hid_device_id lg_devices[] = {
 		.driver_data = LG_FF },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFP_WHEEL),
 		.driver_data = LG_NOGET | LG_FF },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFGT_WHEEL),
+		.driver_data = LG_FF },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WII_WHEEL),
 		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WINGMAN_FFG ),
-- 
1.7.6

>From 7992434338d39959b26cdc1bed39a2a0f2afd59b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20Mal=C3=BD?= <madcatxster@gmail.com>
Date: Wed, 6 Jul 2011 00:36:10 +0200
Subject: [PATCH 3/3] - Moved all Logitech wheel force feedback handling to
 lg4ff driver - Added basic sysfs support to se wheel's
 range (if supported). Currently   available for Driving
 Force pro only

---
 drivers/hid/hid-lg.c    |   26 +++++---
 drivers/hid/hid-lg.h    |    2 +
 drivers/hid/hid-lg4ff.c |  181 +++++++++++++++++++++++++++++++++++++++++------
 drivers/hid/hid-lgff.c  |    7 --
 4 files changed, 179 insertions(+), 37 deletions(-)

diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index 52e8d65..be77789 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -362,7 +362,7 @@ static int lg_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		goto err_free;
 	}
 
-	if (quirks & (LG_FF | LG_FF2 | LG_FF3))
+	if (quirks & (LG_FF | LG_FF2 | LG_FF3 | LG_FF4))
 		connect_mask &= ~HID_CONNECT_FF;
 
 	ret = hid_hw_start(hdev, connect_mask);
@@ -371,7 +371,8 @@ static int lg_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		goto err_free;
 	}
 
-	if (quirks & LG_FF4) {
+	/* Setup wireless link with Logitech Wii wheel */
+	if(hdev->product == USB_DEVICE_ID_LOGITECH_WII_WHEEL) {
 		unsigned char buf[] = { 0x00, 0xAF,  0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
 
 		ret = hdev->hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT);
@@ -404,6 +405,12 @@ err_free:
 	return ret;
 }
 
+static void lg_remove(struct hid_device *hdev)
+{
+	if(hdev->quirks & LG_FF4)
+		lg4ff_deinit(hdev);
+}
+
 static const struct hid_device_id lg_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER),
 		.driver_data = LG_RDESC | LG_WIRELESS },
@@ -430,7 +437,7 @@ static const struct hid_device_id lg_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_EXTREME_3D),
 		.driver_data = LG_NOGET },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WHEEL),
-		.driver_data = LG_NOGET | LG_FF },
+		.driver_data = LG_NOGET | LG_FF4 },
 
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD),
 		.driver_data = LG_FF2 },
@@ -443,17 +450,17 @@ static const struct hid_device_id lg_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_FORCE3D_PRO),
 		.driver_data = LG_FF },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOMO_WHEEL),
-		.driver_data = LG_FF },
+		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2),
-		.driver_data = LG_FF },
+		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G25_WHEEL),
-		.driver_data = LG_FF },
+		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G27_WHEEL),
-		.driver_data = LG_FF },
+		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFP_WHEEL),
-		.driver_data = LG_NOGET | LG_FF },
+		.driver_data = LG_NOGET | LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_DFGT_WHEEL),
-		.driver_data = LG_FF },
+		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WII_WHEEL),
 		.driver_data = LG_FF4 },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WINGMAN_FFG ),
@@ -479,6 +486,7 @@ static struct hid_driver lg_driver = {
 	.input_mapped = lg_input_mapped,
 	.event = lg_event,
 	.probe = lg_probe,
+	.remove = lg_remove
 };
 
 static int __init lg_init(void)
diff --git a/drivers/hid/hid-lg.h b/drivers/hid/hid-lg.h
index b0100ba..3a32959 100644
--- a/drivers/hid/hid-lg.h
+++ b/drivers/hid/hid-lg.h
@@ -21,8 +21,10 @@ static inline int lg3ff_init(struct hid_device *hdev) { return -1; }
 
 #ifdef CONFIG_LOGIWII_FF
 int lg4ff_init(struct hid_device *hdev);
+int lg4ff_deinit(struct hid_device *hdev);
 #else
 static inline int lg4ff_init(struct hid_device *hdev) { return -1; }
+static inline int lg4ff_deinit(struct hid_device *hdev) { return -1; }
 #endif
 
 #endif
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index fa550c8..b3bcf06 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -29,19 +29,43 @@
 
 #include "usbhid/usbhid.h"
 #include "hid-lg.h"
+#include "hid-ids.h"
 
-struct lg4ff_device {
-	struct hid_report *report;
-};
+#define to_hid_device(pdev) container_of(pdev, struct hid_device, dev)
+
+unsigned short ff4_wheel_range;
+
+static void hid_lg4ff_set_autocenter_default(struct input_dev *hid, u16 magnitude);
+void (*hid_ff4_set_range)(struct hid_device *hid, u16 range);
+static ssize_t ff4_range_show(struct device *dev, struct device_attribute *attr, char *buf);
+static ssize_t ff4_range_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
+
+static DEVICE_ATTR(range_set, S_IWUSR | S_IRUGO, ff4_range_show, ff4_range_store);
 
-static const signed short ff4_wheel_ac[] = {
+static const signed short ff4_wheel_effects[] = {
 	FF_CONSTANT,
 	FF_AUTOCENTER,
 	-1
 };
 
-static int hid_lg4ff_play(struct input_dev *dev, void *data,
-			 struct ff_effect *effect)
+struct ff4_wheel_device {
+	__u32 product_id;
+	const signed short *ff_effects;
+	void (*set_autocenter)(struct input_dev *dev, u16 magnitude);
+	const int adj_range;	/* 0 - Not available, 1 - G2x/DFGT command, 2 - DFP command */
+};
+
+static const struct ff4_wheel_device ff4_devices[] = {
+	{USB_DEVICE_ID_LOGITECH_WHEEL,       ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 0},
+	{USB_DEVICE_ID_LOGITECH_MOMO_WHEEL,  ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 0},
+	{USB_DEVICE_ID_LOGITECH_DFP_WHEEL,   ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 2},
+	{USB_DEVICE_ID_LOGITECH_G25_WHEEL,   ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 1},
+	{USB_DEVICE_ID_LOGITECH_DFGT_WHEEL,  ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 1},
+	{USB_DEVICE_ID_LOGITECH_G27_WHEEL,   ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 1},
+	{USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2, ff4_wheel_effects, hid_lg4ff_set_autocenter_default, 0}
+};
+
+static int hid_lg4ff_play(struct input_dev *dev, void *data, struct ff_effect *effect)
 {
 	struct hid_device *hid = input_get_drvdata(dev);
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
@@ -55,11 +79,11 @@ static int hid_lg4ff_play(struct input_dev *dev, void *data,
 		x = effect->u.ramp.start_level + 0x80;	/* 0x80 is no force */
 		CLAMP(x);
 		report->field[0]->value[0] = 0x11;	/* Slot 1 */
-		report->field[0]->value[1] = 0x10;
+		report->field[0]->value[1] = 0x08;
 		report->field[0]->value[2] = x;
-		report->field[0]->value[3] = 0x00;
+		report->field[0]->value[3] = 0x80;
 		report->field[0]->value[4] = 0x00;
-		report->field[0]->value[5] = 0x08;
+		report->field[0]->value[5] = 0x00;
 		report->field[0]->value[6] = 0x00;
 		dbg_hid("Autocenter, x=0x%02X\n", x);
 
@@ -69,7 +93,9 @@ static int hid_lg4ff_play(struct input_dev *dev, void *data,
 	return 0;
 }
 
-static void hid_lg4ff_set_autocenter(struct input_dev *dev, u16 magnitude)
+/* Sends default autocentering command compatible with
+ * all wheels except Formula Force EX */
+static void hid_lg4ff_set_autocenter_default(struct input_dev *dev, u16 magnitude)
 {
 	struct hid_device *hid = input_get_drvdata(dev);
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
@@ -78,15 +104,88 @@ static void hid_lg4ff_set_autocenter(struct input_dev *dev, u16 magnitude)
 
 	*value++ = 0xfe;
 	*value++ = 0x0d;
-	*value++ = 0x07;
-	*value++ = 0x07;
-	*value++ = (magnitude >> 8) & 0xff;
+	*value++ = magnitude >> 13;
+	*value++ = magnitude >> 13;
+	*value++ = magnitude >> 8;
 	*value++ = 0x00;
 	*value = 0x00;
 
 	usbhid_submit_report(hid, report, USB_DIR_OUT);
 }
 
+/* Sends commands to set range compatible with Driving Force Pro wheel */
+static void hid_lg4ff_set_range_dfp(struct hid_device *hid, u16 range)
+{
+	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
+	struct hid_report *report = list_entry(report_list->next, struct hid_report, list);
+	int start_left, start_right, full_range;
+	dbg_hid("Driving Force Pro: setting range to %u\n", range);
+	
+	/* Prepare "coarse" limit command */
+	report->field[0]->value[0] = 0xf8;
+	report->field[0]->value[1] = 0x00; 	/* Set later */
+	report->field[0]->value[2] = 0x00;
+	report->field[0]->value[3] = 0x00;
+	report->field[0]->value[4] = 0x00;
+	report->field[0]->value[5] = 0x00;
+	report->field[0]->value[6] = 0x00;
+    
+	if(range > 200) {
+		report->field[0]->value[1] = 0x03;
+		full_range = 900;
+	} else {
+		report->field[0]->value[1] = 0x02;
+		full_range = 200;
+	}
+	usbhid_submit_report(hid, report, USB_DIR_OUT);
+	
+	/* Prepare "fine" limit command */
+	report->field[0]->value[0] = 0x81;
+	report->field[0]->value[1] = 0x0b;
+	report->field[0]->value[2] = 0x00;
+	report->field[0]->value[3] = 0x00;
+	report->field[0]->value[4] = 0x00;
+	report->field[0]->value[5] = 0x00;
+	report->field[0]->value[6] = 0x00;
+	
+	if(range == 200 || range == 900) {	/* Do not apply any fine limit */
+		usbhid_submit_report(hid, report, USB_DIR_OUT);
+		ff4_wheel_range = range;
+		return;
+	}
+
+	/* Construct range limiting command */
+	start_left = (((full_range - range + 1) * 2047) / full_range);
+	start_right = 0xfff - start_left;
+
+	report->field[0]->value[2] = start_left >> 4;
+	report->field[0]->value[3] = start_right >> 4;
+	report->field[0]->value[4] = 0xff;
+	report->field[0]->value[5] = (start_right & 0xe) << 4 | (start_left & 0xe);
+	report->field[0]->value[6] = 0xff;
+
+	usbhid_submit_report(hid, report, USB_DIR_OUT);
+	ff4_wheel_range = range;
+}
+
+/* Read current range and display it in terminal */
+static ssize_t ff4_range_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	return scnprintf(buf, PAGE_SIZE, "%d\n", ff4_wheel_range);
+}
+
+/* Set range to user specified value, call appropriate function
+ * according to the type of the wheel */
+static ssize_t ff4_range_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	u16 range = simple_strtoul(buf, NULL, 10);
+	/* Check that the range is within margins and that the wheel
+	 * supports setting a custom range */
+	if(range > 39 && range < 901 && hid_ff4_set_range != 0)
+		hid_ff4_set_range(to_hid_device(dev), range);
+
+	return count;
+}
 
 int lg4ff_init(struct hid_device *hid)
 {
@@ -95,9 +194,7 @@ int lg4ff_init(struct hid_device *hid)
 	struct input_dev *dev = hidinput->input;
 	struct hid_report *report;
 	struct hid_field *field;
-	const signed short *ff_bits = ff4_wheel_ac;
-	int error;
-	int i;
+	int error, i, j;
 
 	/* Find the report to use */
 	if (list_empty(report_list)) {
@@ -117,19 +214,61 @@ int lg4ff_init(struct hid_device *hid)
 		hid_err(hid, "NULL field\n");
 		return -1;
 	}
-
-	for (i = 0; ff_bits[i] >= 0; i++)
-		set_bit(ff_bits[i], dev->ffbit);
+	
+	/* Check what model of wheel has been connected */
+	for(i = 0; i < ARRAY_SIZE(ff4_devices); i++) {
+		if(hid->product == ff4_devices[i].product_id) {
+			dbg_hid("Found compatible device %04X\n", ff4_devices[i].product_id);
+			break;
+		}
+	}
+	
+	if(i == ARRAY_SIZE(ff4_devices)) {
+		hid_info(hid, "Device not supported yet\n");
+		return -1;
+	}
+	
+	/* Set supported force feedback capabilities */
+	for (j = 0; ff4_devices[i].ff_effects[j] >= 0; j++)
+		set_bit(ff4_devices[i].ff_effects[j], dev->ffbit);
 
 	error = input_ff_create_memless(dev, NULL, hid_lg4ff_play);
 
 	if (error)
 		return error;
 
-	if (test_bit(FF_AUTOCENTER, dev->ffbit))
-		dev->ff->set_autocenter = hid_lg4ff_set_autocenter;
+	/* Check if autocentering is available and
+	 * disable it by default */
+	if (test_bit(FF_AUTOCENTER, dev->ffbit)) {
+		dev->ff->set_autocenter = ff4_devices[i].set_autocenter;
+		dev->ff->set_autocenter(dev, (u16)0);
+	}
+
+	/* Check if the wheel supports range adjustment, if it does,
+	 * set appropirate range setting function. */
+	switch(ff4_devices[i].adj_range) {
+		case 2:
+			hid_ff4_set_range = hid_lg4ff_set_range_dfp;
+			break;
+		default:
+			hid_ff4_set_range = 0;
+	}
 
+	/* Create /sys interface */
+	if(ff4_devices[i].adj_range > 0) {
+		error = device_create_file(&hid->dev, &dev_attr_range_set);
+		if(error)
+			return error;
+		dbg_hid("/sys interface created\n");
+		hid_ff4_set_range(hid, (u16)900);
+	}
+	
 	hid_info(hid, "Force feedback for Logitech Speed Force Wireless by Simon Wood <simon@mungewell.org>\n");
 	return 0;
 }
 
+int lg4ff_deinit(struct hid_device *hid)
+{
+	device_remove_file(&hid->dev, &dev_attr_range_set);
+	return 0;
+}
diff --git a/drivers/hid/hid-lgff.c b/drivers/hid/hid-lgff.c
index 088f850..a53175e 100644
--- a/drivers/hid/hid-lgff.c
+++ b/drivers/hid/hid-lgff.c
@@ -71,14 +71,7 @@ static const struct dev_type devices[] = {
 	{ 0x046d, 0xc286, ff_joystick_ac },
 	{ 0x046d, 0xc287, ff_joystick_ac },
 	{ 0x046d, 0xc293, ff_joystick },
-	{ 0x046d, 0xc294, ff_wheel },
-	{ 0x046d, 0xc298, ff_wheel },
-	{ 0x046d, 0xc299, ff_wheel },
-	{ 0x046d, 0xc29b, ff_wheel },
 	{ 0x046d, 0xc295, ff_joystick },
-	{ 0x046d, 0xc298, ff_wheel },
-	{ 0x046d, 0xc299, ff_wheel },
-	{ 0x046d, 0xca03, ff_wheel },
 };
 
 static int hid_lgff_play(struct input_dev *dev, void *data, struct ff_effect *effect)
-- 
1.7.6



^ permalink raw reply related	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-07-05 23:04 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-14 20:42 [PATCH] Fix autocentering command in hid-lgff driver Michal Malý
2011-06-14 21:20 ` simon
2011-06-14 22:26   ` Michal Malý
2011-06-14 23:16     ` simon
2011-06-15  0:03       ` Michal Malý
     [not found]       ` <4429494.nOUqc25rPl@qosmio-x300>
2011-06-15 21:56         ` Michal Malý
     [not found] ` <1908821.jaYXT1Nn2e@qosmio-x300>
     [not found]   ` <da2b7e45ed001b587d49824944b802b8.squirrel@host171.canaca.com>
     [not found]     ` <201106262207.23918.michael@m-bauer.org>
2011-06-27 16:15       ` simon
2011-06-27 20:58         ` Michal Malý
2011-06-29  9:28           ` Michael Bauer
2011-06-29 15:23             ` Michael Bauer
2011-06-29 15:50             ` simon
2011-06-29 21:37               ` Michal Malý
2011-07-05 23:04               ` Michal Malý

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).