linux-kernel - Re: [PATCH 2/2] Fix force effect modifications for the Microsoft Sidewinder Force Feedback Pro 2 joystick

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0000014b1b51014e-a736e0b0-11f5-4a60-b857-4585e9e9106d-000000@email.amazonses.com>
Date:	Sat, 24 Jan 2015 09:41:08 +0000
From:	Jim Keir <jimkeir@...cledbadirect.com>
To:	Benjamin Tissoires <benjamin.tissoires@...il.com>
CC:	linux-input <linux-input@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 2/2] Fix force effect modifications for the Microsoft
 Sidewinder Force Feedback Pro 2 joystick

Hi,

Yes, confirmed. The description below still holds.

Cheers,
Jim

On 23/01/2015 18:54, Benjamin Tissoires wrote:
> I have no clue what this code is doing (don't know much about the ff system).
> Quoting your initial 0001/0001, I thing the commit message should be
> the following.
> Jim, can you please validate it?
>
> "
> The FF2 driver (usbhid/hid-pidff.c) does not set the effect ID when
> uploading an effect. The result is that the initial upload works but
> subsequent uploads to modify effect parameters are all directed at the
> last-created effect.
>
> The targeted effect ID must be passed back to the device when effect
> parameters are changed. This is done at the start of
> "pidff_set_condition_report", "pidff_set_periodic_report" etc. based on
> the value of "pidff->block_load[PID_EFFECT_
> BLOCK_INDEX].value[0]".
> However, this value is only ever set during pidff_request_effect_upload.
> The result is stored in "pidff->pid_id[effect->id]" at the end of
> pid_upload_effect, for later use. However, if an effect is modified and
> re-sent then this identifier is not being copied back from
> pidff->pid_id[effect->id] before sending the command to the device. The
> fix is to do this at the start of pidff_upload_effect.
> "
>
> ---
>
> As said, I have no clue* of what this is supposed to do, so I can not
> add my reviewed-by here. The patch seems good however so nothing
> should prevent us to take it if it fixes your problem :)
>
> Cheers,
> Benjamin
>
> * OK, I am pushing a little bit, I just don't want today to go deep in
> the code :-)
>
>
> On Fri, Jan 23, 2015 at 12:21 PM, Jim Keir <jimkeir@...cledbadirect.com> wrote:
>> ---
>> Hi,
>>
>> Changes from previous patches:
>> - All changes removed from higher-level files
>> - Extra debug line removed
>>
>> Signed-off-by: Jim Keir <jimkeir@...cledbadirect.com>
>>
>>   drivers/hid/usbhid/hid-pidff.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
>> index 0b531c6..1b3fa70 100644
>> --- a/drivers/hid/usbhid/hid-pidff.c
>> +++ b/drivers/hid/usbhid/hid-pidff.c
>> @@ -568,6 +568,12 @@ static int pidff_upload_effect(struct input_dev *dev, struct ff_effect *effect,
>>          int type_id;
>>          int error;
>>
>> +       pidff->block_load[PID_EFFECT_BLOCK_INDEX].value[0] = 0;
>> +       if (old && effect) {
>> +               pidff->block_load[PID_EFFECT_BLOCK_INDEX].value[0] =
>> +                       pidff->pid_id[effect->id];
>> +       }
>> +
>>          switch (effect->type) {
>>          case FF_CONSTANT:
>>                  if (!old) {
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/