Re: Proper representation of button touch (as opposed to button press)

[Chase Douglas <chasedouglas@gmail.com>]

On 03/05/2012 02:31 PM, Chris Bagwell wrote:
> On Mon, Mar 5, 2012 at 1:36 PM, Jason Gerecke<killertofu@gmail.com>  wrote:
>> On Sat, Mar 3, 2012 at 7:59 AM, Chris Bagwell<chris@cnpbagwell.com>  wrote:
>>> On Fri, Mar 2, 2012 at 6:21 PM, Dmitry Torokhov
>>> <dmitry.torokhov@gmail.com>  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