All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vicki Pfau <vi@endrift.com>
To: Jiri Kosina <jikos@kernel.org>,
	bentiss@kernel.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>
Subject: Re: Adding more ABS axes and BTN spaces to evdev
Date: Wed, 25 Jun 2025 01:57:52 -0700	[thread overview]
Message-ID: <625ccbb5-4bd7-4d09-8422-e111c2ab407a@endrift.com> (raw)
In-Reply-To: <d04aee95-df86-4863-bd54-b9d7957199c7@endrift.com>

Hello again,

On 6/16/25 7:34 PM, Vicki Pfau wrote:
> Hello,
> 
> I've recently been doing some bringup work on some flight stick and racing wheel controllers and have run into a few issues with how to expose it to userspace that I'm not sure the best way to solve.
> 
> For flight sticks, the protocol I'm working with allows for up to 64 buttons on top of a set few, as well as up to 16 axes. There doesn't appear to be good spaces within within either ABS or BTN for these. Though I don't know any devices that use that many, I am worried about the space for axes especially. Though I can probably fit a few after ABS_MISC, but really not that many.
> 
> More directly important, though, is the racing wheel controllers. The protocol specifies four types of axes and one thing that would fit fairly well as an axis: accelerator, brake, clutch, handbrake, and shifter. It looks like Windows treats the shifter as a series of buttons, one for each location on the shifter, but that's a little less desirable than using an axis for it in my opinion. Regardless, there's no good place to map clutch and handbrake. For clutch, at least, I would assume the best approach would actually be to add a new axis: ABS_CLUTCH, perhaps at 0x1d. Would this be a good idea? And if so, would adding ABS_SHIFTER and/or ABS_HANDBRAKE at 0x1e/0x1f also make sense? Barring that, I can use a few ABS_MISC axes, but that is perhaps suboptimal for conveying intent to userspace programs.

I realized while looking at this again that 0xb-0xf are also unused, so perhaps ABS_CLUTCH at 0xb, ABS_SHIFTER at 0xc, and ABS_HANDBRAKE at 0xd.

> 
> I looked around other devices in the kernel to try to figure out what prior art there was for this stuff, without much luck. I saw ABS_RUDDER in use in a few places, but it wasn't quite clear to me what that's being used for without the devices in question. I'm also not clear on what the HID driver does for things like this.
> 
> How should I start moving forwards with this?
> 
> Thanks,
> Vicki

If I were to go about doing this, should I just put it as one of the patches in a series with the first use of it?

Thanks,
Vicki


      reply	other threads:[~2025-06-25  9:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17  2:34 Adding more ABS axes and BTN spaces to evdev Vicki Pfau
2025-06-25  8:57 ` Vicki Pfau [this message]

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=625ccbb5-4bd7-4d09-8422-e111c2ab407a@endrift.com \
    --to=vi@endrift.com \
    --cc=bentiss@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jikos@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.