On 03/05/2012 02:31 PM, Chris Bagwell wrote:
On Mon, Mar 5, 2012 at 1:36 PM, Jason Gerecke<killertofu@xxxxxxxxx> wrote:
On Sat, Mar 3, 2012 at 7:59 AM, Chris Bagwell<chris@xxxxxxxxxxxxxx> wrote:
On Fri, Mar 2, 2012 at 6:21 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
Hi Jason,
On Fri, Mar 02, 2012 at 10:36:22AM -0800, Jason Gerecke wrote:
The Intuos5 was just announced, and I'm working on adding support for
it to the wacom kernel module. One feature new to the Intuos5 is the
addition of capacitive sensors embedded in the buttons. Each
ExpressKey (button) has two bits of state: one for the capacitive
switch and one for the mechanical switch. These bits are synthesized
into three cases: released, touched, and pressed (the 4th case of
"pressed with a non-capacitive object" isn't particularly
interesting). My initial thought was to call input_event() with a
unique value for the 'touched' case. However, the documentation only
defines three values for EV_KEY: 0 (released), 1 (pressed), and 2
(autorepeat).
Is 'touched' a case we would want to allow for EV_KEY, or should I be
representing things differently?
Differently please. It looks like you have 2 independent objects there -
one mechanical switch (persistent on/off) and one is a key (pressed
while touched).
I think you're confused. The buttons on
Inutos4/Intuos3/Cintiq21UX/etc. report when they've been pressed. The
Intuos5 embeds a capacitive sensor into each button so that they can
report "touched" in addition. If you ignore the capacitive sensor,
each button is exactly the same as you'd find on our other tablets, a
mouse, or a keyboard. It should be in a "pressed" state while
sufficient force is applied, and in an "unpressed" state otherwise. It
is *not* expected to behave like a persistent toggle switch.
Since "touched" is a natural and distinct button state, it makes sense
(to me at least) to have EV_KEY define it as an additional legal
value.
There is a little overlap here with clickpads and it would be nice if
user apps could work similar for both. The main use (I think) of this
proposed key press is to give visual feedback were users finger is at
before they press hard enough to activate button. It could be the HUD
feature of Intuos5 or the taskbar applet Windows synaptics driver has
that gives feedback how touchpad is being touched.
For clickpads, its an X/Y value that a HUD/applet would use to give
the visual feedback. If these new "keys" are not exposed as a full
blown capacitive touch strip then you could simulate that and send an
Y=1 and X=1..4 to represent were finger is.
The main negative with this is you'll have the headache clickpad user
land has trying to detect when X/Y is buttons and when its touchpad
movement. At least in your case, you could send a BTN_TOOL_STRIP or a
BTN_TOOL_FINGER+serial # to let user land know this is a unique area
of touch.
Chris
I'm not sure about this... I don't think there are really any clickpad
user apps out there that would be relevant to the Intuos5 since its
buttons aren't used like one. While it'd be possible to simulate a
clickpad with the raw data, I'm having a hard time seeing the use for
anything beyond a HUD (which could be written without the
faux-position data anyway).
Yeah, but the other extreme is a pain as well. Dmitry suggestion
would be something like send BTN_1/2/3/4 for 4 button presses and
KEY_1/2/3/4 when touching buttons but not pressed hard.
That user land app is way to hard coded if they know to bind those two
things together without hints from kernel.
They need the hint for X/Y solution but I'm only suggesting that
INPUT_PROP_BUTTONPAD already exists to give that hint. There are some
userland assumptions on BUTTONPAD's only wanting BTN_LEFT/RIGHT though
so maybe its not a great idea.
BUTTONPAD is a device-wide property. This feels more like a property of
parts of a device.
I kind of like the simplicity of the EV_KEY approach, but it treats
"pressure" as a binary value. Even if the Intuos 5 only provides a
binary value, I can image future devices that provide a full pressure
absolute value range.
Without having thought of any specific solutions, I think one reasonable
approach would be to come up with a new evdev protocol addition that
allows for event codes to be grouped together, and allow for custom
labels of the codes. The two could be provided by the same mechanism
even. One EV_KEY and EV_ABS axis per Intuos 5 button, both labeled
"Button <blah>" would group them together and provide for extension as
we get more and more complex devices.
-- Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
