From: "John Z." <johnz@pleasantnightmare.com>
To: linux-input@vger.kernel.org
Subject: Thrustmaster T.Flight 4 driver, help needed
Date: Thu, 21 May 2020 12:29:43 -0300 [thread overview]
Message-ID: <20200521152943.GE77215@johnslap.localdomain> (raw)
Hello all,
I've recently acquired Thrustmaster T.Flight 4 HOTAS, and few of the
axes do not work, so I wanted to try and fix that.
I've gotten as far as decoding the USB HID report and comparing it
to the data packets - and realizing that HID report basically lies
about offsets.
The axes that do work are reported correctly, but those that are
missing are changing byte values in Vendor Specific areas. The user
manual also says that if the HOTAS is to be used on PC, it is very
important to install proprietary driver, otherwise some axes won't
work.
I've got a tip from a friend that some hardware requires vendor
specific GET FEATURE request to put hardware into compliant mode,
but I have instead started hacking together a simple userspace
program to parse bytes at correct offsets, and then asked for advice
about how to get this done so that joydev (or evdev, I am not sure)
properly picks this up, rather than (I'm assuming?) relying on HID
report to get the data.
This _might_ produce a buggy driver since joystick has a plug for
pedals as well, which may change things if they're plugged in.
Another person advised me that they don't believe this can be done
in userspace, that I should write a kernel module if I feel capable,
and that if I'm comfortable with coding and willing to merge it
upstream - I should seek further help here.
They further suggested that it might be possible to use a generic
driver as a foundation and make a specialized version that only
loads when vendor and product ID's match the hardware.
If these suggestions are correct - I have a basic skeleton
helloworld module building and working and my userspace prototype
(based on Alan Ott's example). I could use some guidance, even just
pointers to correct places in documentation would be very useful. I
tried finding my way myself, but there's so much information I have
no idea where to even start.
Thanks.
--
John Z.
"Rip and tear until it is done."
reply other threads:[~2020-05-21 15:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20200521152943.GE77215@johnslap.localdomain \
--to=johnz@pleasantnightmare.com \
--cc=linux-input@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).