From: Antonio Ospite <ospite@studenti.unina.it>
To: simon@mungewell.org
Cc: linux-input@vger.kernel.org, Marcin Tolysz <tolysz@gmail.com>
Subject: Re: Rewriting wheels HID descriptor for complete functionality
Date: Wed, 1 Dec 2010 22:20:22 +0100 [thread overview]
Message-ID: <20101201222022.b2e49a1b.ospite@studenti.unina.it> (raw)
In-Reply-To: <e0bdb04c6bf793ed464934fd4f8b663e.squirrel@host171.canaca.com>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
On Wed, 1 Dec 2010 13:23:15 -0500
simon@mungewell.org wrote:
> I am working on a driver for a Logitech gaming wheel where the HID
> descriptor presents a 'joystick' with X and Y axis, the Y is a combined
> acc/brake value even though the wheel has separate paddles for each.
>
> There are 'vendor defined' variables for both the acc/brake within the HID
> descriptor, but these are not (by Linux) tied to their function.
>
> On the Windows, the specialised Logitech driver gives the option to use
> either combined or separate acc/brake.
>
> I am considering re-writing the HID descriptor to expose these separate
> values as 'proper' axis, as they would provide both better resolution and
> better functionality (ie. left foot braking).
>
Simon,
have you tried Marcin Tolysz's approach of loading the new HID
descriptor from an external file?
Look at:
https://patchwork.kernel.org/patch/69723/
If there is interest maybe Marcin's way could be brought back on the
discussion table (Marcin added to CC).
I'll be needing descriptor patching for Sony Sixaxis too, after I solved
some other issues, so I am also interested on settling on a "standard"
way to achieve that.
> Q1. Is this an acceptable thing to do?
>
> Q2. In the case where there is significant change to the HID descriptor,
> is it OK to just re-write the whole block (rather than patch/swap a couple
> of bytes)?
>
> Q3. In re-writing descriptor for the combined acc/brake. Is there a
> particular 'variable' I should change it to (X, Y and Z would already be
> used), or should I just make it 'vendor defined'?
>
> Thanks in advance,
> Simon
> (aka Mungewell)
>
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-12-01 21:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 18:23 Rewriting wheels HID descriptor for complete functionality simon
2010-12-01 19:32 ` Nikolai Kondrashov
2010-12-01 21:20 ` Antonio Ospite [this message]
2010-12-01 22:18 ` simon
2011-02-27 22:45 ` Marcin Tolysz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101201222022.b2e49a1b.ospite@studenti.unina.it \
--to=ospite@studenti.unina.it \
--cc=linux-input@vger.kernel.org \
--cc=simon@mungewell.org \
--cc=tolysz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox