From: Jason Gerecke <hidden> Date: 2011-10-05 19:44:41
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
And what if next device adds another wheel? And another...
Do these rings only make sense in the context of entire Cintiq device,
or maybe they should be treated as ancillary devices (with separate
input_dev from the main tablet device)?
Thanks.
--
Dmitry
From: Jason Gerecke <hidden> Date: 2011-10-06 20:31:11
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
And what if next device adds another wheel? And another...
Do these rings only make sense in the context of entire Cintiq device,
or maybe they should be treated as ancillary devices (with separate
input_dev from the main tablet device)?
Thanks.
--
Dmitry
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
From a practical standpoint, I don't see tablets with more than two
rings on the horizon. The rings already have mode-switch buttons,
obviating the need for more than one ring per hand. And since the user
only has two hands, it makes the need for more than two rings somewhat
difficult to imagine...
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
Hi Jason,
Sorry for not replying earlier.
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
quoted
And what if next device adds another wheel? And another...
Do these rings only make sense in the context of entire Cintiq device,
or maybe they should be treated as ancillary devices (with separate
input_dev from the main tablet device)?
Thanks.
--
Dmitry
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
From a practical standpoint, I don't see tablets with more than two
rings on the horizon. The rings already have mode-switch buttons,
obviating the need for more than one ring per hand. And since the user
only has two hands, it makes the need for more than two rings somewhat
difficult to imagine...
For a tablet... But world is not only limited to tablets and so I loathe
to have the same conversation about ABS_WHEEL5 in the future.
Thanks.
--
Dmitry
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
Ping
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
From: Jason Gerecke <hidden> Date: 2011-11-30 23:52:57
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
[off-list ref] wrote:
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
On Wed, Nov 30, 2011 at 03:52:55PM -0800, Jason Gerecke wrote:
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Right, this requires knowledge in userspace driver as to how use the
data from different sensors. But that is not different from
ABS_WHEEL/ABS_WHEEL2 - _your_ driver knows what they mean but a generic
either has no idea or even a wrong idea.
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Probably multiplexing through ABS_MISC would be not too painful as an
interim solution.
--
Dmitry
From: Chris Bagwell <hidden> Date: 2011-12-01 17:13:24
On Wed, Nov 30, 2011 at 11:11 PM, Dmitry Torokhov
[off-list ref] wrote:
On Wed, Nov 30, 2011 at 03:52:55PM -0800, Jason Gerecke wrote:
quoted
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Right, this requires knowledge in userspace driver as to how use the
data from different sensors. But that is not different from
ABS_WHEEL/ABS_WHEEL2 - _your_ driver knows what they mean but a generic
either has no idea or even a wrong idea.
quoted
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Probably multiplexing through ABS_MISC would be not too painful as an
interim solution.
Here are a few thoughts I have on it.
First, I think that REL_WHEEL is closest meaning the ring has to user
land expectations. Its advertised in user manual to do things you'd
often do with scroll wheel on a mouse. The default mode is sending
generic zooming/scrolling events. The extended usages of the wheel
seem only to be directing the zooming/scrolling to application
specific features. For example, push button 1 and ring zooms whole
canvas. Press button 2 and it zooms size of brush. I think mapping
movement to keystroke feature is outside scope of this thread so I'll
ignore that part.
I do not think user land apps cares much about exact position user is
touching like they would with a steering wheel so I don't think
ABS_WHEEL is needed. There is the tapping specific parts of ring
feature to do minor increments but I think driver can hide that by
sending REL_WHEEL with +5/-5 for scrolls and +1/-1 for taps.
Above part was for the semantic part of thread. It still doesn't
address needing a REL_WHEEL1/2/3/4 for this device and maybe to be
used by one of those crazy gaming mice that has way to many buttons
and wheels.
I don't have much to provide here other than I'd also suggest Dmitry's
idea of multiplex both rings onto 1 REL_WHEEL. I'm not even sure I'd
do multiplexing so much as reporting both as if they were a single
ring. Sure, I'd like to use one ring for zooming canvas and one for
zooming paint brush some day but I'd prefer a working driver today
that has both rings zooming the same thing.
If we move to MT approach for reporting wheels, I suspect we will also
have the "pointer emulation" concept where REL_WHEEL has some hybrid
meaning to work nicely with older applications and
REL_MULTI_WHEEL/REL_MULTI_WHEEL_SLOT for multiplexing wheel data. So
an intermediate step of merging doesn't sound like a dead end.
Chris
From: Jason Gerecke <hidden> Date: 2011-12-01 22:04:03
On Thu, Dec 1, 2011 at 9:13 AM, Chris Bagwell [off-list ref] wrote:
On Wed, Nov 30, 2011 at 11:11 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 03:52:55PM -0800, Jason Gerecke wrote:
quoted
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Right, this requires knowledge in userspace driver as to how use the
data from different sensors. But that is not different from
ABS_WHEEL/ABS_WHEEL2 - _your_ driver knows what they mean but a generic
either has no idea or even a wrong idea.
quoted
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Probably multiplexing through ABS_MISC would be not too painful as an
interim solution.
Multiplexing is certainly simpler than splitting the tablet into
multiple devices. It's not, however, as simple as it seems. If we only
put the right touch ring into ABS_MISC, it wouldn't be too bad; we
could write some trivial placeholder code for the moment and get back
to fleshing it out when we get some time. That's not an option though
since ABS_MISC is already being used to send tool type information.
Placeholder code wouldn't cut it and we'd have to rewrite portions of
the kernel and X driver right now.
Please don't misunderstand -- I agree that multiplexing is a
reasonable interim solution, and I'm not against doing the work. I
just don't have any time in my schedule right now to devote to it.
That's why I'd prefer using an existing axis that we don't already
use. The code is already written and tested, and our driver already
abuses the semantics of so many other axes that a program trying to
use the kernel events in a generic way will fail spectacularly anyway.
If we don't find time to refactor things in the near future, we can
schedule time up-front with the next device that requires yet another
axis on the assumption that you would block any more patches which
further this cycle of semantic abuse.
Here are a few thoughts I have on it.
First, I think that REL_WHEEL is closest meaning the ring has to user
land expectations. Its advertised in user manual to do things you'd
often do with scroll wheel on a mouse. The default mode is sending
generic zooming/scrolling events. The extended usages of the wheel
seem only to be directing the zooming/scrolling to application
specific features. For example, push button 1 and ring zooms whole
canvas. Press button 2 and it zooms size of brush. I think mapping
movement to keystroke feature is outside scope of this thread so I'll
ignore that part.
I do not think user land apps cares much about exact position user is
touching like they would with a steering wheel so I don't think
ABS_WHEEL is needed. There is the tapping specific parts of ring
feature to do minor increments but I think driver can hide that by
sending REL_WHEEL with +5/-5 for scrolls and +1/-1 for taps.
While the touch rings may be closer in use to scroll wheels
(REL_WHEEL) than steering wheels (ABS_WHEEL), there is value in the
absolute information even if few applications use it at the moment.
For instance, I know of an application which provides variable-speed
smooth scroll/zoom depending on the absolute position of your finger
on the touch strip. There are some very interesting uses of the
absolute data, and the kernel shouldn't throw it away just because the
relative axis has a closer semantic meaning in the "usual" case. A
touch strip or ring may /resemble/ a scroll wheel, but it's semantic
meaning is application-specific (and, under Windows where the mode
buttons work, subject to change at a moment's notice!).
Above part was for the semantic part of thread. It still doesn't
address needing a REL_WHEEL1/2/3/4 for this device and maybe to be
used by one of those crazy gaming mice that has way to many buttons
and wheels.
I don't have much to provide here other than I'd also suggest Dmitry's
idea of multiplex both rings onto 1 REL_WHEEL. I'm not even sure I'd
do multiplexing so much as reporting both as if they were a single
ring. Sure, I'd like to use one ring for zooming canvas and one for
zooming paint brush some day but I'd prefer a working driver today
that has both rings zooming the same thing.
The X driver code to do that is already written and waiting on the
kernel driver going upstream. You'll be able to map the wheels
independently, just like you can right now with the strips.
If we move to MT approach for reporting wheels, I suspect we will also
have the "pointer emulation" concept where REL_WHEEL has some hybrid
meaning to work nicely with older applications and
REL_MULTI_WHEEL/REL_MULTI_WHEEL_SLOT for multiplexing wheel data. So
an intermediate step of merging doesn't sound like a dead end.
Chris
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
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 Thu, Dec 01, 2011 at 02:04:00PM -0800, Jason Gerecke wrote:
On Thu, Dec 1, 2011 at 9:13 AM, Chris Bagwell [off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 11:11 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 03:52:55PM -0800, Jason Gerecke wrote:
quoted
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
quoted
quoted
On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
quoted
On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
quoted
I'm working on adding support for the recently-announced Cintiq 24HD,
and am hashing out most of the details on the linuxwacom mailing list.
In the discussions there, it was suggested that we add a new e.g.
"ABS_WHEEL2" axis to the input.h header to represent the second touch
ring available on the 24HD. I think it's a good idea, but wanted to
get some opinions from over here before making a patch. The other
option we have available is to use an axis not already in use by the
wacom driver (such as ABS_RUDDER), but none have a matching semantic
meaning.
Looking at this once more ABS_WHEEL does not semantically match to what
Wacom driver users it for either. ABS_WHEEL is not "an abstract
circular-shaped sensor on a device" for rather a "steering wheel"-like
control on a game controller. So Wacom needs to move away from using this
event.
We can move away from using the WHEEL. But, we do still need to use
something to report the values. We need a constructive suggestion to
"move away" ;).
quoted
quoted
The rings are controls built into the "pad" -- the hardware you bring
the stylus in proximity to. Along with the touch rings, there are also
buttons and touch strips. Now, some devices have controls on only the
left-hand side of the pad, while others have the controls on both
sides of the pad. While one could argue that this makes each "side" a
complete context that can be broken apart into separate devices, that
doesn't really solve anything. What's stopping us from grouping
several rings together?
Well, there are several topics here...
What you apparently have is a group of unclassified, as far as Linux
input subsystem concerned, sensors. When I say unclassified I mean that
there is no appropriate event code we can assign to the control to allow
a generic consumer determine the purpose of that sensor. You need help
of a specialized driver to decide what to do with the data or, in case
of generic driver, user has to explicitly map it to some action, but
there is no way for automatic discovery/configuration which is the goal
of input core. The only and closest event that we have that is suitable
here is ABS_MISC.
Here however is a problem: there is only one ABS_MISC and we often have
several such sensors on a device. I do not want to have ABS_MISCx as
again, it does not solve anything, manufactures always come with bigger
and bigger devices (there some music controllers with dozens of
sliders). Encoding data into ABS_MISC (let's say highest byte denotes
sensor number) is awkward as well. So that is why I propose splitting
them into separate input devices and have driver discover and handle
them as it sees fit.
The rings are on the tablet. Events from them are combined with the
events from the other tools moving on the tablet. Splitting the
wheels/expresskeys from the tablet would only complicate the
situation. We would have to link the wheels back to the tablet in the
user land, an unnecessary step that we should/could avoid in the
kernel.
The fact that they are in the same physical package does not mean that
they are necessarily mapped to a single input device. For example my USB
keyboard consists of 3 logical devices.
I understand that having data from them in the same event stream would
be nice and if you have an idea how to achieve that in a generic way
without resorting to ABS_MISC55 - that would be great. Maybe we
need something similar to multitouch protocol solution, but for
unclassified data.
OTOH separate input devices complicate userland in cases when driver
wants to handle them together but is really flexible.
--
Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Right, this requires knowledge in userspace driver as to how use the
data from different sensors. But that is not different from
ABS_WHEEL/ABS_WHEEL2 - _your_ driver knows what they mean but a generic
either has no idea or even a wrong idea.
quoted
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Probably multiplexing through ABS_MISC would be not too painful as an
interim solution.
Multiplexing is certainly simpler than splitting the tablet into
multiple devices. It's not, however, as simple as it seems. If we only
put the right touch ring into ABS_MISC, it wouldn't be too bad; we
could write some trivial placeholder code for the moment and get back
to fleshing it out when we get some time. That's not an option though
since ABS_MISC is already being used to send tool type information.
Placeholder code wouldn't cut it and we'd have to rewrite portions of
the kernel and X driver right now.
Please don't misunderstand -- I agree that multiplexing is a
reasonable interim solution, and I'm not against doing the work. I
just don't have any time in my schedule right now to devote to it.
That's why I'd prefer using an existing axis that we don't already
use. The code is already written and tested, and our driver already
abuses the semantics of so many other axes that a program trying to
use the kernel events in a generic way will fail spectacularly anyway.
If we don't find time to refactor things in the near future, we can
schedule time up-front with the next device that requires yet another
axis on the assumption that you would block any more patches which
further this cycle of semantic abuse.
I suppose I'd be OK with [ab]using one of existing "free" axes for the
time being, given that we require a specific driver for full support of
wacom tablets anyway.
Thanks.
--
Dmitry