[RFC] libinput configuration interface

Thu Feb 6 14:28:49 PST 2014

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.

Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140206/a1e07b8d/attachment-0001.html>