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 <[email protected]>: > 2014-02-03 Peter Hutterer <[email protected]>: > > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
