linux-kernel - Re: joydev.c and saitek cyborg evo force

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: <d9b9d95f0706120608g979b89oc79dbc277d19862b@mail.gmail.com>
Date:	Tue, 12 Jun 2007 14:08:27 +0100
From:	"Renato Golin" <rengolin@...il.com>
To:	"Jiri Kosina" <jkosina@...e.cz>
Cc:	linux-kernel@...r.kernel.org,
	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
Subject: Re: joydev.c and saitek cyborg evo force

On 12/06/07, Jiri Kosina <jkosina@...e.cz> wrote:
> the thing is that the aim of this quirk is to normalize the values that
> are being reported by bogus devices, so we don't really want to trust the
> values they provide here, do we?

Hi Jiri,

I don't know about the other joysticks, but Saitek did reported [0,
4096] which is the right answer, but between HID and Joydev it was
converted to [-127, 127]. I thought that the quirk was about that.

But seeing the quirk code it seems that if the range doesn't match it
forces [0, 256] (not trusting anything the device sends) and that's
not really needed for Saitek.

I'm not at all sure how the other devices behave and I do understand
the difficulty in testing every single one.

My opinion is that we shouldn't fall back to a hard-coded range for
all types of errors and rely on user calibration. Normally, game users
tend to dislike having to quit the game and recalibrate the joystick
to restart the game again (I do, at least). Furthermore, dealing with
every single type of error is impossible unless you have all devices
available for a recursive test every time something change, which is
not true.

Therefore, my view is that the only neat solution to all that is to
report the range as [0, 0] and auto-calibrate afterwards, while the
device is in use and reporting the real range. I found out that, not
all times the range goes to 4096, most of the time it stays as far as
4038, and setting the final range to that value (with
auto-calibration) is even more precise than the reported by the
device.

The drawback is the few calculations done during the first movements
of the joystick (function call and four small formulas) and the two
"IF (a > b)" for every axis event afterwards.

As this is my first kernel mode code I'm not sure how would that
schedule with other kernel processes (normally I rely on kernel's
scheduling process) but for a user-land program (real-time games
included) I wouldn't say it's too much overhead.

Let me know if I got it all backwards... ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
-
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/