Hi all,
I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm stumbling
on some road blocks. Directional axes should be mapped to e.g.
ABS_X/_Y/_Z, while relative axes make most sense for sensors. The main
issue I'm seeing is that there is no way to determine using evdev what
type of data is exposed on an axis.
Based on definitions in input.h, it seems traditionally ABS_X/_Y/_Z
had a resolution of 'units per millimeter', while ABS_RX/_RY/_RZ where
meant for rotational axes in 'units per radian'. Over the years
handling of these axes evolved, where gamepads often use
ABS_RX/_RY/_RZ for the right stick, which is 'units per millimeter'.
In a similar way some drivers are currently reporting acceleration
through absolute axes (e.g. wii driver). The application has to know
it is dealing with the wii gamepad to be able to really understand the
data. Then there is also a special flag 'INPUT_PROP_ACCELEROMETER'
which some drivers use to report acceleration data through absolute /
relative axes provided the device doesn't report any directional axes
on that same node.
As I have shown, handling of non-positional data is sort of handled
now on a case by case basis. As an application developer you pretty
much have to check the product/vendor IDs to really be able to handle
a device. You can't just rely on detecting the type of axes. Moving
forward I would like to determine what the best way of handling
non-positional data is through evdev.
In my opinion the main problem of the current API is that there is no
way to determine what 'unit' is reported on an axes. Is it positional
data, is it (angular) velocity, is it acceleration, something else?
Ideally I think there should have been some 'type' field in
'input_absinfo', which allowed someone to determine the data type and
e.g. map a resolution of '1024' units to 1G of acceleration or a
certain number of radians per second. Unfortunately user space can't
be broken, but potentially a new ioctl could be invented to add such
information (if that's the way forward) returning e.g.
'input_relinfo'. Another option is to add a new axis type.
What are your thoughts on this matter? Ideally I would like to find a
nice solution if possible.
Thanks,
Roderick
From: Benjamin Tissoires <hidden> Date: 2016-03-15 20:07:03
HI Roderick,
[adding some people in the discussion]
On Tue, Mar 15, 2016 at 8:26 PM, Roderick Colenbrander
[off-list ref] wrote:
Hi all,
I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm stumbling
on some road blocks. Directional axes should be mapped to e.g.
ABS_X/_Y/_Z, while relative axes make most sense for sensors. The main
issue I'm seeing is that there is no way to determine using evdev what
type of data is exposed on an axis.
I am not entirely sure of what you mean by "relative axes". In the
evdev world, relative axes are given through REL_* and there is a
clear separation between relative (think mice) and absolute (think
touchscreen).
Based on definitions in input.h, it seems traditionally ABS_X/_Y/_Z
had a resolution of 'units per millimeter', while ABS_RX/_RY/_RZ where
meant for rotational axes in 'units per radian'. Over the years
handling of these axes evolved, where gamepads often use
ABS_RX/_RY/_RZ for the right stick, which is 'units per millimeter'.
According to our API, ABS_X/Y/Z are positional axis, and are reported
no matter what as "unit per mm" as you mentioned.
ABS_RX/RY/RZ are "rotation X/Y/Z" and are indeed reported as "unit per radian".
This is also what the HID specification says in the HID usage table,
page 29, section 4.2
(http://www.usb.org/developers/hidpage/Hut1_12v2.pdf).
The problem you are seeing is either a bug in the specific driver of
the gamepad, or the fact that the HID report descriptor is not well
understood by us, and we end up using ABs_X|Y for the left stick and
then use the next available ones for the right one: ABS_Z/ABS_RX. This
is ugly, but given that this is how things work for a long time, we
can't fix those without a lot of bandaids for backward compatibility.
In a similar way some drivers are currently reporting acceleration
through absolute axes (e.g. wii driver). The application has to know
it is dealing with the wii gamepad to be able to really understand the
data. Then there is also a special flag 'INPUT_PROP_ACCELEROMETER'
which some drivers use to report acceleration data through absolute /
relative axes provided the device doesn't report any directional axes
on that same node.
Yes, this is now the prefer way. We can report acceleration through
ABS_X/Y/Z, but the driver needs to set the property you mentioned. If
it is not set, ask the driver maintainer to set it.
As I have shown, handling of non-positional data is sort of handled
now on a case by case basis. As an application developer you pretty
much have to check the product/vendor IDs to really be able to handle
a device. You can't just rely on detecting the type of axes. Moving
forward I would like to determine what the best way of handling
non-positional data is through evdev.
The best way would actually not handling this in the final
application, but at the system level. udev already tries to tag
devices (JOYSTICK, ACCELEROMETER, TABLET, etc...). And any per VID/PID
configuration can easily be solved by adding a hwdb entry. Udev
already have a heuristic to determine which device is which, and it is
best to not duplicate this in each and every application.
In my opinion the main problem of the current API is that there is no
way to determine what 'unit' is reported on an axes. Is it positional
data, is it (angular) velocity, is it acceleration, something else?
Ideally I think there should have been some 'type' field in
'input_absinfo', which allowed someone to determine the data type and
e.g. map a resolution of '1024' units to 1G of acceleration or a
certain number of radians per second. Unfortunately user space can't
be broken, but potentially a new ioctl could be invented to add such
information (if that's the way forward) returning e.g.
'input_relinfo'. Another option is to add a new axis type.
Again, for relative, we have REL_* events. I concede that the evdev
protocol might lack some information (the low level HID protocol is
much more flexible in term of units, resolution, and extendability),
but so far we hae been able to circumvent most of the limitations.
What are your thoughts on this matter? Ideally I would like to find a
nice solution if possible.
My solution would be:
- check and rely only on the udev properties. This is already what
libinput does. Also this has the good benefit of being able to say to
your users: "if it doesn't work, add the following hwdb entry, reload
the hwdb, and you will be fixed". And if the axis are wrong, you can
already use the ioctl to remap the axis to something more sensible
(can't remember if udev as a builtin that does that). You can also
extend the udev properties attached to the devices you are working
with (this is what we do in libinput and libratbag) if you want to
classify the devices (crappy-device-with-abs-rx, very-good-one). You
can ship those rules with your application and only you will use them.
- but also report as many misconfigured devices as possible upstream
to their maintainers (here on this list, and ideally add the right
person by looking at the driver code).
Cheers,
Benjamin
Thanks,
Roderick
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Benjamin,
Thanks for your reply so far. I wasn't aware of hwdb, but it could be
interesting for us for some situations.
My device is more like a joystick with many directional axes in
addition to the accelerometer and gyro functionality. I can easily
remap the sensor axes to be reported using REL_* constants, but the
main issue for me are the units. The device has many keys, axes and
the only way to only solution is to hard code the data type in the
application on whether to interpret relative axis data as e.g. units
per rad/s, units per G or units per mm.
Ideally I'm looking for a way to solve the unit problem, but I'm not
sure yet how (new axis type or new ioctl...)
Thanks,
Roderick
On Tue, Mar 15, 2016 at 1:07 PM, Benjamin Tissoires
[off-list ref] wrote:
HI Roderick,
[adding some people in the discussion]
On Tue, Mar 15, 2016 at 8:26 PM, Roderick Colenbrander
[off-list ref] wrote:
quoted
Hi all,
I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm stumbling
on some road blocks. Directional axes should be mapped to e.g.
ABS_X/_Y/_Z, while relative axes make most sense for sensors. The main
issue I'm seeing is that there is no way to determine using evdev what
type of data is exposed on an axis.
I am not entirely sure of what you mean by "relative axes". In the
evdev world, relative axes are given through REL_* and there is a
clear separation between relative (think mice) and absolute (think
touchscreen).
quoted
Based on definitions in input.h, it seems traditionally ABS_X/_Y/_Z
had a resolution of 'units per millimeter', while ABS_RX/_RY/_RZ where
meant for rotational axes in 'units per radian'. Over the years
handling of these axes evolved, where gamepads often use
ABS_RX/_RY/_RZ for the right stick, which is 'units per millimeter'.
According to our API, ABS_X/Y/Z are positional axis, and are reported
no matter what as "unit per mm" as you mentioned.
ABS_RX/RY/RZ are "rotation X/Y/Z" and are indeed reported as "unit per radian".
This is also what the HID specification says in the HID usage table,
page 29, section 4.2
(http://www.usb.org/developers/hidpage/Hut1_12v2.pdf).
The problem you are seeing is either a bug in the specific driver of
the gamepad, or the fact that the HID report descriptor is not well
understood by us, and we end up using ABs_X|Y for the left stick and
then use the next available ones for the right one: ABS_Z/ABS_RX. This
is ugly, but given that this is how things work for a long time, we
can't fix those without a lot of bandaids for backward compatibility.
quoted
In a similar way some drivers are currently reporting acceleration
through absolute axes (e.g. wii driver). The application has to know
it is dealing with the wii gamepad to be able to really understand the
data. Then there is also a special flag 'INPUT_PROP_ACCELEROMETER'
which some drivers use to report acceleration data through absolute /
relative axes provided the device doesn't report any directional axes
on that same node.
Yes, this is now the prefer way. We can report acceleration through
ABS_X/Y/Z, but the driver needs to set the property you mentioned. If
it is not set, ask the driver maintainer to set it.
quoted
As I have shown, handling of non-positional data is sort of handled
now on a case by case basis. As an application developer you pretty
much have to check the product/vendor IDs to really be able to handle
a device. You can't just rely on detecting the type of axes. Moving
forward I would like to determine what the best way of handling
non-positional data is through evdev.
The best way would actually not handling this in the final
application, but at the system level. udev already tries to tag
devices (JOYSTICK, ACCELEROMETER, TABLET, etc...). And any per VID/PID
configuration can easily be solved by adding a hwdb entry. Udev
already have a heuristic to determine which device is which, and it is
best to not duplicate this in each and every application.
quoted
In my opinion the main problem of the current API is that there is no
way to determine what 'unit' is reported on an axes. Is it positional
data, is it (angular) velocity, is it acceleration, something else?
Ideally I think there should have been some 'type' field in
'input_absinfo', which allowed someone to determine the data type and
e.g. map a resolution of '1024' units to 1G of acceleration or a
certain number of radians per second. Unfortunately user space can't
be broken, but potentially a new ioctl could be invented to add such
information (if that's the way forward) returning e.g.
'input_relinfo'. Another option is to add a new axis type.
Again, for relative, we have REL_* events. I concede that the evdev
protocol might lack some information (the low level HID protocol is
much more flexible in term of units, resolution, and extendability),
but so far we hae been able to circumvent most of the limitations.
quoted
What are your thoughts on this matter? Ideally I would like to find a
nice solution if possible.
My solution would be:
- check and rely only on the udev properties. This is already what
libinput does. Also this has the good benefit of being able to say to
your users: "if it doesn't work, add the following hwdb entry, reload
the hwdb, and you will be fixed". And if the axis are wrong, you can
already use the ioctl to remap the axis to something more sensible
(can't remember if udev as a builtin that does that). You can also
extend the udev properties attached to the devices you are working
with (this is what we do in libinput and libratbag) if you want to
classify the devices (crappy-device-with-abs-rx, very-good-one). You
can ship those rules with your application and only you will use them.
- but also report as many misconfigured devices as possible upstream
to their maintainers (here on this list, and ideally add the right
person by looking at the driver code).
Cheers,
Benjamin
quoted
Thanks,
Roderick
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2016-03-15 at 12:26 -0700, Roderick Colenbrander wrote:
Hi all,
I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm
stumbling
on some road blocks.
Depending on what your device is, you might be looking for the IIO sub-
system instead, which hosts most of the sensor-type drivers.
iio-sensor-proxy is one of the daemon that can consume data from it
(even if somewhat unelegantly these days).
Cheers
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
Thanks,
Roderick
On Tue, Mar 15, 2016 at 3:59 PM, Bastien Nocera [off-list ref] wrote:
On Tue, 2016-03-15 at 12:26 -0700, Roderick Colenbrander wrote:
quoted
Hi all,
I'm working on a device driver for an input device, which has both
directional axes in addition to sensors (accelerometer and gyro). I'm
trying to figure out how to map these axes properly, but I'm
stumbling
on some road blocks.
Depending on what your device is, you might be looking for the IIO sub-
system instead, which hosts most of the sensor-type drivers.
iio-sensor-proxy is one of the daemon that can consume data from it
(even if somewhat unelegantly these days).
Cheers
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
From: David Herrmann <hidden> Date: 2016-03-16 15:26:22
Hi
On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera [off-list ref] wrote:
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
I really think evdev is the right place to put any of those devices.
The real problem is that the current set of ABS types is very limited
and strongly overloaded. We didn't do this for other types, but
somehow ABS turned out that way.
In general, Dmitry was ok with introducing new ABS types, properly
representing those types. I sent an RFC some years ago, which also
introduces gyro and accelerometer types (see patch #4):
https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html
The problem is, however, that the current ABS_* namespace is
exhausted. That is, we have to introduce some new way to add new ABS
types (the series introduced ABS2 for that). No-one continued that
effort so far, so we are stuck with the current ABS types. Feel free
to pick this up. It might be a lengthy effort, though. You might be
better off doing it the wiimote way: pick you ABS types and make
user-space recognize them depending on the device name/etc.
Thanks
David
On Wed, Mar 16, 2016 at 8:10 AM, Bastien Nocera [off-list ref] wrote:
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
Correct see it more like a wiimote-like device. I expect many
userspace applications (desktop or embedded) to ultimately support
this device and many existing applications could already use the
device except they can't utilize the motion sensors.
Hi David,
On Wed, Mar 16, 2016 at 8:26 AM, David Herrmann [off-list ref] wrote:
Hi
On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera [off-list ref] wrote:
quoted
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
I really think evdev is the right place to put any of those devices.
The real problem is that the current set of ABS types is very limited
and strongly overloaded. We didn't do this for other types, but
somehow ABS turned out that way.
In general, Dmitry was ok with introducing new ABS types, properly
representing those types. I sent an RFC some years ago, which also
introduces gyro and accelerometer types (see patch #4):
https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html
The problem is, however, that the current ABS_* namespace is
exhausted. That is, we have to introduce some new way to add new ABS
types (the series introduced ABS2 for that). No-one continued that
effort so far, so we are stuck with the current ABS types. Feel free
to pick this up. It might be a lengthy effort, though. You might be
better off doing it the wiimote way: pick you ABS types and make
user-space recognize them depending on the device name/etc.
Thanks
David
Your work was definitely interesting and exactly what I would have
needed. It felt like a reasonable path forward. What was ultimately
the main blocker? There was no interest?
Thanks,
Roderick
2016-03-16 16:26 GMT+01:00 David Herrmann [off-list ref]:
Hi
On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera [off-list ref] wrote:
quoted
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
I really think evdev is the right place to put any of those devices.
The real problem is that the current set of ABS types is very limited
and strongly overloaded. We didn't do this for other types, but
somehow ABS turned out that way.
In general, Dmitry was ok with introducing new ABS types, properly
representing those types. I sent an RFC some years ago, which also
introduces gyro and accelerometer types (see patch #4):
https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html
The problem is, however, that the current ABS_* namespace is
exhausted. That is, we have to introduce some new way to add new ABS
types (the series introduced ABS2 for that). No-one continued that
effort so far, so we are stuck with the current ABS types. Feel free
to pick this up. It might be a lengthy effort, though. You might be
better off doing it the wiimote way: pick you ABS types and make
user-space recognize them depending on the device name/etc.
Hi.
I am writing a user-space driver for the steam controller and I was
wondering how that would fit. The steam controller reports its
absolute gyro data as a quaternion instead of three angles. Although,
in the case of the steam controller, this data is meant to emulate
other kind of devices from the driver, if applications started to use
such an interface, it would be nice that the steam controller supports
it.
On Wed, Mar 16, 2016 at 12:09 PM, Clément VUCHENER
[off-list ref] wrote:
2016-03-16 16:26 GMT+01:00 David Herrmann [off-list ref]:
quoted
Hi
On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera [off-list ref] wrote:
quoted
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
I really think evdev is the right place to put any of those devices.
The real problem is that the current set of ABS types is very limited
and strongly overloaded. We didn't do this for other types, but
somehow ABS turned out that way.
In general, Dmitry was ok with introducing new ABS types, properly
representing those types. I sent an RFC some years ago, which also
introduces gyro and accelerometer types (see patch #4):
https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html
The problem is, however, that the current ABS_* namespace is
exhausted. That is, we have to introduce some new way to add new ABS
types (the series introduced ABS2 for that). No-one continued that
effort so far, so we are stuck with the current ABS types. Feel free
to pick this up. It might be a lengthy effort, though. You might be
better off doing it the wiimote way: pick you ABS types and make
user-space recognize them depending on the device name/etc.
Hi.
I am writing a user-space driver for the steam controller and I was
wondering how that would fit. The steam controller reports its
absolute gyro data as a quaternion instead of three angles. Although,
in the case of the steam controller, this data is meant to emulate
other kind of devices from the driver, if applications started to use
such an interface, it would be nice that the steam controller supports
it.
quoted
Thanks
David
I haven't with the SteamController yet. Based on iFixit it has a
3-axis gyro and 3-axis accelerometer. I guess the microcontroller
could be doing the quaternion calculations. Are you sure it is gyro
data and not maybe orientation data derived from gyro + accel? Try
spinning it around an axis and integrate the output in a script
(provided you knew the resolution in units per deg/s or rad/s).
Some devices may use 1D or 2D sensors, so if for those just ABS_GYRO_X
/ _Y for them, for a 4th dimension _W would make sense I guess.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 16, 2016 at 12:09 PM, Clément VUCHENER
[off-list ref] wrote:
quoted
2016-03-16 16:26 GMT+01:00 David Herrmann [off-list ref]:
Hi.
I am writing a user-space driver for the steam controller and I was
wondering how that would fit. The steam controller reports its
absolute gyro data as a quaternion instead of three angles. Although,
in the case of the steam controller, this data is meant to emulate
other kind of devices from the driver, if applications started to use
such an interface, it would be nice that the steam controller supports
it.
quoted
Thanks
David
I haven't with the SteamController yet. Based on iFixit it has a
3-axis gyro and 3-axis accelerometer. I guess the microcontroller
could be doing the quaternion calculations. Are you sure it is gyro
data and not maybe orientation data derived from gyro + accel? Try
spinning it around an axis and integrate the output in a script
(provided you knew the resolution in units per deg/s or rad/s).
Yes, it is derived from gyro + accel. I did not read David's
documentation correctly and I thought that ABS_GYRO_* was the absolute
position (in rad or deg) but it is the speed (in deg/s). The speed
data is also sent in the report although the quaternion is easier to
use thanks to the calibration and integration done on the hardware.
Some devices may use 1D or 2D sensors, so if for those just ABS_GYRO_X
/ _Y for them, for a 4th dimension _W would make sense I guess.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Herrmann <hidden> Date: 2016-03-17 09:27:27
Hi
On Wed, Mar 16, 2016 at 8:00 PM, Roderick Colenbrander
[off-list ref] wrote:
Hi David,
On Wed, Mar 16, 2016 at 8:26 AM, David Herrmann [off-list ref] wrote:
quoted
Hi
On Wed, Mar 16, 2016 at 4:10 PM, Bastien Nocera [off-list ref] wrote:
quoted
On Tue, 2016-03-15 at 17:17 -0700, Roderick Colenbrander wrote:
quoted
Hi Bastien,
Thanks for providing this suggestion. I can see this approach work
for
situations like screen rotation on tablets. The device I'm involved
with is an input device, which needs a high poll rate for
acceleration
/ velocity and needs to be paired with the button / axes data. Evdev
would be most appropriate.
So more like a Wiimote than a builtin sensor. What will consume events
in user-space? A specialised application?
I really think evdev is the right place to put any of those devices.
The real problem is that the current set of ABS types is very limited
and strongly overloaded. We didn't do this for other types, but
somehow ABS turned out that way.
In general, Dmitry was ok with introducing new ABS types, properly
representing those types. I sent an RFC some years ago, which also
introduces gyro and accelerometer types (see patch #4):
https://lists.freedesktop.org/archives/input-tools/2013-December/000612.html
The problem is, however, that the current ABS_* namespace is
exhausted. That is, we have to introduce some new way to add new ABS
types (the series introduced ABS2 for that). No-one continued that
effort so far, so we are stuck with the current ABS types. Feel free
to pick this up. It might be a lengthy effort, though. You might be
better off doing it the wiimote way: pick you ABS types and make
user-space recognize them depending on the device name/etc.
Thanks
David
Your work was definitely interesting and exactly what I would have
needed. It felt like a reasonable path forward. What was ultimately
the main blocker? There was no interest?
I don't think there was any big blocker, I just never pushed it
forward. Feel free to pick it up. But given that it has to introduce
new evdev APIs, it might take a while to get upstream.
Thanks
David