[RFC] libinput configuration interface

Sat Feb 8 14:18:01 PST 2014

Hallo Jonas,
Thanks for fast replay, basically we have already proprietary 
implementation in place to fulfil requirements from different customers. 
Now we are looking forward to find a good open source component to 
contribute our knowledge, experience and maybe code.
Since we using wayland, libinput library will be a perfect candidate.

The aim of my email was to find out if our requirements/ ideas are 
acceptable for the community. I notice that you start discussion about 
the configuration of the libinput library and thought it a good time to 
put my 2 cents. If the first ideas makes sense for community we will 
come up with a concrete requirements and proposals.

On 07.02.2014 09:52, Jonas Ådahl 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.
>
> I'm not completely sure what you are talking about. Do you mean you want
> configurable button (and scroll) areas of touch pad or tablet devices? I.e.
> not a touch device that has a built in output screen. The idea, AFAIK, is
> that for various touchpad devices, these kind of details should be internal
> to the libinput device backend in question. That being said, this
> doesn't make it impossible to introduce such configuration in the
> future.
>
Yes, I was thinking about adding configuration for new devices with 
configurable button and scroll areas.
If you have to develop a new device e.g. smartphone where the virtual
buttons are outside of the screen area. In this case the touch driver 
has to take care of sending an button event when user touch the 
particular area of the touch panel.
The proposed configuration will make you independent of specific driver 
implementation and you can use different touch panels and putt you 
buttons/scroll areas wherever you wont.
>>
>> Also the weston code contains calibration of the absolute values.
>> It would be good also to have a calibration possibilities in libinput.
>
> This calibration, based on an udev rule, is already possible in libinput.
> It is automatic when using the udev backend it is possible to manually
> calibrate using libinput_device_calibrate() when using the path backend.
Yes, thanks for the advice I saw it. The available configuration covers 
already a part from our requirements.
>
>>
>> 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
>>>
>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>