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