[RFC] libinput configuration interface

Sun Feb 9 04:32:41 PST 2014


On 09.02.2014 05:10, Peter Hutterer wrote:
> On Thu, Feb 06, 2014 at 11:28:49PM +0100, Eugen Friedrich wrote:
>> Hi together,
>> i would like to put some input from the embedded/ automotive perspective.
>>
>> you can think about huge amount of different configurations for different
>> device types.
>> A lot of configuration in the initial post deals with behavior of buttons
>> and scrolling
>> areas of the touch panels.
>>
>> The good approach could be a kind of general configuration of button and
>> scrolling areas of the touch panels
>> the button area could contain a position and dimension of the button in the
>> device coordinate system and the button code
>> the slider area could contain a position and dimension of the slider along
>> with the range.
>
> generally for real touch screens (i.e. not touchpads) I think any
> interpretation of the valthis should IMO
be handled by the compositorues should be on the client side, not in the 
input
> library. There just isn't enough context to interpret it otherwise since
> you're at least partially reliant on UI hints or other elements to make sure
> you're emulating the right thing.
Completely agree, active input elements which are drawn by some 
application should be handled by this application.
>
> For specialized cases like having a permanent input region that maps into
> semantic buttons (e.g. the button bar on the Android phones) this should IMO
> be handled by the compositor.
Yes this was the aim of my proposal. This would give a flexibility to 
use different touch panel with different screens and put you permanent 
buttons and slider wherever you like. Such cases are maybe only 
important if you are building up a new devices but this configuration 
possibility would add a big value for the libinput.
>
>> Also the weston code contains calibration of the absolute values.
>> It would be good also to have a calibration possibilities in libinput.
>
> Yes, calibration is a required feature, I forgot to mention that since it's
> already supported.
>
> Cheers,
>     Peter
>
>>
>> What do you think?
>>
>>
>> 2014-02-03 6:11 GMT+01:00 Alexander E. Patrakov <patrakov at gmail.com>:
>>
>>> 2014-02-03 Peter Hutterer <peter.hutterer at who-t.net>:
>>>> On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
>>>>> Peter Hutterer wrote:
>>>>>> I've been thinking about how to add a device configuration interface
>>> to
>>>>>> libinput, and after getting feedback from Jonas and Benjamin, here's a
>>>>>> proposal (no code yet).
>>>>>>
>>>>>> First, I think the configuration should be feature-specific, not
>>> device
>>>>>> specific, so it is independent of a classification or capabilities of
>>> a
>>>>>> device. To the user it doesn't matter if we classify something as
>>> touchpad
>>>>>> or as mouse, if middle mouse button emulation works that's the only
>>> thing
>>>>>> that counts. At least for configuration purposes, this also avoids the
>>>>>> difficult task of classifying a device correctly. Those pesky HW
>>>>>> manufacturers do have a habit of coming up with devices that elude
>>>>>> previously agreed-on classification schemes, e.g. mice with touchpads
>>> on
>>>>>> them.
>>>>>>
>>>>>> Aside from setting an item, there should be calls to get the current
>>> value,
>>>>>> and a call to reset to the built-in defaults. And, since we're
>>>>>> feature-based, a call to check if the config item is possible for a
>>> device.
>>>>>> Which leads us the the following quartet for each item:
>>>>>>
>>>>>>      int libinput_device_config_set_foo(device, value);
>>>>>>      int libinput_device_config_get_foo(device, &value);
>>>>>>      int libinput_device_config_reset_foo(device);
>>>>>>      bool libinput_device_config_has_foo(device);
>>>>>>
>>>>>> And the actual configuration items I've come up with so far:
>>>>>> * {set|get|reset|has}_tap_single_finger_button
>>>>>> * tap_double_finger_button
>>>>>> * tap_triple_finger_button
>>>>>> * click_finger_single
>>>>>> * click_finger_double
>>>>>> * click_finger_triple
>>>>>> * twofinger_scroll_vertical
>>>>>> * twofinger_scroll_horizonal
>>>>>> * edge_scroll_vertical
>>>>>> * edge_scroll_horizontal
>>>>>> * disable_while_typing
>>>>>> * disable_touch (while pen is in use)
>>>>>>    these two could be merged into "disable while linked device is in
>>> use"
>>>>>> * softbutton_left
>>>>>> * softbutton_middle
>>>>>> * softbutton_right
>>>>>> * emulate_middle_button
>>>>>> * button_mapping
>>>>>> * emulate_wheel
>>>>>> * rotation
>>>>>> * palm_detection
>>>>>> * mode (relative/absolute)
>>>>>> * valid_area
>>>>>>    This is needed on tablets that have a different ratio than the
>>> monitor.
>>>>>>    Mapping them to the monitor results in uneven x/y movements, so the
>>>>>>    easiest approach here is to cut a portion of the tablet off to
>>> match the
>>>>>>    ratio.
>>>>>> * stylus_button_behaviour(some enum)
>>>>>>    Some tablets don't report proximity, the only way to get a
>>> right-button
>>>>>>    click is to hold the right button down and then tip with the stylus.
>>>>>>
>>>>>> Note that the above is not a 1:1 API mapping, e.g. tapping
>>> configuration
>>>>>> could be an API taking nfingers as argument as opposed to 3 different
>>> calls.
>>>>>> Likewise, they can take more than one value argument, e.g. middle
>>> button
>>>>>> emulation could take a boolean to enable it, and a timeout.
>>>>>>
>>>>>> This list excludes options we currently have in the X drivers to
>>> adjust for
>>>>>> hw-specific quirks. Such as defining which pressure makes up a tap,
>>> etc. I
>>>>>> really hope this is something we can work out based on the device.
>>>>>>
>>>>>> It also excludes configurations that I'd really like to hide away if
>>>>>> possible. For example, on the new T440-style touchpads the top part
>>> of it is
>>>>>> a set of buttons for the trackstick. There's nothing to be configured
>>> about
>>>>>> this, it should just work.
>>>>>>
>>>>>> Comments? Does this sound sane enough? Anything important I've missed?
>>>>>
>>>>> You missed our disagreement from August about whether finger movement
>>> in the
>>>>> softbutton area should move the pointer (I suggested that it shouldn't,
>>> you
>>>>> suggested that it should, and both of us had valid arguments, so it
>>> needs to
>>>>> be configurable). Also it was not clearly articulated then, but still, a
>>>>> potential disagreement/configuration point: what to do on a one-button
>>> clickpad
>>>>> if a hardware button reports that it is clicked, but there is no finger
>>> in any
>>>>> softbutton area (i.e. a clickpad is clicked outside of the designated
>>>>> softbutton area)? Possible options: ignore the apparently-false click
>>> (would
>>>>> be my preference), treat this as left click (current situation with the
>>>>> synaptics driver, and I guess some people would prefer this).
>>>>
>>>> tbh, I'm not planning to support every potential option under the sun.
>>>> There's a fine and rather blurry line between what is a preference and
>>> what
>>>> is merely configuration because we can't commit to a single default. I'd
>>>> rather have less configuration options and support those well and do the
>>>> synaptics approach of supporting everything but being quite bad at how
>>> the
>>>> various options interact.
>>>>
>>>> To extend this thought, even the list above is probably too detailed.
>>>> IMO tapping should just be a left, right, middle configuration for 1, 2,
>>> 3
>>>> fingers. Enabling/disabling tapping is a valid configuration but custom
>>>> button mapping is excessive (clickfinger is the same).
>>>> Likewise, there should be only one scroll method at a time, and one
>>> option
>>>> to enable horizontal for that scroll method - no two-finger vertical and
>>>> edge-horizontal scrolling.
>>>
>>> OK.
>>>
>>>> As for the softbuttons config items, I'm somewhat leaning towards finger
>>>> movement in the button areas, but no clicks outside the button area. And
>>> to
>>>> actually trigger a button, you need to start inside the button area -
>>> which
>>>> becomes easier when you have proper finger tracking (synaptics currently
>>>> doesn't). I found that a very decent way to use the trackpad.
>>>
>>> I have just called Sony support and they told me that on newer models
>>> of their laptops (unlike older models like my Z23A4R) there is indeed
>>> no visual distinction between areas for cursor movement and for
>>> clicking, and the Windows driver is configured to accept cursor
>>> movement even near the bottom edge (again, unlike Z23A4R). So your
>>> model is indeed more appropriate for these new laptops (and in fact
>>> the only one that makes sense for Sony Vaio Duo 13, because the height
>>> of the touchpad is insufficient to accommodate both softbutton and
>>> cursor-movement areas).
>>>
>>> Just in case, here are the images of the touchpads.
>>>
>>> Sony Vaio Z23A4R (2011 model) touchpad:
>>> http://static.trustedreviews.com/94/e244d6/5d36/IMG-1738s.jpg
>>>
>>> Sony Vaio Pro 13 touchpad:
>>>
>>> http://www.digitaltrends.com/wp-content/uploads/2013/06/Sony-Vaio-Pro-13-trackpad.jpg
>>>
>>>>> Also I don't see how the suggested interface covers the ChromeBook-style
>>>>> clickpad configuration where there should be no softbuttons and the
>>> only way to
>>>>> right-click is to use two fingers.
>>>>
>>>> I think that's a good example of machine-specific configuration that we
>>> can
>>>> hide away. we already do something similar in the synaptics driver where
>>> we
>>>> don't initialize software buttons for macbooks because they're not
>>> designed
>>>> for that approach. if the chromebooks are similar, restricting it to
>>> tapping
>>>> only seems like a sensible approach.
>>>
>>> Yes, chromebooks are similar to macbooks in this aspect. So what you
>>> say makes sense.
>>>
>>> --
>>> Alexander E. Patrakov
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>