From: "John Z." <firstname.lastname@example.org> To: email@example.com Subject: Thrustmaster T.Flight 4 driver, help needed Date: Thu, 21 May 2020 12:29:43 -0300 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 index 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 \ --firstname.lastname@example.org \ --email@example.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
Linux Input Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-input/0 linux-input/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-input linux-input/ https://lore.kernel.org/linux-input \ firstname.lastname@example.org public-inbox-index linux-input Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-input AGPL code for this site: git clone https://public-inbox.org/public-inbox.git