Re: [PATCH weston 00/25] A new touchscreen calibrator
On Mon, Mar 26, 2018 at 2:36 AM, Pekka Paalanen wrote: > On Fri, 23 Mar 2018 09:33:10 -0700 > Jason Gerecke wrote: > >> Nice! Do you think its reasonable to extend the allowed use of this >> protocol to other kinds of direct-input devices? I don't see anything >> which would prevent this protocol from working equally well to >> calibrate the pen input for a tablet PC or Cintiq for example. The >> compositor would need to obviously have pen support and notify the >> client of the device in a "touch_device" event, but otherwise it looks >> like the client doesn't really have to care about the underlying >> device -- the protocol provides its own definition of down/up/motion >> events. Just the documentation would need to be tweaked. > > Hi Jason, > > I suppose, but I am not at all familiar with such devices, so I cannot > make the call. I have never even used one. > > If the design is a good match for other devices, I would be happy to > accept spec changes and renaming interfaces to be more generic, but > only if someone is working on an implementation somewhere as well. > > Currently the protocol is being proposed to be Weston private. We might > land it as is, and then talk about how it should be generalized and > which package should install it for public use. We can have > libweston-dev install the XML file, or it could be proposed to be > included in wayland-protocols if it satisfies the general inclusion > requirements there. Or somewhere else. > > > Thanks, > pq > Good to know. It certainly seems like a good match at least for this second class of devices, so I would be very interested in seeing the wording made a bit more generic. Weston's tablet support is still in the works (I believe Lyude was last working on it?) so there's not an urgent need to make these changes, but it would be good to think about them if/when the protocol goes public. I imagine GNOME would be remotely interested in this protocol... Their current tablet calibration tool has to deal with exactly the same issues that this protocol very nicely addresses (e.g. un-transforming coordinates, screen mapping, grabbing input). Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > >> On Fri, Mar 23, 2018 at 5:00 AM, Pekka Paalanen wrote: >> > From: Pekka Paalanen >> > >> > Hi all, >> > >> > the existing touchscreen calibrator in Weston has several problems. This >> > proposal intends to solve them all by introducing a new protocol >> > extension for touchscreen calibration and a new calibrator tool. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/25] A new touchscreen calibrator
Nice! Do you think its reasonable to extend the allowed use of this
protocol to other kinds of direct-input devices? I don't see anything
which would prevent this protocol from working equally well to
calibrate the pen input for a tablet PC or Cintiq for example. The
compositor would need to obviously have pen support and notify the
client of the device in a "touch_device" event, but otherwise it looks
like the client doesn't really have to care about the underlying
device -- the protocol provides its own definition of down/up/motion
events. Just the documentation would need to be tweaked.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
On Fri, Mar 23, 2018 at 5:00 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Hi all,
>
> the existing touchscreen calibrator in Weston has several problems. This
> proposal intends to solve them all by introducing a new protocol
> extension for touchscreen calibration and a new calibrator tool.
>
> The benefits of the new tool, which the old tool lacks, are:
>
> - You can unambiguously pick a physical touch device to calibrate.
>
> - You can be sure your touch events come only from that particular
> device, and that you cannot miss touch events even if the current
> calibration is horribly wrong.
>
> - You can be sure the calibration window (pattern) is shown on the right
> output with the right coordinates.
>
> - You can unambiguously calibrate even multiple touchscreens that are
> all cloned (showing the same image).
>
> - You get a libinput style calibation matrix instead of the
> WL_CALIBRATION format which depends on output resolution.
>
> - You can load a new calibration into the compositor without playing
> tricks with udev or restarting the compositor.
>
> There is more discussion about the topic at:
> https://phabricator.freedesktop.org/T7868
>
> This patch series depends on the clone mode series:
> https://patchwork.freedesktop.org/series/32898/
>
> There is a full branch available at:
> https://gitlab.collabora.com/pq/weston/commits/touchcalib-1
>
> This series contains many patches that could be landed separately, but I
> have not pulled them out at this point.
>
> A notable single patch is patch 3 which deprecates the udev property
> WL_CALIBRATION. It is completely already superseded by
> LIBINPUT_CALIBRATION_MATRIX property. I would hope to remove
> WL_CALIBRATION support after few releases and the old calibrator tool
> with it.
>
> Patch 21 adds the touchscreen calibration protocol, patch 24 adds the
> new calibrator tool, and patch 25 gives suggestions on how to let the
> server permanently store a new calibration into udev rules.
>
> As LIBINPUT_CALIBRATION_MATRIX is automatically handled by libinput,
> being a description of the physical input device (like e.g. mouse dpi),
> it perfectly possible to run Weston and the calibrator once to calibrate
> your touchscreens, and then run whatever compositor you want.
>
> One major thing this patch series does not address is how a Wayland
> client gets authorized to use the touchscreen calibration interface. The
> interface offers two privileged actions: the ability to grab all touch
> input (but with provision for the server to cancel at will - not
> implemented in weston so far), and the ability to upload a new
> calibration for a touch device. Obviously these should not be free for
> all. The method implemented here is a simple global configuration
> setting to advertise or not the touchscreen calibration interface. If
> advertised, it is free for all. Therefore it is not advertised by
> default.
>
>
> Thanks,
> pq
>
>
> Louis-Francis Ratté-Boulianne (7):
> input: introduce weston_touch_device
> libweston: fix weston_touch_start_grab() arg name
> input: move touchpoint counting up
> input: introduce touch event mode for calibrator
> libweston: implement touch calibration protocol
> weston: add touchscreen_calibrator option
> clients: add a new touchscreen calibrator
>
> Pekka Paalanen (18):
> libinput: remove evdev_device::devnode
> libinput: note if calibrating without an output
> libinput: deprecate WL_CALIBRATION
> libinput: log input device to output associations
> libinput: make setting the same output a no-op
> libinput: allow evdev_device_set_output(dev, NULL)
> libinput: use head names for output matching
> libweston: require connected heads for input devices
> libinput: do not switch output associations on disable
> man: document WESTON_LIBINPUT_LOG_PRIORITY env
> tests: add test_seat_release() for symmetry
> libinput: move calibration printing into do_set_calibration()
> libweston: notify_touch API to use weston_touch_device
> libweston: unexport weston_{pointer,keyboard,touch}_{create,destroy}()
> libweston: introduce notify_touch_cal() and doc
> input: do not forward unm
[PATCH weston] compositor-rdp: Correct mouse scrolling direction
The direction of scrolling in the RDP compositor appears to be inverted. When using Weston directly in X, sending X11 button 4 cuases window contents to scroll up and button 4 to be reported to xwayland clients. Conversely, when using Weston through RDP (xfreerdp client), sending X11 button 4 causes window contents to scroll down and button 5 to be reported to xwayland clients. The xfreerdp client does not seem to be the cause of this since scrolling works correctly when connecting to a Windows host. Signed-off-by: Jason Gerecke --- libweston/compositor-rdp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c index 4a4dc696..ee68e969 100644 --- a/libweston/compositor-rdp.c +++ b/libweston/compositor-rdp.c @@ -1062,7 +1062,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y) * * https://blogs.msdn.microsoft.com/oldnewthing/20130123-00/?p=5473 explains the 120 value */ - value = (flags & 0xff) / 120.0; + value = -(flags & 0xff) / 120.0; if (flags & PTR_FLAGS_WHEEL_NEGATIVE) value = -value; -- 2.16.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH xserver] xwayland: Support for BTN_STYLUS3 kernel events
On Thu, Nov 9, 2017 at 2:19 PM, Jason Gerecke wrote:
> On Tue, Nov 7, 2017 at 2:37 PM, Peter Hutterer
> wrote:
>> On Tue, Nov 07, 2017 at 11:09:44AM -0800, Jason Gerecke wrote:
>>> BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
>>> status of the third button present on Wacom's new "Pro Pen 3D" stylus.
>>> Treat this button like xf86-input-wacom and send a button 8 event
>>> ("navigate back") when received from Wayland.
>>>
>>> Signed-off-by: Jason Gerecke
>>> ---
>>> Note: this patch is pending the formal acceptance of BTN_STYLU3 into
>>> Linux 4.15. I'll post an update once Jiri merges the patch.
>>
>> Reviewed-by: Peter Hutterer , I'll merge this
>> after your reminder ;)
>>
>> Cheers,
>>Peter
>>
>>
>
> Jiri's accepted the patch into his 'for-4.15/wacom' branch :)
>
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one /
> (That is to say, eight) to the two, /
> But you can’t take seven from three,/
> So you look at the sixty-fours
>
Just noticed that this doesn't appear to have been merged, so sending
another poke :)
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
>>> hw/xwayland/xwayland-input.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
>>> index 68e365051..4325b4c6e 100644
>>> --- a/hw/xwayland/xwayland-input.c
>>> +++ b/hw/xwayland/xwayland-input.c
>>> @@ -1698,6 +1698,7 @@ tablet_tool_button_state(void *data, struct
>>> zwp_tablet_tool_v2 *tool,
>>>
>>> case 0x113: /* BTN_SIDE*/
>>> case 0x116: /* BTN_BACK*/
>>> +case 0x149: /* BTN_STYLUS3 */
>>> xbtn = 8;
>>> break;
>>>
>>> --
>>> 2.15.0
>>>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3 00/17] Tablet device support for weston
On Tue, Dec 19, 2017 at 12:33 AM, Maniraj Devadoss wrote: > Hi Jason, > > I found the root cause for the backtrace you shared > https://lists.freedesktop.org/archives/wayland-devel/2017-November/035964.html > > The issue is that the tablet tool's surface and view is not > set as mapped in tablet_tool_cursor_surface_configure API, > so the same view can be added more than once to the cursor > layer list when the set_cursor is called by the client. This will > lead to corruption of cursor layer list. > > The issue is resolved with this patch series, > Can you please test the same and let us know the result. > > Best Regards, > Maniraj D. > Awesome, thanks! I've given the patch a quick test and the crash does seem to be resolved. I'm now able to interact with shell components (e.g. dragging windows) and the weston-tablet demo also appears to work. I do notice that there are some issues with swapping back and forth between the stylus and eraser within weston-tablet, however (sometimes it erases with the tip, or draws with the eraser). I've also tried running the "mypaint", which is a GTK3 drawing application. Its able to use use the Wayland tablet protocol when run under Mutter, but it doesn't seem to get any tablet events when running inside Weston. I'll take another look at the beginning of January when I'm back from vacation. Hopefully I can be a bit more helpful with the debugging now that things aren't crashing. :) Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > Bastian Farkas (3): > tablet: Fixed compilation errors resulting from tablet patches. > tablet: Fixing compilation issues in weston desktop-shell related to > tablet support patches. > tablet: reordered changes in weston_seat struct to not break ABI > compatibility > > Lyude Paul (13): > tablet: Add initial tablet support to weston > tablet: add handling of tablet focus > tablet: add weston grab interfaces for tablet tools > tablet: hook up libinput tablet events > tablet: handle tablet cursors in the compositor > clients: add support for handling tablets > client: Add tablet cursor support into libtoytoolkit > client: Add support for tablet cursor motion to window frames in > libtoytoolkit > tablet: Add support for moving windows around using the stylus > tablet: Add tablet support to the top panel of the desktop shell > tablet: Add binding to activate surfaces using the tablet tool > tablet: Add demo application for tablets > tablet: Remove tablet-specific tools on disconnect > > Maniraj Devadoss (1): > tablet: unmap the surface only if the sprite is not NULL > > .gitignore | 1 + > Makefile.am | 20 +- > clients/desktop-shell.c | 56 +++ > clients/tablet.c| 254 > clients/window.c| 686 +++ > clients/window.h| 93 + > configure.ac| 2 +- > desktop-shell/shell.c | 289 + > libweston/bindings.c| 39 +- > libweston/compositor.c | 8 + > libweston/compositor.h | 204 ++ > libweston/input.c | 965 > > libweston/libinput-device.c | 340 > libweston/libinput-device.h | 4 +- > shared/cairo-util.h | 4 + > shared/frame.c | 38 ++ > 16 files changed, 2996 insertions(+), 7 deletions(-) > create mode 100644 clients/tablet.c > > -- > 2.7.4 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2 00/16] Tablet device support for weston
On Thu, Nov 23, 2017 at 2:17 AM, Maniraj Devadoss wrote: > Hi, > > The previous posting of this series was at > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035534.html > > which had some issues when Jason Gerecke tried to test > it. > https://lists.freedesktop.org/archives/wayland-devel/2017-November/035716.html > > In this v2 series, I resolved one possible NULL pointer access issue in > input.c > > Best Regards, > Maniraj D. > Thanks for the updated patches, Maniraj. I'm still running into a crash when the pen is brought into proximity for a second time, this time with the following backtrace (full coredump available on request): #0 0x7f0dffda7b6f in surface_stash_subsurface_views (surface=0x55e380cc1930) at libweston/compositor.c:2141 #1 0x7f0dffdac626 in weston_compositor_build_view_list (compositor=compositor@entry=0x55e380b49400) at libweston/compositor.c:2252 #2 0x7f0dffdacb1e in weston_output_repaint (output=0x55e380d040e0, repaint_data=repaint_data@entry=0x55e380d27da0) at libweston/compositor.c:2308 #3 0x7f0dffdaeeb7 in weston_output_maybe_repaint (output=output@entry=0x55e380d040e0, now=now@entry=0x7fff9627cde0, repaint_data=repaint_data@entry=0x55e380d27da0) at libweston/compositor.c:2408 #4 0x7f0dffdaef51 in output_repaint_timer_handler (data=0x55e380b49400) at libweston/compositor.c:2474 #5 0x7f0dffb8f2ca in () at /usr/lib/libwayland-server.so.0 #6 0x7f0dffb8f9b2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0 #7 0x7f0dffb8e14c in wl_display_run () at /usr/lib/libwayland-server.so.0 #8 0x55e37eaacb64 in main (argc=, argv=0x7fff9627d3a8) at compositor/main.c:1970 GDB states that it "Cannot access memory at address 0x454341465245540e" when trying to print the value of "sub->surface" from frame 0. Because of this, I tried recompiling with "-fsanitize=address" and consistently got the following error when bringing the pen into proximity for a second time (full log attached): ==12921==ERROR: AddressSanitizer: heap-use-after-free on address 0x61652b80 at pc 0x7f02c7fdb6fa bp 0x7ffd10383910 sp 0x7ffd10383900 READ of size 8 at 0x61652b80 thread T0 #0 0x7f02c7fdb6f9 in weston_compositor_build_view_list libweston/compositor.c:2252 #1 0x7f02c7fdc15f in weston_output_repaint libweston/compositor.c:2308 #2 0x7f02c7fe17e3 in weston_output_maybe_repaint libweston/compositor.c:2408 #3 0x7f02c7fe19a7 in output_repaint_timer_handler libweston/compositor.c:2474 #4 0x7f02c7da52c9 (/usr/lib/libwayland-server.so.0+0x92c9) #5 0x7f02c7da59b1 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0x99b1) #6 0x7f02c7da414b in wl_display_run (/usr/lib/libwayland-server.so.0+0x814b) #7 0x5563675582dd in main compositor/main.c:1970 #8 0x7f02c6b7cf69 in __libc_start_main (/usr/lib/libc.so.6+0x20f69) #9 0x55636754da99 in _start (/usr/local/bin/weston+0x9a99) 0x61652b80 is located 0 bytes inside of 576-byte region [0x61652b80,0x61652dc0) freed by thread T0 here: #0 0x7f02c8314711 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:45 #1 0x7f02c7fdba56 in weston_view_destroy libweston/compositor.c:1872 #2 0x7f02c7fe4fcf in tablet_tool_unmap_sprite libweston/input.c:1524 #3 0x7f02c7fe636f in tablet_tool_set_cursor libweston/input.c:2823 #4 0x7f02c5f951c7 in ffi_call_unix64 (/usr/lib/libffi.so.6+0x61c7) previously allocated by thread T0 here: #0 0x7f02c8314ce1 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:70 #1 0x7f02c7fd16b4 in zalloc shared/zalloc.h:38 #2 0x7f02c7fd16b4 in weston_view_create libweston/compositor.c:270 #3 0x7f02c7fe63f9 in tablet_tool_set_cursor libweston/input.c:2832 #4 0x7f02c5f951c7 in ffi_call_unix64 (/usr/lib/libffi.so.6+0x61c7) I also notice that the "default_grab_tablet_tool_proximity_out" function has a comment indicating that it should be trying to hide the cursor, but I don't see the pen cursor disappearing when the pen leaves prox. Perhaps it is related? Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > Bastian Farkas (3): > tablet: Fixed compilation errors resulting from tablet patches. > tablet: Fixing compilation issues in weston desktop-shell related to > tablet support patches. > tablet: reordered changes in weston_seat struct to not break ABI > compatibility > > Lyude Paul (13): > tablet: Add initial tablet support to weston > tablet: add handling of tablet focus > tablet: add weston grab interfaces for tablet tools > tablet: hook up libinput tablet events > tablet: handle tablet cursors in the compositor
Re: [PATCH weston 00/16] Tablet device support for weston
Looks like the core files have been deleted but the stack traces are still available. I've attached the logs from coredumpctl for review. I won't have the ability to run Weston for the next few days, but I could potentially get you coredumps after that. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Thu, Nov 16, 2017 at 5:16 AM, Maniraj Devadoss (RBEI/ECF3) wrote: > Hi Jason, > > I am trying to reproduce the issue. But in my environment I am facing some > issue with hid-replay (replay events are not received in weston). Can you > please provide coredumps or backtraces if possible. > > Best regards, > > Devadoss Maniraj > RBEI/ECF3 > > Tel. +91 80 6136-4382 > > > -Original Message- > From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On > Behalf Of Jason Gerecke > Sent: Tuesday, November 7, 2017 8:52 AM > To: Bastian Farkas > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: [PATCH weston 00/16] Tablet device support for weston > > On Wed, Oct 25, 2017 at 4:12 AM, Bastian Farkas > wrote: >> Hi, >> >> with Peter Hutterers permission I modified an outdated patchset from him >> that adds support for tablet devices to the weston compositor. Several minor >> changes were needed to get the patches working with a recent weston version. >> >> I only tested my patches with a virtual tablet device (using python-evdev). >> >> Best regards >> Bastian Farkas >> > > Hi Bastian, > > I tried testing out these patches, but they almost immediately fell flat on > their face. A pointer appears and moves around when I bring my pen into prox, > and disappears when it leaves prox. When I bring the pen into prox a second > time, however, weston either hangs or crashes. > For what its worth, I did test this patchset the last time they were posted > to the list and didn't encounter this problem. > > I've attached a hid-replay log of my Intuos Pro which will hopefully let you > reproduce the issue yourself. I can try to provide coredumps or backtraces > instead if you'd prefer. > > Jason > --- > Now instead of four in the eights place / you’ve got three, ‘Cause you added > one / > (That is to say, eight) to the two, / > But you can’t take seven from three,/ > So you look at the sixty-fours > >> Advanced Driver Information Technology GmbH Engineering System & >> Architecture (ADITG/ESA) Robert-Bosch-Str. 200 >> 31139 Hildesheim >> Germany >> >> Tel. +49 5121 49 6942 >> Fax +49 5121 49 6999 >> bfar...@de.adit-jv.com >> >> ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car >> Multimedia GmbH and DENSO Corporation >> Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 >> Geschäftsführung: Wilhelm Grabow, Ken Yaguchi >> >> Bastian Farkas (3): >> tablet: Fixed compilation errors resulting from tablet patches. >> tablet: Fixing compilation issues in weston desktop-shell related to >> tablet support patches. >> tablet: reordered changes in weston_seat struct to not break ABI >> compatibility >> >> Lyude Paul (13): >> tablet: Add initial tablet support to weston >> tablet: add handling of tablet focus >> tablet: add weston grab interfaces for tablet tools >> tablet: hook up libinput tablet events >> tablet: handle tablet cursors in the compositor >> clients: add support for handling tablets >> client: Add tablet cursor support into libtoytoolkit >> client: Add support for tablet cursor motion to window frames in >> libtoytoolkit >> tablet: Add support for moving windows around using the stylus >> tablet: Add tablet support to the top panel of the desktop shell >> tablet: Add binding to activate surfaces using the tablet tool >> tablet: Add demo application for tablets >> tablet: Remove tablet-specific tools on disconnect >> >> .gitignore | 1 + >> Makefile.am | 20 +- >> clients/desktop-shell.c | 56 +++ >> clients/tablet.c| 254 >> clients/window.c| 686 +++ >> clients/window.h| 93 + >> configure.ac| 2 +- >> desktop-shell/shell.c | 289 + >> libweston/bindings.c| 39 +- >> libweston/compositor.c | 8 + >> libweston/compositor.h | 204
Re: [PATCH xserver] xwayland: Support for BTN_STYLUS3 kernel events
On Tue, Nov 7, 2017 at 2:37 PM, Peter Hutterer wrote:
> On Tue, Nov 07, 2017 at 11:09:44AM -0800, Jason Gerecke wrote:
>> BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
>> status of the third button present on Wacom's new "Pro Pen 3D" stylus.
>> Treat this button like xf86-input-wacom and send a button 8 event
>> ("navigate back") when received from Wayland.
>>
>> Signed-off-by: Jason Gerecke
>> ---
>> Note: this patch is pending the formal acceptance of BTN_STYLU3 into
>> Linux 4.15. I'll post an update once Jiri merges the patch.
>
> Reviewed-by: Peter Hutterer , I'll merge this
> after your reminder ;)
>
> Cheers,
>Peter
>
>
Jiri's accepted the patch into his 'for-4.15/wacom' branch :)
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
>> hw/xwayland/xwayland-input.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
>> index 68e365051..4325b4c6e 100644
>> --- a/hw/xwayland/xwayland-input.c
>> +++ b/hw/xwayland/xwayland-input.c
>> @@ -1698,6 +1698,7 @@ tablet_tool_button_state(void *data, struct
>> zwp_tablet_tool_v2 *tool,
>>
>> case 0x113: /* BTN_SIDE*/
>> case 0x116: /* BTN_BACK*/
>> +case 0x149: /* BTN_STYLUS3 */
>> xbtn = 8;
>> break;
>>
>> --
>> 2.15.0
>>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH xserver] xwayland: Support for BTN_STYLUS3 kernel events
BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
status of the third button present on Wacom's new "Pro Pen 3D" stylus.
Treat this button like xf86-input-wacom and send a button 8 event
("navigate back") when received from Wayland.
Signed-off-by: Jason Gerecke
---
Note: this patch is pending the formal acceptance of BTN_STYLU3 into
Linux 4.15. I'll post an update once Jiri merges the patch.
hw/xwayland/xwayland-input.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 68e365051..4325b4c6e 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -1698,6 +1698,7 @@ tablet_tool_button_state(void *data, struct
zwp_tablet_tool_v2 *tool,
case 0x113: /* BTN_SIDE*/
case 0x116: /* BTN_BACK*/
+case 0x149: /* BTN_STYLUS3 */
xbtn = 8;
break;
--
2.15.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/16] Tablet device support for weston
On Wed, Oct 25, 2017 at 4:12 AM, Bastian Farkas wrote: > Hi, > > with Peter Hutterers permission I modified an outdated patchset from him that > adds support for tablet devices to the weston compositor. Several minor > changes were needed to get the patches working with a recent weston version. > > I only tested my patches with a virtual tablet device (using python-evdev). > > Best regards > Bastian Farkas > Hi Bastian, I tried testing out these patches, but they almost immediately fell flat on their face. A pointer appears and moves around when I bring my pen into prox, and disappears when it leaves prox. When I bring the pen into prox a second time, however, weston either hangs or crashes. For what its worth, I did test this patchset the last time they were posted to the list and didn't encounter this problem. I've attached a hid-replay log of my Intuos Pro which will hopefully let you reproduce the issue yourself. I can try to provide coredumps or backtraces instead if you'd prefer. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > Advanced Driver Information Technology GmbH > Engineering System & Architecture (ADITG/ESA) > Robert-Bosch-Str. 200 > 31139 Hildesheim > Germany > > Tel. +49 5121 49 6942 > Fax +49 5121 49 6999 > bfar...@de.adit-jv.com > > ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car > Multimedia GmbH and DENSO Corporation > Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 > Geschäftsführung: Wilhelm Grabow, Ken Yaguchi > > Bastian Farkas (3): > tablet: Fixed compilation errors resulting from tablet patches. > tablet: Fixing compilation issues in weston desktop-shell related to > tablet support patches. > tablet: reordered changes in weston_seat struct to not break ABI > compatibility > > Lyude Paul (13): > tablet: Add initial tablet support to weston > tablet: add handling of tablet focus > tablet: add weston grab interfaces for tablet tools > tablet: hook up libinput tablet events > tablet: handle tablet cursors in the compositor > clients: add support for handling tablets > client: Add tablet cursor support into libtoytoolkit > client: Add support for tablet cursor motion to window frames in > libtoytoolkit > tablet: Add support for moving windows around using the stylus > tablet: Add tablet support to the top panel of the desktop shell > tablet: Add binding to activate surfaces using the tablet tool > tablet: Add demo application for tablets > tablet: Remove tablet-specific tools on disconnect > > .gitignore | 1 + > Makefile.am | 20 +- > clients/desktop-shell.c | 56 +++ > clients/tablet.c| 254 > clients/window.c| 686 +++ > clients/window.h| 93 + > configure.ac| 2 +- > desktop-shell/shell.c | 289 + > libweston/bindings.c| 39 +- > libweston/compositor.c | 8 + > libweston/compositor.h | 204 ++ > libweston/input.c | 963 > > libweston/libinput-device.c | 340 > libweston/libinput-device.h | 4 +- > shared/cairo-util.h | 4 + > shared/frame.c | 38 ++ > 16 files changed, 2994 insertions(+), 7 deletions(-) > create mode 100644 clients/tablet.c > > -- > 2.7.4 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel D: 0 R: 949 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 01 95 05 81 03 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 0d ff 09 01 a1 01 85 10 09 20 a1 00 09 42 09 44 09 5a 09 45 09 3c 09 32 09 36 15 00 25 01 75 01 95 07 81 02 95 01 81 03 0a 30 01 65 11 55 0d 35 00 47 80 57 00 00 15 00 27 00 af 00 00 75 18 95 01 81 02 0a 31 01 47 d0 39 00 00 27 a0 73 00 00 81 02 09 30 55 00 65 00 15 00 26 ff 1f 75 10 81 02 09 3d 09 3e 65 14 55 00 35 c0 45 3f 15 c0 25 3f 75 08 95 02 81 02 09 41 65 14 55 00 36 4c ff 46 b3 00 16 7c fc 26 83 03 75 10 95 01 81 0a 0a 03 0d 65 00 55 00 15 00 26 ff 07 75 10 95 01 81 02 0a 32 01 15 00 25 3f 75 08 95 01 81 02 09 5b 09 5c 17 00 00 00 80 27 ff ff ff 7f 75 20 95 02 81 02 09 77 15 00 26 ff 0f 75 10 95 01 81 02 c0 85 11 09 39 a1 00 1a 10 09 2a 17 09 15 00 25 01 75 01 95 08 81 02 1a 40 09 2a 47 09 81 02 0a 95 09 95 01 81 02 95 07 81 03 0a 38 01 65 14 55 00 35 00 46 67 01 15 00 25 47 75 07 95 01 81 0a 0a 39 01 65 00 55 00 25 01 75 01 95 01 81 02 75 08 95 04 81 03 c0 85 13 0a 13 10 a1 00 0a 3b 04 15 00 25 64 75 07 95 01 81 02 0a 04 04 25 01 75 01 81 02 0a 52 04 15 00 25 01 75 01 95 01 81 02 95 06 81 03 0a 86 09 95 01 81 02 75 08 95 06 81 03
Re: [PATCH libinput 2/2] pad: use libwacom to get the evdev to button number mapping
(count, 3);
> +#endif
> +}
> +END_TEST
> +
> +START_TEST(pad_button_bamboo)
> +{
> +#if !HAVE_LIBWACOM_GET_BUTTON_EVDEV_CODE
> + struct litest_device *dev = litest_current_device();
> + struct libinput *li = dev->libinput;
> + unsigned int code;
> + unsigned int expected_number = 0;
> + struct libinput_event *ev;
> + struct libinput_event_tablet_pad *pev;
> + unsigned int count;
> +
> + if (!libevdev_has_event_code(dev->evdev, EV_KEY, BTN_LEFT))
> + return;
Pre-3.17 kernels combine the pen and pad on the same device. A device
like the Intuos4 will declare the BTN_0 range for its ExpressKeys, as
well as the BTN_LEFT range for its puck. Not sure if that'll be
problematic...
> +
> + litest_drain_events(li);
> +
> + for (code = BTN_LEFT; code < BTN_JOYSTICK; code++) {
> + if (!libevdev_has_event_code(dev->evdev, EV_KEY, code))
> + return;
> +
> + litest_button_click(dev, code, 1);
> + litest_button_click(dev, code, 0);
> + libinput_dispatch(li);
> +
> + count++;
> +
> + ev = libinput_get_event(li);
> + pev = litest_is_pad_button_event(ev,
> +expected_number,
> +
> LIBINPUT_BUTTON_STATE_PRESSED);
> + ev = libinput_event_tablet_pad_get_base_event(pev);
> + libinput_event_destroy(ev);
> +
> + ev = libinput_get_event(li);
> + pev = litest_is_pad_button_event(ev,
> +expected_number,
> +
> LIBINPUT_BUTTON_STATE_RELEASED);
> + ev = libinput_event_tablet_pad_get_base_event(pev);
> + libinput_event_destroy(ev);
> +
> + expected_number++;
> + }
> +
> + litest_assert_empty_queue(li);
> +
> + ck_assert_int_gt(count, 3);
> +#endif
> +}
> +END_TEST
> +
> +START_TEST(pad_button_libwacom)
> +{
> +#if HAVE_LIBWACOM_GET_BUTTON_EVDEV_CODE
> + struct litest_device *dev = litest_current_device();
> + struct libinput *li = dev->libinput;
> + WacomDeviceDatabase *db = NULL;
> + WacomDevice *wacom = NULL;
> +
> + db = libwacom_database_new();
> + assert(db);
> +
> + wacom = libwacom_new_from_usbid(db,
> + libevdev_get_id_vendor(dev->evdev),
> + libevdev_get_id_product(dev->evdev),
> + NULL);
> + assert(wacom);
> +
> + litest_drain_events(li);
> +
> + for (int i = 0; i < libwacom_get_num_buttons(wacom); i++) {
> + unsigned int code;
> +
> + code = libwacom_get_button_evdev_code(wacom, 'A' + i);
> +
> + litest_button_click(dev, code, 1);
> + litest_button_click(dev, code, 0);
> + libinput_dispatch(li);
> +
> + litest_assert_pad_button_event(li,
> + i,
> + LIBINPUT_BUTTON_STATE_PRESSED);
> + litest_assert_pad_button_event(li,
> + i,
> +
> LIBINPUT_BUTTON_STATE_RELEASED);
> + }
> +
> +
> + libwacom_destroy(wacom);
> + libwacom_database_destroy(db);
> +#endif
> }
> END_TEST
>
> @@ -788,7 +926,10 @@ litest_setup_tests_pad(void)
> litest_add("pad:time", pad_time, LITEST_TABLET_PAD, LITEST_ANY);
>
> litest_add("pad:button", pad_num_buttons, LITEST_TABLET_PAD,
> LITEST_ANY);
> - litest_add("pad:button", pad_button, LITEST_TABLET_PAD, LITEST_ANY);
> + litest_add("pad:button", pad_num_buttons_libwacom, LITEST_TABLET_PAD,
> LITEST_ANY);
> + litest_add("pad:button", pad_button_intuos, LITEST_TABLET_PAD,
> LITEST_ANY);
> + litest_add("pad:button", pad_button_bamboo, LITEST_TABLET_PAD,
> LITEST_ANY);
> + litest_add("pad:button", pad_button_libwacom, LITEST_TABLET_PAD,
> LITEST_ANY);
> litest_add("pad:button", pad_button_mode_groups, LITEST_TABLET_PAD,
> LITEST_ANY);
>
> litest_add("pad:ring", pad_has_ring, LITEST_RING, LITEST_ANY);
> --
> 2.13.6
>
Those concerns aside, for the set:
Acked-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] udev: add quirk for Chalkboard Electronics HID Touchscreen
On Thu, Sep 21, 2017 at 7:00 AM, Matt Porter wrote: > On Thu, Sep 21, 2017 at 10:59:08AM +0200, Hans de Goede wrote: >> Hi, >> >> On 19-09-17 18:41, Matt Porter wrote: >> > The Chalkboard Electronics HID Touchscreen is classified as >> > a tablet device by systemd udev because it has BTN_TOOL_PEN >> > support. It also reports a resolution of 0 for both X and Y >> > axes in absinfo. This causes libinput to reject it as an >> > invalid tablet device. >> > >> > This quirk reclassifies the device as a touchscreen which >> > allows it to be added as a valid input device. >> > >> > Signed-off-by: Matt Porter >> >> Have you considered adding special handling for this device >> to the kernel's hid drivers ? The hid subsys has sub drivers >> for device specific handling and if the device never actually >> has a pen, then the right fix would be to not make the kernel >> export this. Note I assume this is for a so called >> "smart" whiteboard for in classes ? If that is the case then >> the device may actually have a pen/stylus like device in >> some configuration. Some of these smart boards have what >> are basically empty whiteboard-marker in multiple colors >> and the device may report these as different styluses ... > > I hadn't really considered that since this userspace fixup > basically follows the pattern I see for other devices in > systemd's hwdb. Just to clarify, these are not "smartboard" > style devices. They are typical 7-14" touchscreen displays > with HDMI/USB interface from https://www.chalk-elec.com/ > > The updated patch for this is at > https://github.com/systemd/systemd/pull/6880 based on Peter's > earlier comments. It could be solved in the kernel as you > suggest, however it appears that usually that approach is for > very different hid devices with custom protocols (e.g. > logitech-hidpp). I could suppress the pen tool and update absinfo > in a hid-chalkboard.c if that's preferred. There could be an > advantage here for those that aren't using systemd udev. > > -Matt What kernel driver gets bound to the device? I would expect hid-multitouch for a generic multitouch touchscreen, but I don't believe that driver ever exposes BTN_TOOL_PEN. Perhaps a quirk simply needs to be refined or defined? Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: accept accelerometers if they are tagged as other devices too
SOFTWARE.
> + */
> +
> +#include "config.h"
> +
> +#include "litest.h"
> +#include "litest-int.h"
> +
> +static void litest_wacom_mobilestudio_pad_setup(void)
> +{
> + struct litest_device *d =
> litest_create_device(LITEST_WACOM_MOBILESTUDIO_PRO_16_PAD);
> + litest_set_current_device(d);
> +}
> +
> +static struct input_event down[] = {
> + { .type = -1, .code = -1 },
> +};
> +
> +static struct input_event move[] = {
> + { .type = -1, .code = -1 },
> +};
> +
> +static struct input_event ring_start[] = {
> + { .type = EV_ABS, .code = ABS_WHEEL, .value = LITEST_AUTO_ASSIGN },
> + { .type = EV_ABS, .code = ABS_MISC, .value = 15 },
> + { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
> + { .type = -1, .code = -1 },
> +} ;
> +
> +static struct input_event ring_change[] = {
> + { .type = EV_ABS, .code = ABS_WHEEL, .value = LITEST_AUTO_ASSIGN },
> + { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
> + { .type = -1, .code = -1 },
> +} ;
> +
> +static struct input_event ring_end[] = {
> + { .type = EV_ABS, .code = ABS_WHEEL, .value = 0 },
> + { .type = EV_ABS, .code = ABS_MISC, .value = 0 },
> + { .type = EV_SYN, .code = SYN_REPORT, .value = 0 },
> + { .type = -1, .code = -1 },
> +} ;
> +
> +static struct litest_device_interface interface = {
> + .touch_down_events = down,
> + .touch_move_events = move,
> + .pad_ring_start_events = ring_start,
> + .pad_ring_change_events = ring_change,
> + .pad_ring_end_events = ring_end,
> +};
> +static struct input_absinfo absinfo[] = {
> + { ABS_X, -2048, 2048, 0, 0, 0 },
> + { ABS_Y, -2048, 2048, 0, 0, 0 },
> + { ABS_Z, -2048, 2048, 0, 0, 0 },
> + { ABS_WHEEL, 0, 71, 0, 0, 0 },
ABS_WHEEL range for this device is 0..35 (sorry for being so dense in
the bug report...). Aside from that minor nitpick, looks good and does
the trick :)
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> + { ABS_MISC, 0, 0, 0, 0, 0 },
> + { .value = -1 },
> +};
> +
> +static struct input_id input_id = {
> + .bustype = 0x3,
> + .vendor = 0x56a,
> + .product = 0x34e,
> + .version = 0x110,
> +};
> +
> +static int events[] = {
> + EV_KEY, BTN_0,
> + EV_KEY, BTN_1,
> + EV_KEY, BTN_2,
> + EV_KEY, BTN_3,
> + EV_KEY, BTN_4,
> + EV_KEY, BTN_5,
> + EV_KEY, BTN_6,
> + EV_KEY, BTN_7,
> + EV_KEY, BTN_8,
> + EV_KEY, BTN_SOUTH,
> + EV_KEY, BTN_EAST,
> + EV_KEY, BTN_C,
> + EV_KEY, BTN_STYLUS,
> + INPUT_PROP_MAX, INPUT_PROP_ACCELEROMETER,
> + -1, -1,
> +};
> +
> +static const char udev_rule[] =
> +"ACTION==\"remove\", GOTO=\"pad_end\"\n"
> +"KERNEL!=\"event*\", GOTO=\"pad_end\"\n"
> +"\n"
> +"ATTRS{name}==\"litest Wacom MobileStudio Pro 16 Pad*\",\\\n"
> +"ENV{ID_INPUT_TABLET}=\"1\",\\\n"
> +"ENV{ID_INPUT_TABLET_PAD}=\"1\"\\\n"
> +"\n"
> +"LABEL=\"pad_end\"";
> +
> +struct litest_test_device litest_wacom_mobilestudio_13hdt_pad_device = {
> + .type = LITEST_WACOM_MOBILESTUDIO_PRO_16_PAD,
> + .features = LITEST_TABLET_PAD | LITEST_RING,
> + .shortname = "wacom-mobilestudio-pro16-pad",
> + .setup = litest_wacom_mobilestudio_pad_setup,
> + .interface = &interface,
> +
> + .name = "Wacom MobileStudio Pro 16 Pad",
> + .id = &input_id,
> + .events = events,
> + .absinfo = absinfo,
> + .udev_rule = udev_rule,
> +};
> diff --git a/test/litest.c b/test/litest.c
> index cbc0c511..d832adc4 100644
> --- a/test/litest.c
> +++ b/test/litest.c
> @@ -416,6 +416,7 @@ extern struct litest_test_device
> litest_lid_switch_surface3_device;
> extern struct litest_test_device litest_appletouch_device;
> extern struct litest_test_device litest_gpio_keys_device;
> extern struct litest_test_device litest_ignored_mouse_device;
> +extern struct litest_test_device litest_wacom_mobilestudio_13hdt_pad_device;
>
> struct litest_test_device* devices[] = {
> &litest_synaptics_clickpad_device,
> @@ -483,6 +484,7 @@ struct litest_test_device* devices[] = {
> &litest_appletouch_device,
> &litest_gpio_keys_device,
> &litest_ignored_mouse_device,
> + &litest_wacom_mobilestudio_13hdt_pad_device,
> NULL,
> };
>
> diff --git a/test/litest.h b/test/litest.h
> index 150381ec..f33c05fa 100644
> --- a/test/litest.h
> +++ b/test/litest.h
> @@ -236,6 +236,7 @@ enum litest_device_type {
> LITEST_APPLETOUCH,
> LITEST_GPIO_KEYS,
> LITEST_IGNORED_MOUSE,
> + LITEST_WACOM_MOBILESTUDIO_PRO_16_PAD,
> };
>
> enum litest_device_feature {
> --
> 2.13.5
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] lid: disable all types but EV_SYN and EV_SW
On Tue, Jul 25, 2017 at 7:34 AM, Peter Hutterer
wrote:
> The lid dispatch interface is a one-trick pony and can only handle SW_LID. It
> ignores other switches but crashes on any event type other than EV_SW and
> EV_SYN. Disable those types so we just ignore the event instead of asserting.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100057
Surely you meant https://bugs.freedesktop.org/show_bug.cgi?id=101853
Aside from that, seems like a reasonable workaround until the pony can
either be taught a second trick or swapped out for a more capable
animal.
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
>
> Signed-off-by: Peter Hutterer
> ---
> meson.build | 1 +
> src/evdev-lid.c | 8
> test/litest-device-lid-switch-power.c | 71
> +++
> test/litest.c | 2 +
> test/litest.h | 1 +
> test/test-lid.c | 20 ++
> 6 files changed, 103 insertions(+)
> create mode 100644 test/litest-device-lid-switch-power.c
>
> diff --git a/meson.build b/meson.build
> index cf10b35f..224ff9ce 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -538,6 +538,7 @@ if get_option('tests')
> 'test/litest-device-keyboard-all-codes.c',
> 'test/litest-device-keyboard-razer-blackwidow.c',
> 'test/litest-device-lid-switch.c',
> + 'test/litest-device-lid-switch-power.c',
> 'test/litest-device-lid-switch-surface3.c',
> 'test/litest-device-logitech-trackball.c',
> 'test/litest-device-nexus4-touch-screen.c',
> diff --git a/src/evdev-lid.c b/src/evdev-lid.c
> index b3df37c2..6c438e00 100644
> --- a/src/evdev-lid.c
> +++ b/src/evdev-lid.c
> @@ -298,6 +298,7 @@ struct evdev_dispatch *
> evdev_lid_switch_dispatch_create(struct evdev_device *lid_device)
> {
> struct lid_switch_dispatch *dispatch;
> + int type;
>
> dispatch = zalloc(sizeof *dispatch);
> dispatch->base.dispatch_type = DISPATCH_LID_SWITCH;
> @@ -309,5 +310,12 @@ evdev_lid_switch_dispatch_create(struct evdev_device
> *lid_device)
>
> dispatch->lid_is_closed = false;
>
> + for (type = EV_KEY; type < EV_CNT; type++) {
> + if (type == EV_SW)
> + continue;
> +
> + libevdev_disable_event_type(lid_device->evdev, type);
> + }
> +
> return &dispatch->base;
> }
> diff --git a/test/litest-device-lid-switch-power.c
> b/test/litest-device-lid-switch-power.c
> new file mode 100644
> index ..c7a3d557
> --- /dev/null
> +++ b/test/litest-device-lid-switch-power.c
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright © 2017 James Ye
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "config.h"
> +
> +#include "litest.h"
> +#include "litest-int.h"
> +
> +static void
> +litest_lid_switch_setup(void)
> +{
> + struct litest_device *d = litest_create_device(LITEST_LID_SWITCH);
> + litest_set_current_device(d);
> +}
> +
> +static struct input_id input_id = {
> + .bustype = 0x19,
> + .vendor = 0x0,
> + .product = 0x5,
> +};
> +
>
Re: [RFC wayland-protocols] Color management protocol
On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote: > On 12/19/2016 03:04 AM, Pekka Paalanen wrote: >> We very deliberately avoid defining any "standard" Wayland interfaces >> for configuring a compositor, because every compositor is different. >> With X11, you had the one single X server implementation and no other. >> On Wayland, every compositor is an individual, just like every X11 >> window manager is. >> >> I do not want to waste time in designing a "standard configuration >> interface" when the realistic expectation is that none of the major >> DEs' compositor will be implementing it. They already have their own >> tailor-made ways. As a case study one could look at the feature set of >> xrandr tool. > > At first glance, that comes across as off-point and shirking responsibility, > where Weston boastfully promotes itself as "*the* reference implementation of > a > Wayland compositor, and a useful compositor in its own right". > > Where is *Weston's* "pixel perfect" Color Management System? > > Unless the argument is convincingly made that *nothing* will ever be required > from the Wayland protocol in order for any compositor to implement a "pixel > perfect" CMS, on its own, then 'deliberately avoid[ing] defining any > "standard" > Wayland interfaces for configuring a compositor' is just "throwing a monkey > wrench" into the conversation. > > To convincingly make that argument, create the Weston "pixel perfect" CMS, and > demonstrate that nothing CMS related was required from the Wayland protocol. > > What is the design outline of that Wayland-protocol-free CMS? I can certainly see where you're coming from, as I too had similar thoughts when getting my feet wet with with protocol design for tablet input events. What it basically comes down to is that standardized Wayland protocols are intended for providing features to "general purpose" applications. Standardized protocols are not generally used for configuring compositors for multiple reasons, e.g. recognizing that not every compositor will want to offer the same configuration options in the same way (read: feature-creep of configuration interfaces with ever-more-niche options that only matter to single compositors), and concerns about random applications changing settings (read: sensitive/priviliged operations and applications "fighting" each other to apply conflicting configs). There is no "standard configuration interface" for something even so basic as configuring input devices. It sure feels like shirking responsibility, but its a conscious design decision to try and avoid some of the pain points that we lived with in X. Its possible to separate concerns of usage from configuration without "throwing a monkey wrench" into the conversation. Its just necessary to be mindful that defining (standard) Wayland interfaces is not necessarily always the appropriate design decision. I'm just a hobbyist photographer whose done casual reading about color management and use a second-hand colorimeter and can't wait to see some color management come to Wayland. But it will be necessary to figure out exactly how to deal with its complexities in a way that is compatible with Wayland's fundamental design decisions. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] tablet: specify the tool button numbers are simply sequentially numbered
On 11/03/2016 06:46 PM, Peter Hutterer wrote: > We're using sequentially numbered buttons for the pad because actual tablets > are quite varied in how the present buttons (BTN_A, BTN_0, etc.). For this > reason, libinput numbers pad buttons sequentially. > > Let's do the same for tablet tools. Unfortunately libinput doesn't do this, so > the mapping is up to the compositor but at least we can get the wayland > protocol right. The ony event codes a tool currently sends are BTN_STYLUS and > BTN_STYLUS2 anyway, so it's already sequentially numbered with a make-pretend > fancy name. > This sounds fine from the viewpoint of making things consistent, but I'm a still a little hesitant about making such a change. I don't want to throw away semantic information which could be valuable to clients. If there's one thing I've learned from X11 and xf86-input-wacom its that sequentially numbered buttons only work if the buttons are effectively interchangeable (example: ExpressKeys, whose functions are arbitrarily defined by the client; anti-example: mouse buttons, whose functions are defined by tradition[1]). Are the two buttons on a stylus arbitrarily interchangeable? My immediate gut feeling is "yes"[2], but I don't want to be too hasty in changing protocol. If a stylus is introduced with a third button that has some specific intended functionality, is it added to the sequential button list or do we define a new event that gets sent when that button is pressed? Does it depend on how the kernel defines it? I'm willing to give this an acked-by but I'd like to hear your thoughts back first :) > Signed-off-by: Peter Hutterer > --- > This is something Carlos and I discussed at XDC, TLDR: it doesn't make much > sense sending BTN_STYLUS for a tool but button index 0 for the pad. > > I didn't bump the version number here because it either > a) doesn't matter to clients > b) needs a interface version bump, but then probably a) applies > c) needs a full tablet-unstable-v3.xml but that seems excessive. > > Not 100% which one of those applies, Carlos will know more since he's doing > the mutter/GTK bits. Weston doesn't care, we don't have a tablet > implementation yet. > Shouldn't changing the starting point for button numbers from 0x14B (BTN_STYLUS) to 0 necessitate a version change? I haven't looked at Mutter/GTK, but my in-development Xwayland patches[3] would break from the change. [1]: Oh, you have a four-button mouse with left/right/forward/back buttons? Well, I hope the last two are reported as the 6th and 7th mouse button or else they aren't going to work right. [2]: A couple of reasons: "BTN_STYLUS" and "BTN_STYLUS2" sound pretty interchangeable, the buttons have no "obvious" or "traditional" semantics, and the default right/middle mapping on Linux is opposite to Windows but I haven't heard any complaints. [3]: Hopefully my queue of higher-priority tasks will clear up soon(TM) and I can get back to finishing them... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours > unstable/tablet/tablet-unstable-v2.xml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/unstable/tablet/tablet-unstable-v2.xml > b/unstable/tablet/tablet-unstable-v2.xml > index 728a3df..e7a15bd 100644 > --- a/unstable/tablet/tablet-unstable-v2.xml > +++ b/unstable/tablet/tablet-unstable-v2.xml > @@ -555,6 +555,8 @@ > button events are generated by the compositor. See > wp_tablet_tool.proximity_in and wp_tablet_tool.proximity_out for > details. > + > + Buttons are indexed sequentially, starting at button 0. > > > > @@ -1141,6 +1143,8 @@ > > > Sent whenever the physical state of a button changes. > + > + Buttons are indexed sequentially, starting at button 0. > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weston and graphics tablet support?
On 10/27/2016 10:22 PM, Peter Hutterer wrote: > Time to discuss graphics tablet support in weston: I had a patchset for some > earlier version of the tablet protocol, since then we've added a few bits > and bobs, including the mode switching support. > > Short story behind this email is: I seriously question the point of having a > tablet implementation in weston. I know it's supposed to be the test bed for > protocols (fwiw, we already have mutter + GTK support for tablets). But in > order to test this particular protocol, a lot of supporting infrastructure > has to be there that libtoytoolkit doesn't have. In addition, there are a > couple of things to be added to the compositor support, especially for mode > switching, that I question the value of having this in weston at all [1]. > > Some or most of this work will likely end up being an unused (and thus > untested) code path, the compositors that care about a niche feature like > graphics tablet support are unlikely to be the ones that use libweston. > > So right now, I'm tending to *not* implementing tablet support for weston. > Any opinions? Yay? Nay? Banana!? > > Cheers, >Peter > > [1] yes, you can attribute some of all this to laziness I'm sure you can guess that I'm in favor of adding support to Weston and libtoytoolkit, but hopefully I can provide some sound reasons to back up that opinion. While pen input may not be as ubiquitous as the mouse/touchpad or keyboard, it isn't exactly uncommon either. The tablet PC user expects to be able to use their pen anywhere they could use a mouse: opening applications, moving/resizing/closing windows, interacting with dialog boxes and application UI, etc. The pen is just as capable of clicking and dragging as a mouse or finger and is used for those purposes almost as much as for drawing/writing. libtoytoolkit use is niche enough that that perhaps it is acceptable to say that clicking/dragging and other basic UI interactions should be effectively "broken" in the name of simplicity. On the other hand, it would be nice if the toolkit was responsive to at least a minimal degree. I do so much hate having to dig in my drawer for a mouse just because an application doesn't recognize my pen or puck. As for Weston, I have a much harder time accepting that it should go without support. Doing so effectively says that Weston is not suitable for use by artists with applications like GIMP and Krita. Certainly the reference compositor is free to ignore applications and use-cases that it finds irrelevant, but (as I already mentioned), artists and pens aren't exactly uncommon. Further, leaving support out of Weston just leaves the barrier that much higher for developers of other compositors. Developers aren't going to implement from-scratch support for hardware they don't have, and aren't going to be able to justify the expense of buying a tablet when there are more important bugs/features impacting their userbase. Having reference code available is useful and doubly-so to have a working implementation included in the library you're building on (libweston). Tablets currently see use in environments where "niche" compositors (e.g. nested remote desktop or single-application workstations) would likely see use. I also believe that getting support into (lib)Weston would ensure improved quality compared to the alternative since the code would be used by multiple small compositors who would have a reasonably diverse combined userbase. Sure it won't be as large as e.g. Mutter, but it should be sufficient and certainly better than the number of users individual implementations would have. Finally, I should note that adding support for tablets doesn't mean that the support has to be 100% feature-complete. Leaving out support for those parts of the protocol which are more complex and less used (e.g. mode switching; maybe even pads TBH) may be reasonable. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput 6/6] tablet: add touch arbitration
On 09/05/2016 06:04 PM, Peter Hutterer wrote:
> So far we've relied on the wacom kernel module to do touch arbitration for us
> but that won't be the case in upcoming kernels. Implement touch arbitration in
> userspace by pairing the two devices and suspending the touch device whenever
> a tool comes into proximity.
>
> In the future more sophisticated arbitration can be done (e.g. only touches
> which are close to the pen) but let's burn that bridge when we have to cross
> it.
>
> Note that touch arbitration is "device suspend light", i.e. we leave the
> device enabled and the fd is active. Tablet interactions are comparatively
> short-lived, so closing the fd and asking logind for a new one every time the
> pen changes proximity is suboptimal. Instead, we just keep a boolean around
> and discard all events while it is set.
>
> Signed-off-by: Peter Hutterer
The revised series looks good to me -- thanks again :)
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
> ---
> Changes to v1:
> - drop the previous evdev_device_suspend() approach and use a ignore_events
> boolean in the dispatch instead.
> - add test for suspending/resuming the touch device during arbitration
> - use a common helper for each arbitration test. the tests only differ in
> the second device created and what events we expect so let's re-use
> everything else
>
> doc/tablet-support.dox | 13 ++
> src/evdev-mt-touchpad.c | 21 +++
> src/evdev-mt-touchpad.h | 4 +
> src/evdev-tablet-pad.c | 1 +
> src/evdev-tablet.c | 80 ++-
> src/evdev-tablet.h | 3 +
> src/evdev.c | 21 +++
> src/evdev.h | 8 ++
> test/tablet.c | 344
>
> 9 files changed, 492 insertions(+), 3 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index cda0d70..19c5d8f 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -331,4 +331,17 @@ button and ring events on the right. When one of the
> three mode toggle
> buttons on the right is pressed, the right mode switches to that button's
> mode but the left mode remains unchanged.
>
> +@section tablet-touch-arbitration Tablet touch arbitration
> +
> +"Touch arbitration" is the terminology used when touch events are suppressed
> +while the pen is in proximity. Since it is almost impossible to use a stylus
> +or other tool without triggering touches with the hand holding the tool,
> +touch arbitration serves to reduce the number of accidental inputs.
> +The wacom kernel driver currently provides touch arbitration but for other
> +devices arbitration has to be done in userspace.
> +
> +libinput uses the @ref libinput_device_group to decide on touch arbitration
> +and automatically discards touch events whenever a tool is in proximity.
> +The exact behavior is device-dependent.
> +
> */
> diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
> index 65b0abf..2354061 100644
> --- a/src/evdev-mt-touchpad.c
> +++ b/src/evdev-mt-touchpad.c
> @@ -1165,6 +1165,9 @@ tp_interface_process(struct evdev_dispatch *dispatch,
> struct tp_dispatch *tp =
> (struct tp_dispatch *)dispatch;
>
> + if (tp->ignore_events)
> + return;
> +
> switch (e->type) {
> case EV_ABS:
> if (tp->has_mt)
> @@ -1679,6 +1682,23 @@ evdev_tag_touchpad(struct evdev_device *device,
> }
> }
>
> +static void
> +tp_interface_toggle_touch(struct evdev_dispatch *dispatch,
> + struct evdev_device *device,
> + bool enable)
> +{
> + struct tp_dispatch *tp = (struct tp_dispatch*)dispatch;
> + bool ignore_events = !enable;
> +
> + if (ignore_events == tp->ignore_events)
> + return;
> +
> + if (ignore_events)
> + tp_clear_state(tp);
> +
> + tp->ignore_events = ignore_events;
> +}
> +
> static struct evdev_dispatch_interface tp_interface = {
> tp_interface_process,
> tp_interface_suspend,
> @@ -1689,6 +1709,7 @@ static struct evdev_dispatch_interface tp_interface = {
> tp_interface_device_removed, /* device_suspended, treat as remove */
> tp_interface_device_added, /* device_resumed, treat as add */
> NULL,/* post_added */
> + tp_interface_toggle_touch,
> };
>
> static void
> diff --git a/src/evdev-mt-touchpad.h b
Re: [PATCH libinput 6/6] tablet: add touch arbitration
The first 5 patches look fine, but I have a few questions about this
one, especially in the unit tests:
On 08/21/2016 11:14 PM, Peter Hutterer wrote:
> So far we've relied on the wacom kernel module to do touch arbitration for us
> but that won't be the case in upcoming kernels. Implement touch arbitration in
> userspace by pairing the two devices and suspending the touch device whenever
> a tool comes into proximity.
>
> In the future more sophisticated arbitration can be done (e.g. only touches
> which are close to the pen) but let's burn that bridge when we have to cross
> it.
>
> Signed-off-by: Peter Hutterer
> ---
> doc/tablet-support.dox | 12 ++
> src/evdev-mt-touchpad.c | 18 +++
> src/evdev-tablet-pad.c | 1 +
> src/evdev-tablet.c | 80 ++-
> src/evdev-tablet.h | 3 +
> src/evdev.c | 15 +++
> src/evdev.h | 4 +
> test/tablet.c | 352
>
> 8 files changed, 482 insertions(+), 3 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index cda0d70..839924b 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -331,4 +331,16 @@ button and ring events on the right. When one of the
> three mode toggle
> buttons on the right is pressed, the right mode switches to that button's
> mode but the left mode remains unchanged.
>
> +@section tablet-touch-arbitration Tablet touch arbitration
> +
> +"Touch arbitration" is the terminology used when touch events are suppressed
> +while the pen is in proximity. Since it is almost impossible to use a stylus
> +or other tool without triggering touches with the hand holding the tool,
> +touch arbitration serves to reduce the number of accidental inputs.
> +The wacom kernel driver provides touch arbitration but for other devices
> +arbitration has to be done in userspace.
> +
> +libinput uses the @ref libinput_device_group to decide on touch arbitration
> +and automatically discards touch events whenever a tool is in proximity.
> +
> */
> diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
> index 3baed09..cbcac8a 100644
> --- a/src/evdev-mt-touchpad.c
> +++ b/src/evdev-mt-touchpad.c
> @@ -1679,6 +1679,23 @@ evdev_tag_touchpad(struct evdev_device *device,
> }
> }
>
> +static void
> +tp_interface_toggle_touch(struct evdev_dispatch *dispatch,
> + struct evdev_device *device,
> + bool enable)
> +{
> + struct tp_dispatch *tp = (struct tp_dispatch*)dispatch;
> +
> + if (enable != tp->device->is_suspended)
> + return;
> +
> + if (enable)
> + tp_resume(tp, device);
> + else
> + tp_suspend(tp, device);
> +
> +}
> +
> static struct evdev_dispatch_interface tp_interface = {
> tp_interface_process,
> tp_interface_suspend,
> @@ -1689,6 +1706,7 @@ static struct evdev_dispatch_interface tp_interface = {
> tp_interface_device_removed, /* device_suspended, treat as remove */
> tp_interface_device_added, /* device_resumed, treat as add */
> NULL,/* post_added */
> + tp_interface_toggle_touch,
> };
>
> static void
> diff --git a/src/evdev-tablet-pad.c b/src/evdev-tablet-pad.c
> index 0e95408..82542bc 100644
> --- a/src/evdev-tablet-pad.c
> +++ b/src/evdev-tablet-pad.c
> @@ -512,6 +512,7 @@ static struct evdev_dispatch_interface pad_interface = {
> NULL, /* device_suspended */
> NULL, /* device_resumed */
> NULL, /* post_added */
> + NULL, /* toggle_touch */
> };
>
> static void
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 8f24555..4a2cae5 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -1422,6 +1422,39 @@ tablet_flush(struct tablet_dispatch *tablet,
> }
>
> static inline void
> +tablet_set_touch_device_enabled(struct evdev_device *touch_device,
> + bool enable)
> +{
> + struct evdev_dispatch *dispatch;
> +
> + if (touch_device == NULL)
> + return;
> +
> + dispatch = touch_device->dispatch;
> + if (dispatch->interface->toggle_touch)
> + dispatch->interface->toggle_touch(dispatch,
> + touch_device,
> + enable);
> +}
> +
> +static inline void
> +tablet_toggle_touch_device(struct tablet_dispatch *tablet,
> +struct evdev_device *tablet_device)
> +{
> + bool enable_events;
> +
> + enable_events = tablet_has_status(tablet,
> + TABLET_TOOL_OUT_OF_RANGE) ||
> + tablet_has_status(tablet, TABLET_NONE) ||
> + tablet_has_status(tablet,
> + TABLET_TOOL_LEAVING_PROXIMITY) ||
> + tablet_has_status(tablet,
> + TABLET_TOOL_OUT_OF_PROXIMIT
Re: [PATCH v2 libinput] tablet: if a serial comes in late, discard it
On 08/31/2016 11:43 PM, Peter Hutterer wrote:
> If a tool starts reporting with serial 0 and later updates to a real serial,
> discard that serial and keep reporting as serial 0. We cannot really change
> the tool after proximity in as we don't know when callers query for the serial
> (well, we could know but any well-written caller will ask for the serial on
> the proximity in event, so what's the point).
>
> Thus if we do get a serial in and the matching tool, check if we have a tool
> with the serial 0 already. If so, re-use that. This means we lose correct tool
> tracking on such tablets but so far these seem to only be on devices where the
> use of multiple tools is unlikely.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=97526
>
> Signed-off-by: Peter Hutterer
> ---
> Changes to v1:
> - change tool_list assignment to be more obvious
> - fix proximity out in the new test
>
> src/evdev-tablet.c | 27 -
> test/tablet.c | 88
> ++
> 2 files changed, 107 insertions(+), 8 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 36ff6a5..70ac0f7 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -900,13 +900,12 @@ tablet_get_tool(struct tablet_dispatch *tablet,
> uint32_t tool_id,
> uint32_t serial)
> {
> + struct libinput *libinput = tablet_libinput_context(tablet);
> struct libinput_tablet_tool *tool = NULL, *t;
> struct list *tool_list;
>
> if (serial) {
> - struct libinput *libinput = tablet_libinput_context(tablet);
> tool_list = &libinput->tool_list;
> -
> /* Check if we already have the tool in our list of tools */
> list_for_each(t, tool_list, link) {
> if (type == t->type && serial == t->serial) {
> @@ -914,20 +913,32 @@ tablet_get_tool(struct tablet_dispatch *tablet,
> break;
> }
> }
> - } else {
> + }
> +
> + /* If we get a tool with a delayed serial number, we already created
> + * a 0-serial number tool for it earlier. Re-use that, even though
> + * it means we can't distinguish this tool from others.
> + * https://bugs.freedesktop.org/show_bug.cgi?id=97526
> + */
> + if (!tool) {
> + tool_list = &tablet->tool_list;
> /* We can't guarantee that tools without serial numbers are
>* unique, so we keep them local to the tablet that they come
>* into proximity of instead of storing them in the global tool
> - * list */
> - tool_list = &tablet->tool_list;
> -
> - /* Same as above, but don't bother checking the serial number */
> - list_for_each(t, tool_list, link) {
> + * list
> + * Same as above, but don't bother checking the serial number
> + */
> + list_for_each(t, &tablet->tool_list, link) {
Nit: Just use 'tool_list' instead of '&tablet->tool_list' here?
Aside from that, for this set:
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
> if (type == t->type) {
> tool = t;
> break;
> }
> }
> +
> + /* Didn't find the tool but we have a serial. Switch
> + * tool_list back so we create in the correct list */
> + if (!tool && serial)
> + tool_list = &libinput->tool_list;
> }
>
> /* If we didn't already have the new_tool in our list of tools,
> diff --git a/test/tablet.c b/test/tablet.c
> index 7bf6ac6..abb826a 100644
> --- a/test/tablet.c
> +++ b/test/tablet.c
> @@ -2153,6 +2153,93 @@ START_TEST(tools_without_serials)
> }
> END_TEST
>
> +START_TEST(tool_delayed_serial)
> +{
> + struct litest_device *dev = litest_current_device();
> + struct libinput *li = dev->libinput;
> + struct libinput_event *event;
> + struct libinput_event_tablet_tool *tev;
> + struct libinput_tablet_tool *tool;
> + unsigned int serial;
> +
> + litest_drain_events(li);
> +
> + litest_event(dev, EV_ABS, ABS_X, 4500);
> + litest_event(dev, EV_ABS, ABS_Y, 2000);
> + litest_
Re: [PATCH libinput] tablet: don't send tip up/button release/prox out events for unknown tools
On 08/17/2016 10:20 PM, Peter Hutterer wrote:
> If the kernel does not send the MSC_SERIAL information with every event, we
> end up creating a tool with a serial of 0. When the MSC_SERIAL comes in
> later for this tool libinput will think it's a new tool. On proximity out of
> that new tool we send the required release events even though we never sent
> the proximity in/button down/tip down events.
>
> Simply ditch those events and log a bug message instead. This causes the
> first tool with serial 0 to remain in proximity/down state forever but it's a
> made-up situation anyway, let's deal with that when we have devices other
> than our own test devices triggering this.
>
Hmmm. It sounds like a tablet PC which uses one of Wacom's "AES"
sensors* might be able to trigger this. It often takes several packets
for the sensor to send a non-zero pen serial number, and continues to
report a serial until the pen leaves prox. I don't know if this
could/should be fixed in the kernel since in some cases the delay from
prox to serial can be several tenths of a second -- large enough that if
the kernel drops events until a serial is seen the user may think
something is malfunctioning.
I've attached an evemu log from an AES tablet I have handy for review.
* Examples include the Dell Venue 10 Pro 5055, HP Envy 8 Note 5000,
Lenovo ThinkPad X1 Yoga, ThinkPad Yoga 260, ThinkPad Yoga 460, etc.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
> Signed-off-by: Peter Hutterer
> ---
> src/evdev-tablet.c | 58 +++-
> src/libinput-private.h | 2 ++
> test/tablet.c | 72
> ++
> 3 files changed, 114 insertions(+), 18 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 8f24555..bc85655 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -1198,6 +1198,24 @@ tablet_mark_all_axes_changed(struct tablet_dispatch
> *tablet,
> sizeof(tablet->changed_axes));
> }
>
> +static inline bool
> +tool_was_in_proximity(struct tablet_dispatch *tablet,
> + struct libinput_tablet_tool *tool)
> +{
> + if (!tool->in_proximity) {
> + struct libinput *libinput = tablet_libinput_context(tablet);
> + log_bug_kernel(libinput,
> +"%s: prox out for tool type %d tool_id %#x
> serial %#x, "
> +"but no prox in recorded\n",
> +tablet->device->devname,
> +tool->type,
> +tool->serial,
> +tool->tool_id);
> + }
> +
> + return tool->in_proximity;
> +}
> +
> static void
> tablet_update_proximity_state(struct tablet_dispatch *tablet,
> struct evdev_device *device,
> @@ -1295,6 +1313,7 @@ tablet_send_axis_proximity_tip_down_events(struct
> tablet_dispatch *tablet,
> LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN,
> tablet->changed_axes,
> &axes);
> + tool->in_proximity = true;
> tablet_unset_status(tablet, TABLET_TOOL_ENTERING_PROXIMITY);
> tablet_unset_status(tablet, TABLET_AXES_UPDATED);
> }
> @@ -1310,12 +1329,13 @@ tablet_send_axis_proximity_tip_down_events(struct
> tablet_dispatch *tablet,
> tablet_unset_status(tablet, TABLET_TOOL_ENTERING_CONTACT);
> tablet_set_status(tablet, TABLET_TOOL_IN_CONTACT);
> } else if (tablet_has_status(tablet, TABLET_TOOL_LEAVING_CONTACT)) {
> - tablet_notify_tip(&device->base,
> - time,
> - tool,
> - LIBINPUT_TABLET_TOOL_TIP_UP,
> - tablet->changed_axes,
> - &tablet->axes);
> + if (tool_was_in_proximity(tablet, tool))
> + tablet_notify_tip(&device->base,
> + time,
> + tool,
> + LIBINPUT_TABLET_TOOL_TIP_UP,
> + tablet->changed_axes,
> + &tablet->axes);
> tablet_unset_status(tablet, TABLET_AXES_UPDATED);
> tablet_unset_status(tablet, TABLET_TOOL_LEAVING_CONTACT);
> tablet_unset_status(tablet, TABLET_TOOL_IN_CONTACT);
> @@ -1388,11 +1408,12 @@ tablet_flush(struct tablet_dispatch *tablet,
> time);
>
> if (tablet_has_status(tablet, TABLET_BUTTONS_RELEASED)) {
> - tablet_notify_buttons(tablet,
> -
Re: [PATCH wayland-protocols v5 4/4] tablet: Add pad support to the tablet protocol
On 07/11/2016 08:13 AM, Carlos Garnacho wrote: > The pad's interface is similar to the tool interface, a client is notified of > the pad after the tablet_added event. > > The pad has three functionalities: buttons, rings and strips. > Buttons are fairly straightforward, rings and strips are separate interfaces > with a pointer-axis-like source/value/frame events. > The two interfaces are effectively identical but for the actual value they > send (degrees vs normalized position). > > Buttons are sequentially indexed starting with zero, unlike other protocols > where a linux/input.h-style semantic event code is used. Since we expect all > buttons to have client-specific functionality, an additional event tells the > client when a given button index is not available, usually because the > compositor assignes some function to it (e.g. mode switching, see below). > > Specific to the pad device is the set_feedback request which enables a client > to set a user-defined string to display for an OSD on the current mappings. > This request is available for buttons, rings and strips. > > Finally, the pad supports groups, effectively sets of button/ring/strip > configurations. Those groups may have multiple modes each, so that > users/clients may map several actions to a single element. > > Signed-off-by: Carlos Garnacho > Signed-off-by: Peter Hutterer > Reviewed-by: Jason Gerecke > --- > unstable/tablet/tablet-unstable-v2.xml | 540 > + > 1 file changed, 540 insertions(+) > > diff --git a/unstable/tablet/tablet-unstable-v2.xml > b/unstable/tablet/tablet-unstable-v2.xml > index 77b185c..2cc3a92 100644 > --- a/unstable/tablet/tablet-unstable-v2.xml > +++ b/unstable/tablet/tablet-unstable-v2.xml > @@ -172,6 +172,22 @@ > > summary="the newly added tablet tool"/> > > + > + > + > + This event is sent whenever a new pad is known to the system. Typically, > + pads are physically attached to tablets and a pad_added event is > + sent immediately after the wp_tablet_seat.tablet_added. > + However, some standalone pad devices logically attach to tablets at > + runtime, and the client must wait for wp_tablet_pad.enter to know > + the tablet a pad is attached to. > + > + This event only provides the object id of the pad. All further > + features (buttons, strips, rings) are sent through the wp_tablet_pad > + interface. > + > + summary="the newly added pad"/> > + > > > > @@ -636,4 +652,528 @@ > > > > + > + > + A circular interaction area, such as the touch ring on the Wacom Intuos > + Pro series tablets. > + > + Events on a ring are logically grouped by the wl_tablet_pad_ring.frame > + event. > + > + > + > + > + Request that the compositor use the provided feedback string > + associated with this ring. This request should be issued immediately > + after a wp_tablet_pad_group.mode_switch event from the corresponding > + group is received, or whenever the ring is mapped to a different > + action. See wp_tablet_pad_group.mode_switch for more details. > + > + Clients are encouraged to provide context-aware descriptions for > + the actions associated with the ring; compositors may use this > + information to offer visual feedback about the button layout > + (eg. on-screen displays). > + > + The provided string 'description' is a UTF-8 encoded string to be > + associated with this ring, and is considered user-visible; general > + internationalization rules apply. > + > + The serial argument will be that of the last > + wp_tablet_pad_group.mode_switch event received for the group of this > + ring. Requests providing other serials than the most recent one will be > + ignored. > + > + > + > + > + > + > + > + This destroys the client's resource for this ring object. > + > + > + > + > + > + Describes the source types for ring events. This indicates to the > + client how a ring event was physically generated; a client may > + adjust the user interface accordingly. For example, events > + from a "finger" source may trigger kinetic scrolling. > + > + > + > + > + > + > + Source information for ring events. > + > + This event does not occur on its own. It is sent before a > + wp_tablet_pad_ring.frame event and carries the source information > + for all events within that fra
Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol
On 06/30/2016 05:16 AM, Jonas Ådahl wrote: > On Thu, Jun 30, 2016 at 01:10:33PM +0200, Carlos Garnacho wrote: >> Hi!, >> >> On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl wrote: >>> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote: >>>> The pad's interface is similar to the tool interface, a client is notified >>>> of >>>> the pad after the tablet_added event. >>>> >>>> The pad has three functionalities: buttons, rings and strips. >>>> Buttons are fairly straightforward, rings and strips are separate >>>> interfaces >>>> with a pointer-axis-like source/value/frame events. >>>> The two interfaces are effectively identical but for the actual value they >>>> send (degrees vs normalized position). >>>> >>>> Buttons are sequentially indexed starting with zero, unlike other protocols >>>> where a linux/input.h-style semantic event code is used. Since we expect >>>> all >>>> buttons to have client-specific functionality, an additional event tells >>>> the >>>> client when a given button index is not available, usually because the >>>> compositor assignes some function to it (e.g. mode switching, see below). >>>> >>>> Specific to the pad device is the set_feedback request which enables a >>>> client >>>> to set a user-defined string to display for an OSD on the current mappings. >>>> This request is available for buttons, rings and strips. >>>> >>>> Finally, the pad supports groups, effectively sets of button/ring/strip >>>> configurations. Those groups may have multiple modes each, so that >>>> users/clients may map several actions to a single element. >>>> >>>> Signed-off-by: Carlos Garnacho >>>> Signed-off-by: Peter Hutterer >>>> Reviewed-by: Jason Gerecke >>>> --- >>>> > > ... snip ... > >>>> + >>>> + >>>> + >>>> + Sent on wp_tablet_pad_group initialization to announce available >>>> rings. >>>> + One event is sent for each ring available on this pad group. >>>> + >>>> + This event is sent in the initial burst of events before the >>>> + wp_tablet_pad_group.done event. This event is only sent when at least >>>> + one ring is available. >>> >>> The last sentence is redundant. It already says that there'll be one >>> event per ring, thus no rings, no events. It also makes it slightly >>> unclear (by the description alone) whethere multiple rings will result >>> in multiple events. >> >> Agreed, removed. As for the last part... I guess the "One event is >> sent for each ring available..." bit makes it clear enough already? > > Yes, I think that part makes it clear. It was only the part you now > removed that made it possible to doubt the first part for a second. > >> > > ... snip ... > >>>> + >>>> + >>>> + >>>> + Notification that the mode was switched. >>>> + >>>> + A mode applies to all buttons, rings and strips in a group >>>> + simultaneously, but a client is not required to assign different >>>> actions >>>> + for each mode. For example, a client may have mode-specific button >>>> + mappings but map the ring to vertical scrolling in all modes. Mode >>>> + indices start at 0. >>>> + >>>> + Switching modes is compositor-dependent. The compositor may provide >>>> + visual cues to the client about the mode, e.g. by toggling LEDs on >>>> + the tablet device. Mode-switching may be software-controlled or >>>> + controlled by one or more physical buttons. For example, on a Wacom >>>> + Intuos Pro, the button inside the ring may be assigned to switch >>>> + between modes. >>>> + >>>> + The current mode is compositor-global, the compositor will also send >>> >>> Isn't it just seat global? And why would this event be on the pad group >>> and not on the seat wide interface? >> >> perhaps I should expand that first phrase :). >> >> The extent of the current mode is pretty much group local, it only >> affects the buttons/rings/strips that have been announced through this >> group. >> >> However, the current mode of every given gro
Re: [PATCH libinput] tablet: make the cursor/lens tool behave like a 1000dpi mouse
On 06/26/2016 09:53 PM, Peter Hutterer wrote:
> The current code tried to emulate the relative motion to be equivalent to the
> absolute motion, except in screen coordinates. This is way too slow for the
> cursor tool that we want to behave like a mouse.
>
> Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
> motion is way too fast to be usable. Scale it down to match a 1000dpi device
> instead. Since the cursor and lens tool are still high precision devices leave
> them in a flat acceleration profile without actual acceleration.
>
> For the stylus-like devices leave the current accel, pointer acceleration on a
> stylus is hard to handle.
>
> This also adds the missing bits for actually using the speed factor set
> through the config interface.
>
> Signed-off-by: Peter Hutterer
Looks good to me --
Reviewed-by: Jason Gerecke
> ---
> src/evdev-tablet.c | 19 +++--
> src/filter.c | 80
> ++
> tools/Makefile.am | 2 +-
> 3 files changed, 80 insertions(+), 21 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 395e5a0..940a1e0 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -386,22 +386,23 @@ tablet_handle_xy(struct tablet_dispatch *tablet,
> }
>
> static inline struct normalized_coords
> -tablet_process_delta(struct tablet_dispatch *tablet,
> - const struct evdev_device *device,
> - const struct device_coords *delta,
> - uint64_t time)
> +tool_process_delta(struct libinput_tablet_tool *tool,
> +const struct evdev_device *device,
> +const struct device_coords *delta,
> +uint64_t time)
> {
> struct normalized_coords accel;
>
> - /* The tablet accel code uses mm as input */
> - accel.x = 1.0 * delta->x/device->abs.absinfo_x->resolution;
> - accel.y = 1.0 * delta->y/device->abs.absinfo_y->resolution;
> + accel.x = 1.0 * delta->x;
> + accel.y = 1.0 * delta->y;
>
> if (normalized_is_zero(accel))
> return accel;
>
> return filter_dispatch(device->pointer.filter,
> -&accel, tablet, time);
> +&accel,
> +tool,
> +time);
> }
>
> static inline double
> @@ -548,7 +549,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
> axes.distance = tablet_handle_distance(tablet, device);
> axes.slider = tablet_handle_slider(tablet, device);
> axes.tilt = tablet_handle_tilt(tablet, device);
> - axes.delta = tablet_process_delta(tablet, device, &delta, time);
> + axes.delta = tool_process_delta(tool, device, &delta, time);
>
> /* We must check ROTATION_Z after TILT_X/Y so that the tilt axes are
>* already normalized and set if we have the mouse/lens tool */
> diff --git a/src/filter.c b/src/filter.c
> index cf8996d..0bb066c 100644
> --- a/src/filter.c
> +++ b/src/filter.c
> @@ -168,6 +168,8 @@ struct tablet_accelerator_flat {
>
> double factor;
> int xres, yres;
> + double xres_scale, /* 1000dpi : tablet res */
> +yres_scale; /* 1000dpi : tablet res */
> };
>
> static void
> @@ -972,17 +974,39 @@ create_pointer_accelerator_filter_flat(int dpi)
> return &filter->base;
> }
>
> -/* The tablet accel code uses mm as input */
> +static inline struct normalized_coords
> +tablet_accelerator_filter_flat_mouse(struct tablet_accelerator_flat *filter,
> + const struct normalized_coords *units)
> +{
> + struct normalized_coords accelerated;
> +
> + /*
> +The input for and output of accel methods is usually a delta in
> +1000dpi equivalents. Tablets are high res (Intuos 4 is 5080 dpi)
> +and unmodified deltas are way too high. Slow it down to the
> +equivalent of a 1000dpi mouse. The ratio of that is:
> + ratio = 1000/(resolution_per_mm * 25.4)
> +
> +i.e. on the Intuos4 it's a ratio of ~1/5.
> +
> + */
> +
> + accelerated.x = units->x * filter->xres_scale;
> + accelerated.y = units->y * filter->yres_scale;
> +
> + accelerated.x *= filter->factor;
> + accelerated.y *= filter->factor;
> +
> + return accelerated;
> +}
> +
> static struct normalized_coords
> -tablet_accelerator_filter_flat(struct motion_filter *filter,
> -const struct normalized_coords *mm,
> -
Re: [PATCH v2 libinput 00/10] pad: add a mode toggle API
On 06/14/2016 11:37 PM, Peter Hutterer wrote: > > Updated patchset adds EKR support and fixes a bunch of issues pointed out in > v1. Patch 04 is intentionally missing, that's the SVG being added which > wouldn't make it past the mailman filters. > > The branch is available on > https://github.com/whot/libinput/tree/wip/tablet-pad-modes-v2 > > One important thing of note: Benjamin and I discussed the kernel side of > things and we'll be aiming for handling the LED toggling in the kernel > through the LED class interface. This means that libinput won't need write > support to sysfs and that libinput doesn't actually have to update the mode, > merely read the changed mode. > > this also means that patch 06 and 07 will change significantly though the > public API will remain the same. once the kernel patches are on track to be > in an upstream kernel I'll update the implementation, for now we go with > this one. > > Cheers, > Peter Aside from the small comments on two of the patches, this looks good to me. Testing also seems to look good aside from the not-yet-implemented direct mode switching on my 24HD. Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput 07/10] pad: implement support for the Express Key Remote
On 06/14/2016 11:37 PM, Peter Hutterer wrote:
> Requires the newest libwacom. For distributions that want to ship libinput but
> don't have the new libwacom available: the actual minimum requirement is
> libwacom 0.17 but with that test cases will fail due to wrong button labelling
> for the EKR.
>
> Signed-off-by: Peter Hutterer
> ---
> Changes to v1:
> - new in v2
>
> configure.ac | 2 +-
> src/evdev-tablet-pad-leds.c| 131
> -
> src/evdev.c| 1 +
> src/evdev.h| 1 +
> udev/90-libinput-model-quirks.hwdb | 3 +
> 5 files changed, 134 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 8278be2..740deac 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -203,7 +203,7 @@ AC_ARG_ENABLE(libwacom,
> [use_libwacom="$enableval"],
> [use_libwacom="yes"])
> if test "x$use_libwacom" = "xyes"; then
> - PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.17], [HAVE_LIBWACOM="yes"])
> + PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.20], [HAVE_LIBWACOM="yes"])
> AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
> fi
>
> diff --git a/src/evdev-tablet-pad-leds.c b/src/evdev-tablet-pad-leds.c
> index 87fce7a..c17e70d 100644
> --- a/src/evdev-tablet-pad-leds.c
> +++ b/src/evdev-tablet-pad-leds.c
> @@ -23,6 +23,7 @@
> #include "config.h"
>
> #include
> +#include
> #include
> #include
> #include
> @@ -38,8 +39,10 @@
> struct pad_led_group {
> struct libinput_tablet_pad_mode_group base;
>
> - /* /sys/devices//wacom_led/status_led0_select */
> + /* /sys/devices//wacom_led/status_led0_select or
> + /sys/devices//wacom_remote//remote_mode on the EKR */
> int led_status_fd;
> + bool self_updating;
>
> struct list toggle_button_list;
> };
> @@ -79,6 +82,15 @@ pad_led_group_set_mode(struct pad_led_group *group,
> char buf[4] = {0};
> int rc;
>
> + /* EKR toggles the mode automatically so we just read the new mode
> + * from the fd */
> + if (group->self_updating) {
> + rc = pad_led_group_get_mode(group);
> + if (rc >= 0)
> + group->base.current_mode = rc;
> + return;
> + }
> +
> rc = snprintf(buf, sizeof(buf), "%d", mode);
> if (rc == -1)
> return;
> @@ -255,6 +267,63 @@ pad_led_get_sysfs_base_path(struct evdev_device *device,
> return rc != -1;
> }
>
> +static bool
> +pad_led_get_sysfs_ekr_path(struct evdev_device *device,
> +char *path_out,
> +size_t path_out_sz)
> +{
> + const char *hid_sysfs_path;
> + char path[PATH_MAX];
> + int rc;
> + DIR *dirp;
> + struct dirent *dp;
> + int serial = 0;
> +
> + hid_sysfs_path = pad_get_hid_sysfs_base_path(device);
> + if (hid_sysfs_path == NULL)
> + return false;
> +
> + rc = snprintf(path, sizeof(path), "%s/wacom_remote", hid_sysfs_path);
> + if (rc == -1)
> + return false;
> +
> + dirp = opendir(path);
> + if (!dirp)
> + return false;
> +
> + while ((dp = readdir(dirp)) != NULL) {
> + if (dp->d_name[0] == '.')
> + continue;
> +
> + /* There should be one entry per remote: the remote's serial
> + * in decimal notation. We always return
> + * the first we find, multiple remotes is not supported yet.
> + */
Supporting multiple EKRs is going to be very difficult given how they
work, so this is probably fine. I would only note that the statement
above doesn't quite mean what some may think. This list of remotes is a
list of *pairings* and may contain remotes which aren't actually within
communication range of the dongle. If more than one remote has ever been
paired with the dongle, this could mean problems. Of course, the list of
pairings can always be cleared by using the 'unpair_remote' sysfs command.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
> + if (safe_atoi(dp->d_name, &serial))
> + break;
> + }
> + closedir(dirp);
> +
> + if (serial == 0)
> + return false;
> +
> + rc = snprintf(path_out,
> + path_out_sz,
> + "%s/wacom_remote/%d/remote_mode",
> + hid_sysfs_path,
> + serial);
> + if (rc == -1)
> + return false;
> +
> + rc = access(path, R_OK);
> + if (rc == -1)
> + log_error(device->base.seat->libinput,
> + "Unable to access EKR LED syspath %s (%s)\n",
> + path_out,
> + strerror(errno));
> + return rc != -1;
> +}
> +
Re: [PATCH v2 libinput 05/10] pad: Add a new API for modes and mode groups
On 06/14/2016 11:37 PM, Peter Hutterer wrote: > Move mode control to libinput. This reduces some flexibility on what we can do > with modes but makes it a lot easier for anyone to implement modes correctly > and have the LEDs apply appropriately, etc. Let's go with the option to make > the 95% use-case easy. Note: whether the mode is actually used is up to the > caller, e.g. under Windows and OS X the mode only applies to the > rings/strips, not the buttons. > > A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned > to a mode group. That group has a numeric mode index and is hooked to the > LEDs. libinput will switch the LEDs accordingly. > > The mode group is a separate object. This allows for better APIs when it comes > to: > * checking whether a button/ring/strip is part of a mode group > * checking whether a button will trigger a mode transition > > and in the future potentially: > * checking which mode transition will happen > * setting which button should change the mode transition > * changing what type of mode transition should happen. > * moving a button from one mode group to the other > > This patch adds the basic scaffolding, without any real implementation. > > Signed-off-by: Peter Hutterer > Proofread-by: Yong Bakos > --- > Changes to v1: > - a bunch of typos, grammar, etc fixes as suggested > - the MODE event was removed > - I've also removed the call to fetch the target mode for a mode toggle > button. I wasn't happy with the API, couldn't come up with anything better > and since it's a niche feature anyway we can sort this if we have a direct > requirement for it > > doc/tablet-support.dox | 59 +- > src/libinput-private.h | 6 + > src/libinput.c | 127 ++ > src/libinput.h | 290 > + > src/libinput.sym | 15 +++ > test/litest.c | 3 + > tools/event-debug.c| 61 +-- > tools/event-gui.c | 1 + > 8 files changed, 550 insertions(+), 12 deletions(-) > > diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox > index c555cea..cda0d70 100644 > --- a/doc/tablet-support.dox > +++ b/doc/tablet-support.dox > @@ -240,8 +240,7 @@ tablet. > > Some buttons may have expected default behaviors. For example, on Wacom > Intuos Pro series tablets, the button inside the touch ring is expected to > -switch between a mode switch. Mode switching is a feature implemented in the > -caller and libinput does not provide specific handling. Callers should use > +switch between modes, see @ref tablet-pad-modes. Callers should use > external sources like libwacom to identify which buttons have semantic > behaviors. > > @@ -276,4 +275,60 @@ symmetric and thus do not support left-handed mode. > libinput requires > libwacom to determine if a tablet is capable of being switched to > left-handed mode. > > +@section tablet-pad-modes Tablet pad modes > + > +Tablet pad modes are virtual groupings of button, ring and strip > +functionality. A caller may assign different functionalities depending on > +the mode the tablet is in. For example, in mode 0 the touch ring may emulate > +scrolling, in mode 1 the touch ring may emulate zooming, etc. libinput > +handles the modes and mode switching but does not assign specific > +functionality to buttons, rings or strips based on the mode. It is up to the > +caller to decide whether the mode only applies to buttons, rings and strips > +or only to rings and strips (this is the case with the Wacom OS X and > +Windows driver). > + > +The availability of modes on a touchpad usually depends on visual feedback > +such as LEDs around the touch ring. If no visual feedback is available, only > +one mode may be available. > + > +Mode switching is controlled by libinput and usually toggled by one or > +more buttons on the device. For example, on the Wacom Intuos 4, 5, and > +Pro series tablets the mode button is the button centered in the touch > +ring and toggles the modes sequentially. On the Wacom Cintiq 24HD the > +three buttons next to each touch ring allow for directly changing the > +mode to the desired setting. > + > +Multiple modes may exist on the tablet, libinput uses the term "mode group" > +for such groupings of buttons that share a mode and mode toggle. For > +example, the Wacom Cintiq 24HD has two separate mode groups, one for the > +left set of buttons, strips, and touch rings and one for the right set. > +libinput handles the mode groups independently and returns the mode for each > +button as appropriate. The mode group is static for the lifetime of the > +device. > + > +@image html tablet-intuos-modes.svg "Modes on an Intuos Pro-like tablet" > + > +In the image above, the Intuos Pro-like tablet provides 4 LEDs to indicate > +the currently active modes. The button inside the touch ring cycles through > +the modes in a clockwise fashion. The upper-right LED indicates that the > +currently activ
Re: [PATCH libinput 6/7] Implement tablet pad group mode support
On Sun, Jun 5, 2016 at 11:50 PM, Peter Hutterer
wrote:
> Signed-off-by: Peter Hutterer
> ---
> configure.ac | 2 +-
> src/Makefile.am | 1 +
> src/evdev-tablet-pad-leds.c | 621
> ++
> src/evdev-tablet-pad.c| 76 +-
> src/evdev-tablet-pad.h| 12 +
> src/evdev.h | 16 ++
> src/libinput-private.h| 22 +-
> src/libinput-util.h | 1 +
> src/libinput.c| 82 +-
> tools/libinput-list-devices.c | 6 +-
> 10 files changed, 814 insertions(+), 25 deletions(-)
> create mode 100644 src/evdev-tablet-pad-leds.c
>
> diff --git a/configure.ac b/configure.ac
> index 8c14efe..8278be2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -203,7 +203,7 @@ AC_ARG_ENABLE(libwacom,
> [use_libwacom="$enableval"],
> [use_libwacom="yes"])
> if test "x$use_libwacom" = "xyes"; then
> - PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.12], [HAVE_LIBWACOM="yes"])
> + PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.17], [HAVE_LIBWACOM="yes"])
> AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
> fi
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 39c22c2..48e704a 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -22,6 +22,7 @@ libinput_la_SOURCES = \
> evdev-tablet.h \
> evdev-tablet-pad.c \
> evdev-tablet-pad.h \
> + evdev-tablet-pad-leds.c \
> filter.c\
> filter.h\
> filter-private.h\
> diff --git a/src/evdev-tablet-pad-leds.c b/src/evdev-tablet-pad-leds.c
> new file mode 100644
> index 000..4aa1590
> --- /dev/null
> +++ b/src/evdev-tablet-pad-leds.c
> @@ -0,0 +1,621 @@
> +/*
> + * Copyright © 2016 Red Hat, Inc.
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> + * its documentation for any purpose is hereby granted without fee, provided
> + * that the above copyright notice appear in all copies and that both that
> + * copyright notice and this permission notice appear in supporting
> + * documentation, and that the name of the copyright holders not be used in
> + * advertising or publicity pertaining to distribution of the software
> + * without specific, written prior permission. The copyright holders make
> + * no representations about the suitability of this software for any
> + * purpose. It is provided "as is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> + * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> + * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> + * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
> + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
> + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include "config.h"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "evdev-tablet-pad.h"
> +
> +#if HAVE_LIBWACOM
> +#include
> +#endif
> +
> +struct pad_led_group {
> + struct libinput_tablet_pad_mode_group base;
> +
> + /* /sys/devices//wacom_led/status_led0_select */
> + int led_status_fd;
> + /* /sys/devices//wacom_led/status0_luminance */
> + int led_luminance_fd;
> +
> + struct list toggle_button_list;
> +};
> +
> +struct pad_mode_toggle_button {
> + struct list link;
> + unsigned int button_index;
> + unsigned int target_mode;
> +};
> +
> +static inline void
> +pad_led_group_set_brightness(struct pad_led_group *group,
> +double brightness)
> +{
> + char buf[4] = {0};
> + int b;
> +
> + assert(brightness > 0.0);
> +
> + /* FIXME: check what the range is on all models */
> + b = 127 * brightness;
> + if (sprintf(buf, "%d", b) > -1) {
> + write(group->led_luminance_fd, buf, strlen(buf));
> + fsync(group->led_luminance_fd);
> + }
> +}
> +
> +static inline int
> +pad_led_group_get_mode(struct pad_led_group *group)
> +{
> + char buf[4] = {0};
> + int rc;
> + unsigned int mode;
> +
> + rc = read(group->led_status_fd, buf, sizeof(buf) - 1);
> + if (rc == -1)
> + return -errno;
> +
> + rc = sscanf(buf, "%u\n", &mode);
> + if (rc != 1)
> + return -EINVAL;
> +
> + return mode;
> +}
> +
> +static inline void
> +pad_led_group_set_mode(struct pad_led_group *group,
> + unsigned int mode)
> +{
> + char buf[4] = {0};
> + int rc;
> +
> + rc = sprintf(buf, "%d", mode);
> + if (rc == -1)
> + return;
> +
> + rc = write(group->led
Re: [PATCH libinput 5/7] pad: Add a new API for modes and mode groups
On Sun, Jun 5, 2016 at 11:50 PM, Peter Hutterer wrote: > Move mode control to libinput. This reduces some flexibility on what we can do > with modes but makes it a lot easier for anyone to implement modes correctly > and have the LEDs apply appropriately, etc. Let's go with the option to make > the 95% use-case easy. Note: whether the mode is actually used is up to the > caller, e.g. under Windows and OS X the mode only applies to the > rings/strips, not the buttons. > > A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned > to a mode group. That group has a numeric mode index and is hooked to the > LEDs. libinput will switch the LEDs accordingly. > > The mode group is a separate object. This allows for better APIs when it comes > to: > * checking whether a button/ring/strip is part of a mode group > * checking whether a button will trigger a mode transition > * checking which mode transition will happen > > and in the future potentially: > * setting which button should change the mode transition > * changing what type of mode transition should happen. > * moving a button from one mode group to the other > > This patch adds the basic scaffolding, without any real implementation. > > Signed-off-by: Peter Hutterer > --- > doc/tablet-support.dox | 59 - > src/libinput-private.h | 6 + > src/libinput.c | 128 +++ > src/libinput.h | 324 > + > src/libinput.sym | 16 +++ > test/litest.c | 3 + > tools/event-debug.c| 61 -- > tools/event-gui.c | 1 + > 8 files changed, 586 insertions(+), 12 deletions(-) > > diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox > index c555cea..b7267a8 100644 > --- a/doc/tablet-support.dox > +++ b/doc/tablet-support.dox > @@ -240,8 +240,7 @@ tablet. > > Some buttons may have expected default behaviors. For example, on Wacom > Intuos Pro series tablets, the button inside the touch ring is expected to > -switch between a mode switch. Mode switching is a feature implemented in the > -caller and libinput does not provide specific handling. Callers should use > +switch between a mode switch, see @ref tablet-pad-modes. Callers should use This was an issue in the prior version but "switch between a mode switch" doesn't really make sense. Perhaps "switch between modes" would be clearer? > external sources like libwacom to identify which buttons have semantic > behaviors. > > @@ -276,4 +275,60 @@ symmetric and thus do not support left-handed mode. > libinput requires > libwacom to determine if a tablet is capable of being switched to > left-handed mode. > > +@section tablet-pad-modes Tablet pad modes > + > +Tablet pad modes are virtual groupings of button, ring and strip > +functionality. A caller may assign different functionalities depending on > +the mode the tablet is in. For example, in mode 0 the touch ring may emulate > +scrolling, in mode 1 the touch ring may emulate zooming, etc. libinput > +handles the modes and mode switching but does not assign specific > +functionality to buttons, rings or strips based on the mode. It is up to the > +caller to decide whether the mode only applies to buttons, rings and strips > +or only to rings and strips (this is the case with the Wacom OS X and > +Windows driver). > + > +The availability of modes on a touchpad usually depends on visual feedback > +such as LEDs around the touch ring. If no visual feedback is available, only > +one mode may be available. > + > +Mode switching is controlled by libinput and usually toggled by one or > +more buttons on the device. For example, on the Wacom Intuos 4, 5, and > +Pro series tablets the mode button is the button centered in the touch > +ring and toggles the modes sequentially. On the Wacom Cintiq 24HD the > +three buttons next to each touch ring allow for directly changing the > +mode to the desired setting. > + > +Multiple modes may exist on the tablet, libinput uses the term "mode group" > +for such groupings of buttons that share a mode and mode toggle. For > +example, the Wacom Cintiq 24HD has two separate mode groups, one for the > +left set of buttons, strips, and touch rings and one for the right set. > +libinput handles the mode groups independently and returns the mode for each > +button as appropriate. The mode group is static for the lifetime of the > +device. > + > +@image html tablet-intuos-modes.svg "Modes on an Intuos Pro-like tablet" > + > +In the image above, the Intuos Pro-like tablet provides 4 LEDs to indicate > +the currently active modes. The button inside the touch ring cycles through > +the modes in a clockwise fashion. The upper-right LED indicates that the > +currently active mode is 1, based on 0-indexed mode numbering. > +libinput_event_tablet_pad_get_mode() would thus return 1 for all button and > +ring events on this tablet. When the center button is pressed, the mode > +switches to mode 2, the LED ch
Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol
On 05/17/2016 03:02 AM, Carlos Garnacho wrote: > Hey :), > > On Tue, May 17, 2016 at 2:50 AM, Peter Hutterer > wrote: >> On Tue, May 17, 2016 at 01:30:03AM +0200, Carlos Garnacho wrote: >>> Hey :), >>> >>> On Wed, May 11, 2016 at 4:51 AM, Peter Hutterer >>> wrote: From: Carlos Garnacho The pad's interface is similar to the tool interface, a client is notified of the pad after the tablet_added event. The pad has three functionalities: buttons, rings and strips. Buttons are fairly straightforward, rings and strips are separate interfaces with a pointer-axis-like source/value/frame events. The two interfaces are effectively identical but for the actual value they send (degrees vs normalized position). Buttons are sequentially indexed starting with zero, unlike other protocols where a linux/input.h-style semantic event code is used. Since we expect all buttons to have client-specific functionality, an additional event tells the client when a given button index is not available, usually because the compositor assignes some function to it (e.g. mode switching, see below). Specific to the pad device is the set_feedback request which enables a client to set a user-defined string to display for an OSD on the current mappings. This request is available for buttons, rings and strips. Finally, the pad supports "modes", effectively sets of button/ring/strip configurations. Signed-off-by: Carlos Garnacho Signed-off-by: Peter Hutterer --- Changes to v2: - change to v2 of the protocol - various comments and suggestions for improved wording incorporated - ring is in wl_fixed degrees now (was int, in 0.01 of a degree) - button events changed to sequential indices - new buttons_reserved event unstable/tablet/tablet-unstable-v2.xml | 436 + 1 file changed, 436 insertions(+) >> >> .. >> + + + Sent on wp_tablet_pad initialization and/or at a later time to notify the + client of reserved buttons. + + Compositors may consume some buttons for global actions, those + global actions will not trigger wl_tablet_pad.button events (e.g. + the button to switch between modes, if any). This event notifies the + client that some button indices are reserved by the compositor and + will not generate events visible to the client. Button indices start + at 0. + + This event may is sent in the initial burst of events before the + wp_tablet_pad.done event and/or at any later time when the + compositor changes the list of reserved buttons. This event is only + sent when the compositor reserves at least one button. + + + + + >>> >>> After some hands-on experience, I see this API in libwacom: >>> >>> int libwacom_get_ring_num_modes(const WacomDevice *device); >>> int libwacom_get_ring2_num_modes(const WacomDevice *device); >>> int libwacom_get_strips_num_modes(const WacomDevice *device); >>> >>> This makes me think, are there devices with more than one of these >>> modes? In that case I guess would be better to move .modes and .mode >>> to wp_tablet_pad_ring/strip than exposing the NxM combinations here. I >>> guess it also means renouncing to making these modes affect anything >>> else than the ring/strip. >>> >>> If we move these events there, I wonder if we better add .done events >>> there too, or it suffices with wp_tablet_pad.done. I'd expect all >>> device characteristics to be announced before wp_tablet_pad.done >>> anyway. >> >> the only device that had two rings and modes was the 24HD and both had 4 >> modes iirc. that device isn't on sale anymore and given the current gen of >> wacom tablets I doubt it comes back. >> 3 modes on each side, actually :) >> however, the 22hd has two touch strips at the back and two mode switch >> buttons. I don't think there's much of a use-case for having different >> numbers of modes but having the modes switch independently is certainly >> something we should support. >> The chances of a device having multiple mode switches with a different number of modes is pretty low. The reason has to do with why some devices have a second set of buttons/rings/switches in the first place: left-handed users. While it's trivial enough to rotate an Intuos around so the pad controls are under the users's non-dominant hand, that's not the case with the Cintiqs. To address this, a mirror-image set of pad controls is present to make things equally accessible to either hand. There's basically zero chance that a tablet would have a different number of modes on its two mirrored halves. More likely is a device that doesn't have a mirrored layout but
Re: [PATCH wayland-protocols 0/4] tablet: switch to v2, add tablet pad
On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer wrote: > > The switch to v2 is needed primarily for the ABI break when we go from ints > to fixed for any rotational values. Patch 3/4 restricts the role a surface > can play when assigned as tool cursor, specifically we now only allow a > cursor surface to be assigned to one tool rather than shared across > multiple. This is slightly more work in the client but better defined and > managable in the compositor. See the patch for a detailed explanation. > > The last patch adds the pad interface, mostly the same as last time but > rebased onto v2 and with a couple of small additions. > > Cheers, > Peter > Aside from my minor comments, these look good to me :) Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol
On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer wrote: > From: Carlos Garnacho > > The pad's interface is similar to the tool interface, a client is notified of > the pad after the tablet_added event. > > The pad has three functionalities: buttons, rings and strips. > Buttons are fairly straightforward, rings and strips are separate interfaces > with a pointer-axis-like source/value/frame events. > The two interfaces are effectively identical but for the actual value they > send (degrees vs normalized position). > > Buttons are sequentially indexed starting with zero, unlike other protocols > where a linux/input.h-style semantic event code is used. Since we expect all > buttons to have client-specific functionality, an additional event tells the > client when a given button index is not available, usually because the > compositor assignes some function to it (e.g. mode switching, see below). > > Specific to the pad device is the set_feedback request which enables a client > to set a user-defined string to display for an OSD on the current mappings. > This request is available for buttons, rings and strips. > > Finally, the pad supports "modes", effectively sets of button/ring/strip > configurations. > > Signed-off-by: Carlos Garnacho > Signed-off-by: Peter Hutterer > --- > Changes to v2: > - change to v2 of the protocol > - various comments and suggestions for improved wording incorporated > - ring is in wl_fixed degrees now (was int, in 0.01 of a degree) > - button events changed to sequential indices > - new buttons_reserved event > > unstable/tablet/tablet-unstable-v2.xml | 436 > + > 1 file changed, 436 insertions(+) > > diff --git a/unstable/tablet/tablet-unstable-v2.xml > b/unstable/tablet/tablet-unstable-v2.xml > index d3f57ff..388b4d2 100644 > --- a/unstable/tablet/tablet-unstable-v2.xml > +++ b/unstable/tablet/tablet-unstable-v2.xml > @@ -172,6 +172,22 @@ > > summary="the newly added tablet tool"/> > > + > + > + > + This event is sent whenever a new pad is known to the system. > Typically, > + pads are physically attached to tablets and a pad_added event is > + sent immediately after the wp_tablet_seat.tablet_added. > + However, some standalone pad devices logically attach to tablets at > + runtime, and the client must wait for wp_tablet_pad.enter to know > + the tablet a pad is attached to. > + > + This event only provides the object id of the pad; and all further > + features (buttons, strips, rings) are sent through the wp_tablet_pad > + interface. > + > + summary="the newly added pad"/> > + > > > > @@ -636,4 +652,424 @@ > > > > + > + > + A circular interaction area. > + > + Events on a ring are logically grouped by the wl_tablet_pad_ring.frame > + event. > + > + > + > + > + Request that the compositor use the provided feedback string > + associated with this ring. This request should be issued immediately > + after a wp_tablet_pad.enter, or whenever the ring is mapped to a > + different action. > + > + Clients are encouraged to provide context-aware descriptions for > + the actions associated with the ring; compositors may use this > + information to offer visual feedback about the button layout > + (eg. on-screen displays). > + > + The provided string 'description' is an UTF-8 encoded string to be > + associated with this ring, and is considered user visible; general > + internationalization rules apply. > + > + > + > + > + > + > + This destroys the client's resource for this ring object. > + > + > + > + > + > + Describes the source types for ring events. This indicates to the > + client how a ring event was physically generated; a client may > + adjust the user interface accordingly. For example, events > + from a "finger" source may trigger kinetic scrolling. > + > + > + > + > + > + > + Source information for ring events. > + > + This event does not occur on its own. It is sent before a > + wp_tablet_pad_ring.frame event and carries the source information > + for all events within that frame. > + > + The source specifies how this event was generated. If the source is > + wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event > + will be sent when the user lifts the finger off the device. > + > + This event is optional. If the source is unknown for an interaction, > + no event is sent. > + > + > + > + > + > + > + Sent whenever the angle on a ring changes. > + > + The angle is provided in degrees clockwise from the logical > + north of the ring in the pad's current rotation. > + > + > + > + > + > + > +
Re: [PATCH wayland-protocols 3/4] tablet: restrict the cursor surface to one per tool
On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer wrote: > The initial approach was to allow one surface to be re-used between tools, > seats and even used together as wl_pointer cursor surface. This has a few > drawbacks, most of which are related to managing the surface correctly in the > compositor. For example, the same cursor surface could have two different > hotspots. Animated cursors should animate independently rather than update at > the same time. > > Furthermore: a client cannot know when a surface will cease being used as a > cursor surface. The basic assumption of "after focus out" is an implementation > detail in the compositor and unless the client unsets the cursor it is not > guaranteed that the surface is released. This again makes sharing a surface > less obvious - you cannot know if the wl_pointer surface is still in use when > you set it for a new wp_tablet_tool. > > Avoid these headaches (and push some of them to the clientl) by simply > restricting a wl_surface to be assigned to a single tool. For the 99% use case > where we have one tablet with two tools (pen + eraser) this means we merely > get two extra surfaces, and the two don't usually share the same cursor shape > anyway. If sharing is absolutely, a client may still opt to share the > underlying wl_buffer. > > Signed-off-by: Peter Hutterer > --- > unstable/tablet/tablet-unstable-v2.xml | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/unstable/tablet/tablet-unstable-v2.xml > b/unstable/tablet/tablet-unstable-v2.xml > index e7b8626..d3f57ff 100644 > --- a/unstable/tablet/tablet-unstable-v2.xml > +++ b/unstable/tablet/tablet-unstable-v2.xml > @@ -225,13 +225,11 @@ > and pending input regions become undefined, and the wl_surface is > unmapped. > > - This request gives the surface the role of a cursor. The role > - assigned by this request is the same as assigned by > - wl_pointer.set_cursor meaning the same surface can be > - used both as a wl_pointer cursor and a wp_tablet cursor. If the > - surface already has another role, it raises a protocol error. > - The surface may be used on multiple tablets and across multiple > - seats. > + This request gives the surface the role of a wp_tablet_tool cursor. A > + surface may only ever be used as cursor surface for one A surface may only ever be used as "the" cursor surface Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > + wp_tablet_tool. If the surface already has another role or has > + previously been used as cursor surface for a different tool, a > + protocol error is raised. > > > allow-null="true"/> > -- > 2.7.4 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] tablet: fix distance normalization range after 25a9f39
On Mon, Apr 25, 2016 at 7:22 PM, Peter Hutterer
wrote:
> 25a9f39 changed the range to [-1, 1] but that's incorrect for the distance
> values. Split the normalization up into two functions and make sure our
> distance range is correct.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=95074
>
> And while we're at it, sneak in a test for pressure ranges too.
>
> Signed-off-by: Peter Hutterer
Looks good to me --
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> ---
> src/evdev-tablet.c | 15 +---
> test/tablet.c | 68
> ++
> 2 files changed, 80 insertions(+), 3 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 5262230..4e8b920 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -231,7 +231,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
> }
>
> static inline double
> -normalize_dist_slider(const struct input_absinfo *absinfo)
> +normalize_slider(const struct input_absinfo *absinfo)
> {
> double range = absinfo->maximum - absinfo->minimum;
> double value = (absinfo->value - absinfo->minimum) / range;
> @@ -240,6 +240,15 @@ normalize_dist_slider(const struct input_absinfo
> *absinfo)
> }
>
> static inline double
> +normalize_distance(const struct input_absinfo *absinfo)
> +{
> + double range = absinfo->maximum - absinfo->minimum;
> + double value = (absinfo->value - absinfo->minimum) / range;
> +
> + return value;
> +}
> +
> +static inline double
> normalize_pressure(const struct input_absinfo *absinfo,
>struct libinput_tablet_tool *tool)
> {
> @@ -420,7 +429,7 @@ tablet_handle_distance(struct tablet_dispatch *tablet,
> if (bit_is_set(tablet->changed_axes,
>LIBINPUT_TABLET_TOOL_AXIS_DISTANCE)) {
> absinfo = libevdev_get_abs_info(device->evdev, ABS_DISTANCE);
> - tablet->axes.distance = normalize_dist_slider(absinfo);
> + tablet->axes.distance = normalize_distance(absinfo);
> }
>
> return tablet->axes.distance;
> @@ -435,7 +444,7 @@ tablet_handle_slider(struct tablet_dispatch *tablet,
> if (bit_is_set(tablet->changed_axes,
>LIBINPUT_TABLET_TOOL_AXIS_SLIDER)) {
> absinfo = libevdev_get_abs_info(device->evdev, ABS_WHEEL);
> - tablet->axes.slider = normalize_dist_slider(absinfo);
> + tablet->axes.slider = normalize_slider(absinfo);
> }
>
> return tablet->axes.slider;
> diff --git a/test/tablet.c b/test/tablet.c
> index a44f63b..e30705b 100644
> --- a/test/tablet.c
> +++ b/test/tablet.c
> @@ -3106,6 +3106,39 @@ static void pressure_threshold_warning(struct libinput
> *libinput,
> (*warning_triggered)++;
> }
>
> +START_TEST(tablet_pressure_range)
> +{
> + struct litest_device *dev = litest_current_device();
> + struct libinput *li = dev->libinput;
> + struct libinput_event *event;
> + struct libinput_event_tablet_tool *tev;
> + struct axis_replacement axes[] = {
> + { ABS_DISTANCE, 0 },
> + { ABS_PRESSURE, 10 },
> + { -1, -1 },
> + };
> + int pressure;
> + double p;
> +
> + litest_tablet_proximity_in(dev, 5, 100, axes);
> + litest_drain_events(li);
> + libinput_dispatch(li);
> +
> + for (pressure = 1; pressure <= 100; pressure += 10) {
> + litest_axis_set_value(axes, ABS_PRESSURE, pressure);
> + litest_tablet_motion(dev, 70, 70, axes);
> + libinput_dispatch(li);
> +
> + event = libinput_get_event(li);
> + tev = litest_is_tablet_event(event,
> LIBINPUT_EVENT_TABLET_TOOL_AXIS);
> + p = libinput_event_tablet_tool_get_pressure(tev);
> + ck_assert_double_ge(p, 0.0);
> + ck_assert_double_le(p, 1.0);
> + libinput_event_destroy(event);
> + }
> +}
> +END_TEST
> +
> START_TEST(tablet_pressure_offset_exceed_threshold)
> {
> struct litest_device *dev = litest_current_device();
> @@ -3212,6 +3245,39 @@
> START_TEST(tablet_pressure_offset_none_for_small_distance)
> }
> END_TEST
>
> +START_TEST(tablet_distance_range)
> +{
> + struct litest_device *dev = litest_curren
Re: [PATCH v2 wayland-protocols] Add pad support to the tablet protocol
On Thu, Apr 21, 2016 at 7:02 PM, Peter Hutterer wrote: > On Thu, Apr 21, 2016 at 05:46:24PM -0700, Jason Gerecke wrote: >> On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer >> wrote: >> > From: Carlos Garnacho >> > >> > The pad's interface is similar to the tool interface, a client is notified >> > of >> > the pad after the tablet_added event. >> > >> > The pad has three functionalities: buttons, rings and strips. >> > Buttons are fairly straightforward, rings and strips are separate >> > interfaces >> > with a pointer-axis-like source/value/frame events. >> > The two interfaces are effectively identical but for the actual value they >> > send (degrees vs normalized position). >> > >> > Specific to the pad device is the set_feedback request which enables a >> > client >> > to set a user-defined string to display for an OSD on the current mappings. >> > This request is available for buttons, rings and strips. >> > >> > Finally, the pad supports "modes", effectively sets of button/ring/strip >> > configurations. >> > >> > Signed-off-by: Carlos Garnacho >> > Signed-off-by: Peter Hutterer >> > --- >> > Changes to v1: >> > - typos fixed >> > >> > unstable/tablet/tablet-unstable-v1.xml | 423 >> > - >> > 1 file changed, 421 insertions(+), 2 deletions(-) >> > >> > diff --git a/unstable/tablet/tablet-unstable-v1.xml >> > b/unstable/tablet/tablet-unstable-v1.xml >> > index 907126c..36b9ae8 100644 >> > --- a/unstable/tablet/tablet-unstable-v1.xml >> > +++ b/unstable/tablet/tablet-unstable-v1.xml >> > @@ -115,7 +115,7 @@ >> > interface version number is reset. >> > >> > >> > - >> > + >> > >> >An object that provides access to the graphics tablets available on >> > this >> >system. All tablets are associated with a seat, to get access to the >> > @@ -139,7 +139,7 @@ >> > >> > >> > >> > - >> > + >> > >> >An object that provides access to the graphics tablets available on >> > this >> >seat. After binding to this interface, the compositor sends a set of >> > @@ -172,6 +172,23 @@ >> > >> >> > summary="the newly added tablet tool"/> >> > >> > + >> > + >> > + >> > + >> > + >> > + This event is sent whenever a new pad is known to the system. >> > Typically, >> > + pads are physically attached to tablets and a pad_added event is >> > + sent immediately after the wp_tablet_seat.tablet_added. >> > + However, some standalone pad devices logically attach to tablets at >> > + runtime, the client must wait for wp_tablet_pad.enter to know the >> > + tablet a pad is attached to. >> > + >> >> If a compositor wanted to support "bare" pad devices, I'm assuming >> they'd have to fake one or more wp_tablet objects for that use, >> correct? > > yeah, I think so. but there is the question of what a standalone pad (I > assume you're talking about the EKR) would do in a wacom/tablet context? > and whether the EKR would just be better off as a buttonset device when it's > not connected to a tablet. > Ah, I had forgotten about that. Exposing it (yeah, talking about the EKR) as a buttonset when there's no tablet to connect to seems reasonable as well, but I wonder if clients really care to support both interfaces and (somehow) synchronize preferences between pad-as-a-buttonset and pad-as-a-tablet. That's probably my general discomfort with pad-as-a-tablet showing again though... >> > + >> > + >> > + Source information for ring events. >> > + >> > + This event does not occur on its own. It is sent before a >> > + wp_tablet_pad_ring.frame event and carries the source information >> > + for all events within that frame. >> > + >> > + The source specifies how this event was generated. If the source is >> > + wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event >> > + will be sent when the user lifts the finger off the device. >> > + >> > + This event is optional. If the source is unknown for an >&
Re: [PATCH v2 wayland-protocols] Add pad support to the tablet protocol
On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer wrote: > From: Carlos Garnacho > > The pad's interface is similar to the tool interface, a client is notified of > the pad after the tablet_added event. > > The pad has three functionalities: buttons, rings and strips. > Buttons are fairly straightforward, rings and strips are separate interfaces > with a pointer-axis-like source/value/frame events. > The two interfaces are effectively identical but for the actual value they > send (degrees vs normalized position). > > Specific to the pad device is the set_feedback request which enables a client > to set a user-defined string to display for an OSD on the current mappings. > This request is available for buttons, rings and strips. > > Finally, the pad supports "modes", effectively sets of button/ring/strip > configurations. > > Signed-off-by: Carlos Garnacho > Signed-off-by: Peter Hutterer > --- > Changes to v1: > - typos fixed > > unstable/tablet/tablet-unstable-v1.xml | 423 > - > 1 file changed, 421 insertions(+), 2 deletions(-) > > diff --git a/unstable/tablet/tablet-unstable-v1.xml > b/unstable/tablet/tablet-unstable-v1.xml > index 907126c..36b9ae8 100644 > --- a/unstable/tablet/tablet-unstable-v1.xml > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -115,7 +115,7 @@ > interface version number is reset. > > > - > + > >An object that provides access to the graphics tablets available on > this >system. All tablets are associated with a seat, to get access to the > @@ -139,7 +139,7 @@ > > > > - > + > >An object that provides access to the graphics tablets available on > this >seat. After binding to this interface, the compositor sends a set of > @@ -172,6 +172,23 @@ > > summary="the newly added tablet tool"/> > > + > + > + > + > + > + This event is sent whenever a new pad is known to the system. > Typically, > + pads are physically attached to tablets and a pad_added event is > + sent immediately after the wp_tablet_seat.tablet_added. > + However, some standalone pad devices logically attach to tablets at > + runtime, the client must wait for wp_tablet_pad.enter to know the > + tablet a pad is attached to. > + If a compositor wanted to support "bare" pad devices, I'm assuming they'd have to fake one or more wp_tablet objects for that use, correct? > + This event only provides the object id of the pad, any further > features > + (buttons, strips, rings) is sent through the wp_tablet_pad interface. > + > + summary="the newly added pad"/> > + > > > > @@ -638,4 +655,406 @@ > > > > + > + > + A circular interaction area. > + > + Events on a ring are logically grouped by the wl_tablet_pad_ring.frame > + event. > + > + > + > + > + Requests the compositor to use the provided feedback UTF-8 encoded > + string associated with this ring. > + > + Clients are encouraged to provide context-aware descriptions for > + the actions associated with the ring, compositors may use this > + information to offer visual feedback about the button layout > + (eg. on-screen displays). > + > + The string offered is considered user visible; general > + internationalization rules apply. > + > + This request should be issued immediately after a > + wp_tablet_pad.enter, or whenever the ring is mapped to a different > + action. > + > + > + > + > + > + > + This destroys the client's resource for this ring object. > + > + > + > + > + > + Describes the source types for ring events. This indicates to the > + client how a ring event was physically generated; a client may > + adjust the user interface accordingly. For example, events > + from a "finger" source may trigger kinetic scrolling. > + > + > + > + > + > + > + Source information for ring events. > + > + This event does not occur on its own. It is sent before a > + wp_tablet_pad_ring.frame event and carries the source information > + for all events within that frame. > + > + The source specifies how this event was generated. If the source is > + wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event > + will be sent when the user lifts the finger off the device. > + > + This event is optional. If the source is unknown for an interaction, > + no event is sent. > + > + > + > + > + > + > + Sent whenever the angle on a ring changes. > + > + The angle is provided in 0.01 of a degree clockwise from the logical > + north of the ring in the pad's current rotation. > + > + I assume this will be updated to use the "fixed" type (along with pen tilt an
Re: [PATCH v2 libinput 0/5] Add tablet pad support
On 04/10/2016 09:15 PM, Peter Hutterer wrote: > > Second version of the tablet pad support patches. The main change is > switching from button codes to simple button numbers. This is motivated > by the fact that most buttons don't have any actual meaning and the only > reason we have something other than BTN_0, BTN_1 etc is that we run out of > space in the kernel's event code range. What a button does is defined > largely by the client anyway. > > This also caused the removal of the seat button count and a change from > libinput_event_tablet_pad_get_button() to the more explicitly named > libinput_event_tablet_pad_get_button_number(). Just to drive the point home. > > Cheers, > Peter Just a few small issues highlighted in their respective patches (esp. in patch 4), but nothing that I think is beyond a pre-push fixup. Reviewed-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput 2/5] Add the LIBINPUT_DEVICE_CAP_TABLET_PAD capability and matching interface
On 04/10/2016 09:15 PM, Peter Hutterer wrote: > This interface handles the buttons on the physical tablet itself, including > the touch ring and the strip. > > A notable difference to other libinput interfaces here is that we do not use > linux/input.h event codes for buttons. Instead, the buttons are merely > numbered sequentially, starting at button 1. This means: > * the API is different, instead of get_button() we have get_button_number() to > drive the point home > * there is no seat button count. pads are inherently different devices and > compositors should treat them as such. The seat button count makes sense > when you want to know how many devices have BTN_LEFT down, but it makes no > sense for buttons where all the semantics are handled by the compositor > anyway. > > Signed-off-by: Peter Hutterer > --- > Changes to v1: > - squashed left-handed patch (previously separate) into this one > - change from linux/input.h-style button numbering to simple sequential > numbers > - dropped the seat button count bits > > doc/tablet-support.dox | 31 - > src/libinput-private.h | 18 +++ > src/libinput.c | 257 > src/libinput.h | 313 > - > src/libinput.sym | 19 +++ > test/litest.c | 9 ++ > tools/event-debug.c| 81 + > tools/event-gui.c | 4 + > 8 files changed, 729 insertions(+), 3 deletions(-) > > diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox > index 35b9230..8bfdf58 100644 > --- a/doc/tablet-support.dox > +++ b/doc/tablet-support.dox > @@ -8,7 +8,7 @@ Apple iPad. > > @image html tablet.svg "Illustration of a graphics tablet" > > -@section tablet-tools Tablet buttons vs. tablet tools > +@section tablet-tools Pad buttons vs. tablet tools > > Most tablets provide two types of devices. The pysical tablet often provides > a number of buttons and a touch ring or strip. Interaction on the drawing > @@ -17,6 +17,12 @@ The libinput interface exposed by devices with the @ref > LIBINPUT_DEVICE_CAP_TABLET_TOOL capability applies only to events generated > by tools. > > +Buttons, rings or strips on the physical tablet hardware (the "pad") are > +exposed by devices with the @ref LIBINPUT_DEVICE_CAP_TABLET_PAD capability. > +Pad events do not require a tool to be in proximity. Note that both > +capabilities may exist on the same device though usually they are split > +across multiple kernel devices. > + > Touch events on the tablet integrated into a screen itself are exposed > through the @ref LIBINPUT_DEVICE_CAP_TOUCH capability. Touch events on a > standalone tablet are exposed through the @ref LIBINPUT_DEVICE_CAP_POINTER > @@ -25,7 +31,7 @@ node for the touch device, resulting in a separate libinput > device. > See libinput_device_get_device_group() for information on how to associate > the touch part with other devices exposed by the same physical hardware. > > -@section tablet-tip Tool tip events vs. button events > +@section tablet-tip Tool tip events vs. tool button events > > The primary use of a tablet tool is to draw on the surface of the tablet. > When the tool tip comes into contact with the surface, libinput sends an > @@ -113,6 +119,8 @@ tablets however extends further than the user may lift > the mouse, i.e. the > tool may not be lifted out of physical proximity. For such tools, libinput > provides software-emulated proximity. > > +Events from the pad do not require proximity, they may be sent any time. > + > @section tablet-pressure-offset Pressure offset on worn-out tools > > When a tool is used for an extended period it can wear down physically. A > @@ -209,4 +217,23 @@ libinput_event_tablet_tool_get_y_transformed() the > resulting value may be > less than 0 or larger than the upper range provided. It is up to the caller > to test for this and handle or ignore these events accordingly. > > +@section tablet-pad-buttons Tablet pad button numbers > + > +Tablet Pad buttons are numbered sequentially, starting with button 0. Thus > +button numbers returned by libinput_event_tablet_pad_get_button_number() > +have no semantic meaning, a notable difference to the button codes returned > +by other libinput interfaces (e.g. libinput_event_tablet_tool_get_button()). > + > +The Linux kernel requires all input events to have semantic event codes, > +but generic buttons like those on a pad cannot easily be assigned semantic > +codes. The kernel supports generic codes in the form of BTN_0 through to > +BTN_9 and additional unnamed space up until code 0x10f. Additional generic > +buttons are available as BTN_A in the range dedicated for gamepads and > +joysticks. Thus, tablet with a large number of buttons have to map across > +two semantic ranges, have to use unnamed kernel button codes or risk leaking > +into an unrelated range. libinput transparently maps the kernel event codes > +into a se
Re: [PATCH v2 libinput 4/5] pad: implement wacom pad support
On 04/10/2016 09:15 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> Adjustments for the new API in 2/5
>
> src/Makefile.am| 1 +
> src/evdev-tablet-pad.c | 614
> +
> src/evdev-tablet-pad.h | 69 ++
> src/evdev.c| 28 ++-
> src/evdev.h| 13 ++
> src/libinput.c | 6 +-
> 6 files changed, 716 insertions(+), 15 deletions(-)
> create mode 100644 src/evdev-tablet-pad.c
> create mode 100644 src/evdev-tablet-pad.h
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 343e75c..a3df6c8 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -20,6 +20,7 @@ libinput_la_SOURCES = \
> evdev-mt-touchpad-gestures.c\
> evdev-tablet.c \
> evdev-tablet.h \
> + evdev-tablet-pad.c \
> filter.c\
> filter.h\
> filter-private.h\
> diff --git a/src/evdev-tablet-pad.c b/src/evdev-tablet-pad.c
> new file mode 100644
> index 000..8c64830
> --- /dev/null
> +++ b/src/evdev-tablet-pad.c
> @@ -0,0 +1,614 @@
> +/*
> + * Copyright © 2016 Red Hat, Inc.
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> + * its documentation for any purpose is hereby granted without fee, provided
> + * that the above copyright notice appear in all copies and that both that
> + * copyright notice and this permission notice appear in supporting
> + * documentation, and that the name of the copyright holders not be used in
> + * advertising or publicity pertaining to distribution of the software
> + * without specific, written prior permission. The copyright holders make
> + * no representations about the suitability of this software for any
> + * purpose. It is provided "as is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> + * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> + * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> + * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
> + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
> + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include "config.h"
> +#include "evdev-tablet-pad.h"
> +
> +#include
> +#include
> +#include
> +
> +#define pad_set_status(pad_,s_) (pad_)->status |= (s_)
> +#define pad_unset_status(pad_,s_) (pad_)->status &= ~(s_)
> +#define pad_has_status(pad_,s_) (!!((pad_)->status & (s_)))
> +
> +static void
> +pad_get_buttons_pressed(struct pad_dispatch *pad,
> + struct button_state *buttons)
> +{
> + struct button_state *state = &pad->button_state;
> + struct button_state *prev_state = &pad->prev_button_state;
> + unsigned int i;
> +
> + for (i = 0; i < sizeof(buttons->bits); i++)
> + buttons->bits[i] = state->bits[i] & ~(prev_state->bits[i]);
> +}
> +
> +static void
> +pad_get_buttons_released(struct pad_dispatch *pad,
> + struct button_state *buttons)
> +{
> + struct button_state *state = &pad->button_state;
> + struct button_state *prev_state = &pad->prev_button_state;
> + unsigned int i;
> +
> + for (i = 0; i < sizeof(buttons->bits); i++)
> + buttons->bits[i] = prev_state->bits[i] & ~(state->bits[i]);
> +}
> +
> +static inline bool
> +pad_button_is_down(const struct pad_dispatch *pad,
> +uint32_t button)
> +{
> + return bit_is_set(pad->button_state.bits, button);
> +}
> +
> +static inline bool
> +pad_any_button_down(const struct pad_dispatch *pad)
> +{
> + const struct button_state *state = &pad->button_state;
> + unsigned int i;
> +
> + for (i = 0; i < sizeof(state->bits); i++)
> + if (state->bits[i] != 0)
> + return true;
> +
> + return false;
> +}
> +
> +static inline void
> +pad_button_set_down(struct pad_dispatch *pad,
> + uint32_t button,
> + bool is_down)
> +{
> + struct button_state *state = &pad->button_state;
> +
> + if (is_down) {
> + set_bit(state->bits, button);
> + pad_set_status(pad, PAD_BUTTONS_PRESSED);
> + } else {
> + clear_bit(state->bits, button);
> + pad_set_status(pad, PAD_BUTTONS_RELEASED);
> + }
> +}
> +
> +static void
> +pad_process_absolute(struct pad_dispatch *pad,
> + struct evdev_device *device,
> + struct input_event *e,
> + uint64_t time)
> +{
> + switch (e->code) {
> + case ABS_WHEEL:
> + pad->changed_axes |= PAD_AXIS_RING1;
> + pad_set_status(pad, PAD_AXES_UPDATED);
> + break;
> + case ABS_THROTTLE:
> +
Re: [PATCH libinput] tablet: add a fuzz-filter to avoid spamming callers with subpixel updates
On Mon, Apr 11, 2016 at 5:17 PM, Peter Hutterer
wrote:
> This is especially a problem for the cursor tool which can be legitimately
> left on the tablet. It wobbles by a couple of device units, resulting in
> continuous axis updates to the caller. Pre-filter any of these events by the
> axis' fuzz value so we don't even process them.
>
> For ABS_DISTANCE which doesn't have a fuzz we hard-code a minimum fuzz of 2.
> This should eventually land in the udev hwdb though.
>
Bikeshed: s/udev hwdb/kernel/ (and poke Ping and I with a stick) since
the lack of fuzz isn't a huge issue but is still something that should
be fixed?
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> https://bugs.freedesktop.org/show_bug.cgi?id=94892
>
> Signed-off-by: Peter Hutterer
> ---
> src/evdev-tablet.c | 35 +++
> src/evdev-tablet.h | 2 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 84563a8..be828d9 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -112,6 +112,36 @@ tablet_device_has_axis(struct tablet_dispatch *tablet,
> return has_axis;
> }
>
> +static inline bool
> +tablet_filter_axis_fuzz(const struct tablet_dispatch *tablet,
> + const struct evdev_device *device,
> + const struct input_event *e,
> + enum libinput_tablet_tool_axis axis)
> +{
> + int delta, fuzz;
> + int current, previous;
> +
> + previous = tablet->prev_value[axis];
> + current = e->value;
> + delta = previous - current;
> +
> + fuzz = libevdev_get_abs_fuzz(device->evdev, e->code);
> +
> + /* ABS_DISTANCE doesn't have have fuzz set and causes continuous
> +* updates for the cursor/lens tools. Add a minimum fuzz of 2, same
> +* as the xf86-input-wacom driver
> +*/
> + switch (e->code) {
> + case ABS_DISTANCE:
> + fuzz = max(2, fuzz);
> + break;
> + default:
> + break;
> + }
> +
> + return abs(delta) <= fuzz;
> +}
> +
> static void
> tablet_process_absolute(struct tablet_dispatch *tablet,
> struct evdev_device *device,
> @@ -137,6 +167,11 @@ tablet_process_absolute(struct tablet_dispatch *tablet,
> break;
> }
>
> + tablet->prev_value[axis] = tablet->current_value[axis];
> + if (tablet_filter_axis_fuzz(tablet, device, e, axis))
> + break;
> +
> + tablet->current_value[axis] = e->value;
> set_bit(tablet->changed_axes, axis);
> tablet_set_status(tablet, TABLET_AXES_UPDATED);
> break;
> diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
> index 880d523..d12c675 100644
> --- a/src/evdev-tablet.h
> +++ b/src/evdev-tablet.h
> @@ -55,6 +55,8 @@ struct tablet_dispatch {
> unsigned char changed_axes[NCHARS(LIBINPUT_TABLET_TOOL_AXIS_MAX + 1)];
> struct tablet_axes axes;
> unsigned char axis_caps[NCHARS(LIBINPUT_TABLET_TOOL_AXIS_MAX + 1)];
> + int current_value[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1];
> + int prev_value[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1];
>
> /* Only used for tablets that don't report serial numbers */
> struct list tool_list;
> --
> 2.5.5
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v7 wayland-protocols] Add the tablet protocol
On 03/08/2016 10:10 PM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > Reviewed-by: Daniel Stone > Reviewed-by: Jonas Ådahl > --- > Changes to v6: > - a bunch of typos/grammar fixes > - clarified the "down" event on enter > - clarified the "up" event, specifically: the up event isn't sent when the > tool leaves the input region but rather when the compositor deems it's up > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 637 > + > 3 files changed, 642 insertions(+) > create mode 100644 unstable/tablet/README > create mode 100644 unstable/tablet/tablet-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..a7f838b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/tablet/tablet-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/tablet/README b/unstable/tablet/README > new file mode 100644 > index 000..7ba8e77 > --- /dev/null > +++ b/unstable/tablet/README > @@ -0,0 +1,4 @@ > +Tablet protocol > + > +Maintainers: > +Peter Hutterer > diff --git a/unstable/tablet/tablet-unstable-v1.xml > b/unstable/tablet/tablet-unstable-v1.xml > new file mode 100644 > index 000..8e3ab6f > --- /dev/null > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -0,0 +1,637 @@ > + > + > + > +Copyright 2014 © Stephen "Lyude" Chandler Paul > +Copyright 2015-2016 © Red Hat, Inc. > + > +Permission is hereby granted, free of charge, to any person > +obtaining a copy of this software and associated documentation files > +(the "Software"), to deal in the Software without restriction, > +including without limitation the rights to use, copy, modify, merge, > +publish, distribute, sublicense, and/or sell copies of the Software, > +and to permit persons to whom the Software is furnished to do so, > +subject to the following conditions: > + > +The above copyright notice and this permission notice (including the > +next paragraph) shall be included in all copies or substantial > +portions of the Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > +SOFTWARE. > + > + > +This description provides a high-level overview of the interplay between > +the interfaces defined this protocol. For details, see the protocol > +specification. > + > +More than one tablet may exist, and device-specifics matter. Tablets are > +not represented by a single virtual device like wl_pointer. A client > +binds to the tablet manager object which is just a proxy object. From > +that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat) > +and that returns the actual interface that has all the tablets. With > +this indirection, we can avoid merging wp_tablet into the actual wayland > +protocol, a long-term benefit. > + > +The wp_tablet_seat sends a "tablet added" event for each tablet > +connected. That event is followed by descriptive events about the > +hardware; currently that includes events for name, vid/pid and > +a wp_tablet.path event that describes a local path. This path can be > +used to uniquely identify a tablet or get more information through > +libwacom. Emulated or nested tablets can skip any of those, e.g. a > +virtual tablet may not have a vid/pid. The sequence of descriptive > +events is terminated by a wp_tablet.done event to signal that a client > +may now finalize any initialization for that tablet. > + > +Events from tablets require a tool in proximity. Tools are also managed > +by the tablet seat; a "tool added" event is sent whenever a tool is new > +to the compositor. That event is followed by a number of descriptive > +events about the hardware; currently that includes capabilities, > +hardware id and serial number, and tool type. Similar to the tablet > +interface, a wp_tablet_tool.done event is sent to terminate that initial > +sequence. > + > +Any even
Re: [PATCH v6 wayland-protocols] Add the tablet protocol
A number of tiny fixes, and a couple of questions: On 02/29/2016 04:09 PM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > Reviewed-by: Daniel Stone > --- > Changes to v5: > - remove leftover statement falsely claminig wp_tablet_tool.destroy requires > a remove event first > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 622 > + > 3 files changed, 627 insertions(+) > create mode 100644 unstable/tablet/README > create mode 100644 unstable/tablet/tablet-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..a7f838b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/tablet/tablet-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/tablet/README b/unstable/tablet/README > new file mode 100644 > index 000..7ba8e77 > --- /dev/null > +++ b/unstable/tablet/README > @@ -0,0 +1,4 @@ > +Tablet protocol > + > +Maintainers: > +Peter Hutterer > diff --git a/unstable/tablet/tablet-unstable-v1.xml > b/unstable/tablet/tablet-unstable-v1.xml > new file mode 100644 > index 000..988f949 > --- /dev/null > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -0,0 +1,622 @@ > + > + > + > +Copyright 2014 © Stephen "Lyude" Chandler Paul > +Copyright 2015-2016 © Red Hat, Inc. > + > +Permission is hereby granted, free of charge, to any person > +obtaining a copy of this software and associated documentation files > +(the "Software"), to deal in the Software without restriction, > +including without limitation the rights to use, copy, modify, merge, > +publish, distribute, sublicense, and/or sell copies of the Software, > +and to permit persons to whom the Software is furnished to do so, > +subject to the following conditions: > + > +The above copyright notice and this permission notice (including the > +next paragraph) shall be included in all copies or substantial > +portions of the Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > +SOFTWARE. > + > + > +This description provides a high-level overview of the interplay between > +the interfaces defined this protocol. For details, see the protocol > +specification. > + > +More than one tablet may exist, and device-specifics matter. Tablets are > +not represented by a single virtual device like wl_pointer. A client > +binds to the tablet manager object which is just a proxy object. From > +that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat) > +and that returns the actual interface that has all the tablets. With > +this indirection, we can avoid merging wp_tablet into the actual wayland > +protocol, a long-term benefit. > + > +The wp_tablet_seat sends a "tablet added" for each tablet connected. > +That event is followed by descriptive events about the hardware; Reads a little awkwardly. Perhaps 'The wp_tablet_seat sends a "tablet added" event for each tablet connected. That is followed...' > +currently that includes events for name, vid/pid and > +a wp_tablet.path event that describes a local path. This path can be > +used to uniquely identify a tablet, or get more information through s/,// > +libwacom. Emulated or nested tablets can skip any of those, e.g. a > +virtual tablet may not have a vid/pid. The sequence of descriptive > +events is terminated by a wp_tablet.done event to signal that a client > +may now finalize any initialization for that tablet. > + > +Events from tablets require a tool in proximity. Tools are also managed > +by the tablet seat, a "tool added" is sent whenever a tool is new to s/,/;/ Also, similar request as for wording of "tablet added" above. > +the compositor. That event is followed by a number of descriptive events > +about the hardware; currently that includes capabilities, serial id, > +hardware serial and tool type. Similar to the tablet interface, a "Seri
Re: [PATCH libinput] tablet: use the tilt resolution if we have it
On 02/17/2016 05:39 PM, Peter Hutterer wrote:
> A nonzero resolution on the tilt axes is units/rad so we can calculate the
> physical min/max based. Uneven min/max ranges are supported.
>
> Signed-off-by: Peter Hutterer
> ---
> src/evdev-tablet.c | 28 +---
> test/tablet.c | 12
> 2 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 1e5c2cd..226d5bd 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -230,17 +230,31 @@ adjust_tilt(const struct input_absinfo *absinfo)
> double range = absinfo->maximum - absinfo->minimum;
> double value = (absinfo->value - absinfo->minimum) / range;
> const int WACOM_MAX_DEGREES = 64;
> + double max_degrees;
> +
> + /* If resolution is nonzero, it's in units/radian. But require
> + * a min/max less/greater than zero so we can assume 0 is the
> + * center */
> + if (absinfo->resolution != 0 &&
> + absinfo->maximum > 0 &&
> + absinfo->minimum < 0) {
> + int range_max = absinfo->value >= 0 ? absinfo->maximum
> + : -absinfo->minimum;
> +
> + max_degrees = 180.0/M_PI * range_max/absinfo->resolution;
> + } else {
> + /* Wacom supports physical [-64, 64] degrees, so map to that by
> + * default. If other tablets have a different physical range or
> + * nonzero physical offsets, they need extra treatment
> + * here.
> + */
> + max_degrees = WACOM_MAX_DEGREES;
> + }
>
> /* Map to the (-1, 1) range */
> value = (value * 2) - 1;
>
> - /* Wacom supports physical [-64, 64] degrees, so map to that by
> - * default. If other tablets have a different physical range or
> - * nonzero physical offsets, they need extra treatment
> - * here.
> - */
> -
> - return value * WACOM_MAX_DEGREES;
> + return value * max_degrees;
> }
This looks correct, if a bit difficult to follow because of the range
normalization (specifically the subtle need for "range_max"). You might
consider having the normalization only occur in the 'else' case so that
the 'if' can be written more straightforwardly:
double value;
const int WACOM_MAX_DEGREES = 64;
if ( /* can use resolution */ ) {
value = 180.0/M_PI * absinfo->value/absinfo->resolution;
} else {
/* normalize and scale to +-64 degrees */
}
return value;
That aside, everything looks fine.
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
>
> static inline int32_t
> diff --git a/test/tablet.c b/test/tablet.c
> index c5dc892..ad6ac45 100644
> --- a/test/tablet.c
> +++ b/test/tablet.c
> @@ -3298,7 +3298,8 @@ START_TEST(tilt_x)
> ck_assert_double_ge(tx, -52);
>
> ty = libinput_event_tablet_tool_get_tilt_y(tev);
> - ck_assert_double_eq(ty, -64);
> + ck_assert_double_ge(ty, -65);
> + ck_assert_double_lt(ty, -63);
>
> libinput_event_destroy(event);
>
> @@ -3320,7 +3321,8 @@ START_TEST(tilt_x)
> ck_assert_double_le(tx, expected_tx + 2);
>
> ty = libinput_event_tablet_tool_get_tilt_y(tev);
> - ck_assert_double_eq(ty, -64);
> + ck_assert_double_ge(ty, -65);
> + ck_assert_double_lt(ty, -63);
>
> libinput_event_destroy(event);
>
> @@ -3365,7 +3367,8 @@ START_TEST(tilt_y)
> ck_assert_double_ge(ty, -52);
>
> tx = libinput_event_tablet_tool_get_tilt_x(tev);
> - ck_assert_double_eq(tx, -64);
> + ck_assert_double_ge(tx, -65);
> + ck_assert_double_lt(tx, -63);
>
> libinput_event_destroy(event);
>
> @@ -3387,7 +3390,8 @@ START_TEST(tilt_y)
> ck_assert_double_le(ty, expected_ty + 2);
>
> tx = libinput_event_tablet_tool_get_tilt_x(tev);
> - ck_assert_double_eq(tx, -64);
> + ck_assert_double_ge(tx, -65);
> + ck_assert_double_lt(tx, -63);
>
> libinput_event_destroy(event);
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] tablet: change tilt axes to use degrees
On Tue, Feb 2, 2016 at 2:59 PM, Peter Hutterer wrote:
> The Wacom tilt range is 64 degrees so we map everything into that until we
> know otherwise.
>
> This commit also switches the tilt axes around to align the angles with the
> x/y orientation, i.e. tilting the top of the stylus towards the positive x
> axis now generates a positive x tilt.
>
> Signed-off-by: Peter Hutterer
> ---
> doc/tablet-support.dox | 12
> src/evdev-tablet.c | 28 +++
> src/libinput-private.h | 7 ++-
> src/libinput.h | 16
> test/tablet.c | 52
> +-
> 5 files changed, 72 insertions(+), 43 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index cc5d409..ff4e460 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -83,15 +83,19 @@ additionally provide tilt information along the x and y
> axis.
>
> @image html tablet-axes.svg "Illustration of the distance, pressure and tilt
> axes"
>
> -The granularity and precision of these axes varies between tablet devices
> -and cannot usually be mapped into a physical unit.
> -libinput normalizes distance and pressure into the [0, 1] range and the tilt
> -axes into the [-1, 1] range with 0 as the neutral point.
> +The granularity and precision of the distance and pressure axes varies
> +between tablet devices and cannot usually be mapped into a physical unit.
> +libinput normalizes distance and pressure into the [0, 1] range.
>
> While the normalization range is identical for these axes, a caller should
> not interpret identical values as identical across axes, i.e. a value v1 on
> the distance axis has no relation to the same value v1 on the pressure axis.
>
> +The tilt axes provide the angle in degrees between a vertical line out of
> +the tablet and the top of the stylus. The angle is measured along the x and
> +y axis, respectively, a positive tilt angle thus means that the stylus' top
> +is tilted towards the logical right and/or bottom of the tablet.
> +
> @section tablet-fake-proximity Handling of proximity events
>
> libinput's @ref LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY events notify a caller
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index e684055..2157dfc 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -225,13 +225,25 @@ normalize_pressure(const struct input_absinfo *absinfo,
> }
>
> static inline double
> -normalize_tilt(const struct input_absinfo *absinfo)
> +adjust_tilt(const struct input_absinfo *absinfo)
> {
> double range = absinfo->maximum - absinfo->minimum;
> double value = (absinfo->value - absinfo->minimum) / range;
> + const int WACOM_MAX_DEGREES = 64;
>
> /* Map to the (-1, 1) range */
> - return (value * 2) - 1;
> + value = (value * 2) - 1;
> +
> + /* Wacom supports physical [-64, 64] degrees, so map to that by
> +* default. If other tablets have a different physical range or
> +* nonzero physical offsets, they need extra treatment
> +* here.
> +*
> +* And invert because we flip the axes to align with the x/y
> +* positive direction.
> +*/
> +
> + return value * WACOM_MAX_DEGREES * -1;
The axes should already be aligned to positive X/Y, so I'm not sure
what this is about. Watching the output from evemu-record, tilt values
are positive for right/down and negative for left/up. Am I missing
something?
> }
>
> static inline int32_t
> @@ -251,8 +263,8 @@ convert_tilt_to_rotation(struct tablet_dispatch *tablet)
>values. The device has a 175 degree CCW hardware offset but since
> we use
>atan2 the effective offset is just 5 degrees.
>*/
> - x = tablet->axes.tilt.x;
> - y = tablet->axes.tilt.y;
> + x = -tablet->axes.tilt.x;
> + y = -tablet->axes.tilt.y;
Ditto.
Otherwise,
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> clear_bit(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_TILT_X);
> clear_bit(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_TILT_Y);
>
> @@ -398,17 +410,17 @@ tablet_handle_slider(struct tablet_dispatch *tablet,
> return tablet->axes.slider;
> }
>
> -static inline struct normalized_range_coords
> +static inline struct tilt_degrees
> tablet_handle_tilt(struct tablet_dispatch *tablet,
>
Re: [PATCH v3 wayland-protocols] Add the tablet protocol
On Tue, Feb 2, 2016 at 1:12 PM, Bill Spitzak wrote: > > > On Mon, Feb 1, 2016 at 6:38 PM, Jason Gerecke wrote: >> >> >> Ultimately, the tilt information is almost universally used by >> applications to set brush orientation. To do that, you have to use >> some trig to transform the X and Y tilt values into something like >> Alt-Az form. Tilt on a scale of 0-1 is fine for calculating the >> azimuth, but you can't calculate the altitude angle without knowing >> what 100% physically corresponds to. You can guess (e.g. assume it >> corresponds to the reasonable physical limit of +-90 degrees), get a >> horribly wrong answer (since the hardware limit is actually +-64 >> degrees), and then either ignore the discrepancy or fudge other bits >> of the brush engine to not do nonsensical things. Actually, to be >> fair, that's exactly how GIMP does things right now :P > > > I think a lot of software treats the tilt information as actually the > position of a point some distance up the pen relative to the tip. I would That's certainly true for GIMP and Krita at least (see [1] and [2]). Its incorrect, but its "close enough" that nobody seems to complain (though I've been tempted to in the past ;)) > guess the hardware produces this directly (by reusing the proximity hardware > for a different point higher up in the pen). To get a projection of the pen > onto the tablet surface, these values can be fed to atan2. > > If they were actual angles, they must be the angle of the projection of the > pen onto the two vertical planes of the x and y axis. This is really noisy > when the pen is near one of the axis, and I would think the hardware/driver > could not produce this except by calculating atan2 of a more linear value. > > Therefore I would be very suspicious of any claim that the values being > produced are angles. The current api reporting them as normalized values > seems better. > I've been down this road before a few years back. Does the hardware measure and report true angles or does it measure a projection? If its a projection, does it report them directly, or does it calculate sin^-1 to transform it into an angle? In the end, the specs from the firmware guys say to interpret the data as measured in degrees, so that's what we do. [1]: https://git.gnome.org/browse/gimp/tree/app/core/gimpdynamicsoutput.c#n548 [2]: https://github.com/KDE/krita/blob/master/libs/image/brushengine/kis_paint_information.cc#L507 Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 wayland-protocols] Add the tablet protocol
On Mon, Feb 1, 2016 at 4:55 PM, Peter Hutterer wrote: > On Mon, Feb 01, 2016 at 04:12:24PM -0800, Jason Gerecke wrote: >> On Sun, Jan 31, 2016 at 2:27 PM, Peter Hutterer >> wrote: >> > On Fri, Jan 29, 2016 at 11:40:44AM -0800, Jason Gerecke wrote: >> >> On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer >> >> wrote: >> >> > Signed-off-by: Peter Hutterer >> >> > --- >> >> > Changes to v2: >> >> > - renamed hwserial to hardware_serial >> >> > - renamed to hwid event to a hardware_id_wacom. no-one else uses this ID >> >> > type, so having a generic event with a wacom-specific type + enum is >> >> > optimistic. The next company may use a string instead, so it'll be >> >> > non-generic anyway. Might as well rename it to something specific now. >> >> > - added slider, rotation and wheel axes >> >> > - couple of documentation fixes >> > >> > [...] >> > >> >> > + >> >> > + >> >> > + >> >> > + Sent whenever the distance axis on a tool changes. The value of >> >> > this >> >> > + event is normalized to a value between 0 and 65535. >> >> > + >> >> > + Note that distance may be nonzero even when a tool is not in >> >> > logical >> >> > + contact. See the down and up events for more details. >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + Sent whenever one or both of the tilt axes on a tool change. >> >> > Each tilt >> >> > + value is normalized between -65535 and 65535. >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + >> >> > + Sent whenever the z-rotation axis on the tool changes. The >> >> > + rotation value is in 0.01 of a degree clockwise from the tool's >> >> > + logical neutral position. >> >> > + >> >> >> >> From the protocol description: "Any extra axis is normalized, i.e. the >> >> client knows the range as specified in the protocol (e.g. [0, 65535]), >> >> the granularity however is unknown." This was chosen because we don't >> >> always have the necessary information to translate a kernel value for >> >> a given device's axis into a physical measurement, but we can always >> >> report a normalized value that that gives clients a sense of its >> >> relative magnitude. >> > >> > yeah, we did this for pressure and distance because we know we can't >> > convert >> > them into anything useful. rotation I thought was different and libinput >> > advertises z-rotation in degrees as well. That means two things: >> > * either we commit to degrees and fix it up per-device as needed in >> > libinput >> > * admit that we really can't even get degrees out of rotation and change >> > libinput's API to normalize into a [-1, 1] range. If so, we need to do >> > this *now*, I'm about to release it as a stable API. >> > >> > I am ok with the second option so it's your call really. You have better >> > access to the hw. fwiw, adding degrees later if/when the HW gets more >> > precise is easy enough. >> > >> >> I don't think precision (more correctly, accuracy) is really the issue >> at hand. Its more about the difference between qualitative axes like >> pressure and distance (where there are basically no information about >> the physical values that even minimum and maximum correspond to) and >> quantitative axes like position, tilt, and rotation (which have >> varying degrees of accuracy but are at least specified to have a >> conversion to physical units). Devices based on different technologies >> may have different qualitative and quantitative axes, so reporting >> normalized data as a least common denominator format can be useful. >> >> I would have expected rotation and tilt to both be reported in the >> same format -- either in degrees or normalized. I think both formats >> are fine (since its hard for me to imagine either as a >> merely-qualitative axis), though there are advantages to using the &
Re: [PATCH v3 wayland-protocols] Add the tablet protocol
On Sun, Jan 31, 2016 at 2:27 PM, Peter Hutterer wrote: > On Fri, Jan 29, 2016 at 11:40:44AM -0800, Jason Gerecke wrote: >> On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer >> wrote: >> > Signed-off-by: Peter Hutterer >> > --- >> > Changes to v2: >> > - renamed hwserial to hardware_serial >> > - renamed to hwid event to a hardware_id_wacom. no-one else uses this ID >> > type, so having a generic event with a wacom-specific type + enum is >> > optimistic. The next company may use a string instead, so it'll be >> > non-generic anyway. Might as well rename it to something specific now. >> > - added slider, rotation and wheel axes >> > - couple of documentation fixes > > [...] > >> > + >> > + >> > + >> > + Sent whenever the distance axis on a tool changes. The value of >> > this >> > + event is normalized to a value between 0 and 65535. >> > + >> > + Note that distance may be nonzero even when a tool is not in >> > logical >> > + contact. See the down and up events for more details. >> > + >> > + >> > + >> > + >> > + >> > + >> > + Sent whenever one or both of the tilt axes on a tool change. Each >> > tilt >> > + value is normalized between -65535 and 65535. >> > + >> > + >> > + >> > + >> > + >> > + >> > + >> > + Sent whenever the z-rotation axis on the tool changes. The >> > + rotation value is in 0.01 of a degree clockwise from the tool's >> > + logical neutral position. >> > + >> >> From the protocol description: "Any extra axis is normalized, i.e. the >> client knows the range as specified in the protocol (e.g. [0, 65535]), >> the granularity however is unknown." This was chosen because we don't >> always have the necessary information to translate a kernel value for >> a given device's axis into a physical measurement, but we can always >> report a normalized value that that gives clients a sense of its >> relative magnitude. > > yeah, we did this for pressure and distance because we know we can't convert > them into anything useful. rotation I thought was different and libinput > advertises z-rotation in degrees as well. That means two things: > * either we commit to degrees and fix it up per-device as needed in libinput > * admit that we really can't even get degrees out of rotation and change > libinput's API to normalize into a [-1, 1] range. If so, we need to do > this *now*, I'm about to release it as a stable API. > > I am ok with the second option so it's your call really. You have better > access to the hw. fwiw, adding degrees later if/when the HW gets more > precise is easy enough. > I don't think precision (more correctly, accuracy) is really the issue at hand. Its more about the difference between qualitative axes like pressure and distance (where there are basically no information about the physical values that even minimum and maximum correspond to) and quantitative axes like position, tilt, and rotation (which have varying degrees of accuracy but are at least specified to have a conversion to physical units). Devices based on different technologies may have different qualitative and quantitative axes, so reporting normalized data as a least common denominator format can be useful. I would have expected rotation and tilt to both be reported in the same format -- either in degrees or normalized. I think both formats are fine (since its hard for me to imagine either as a merely-qualitative axis), though there are advantages to using the normalized format like everything else. >> We do need to provide a way for clients to translate the normalized >> values into physical measurements if possible though. I would suggest >> adding the following event to the tool definition. Several could be >> sent as part of the initial pre-"done" burst. >> >> >> >> This event provides information about the physical range of one >> of the axes of the tool. This information can be used to translateIts a >> little difficult to imagine a merely-qualitative tilt axis >> the normalized values (0 to 65535, or -65535 to +65535) axis values >> sent by events into physical quantities. >> >> Minimum and maximum values have units of gram-force for pressure, >> millimeters for distance, and degrees of arc for tilt and rotat
Re: [PATCH v3 wayland-protocols] Add the tablet protocol
On Thu, Jan 28, 2016 at 8:32 PM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > Changes to v2: > - renamed hwserial to hardware_serial > - renamed to hwid event to a hardware_id_wacom. no-one else uses this ID > type, so having a generic event with a wacom-specific type + enum is > optimistic. The next company may use a string instead, so it'll be > non-generic anyway. Might as well rename it to something specific now. > - added slider, rotation and wheel axes > - couple of documentation fixes > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 622 > + > 3 files changed, 627 insertions(+) > create mode 100644 unstable/tablet/README > create mode 100644 unstable/tablet/tablet-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 582b3f2..f3a6dd5 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -5,6 +5,7 @@ unstable_protocols = > \ > unstable/text-input/text-input-unstable-v1.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > + unstable/tablet/tablet-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/tablet/README b/unstable/tablet/README > new file mode 100644 > index 000..7ba8e77 > --- /dev/null > +++ b/unstable/tablet/README > @@ -0,0 +1,4 @@ > +Tablet protocol > + > +Maintainers: > +Peter Hutterer > diff --git a/unstable/tablet/tablet-unstable-v1.xml > b/unstable/tablet/tablet-unstable-v1.xml > new file mode 100644 > index 000..22ff4eb > --- /dev/null > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -0,0 +1,622 @@ > + > + > + > +Copyright 2014 © Stephen "Lyude" Chandler Paul > +Copyright 2015 © Red Hat, Inc. > + > +Permission is hereby granted, free of charge, to any person > +obtaining a copy of this software and associated documentation files > +(the "Software"), to deal in the Software without restriction, > +including without limitation the rights to use, copy, modify, merge, > +publish, distribute, sublicense, and/or sell copies of the Software, > +and to permit persons to whom the Software is furnished to do so, > +subject to the following conditions: > + > +The above copyright notice and this permission notice (including the > +next paragraph) shall be included in all copies or substantial > +portions of the Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > +SOFTWARE. > + > + > +This description provides a high-level overview of the interplay between > +the interfaces defined this protocol. For details, see the protocol > +specification. > + > +More than one tablet may exist, and device-specifics matter. Tablets are > +not represented by a single virtual device like wl_pointer. A client > +binds to the tablet manager object which is just a proxy object. From > +that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat) > +and that returns the actual interface that has all the tablets. With > +this indirection, we can avoid merging wp_tablet into the actual wayland > +protocol, a long-term benefit. > + > +The wp_tablet_seat sends a "tablet added" for each tablet connected. > +That event is followed by descriptive events about the hardware; > +currently that includes events for name, vid/pid and > +a wp_tablet.path event that describes a local path. This path can be > +used to uniquely identify a tablet, or get more information through > +libwacom. Emulated or nested tablets can skip any of those, e.g. a > +virtual tablet may not have a vid/pid. The sequence of descriptive > +events is terminated by a wp_tablet.done event to signal that a client > +may now finalize any initialization for that tablet. > + > +Events from tablets require a tool in proximity. Tools are also managed > +by the tablet seat, a "tool added" is sent whenever a tool is new to > +the compositor. That event is followed by a number of descriptive events > +about the hardware; currently that includes capabilities, serial id, > +hardware serial and tool type. Similar to the
Re: [PATCH libinput 0/7] tablet: add support for relative x/y motion deltas
On Thu, Jan 14, 2016 at 4:26 PM, Peter Hutterer wrote: > > This patchset adds support for relative motion to the tablet branch. AFAICT, > this is the last large feature that was still missing. > The approach is notably different to the current X driver. There we > toggle a property in the driver to switch the tablet into relative mode and > then only send out relative events. The property works per tool. > > libinput's approach is to always calculate relative motion and provide both > absolute and relative motion for each event. The caller must decide which > tool should use which type of motion. > > Unlike the X driver, the relative motion is converted into a pixel-like > motion vector that can be used like the mouse motion. if a caller wants > mm-based movement they can easily calculate the deltas themselves anyway. > > Pointer acceleration is quite simple atm, it's a flat profile and the speed > setting simply multiplies the vector. Can be extended later if need be. > > Cheers, > Peter Looks good! I don't see any obvious problems, though I'm still not 100% familiar with the codebase. For the set: Acked-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] tablet: allow the various get_ on tablet button events
On Wed, Jan 13, 2016 at 8:22 PM, Peter Hutterer wrote: > There's no reason to prevent this for button events. Unlike the pointer > which is a relative device a tablet is (usually) a device with a lot of state. > Caller code that handles axes is likely shared between the various events, > treating button events separately here doesn't get us any benefit. > > Signed-off-by: Peter Hutterer Still not convinced about providing axis info in the tip and button events, but its not my API to design :D Acked-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > --- > src/libinput.c | 12 > src/libinput.h | 27 ++- > 2 files changed, 30 insertions(+), 9 deletions(-) > > diff --git a/src/libinput.c b/src/libinput.c > index d73637a..01e171d 100644 > --- a/src/libinput.c > +++ b/src/libinput.c > @@ -921,6 +921,7 @@ libinput_event_tablet_tool_x_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -936,6 +937,7 @@ libinput_event_tablet_tool_y_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -951,6 +953,7 @@ libinput_event_tablet_tool_pressure_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -966,6 +969,7 @@ libinput_event_tablet_tool_distance_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -981,6 +985,7 @@ libinput_event_tablet_tool_tilt_x_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -996,6 +1001,7 @@ libinput_event_tablet_tool_tilt_y_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -1011,6 +1017,7 @@ libinput_event_tablet_tool_rotation_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -1026,6 +1033,7 @@ libinput_event_tablet_tool_slider_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > return bit_is_set(event->changed_axes, > @@ -1041,6 +1049,7 @@ libinput_event_tablet_tool_wheel_has_changed( >0, >LIBINPUT_EVENT_TABLET_TOOL_AXIS, >LIBINPUT_EVENT_TABLET_TOOL_TIP, > + LIBINPUT_EVENT_TABLET_TOOL_BUTTON, >LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY); > > retur
Re: [PATCH libinput] tablet: insert "STATE" into proximity/tip states
On Mon, Jan 4, 2016 at 8:48 PM, Peter Hutterer wrote:
> Makes it even longer, but at least it's consistent with button and key state.
>
> Signed-off-by: Peter Hutterer
> ---
> sorry, another API change.
Peter and the Amazing Technicolor Bikeshed? :) (but seriously: yay for
consistency!)
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
>
> src/evdev-tablet.c | 4 ++--
> src/libinput.c | 6 +++---
> src/libinput.h | 8
> test/tablet.c | 28 ++--
> tools/event-debug.c | 4 ++--
> tools/event-gui.c | 2 +-
> 6 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 7804c91..8eb69a5 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -513,7 +513,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
> tablet_notify_proximity(&device->base,
> time,
> tool,
> -
> LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
> +
> LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN,
> tablet->changed_axes,
> axes);
> } else {
> @@ -1230,7 +1230,7 @@ tablet_flush(struct tablet_dispatch *tablet,
> tablet_notify_proximity(&device->base,
> time,
> tool,
> - LIBINPUT_TABLET_TOOL_PROXIMITY_OUT,
> +
> LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_OUT,
> tablet->changed_axes,
> tablet->axes);
>
> diff --git a/src/libinput.c b/src/libinput.c
> index 3a10df4..d73637a 100644
> --- a/src/libinput.c
> +++ b/src/libinput.c
> @@ -2170,7 +2170,7 @@ tablet_notify_axis(struct libinput_device *device,
> *axis_event = (struct libinput_event_tablet_tool) {
> .time = time,
> .tool = tool,
> - .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
> + .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN,
> .tip_state = tip_state,
> .wheel_discrete = wheel_discrete,
> };
> @@ -2238,7 +2238,7 @@ tablet_notify_tip(struct libinput_device *device,
> .time = time,
> .tool = tool,
> .tip_state = tip_state,
> - .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
> + .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN,
> };
> memcpy(tip_event->axes,
>axes,
> @@ -2276,7 +2276,7 @@ tablet_notify_button(struct libinput_device *device,
> .button = button,
> .state = state,
> .seat_button_count = seat_button_count,
> - .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
> + .proximity_state = LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN,
> .tip_state = tip_state,
> };
> memcpy(button_event->axes, axes, sizeof(button_event->axes));
> diff --git a/src/libinput.h b/src/libinput.h
> index e29b01a..9848d59 100644
> --- a/src/libinput.h
> +++ b/src/libinput.h
> @@ -197,8 +197,8 @@ enum libinput_tablet_tool_type {
> * distance (a few cm) off the surface.
> */
> enum libinput_tablet_tool_proximity_state {
> - LIBINPUT_TABLET_TOOL_PROXIMITY_OUT = 0,
> - LIBINPUT_TABLET_TOOL_PROXIMITY_IN = 1,
> + LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_OUT = 0,
> + LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN = 1,
> };
>
> /**
> @@ -284,9 +284,9 @@ enum libinput_event_type {
> * with @ref LIBINPUT_EVENT_TABLET_TOOL_AXIS events.
> *
> * Some tools may always be in proximity. For these tools, events of
> -* type @ref LIBINPUT_TABLET_TOOL_PROXIMITY_IN are sent only once
> after @ref
> +* type @ref LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_IN are sent only
> once after @ref
> * LIBINPUT_EVENT_DEVICE_ADDED, and events of type @ref
> -* LIBINPUT_TABLET_TOOL_PROXIMITY_OUT are sent only once before @ref
> +* LIBINPUT_TABLET_TOOL_PROXIMITY_STATE_OUT are sent only once before
> @ref
Re: [PATCH libinput 0/5] tablet: pressure threshold handling
Largely looks good, aside from a few comments. For the series: Acked-by: Jason Gerecke Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours On Mon, Jan 4, 2016 at 5:21 PM, Peter Hutterer wrote: > > This patchset adds pressure thresholds handling for tools. Rather than > relying on BTN_TOUCH being set by the kernel, we look at the pressure and > generate our tip events based on that. Long-term this can be > device-specific, right now we just use 5%. > > One major functional change: this means tip events now replace the axis > event, i.e. where before a caller would get an axis event with axis updates > + a tip event with unchanged axes, now the caller only gets the tip event, > with the axis updates includes. > > Cheers, > Peter > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 4/5] tablet: a tip event can replace an axis event
On Mon, Jan 4, 2016 at 5:21 PM, Peter Hutterer wrote:
> When we're only dealing with BTN_TOUCH we can make the tip event independent
> of the axis event. Now that we handle pressure thresholds to trigger tip state
> this does not work, we'd have to send an axis event with the new pressure and
> then a tip event. Since the pressure triggers the tip event this seems
> disconnected.
>
> Make the tip event officially capable of carrying axes. A caller can then
> decide how to forward this to the next layer.
>
> Signed-off-by: Peter Hutterer
> ---
Tracking axis values across multiple types of event seems kinda
ugly... I'm not sure I'd prefer it to events that seem "disconnected".
I mean, at some level, pressure is what is triggering the tip event
anyway. The hardware may (though I don't think typically would...)
start reporting HID_DG_TIPPRESSURE prior to HID_DG_TIPSWITCH, and
likewise the kernel may (wacom.ko does, though its hard to see) start
reporting ABS_PRESSURE prior to BTN_TOUCH.
You're more familiar with what users of libinput would want/expect
though, so I'll leave API decisions in your hands :)
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> doc/tablet-support.dox | 3 +-
> src/evdev-tablet.c | 168
> +++--
> src/libinput-private.h | 1 +
> src/libinput.c | 4 ++
> src/libinput.h | 28 -
> test/tablet.c | 101 -
> 6 files changed, 179 insertions(+), 126 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index a3d4d7b..a5fa738 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -43,7 +43,8 @@ pressure value while the tip is logically up. Most
> application can and
> should ignore pressure information until they receive the event of type @ref
> LIBINPUT_EVENT_TABLET_TOOL_TIP. Applications that require extremely
> fine-grained pressure sensitivity should use the pressure data instead of
> -the tip events.
> +the tip events to determine a logical tip down state and treat the tip
> +events like axis events otherwise.
>
> Note that the pressure threshold to trigger a logical tip event may be zero
> on some devices. On tools without pressure sensitivity, determining when a
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 2f57805..0c20483 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -453,13 +453,14 @@ tablet_handle_wheel(struct tablet_dispatch *tablet,
> return tablet->axes[a];
> }
>
> -static void
> +static bool
> tablet_check_notify_axes(struct tablet_dispatch *tablet,
> struct evdev_device *device,
> -uint64_t time,
> -struct libinput_tablet_tool *tool)
> +struct libinput_tablet_tool *tool,
> +double *axes_out,
> +size_t axes_sz,
> +int *wheel_discrete_out)
> {
> - struct libinput_device *base = &device->base;
> double axes[LIBINPUT_TABLET_TOOL_AXIS_MAX + 1] = {0};
> int wheel_discrete = 0;
> struct device_coords point;
> @@ -467,8 +468,9 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
> const char tmp[sizeof(tablet->changed_axes)] = {0};
>
> if (memcmp(tmp, tablet->changed_axes, sizeof(tmp)) == 0)
> - return;
> + return false;
>
> + assert(axes_sz == sizeof(axes));
> point = tablet_handle_xy(tablet, device);
> axes[LIBINPUT_TABLET_TOOL_AXIS_X] = point.x;
> axes[LIBINPUT_TABLET_TOOL_AXIS_Y] = point.y;
> @@ -501,41 +503,10 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
> axes[LIBINPUT_TABLET_TOOL_AXIS_REL_WHEEL] =
> tablet_handle_wheel(tablet, device, &wheel_discrete);
>
> - /* We need to make sure that we check that the tool is not out of
> -* proximity before we send any axis updates. This is because many
> -* tablets will send axis events with incorrect values if the tablet
> -* tool is close enough so that the tablet can partially detect that
> -* it's there, but can't properly receive any data from the tool. */
> - if (!tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY) &&
> - !tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY)) {
> - if (tablet_has_status(tablet,
> - TABLET_TOOL_ENTERING_PROXIMITY)) {
> - tablet_notify_proximity(&device->base,
> - time,
> - tool,
> -
> LIBINPUT_TABLET_TOOL_PROXIMITY_IN,
> -
Re: [PATCH libinput 3/5] tablet: add pressure threshold handling
'On Mon, Jan 4, 2016 at 5:21 PM, Peter Hutterer
wrote:
> On tablets with ABS_PRESSURE use a pressure value to determine tip state, not
> BTN_TOUCH. This enables us (down the road) to have device-specific pressure
> thresholds. For now we use a 5% default for all devices.
>
> The threshold is a range, if we go past the upper range we initiate the tip
> down, if we go below the lower range we release the tip again.
>
> This affects two current tests:
> * Once we have pressure offsets and pressure thresholds, we're biased towards
> pressure. So we can only check that distance is zero when there is a pressure
> value, not the other way round.
> * When the pressure threshold is exceeded on proximity in with a nonzero
> distance, we can only warn and handle the pressure as normal. Since this is a
> niche case anyway anything fancier is likely unnecessary.
>
> Signed-off-by: Peter Hutterer
> ---
> doc/tablet-support.dox | 16 +
> src/evdev-tablet.c | 94
> --
> src/libinput-private.h | 8 +
> test/tablet.c | 67 ---
> 4 files changed, 122 insertions(+), 63 deletions(-)
>
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index fbe778d..a3d4d7b 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -33,6 +33,22 @@ Tablet tools may send button events; these are exclusively
> for extra buttons
> unrelated to the tip. A button event is independent of the tip and occur
> at any time.
>
> +Some tablet tools' pressure detection is too sensitive, causing phantom
> +touches when the user only slightly brushes the surfaces. For example, some
> +tools are capable of detecting 1 gram of pressure.
> +
> +libinput uses a device-specific pressure threshold to determine when the tip
> +is considered logically down. As a result, libinput may send a nonzero
> +pressure value while the tip is logically up. Most application can and
> +should ignore pressure information until they receive the event of type @ref
> +LIBINPUT_EVENT_TABLET_TOOL_TIP. Applications that require extremely
> +fine-grained pressure sensitivity should use the pressure data instead of
> +the tip events.
> +
> +Note that the pressure threshold to trigger a logical tip event may be zero
> +on some devices. On tools without pressure sensitivity, determining when a
> +tip is down is device-specific.
> +
> @section tablet-axes Special axes on tablet tools
>
> A tablet tool usually provides additional information beyond x/y positional
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 7f6c860..2f57805 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -617,10 +617,15 @@ tablet_process_key(struct tablet_dispatch *tablet,
>e->value);
> break;
> case BTN_TOUCH:
> - if (e->value)
> - tablet_set_status(tablet,
> TABLET_TOOL_ENTERING_CONTACT);
> - else
> - tablet_set_status(tablet,
> TABLET_TOOL_LEAVING_CONTACT);
> + if (!bit_is_set(tablet->axis_caps,
> + LIBINPUT_TABLET_TOOL_AXIS_PRESSURE)) {
> + if (e->value)
> + tablet_set_status(tablet,
> +
> TABLET_TOOL_ENTERING_CONTACT);
> + else
> + tablet_set_status(tablet,
> +
> TABLET_TOOL_LEAVING_CONTACT);
> + }
> break;
> case BTN_LEFT:
> case BTN_RIGHT:
> @@ -844,6 +849,12 @@ tool_set_bits(const struct tablet_dispatch *tablet,
> }
> }
>
> +static inline int
> +axis_range_percentage(const struct input_absinfo *a, double percent)
> +{
> + return (a->maximum - a->minimum) * percent/100.0 + a->minimum;
> +}
> +
> static struct libinput_tablet_tool *
> tablet_get_tool(struct tablet_dispatch *tablet,
> enum libinput_tablet_tool_type type,
> @@ -894,12 +905,22 @@ tablet_get_tool(struct tablet_dispatch *tablet,
>
> tool->pressure_offset = 0;
> tool->has_pressure_offset = false;
> + tool->pressure_threshold.lower = 0;
> + tool->pressure_threshold.upper = 1;
>
> pressure = libevdev_get_abs_info(tablet->device->evdev,
> ABS_PRESSURE);
> - if (pressure)
> + if (pressure) {
> tool->pressure_offset = pressure->minimum;
>
> + /* 5% of the pressure range */
> + tool->pressure_threshold.upper =
> + pressure->minimum +
> + axis_range_percentage(pressure, 5);
The addition here seems incorrect. 'axis_range_percentage' already
accounts for the minimu
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Sun, Dec 6, 2015 at 8:22 PM, Peter Hutterer wrote: > On Thu, Dec 03, 2015 at 07:57:30PM -0800, Jason Gerecke wrote: >> On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer >> wrote: >> > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: >> >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer >> >> wrote: >> >> > If a tool wears out, it may have a pre-loaded pressure offset. In that >> >> > case, >> >> > even when the tool is not physically in contact with the tablet surface >> >> > it >> >> > will send pressure events. >> >> > >> >> > The X.Org wacom driver has automatic pressure preload detection, but it >> >> > is >> >> > unreliable. A quick tap can trigger the detection, making the pen >> >> > unusable >> >> > (see xf86-input-wacom-0.23.0-43-g10cc765). >> >> > >> >> > Since this is a hardware-specific property, add a new udev property >> >> > with the >> >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide >> >> > through the >> >> > hwdb or some other process. Use the value of this property to offset any >> >> > incoming pressure values and scale into the original normalized axis >> >> > range. >> >> > >> >> > Signed-off-by: Peter Hutterer >> >> >> >> I've been asked by Ping (who is going to be OOO for the next few days) >> >> to try and express some of her concerns about how libinput will handle >> >> pen pressure. The two of us have had some lengthy discussions, and >> >> though I'm not sure I agree on all points, I'll try to argue them as >> >> best I can. >> >> >> >> The idea behind the X driver's automatic preload detection was to >> >> provide a way to handle the pen-specific pressure offsets without >> >> requiring the user to configure or calibrate anything. The minimum >> >> pressure seen from a pen is a fairly reliable measure of the offset, >> >> and the X driver attempts to measure this as the pen hovers in >> >> proximity. This works well in most circumstances, but obviously fails >> >> if the pen is "stabbed" at the tablet so quickly that it comes into >> >> contact before it can report an unloaded pressure value. This kind of >> >> wanton hardware abuse isn't something we encourage ;) >> >> >> >> Making the pressure offset a configuration option like you propose >> >> here doesn't suffer from mis-detection, but does require the user to >> >> periodically run a tool to update the UDEV HWDB. Updates to the DB >> >> won't take immediate effect[1], won't propagate across systems[2], and >> >> are incapable of distinguishing between tools without a serial number. >> > >> > a couple of questions here: >> > * how common is this pressure preload? >> > * does it affect all pens or only specific pens? >> > * is there a maximum observed threshold for this pen preload? >> > >> > The last one is specifically: is there a point where we can throw up our >> > hands and tell the user to just buy a new pen rather than needing automatic >> > detection *and* the udev property for anything that exceeds that threshold? >> > >> >> Pens which are fresh from the factory or only lightly used (e.g., all >> the pens in my office...) should have a preload of zero. As time goes >> on and the pen's pressure transducer starts to wear out (especially if >> the pen is "abused") the preload will increase. Unfortunately, I don't >> have any data on how quickly preload accumulates or what ranges of >> values might be expected in the wild. The X driver logs a warning when >> the preload exceeds 20% of maximum pressure, but the origin of that >> particular number is unknown. > > that number was simply made up, based on the assumption that if you're > losing 1/5 of your pressure range (and thus granularity) then it's probably > time to get a new tool. it's a relatively recent commit, so maybe this is > more common than expected. > >> >> One change that could be made to the automatic method that would make >> >> it a bit more reliable would be to define a maximum pressure that it >> >> would consider to be a sane preload. A 'stabbed' pen would almost >> >> certainly overshoo
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Wed, Dec 2, 2015 at 5:03 PM, Peter Hutterer wrote: > On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote: >> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer >> wrote: >> > If a tool wears out, it may have a pre-loaded pressure offset. In that >> > case, >> > even when the tool is not physically in contact with the tablet surface it >> > will send pressure events. >> > >> > The X.Org wacom driver has automatic pressure preload detection, but it is >> > unreliable. A quick tap can trigger the detection, making the pen unusable >> > (see xf86-input-wacom-0.23.0-43-g10cc765). >> > >> > Since this is a hardware-specific property, add a new udev property with >> > the >> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through >> > the >> > hwdb or some other process. Use the value of this property to offset any >> > incoming pressure values and scale into the original normalized axis range. >> > >> > Signed-off-by: Peter Hutterer >> >> I've been asked by Ping (who is going to be OOO for the next few days) >> to try and express some of her concerns about how libinput will handle >> pen pressure. The two of us have had some lengthy discussions, and >> though I'm not sure I agree on all points, I'll try to argue them as >> best I can. >> >> The idea behind the X driver's automatic preload detection was to >> provide a way to handle the pen-specific pressure offsets without >> requiring the user to configure or calibrate anything. The minimum >> pressure seen from a pen is a fairly reliable measure of the offset, >> and the X driver attempts to measure this as the pen hovers in >> proximity. This works well in most circumstances, but obviously fails >> if the pen is "stabbed" at the tablet so quickly that it comes into >> contact before it can report an unloaded pressure value. This kind of >> wanton hardware abuse isn't something we encourage ;) >> >> Making the pressure offset a configuration option like you propose >> here doesn't suffer from mis-detection, but does require the user to >> periodically run a tool to update the UDEV HWDB. Updates to the DB >> won't take immediate effect[1], won't propagate across systems[2], and >> are incapable of distinguishing between tools without a serial number. > > a couple of questions here: > * how common is this pressure preload? > * does it affect all pens or only specific pens? > * is there a maximum observed threshold for this pen preload? > > The last one is specifically: is there a point where we can throw up our > hands and tell the user to just buy a new pen rather than needing automatic > detection *and* the udev property for anything that exceeds that threshold? > Pens which are fresh from the factory or only lightly used (e.g., all the pens in my office...) should have a preload of zero. As time goes on and the pen's pressure transducer starts to wear out (especially if the pen is "abused") the preload will increase. Unfortunately, I don't have any data on how quickly preload accumulates or what ranges of values might be expected in the wild. The X driver logs a warning when the preload exceeds 20% of maximum pressure, but the origin of that particular number is unknown. >> One change that could be made to the automatic method that would make >> it a bit more reliable would be to define a maximum pressure that it >> would consider to be a sane preload. A 'stabbed' pen would almost >> certainly overshoot the ceiling and we could simply assume an >> arbitrary preload of our choosing (zero? the ceiling?). A very light >> 'stab' could still cause issues, but its quite difficult to both move >> the pen quickly enough to enter and exit prox at a high enough speed >> to not get an unloaded pressure reading *and* only lightly come into >> contact with the surface. > > at least on the tablets that do distance we can combine the maximum pressure > threshold with the distance measurement. It's harder to do that on tablets > without distance though. > The distance data is pretty rough and I believe varies based on the environment (since its similar to [but I don't think /quite/ the same as] SNR) but that still might be an interesting idea. If the driver has a reasonable idea of a minimum "safe" distance where the pen is almost certainly not in contact, then it can figure out if the pressure can be interpreted as preload or not. >> A second issue that Ping brought up is the tying of pressure >> information to the "d
Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets
On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer wrote: > If a tool wears out, it may have a pre-loaded pressure offset. In that case, > even when the tool is not physically in contact with the tablet surface it > will send pressure events. > > The X.Org wacom driver has automatic pressure preload detection, but it is > unreliable. A quick tap can trigger the detection, making the pen unusable > (see xf86-input-wacom-0.23.0-43-g10cc765). > > Since this is a hardware-specific property, add a new udev property with the > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through the > hwdb or some other process. Use the value of this property to offset any > incoming pressure values and scale into the original normalized axis range. > > Signed-off-by: Peter Hutterer I've been asked by Ping (who is going to be OOO for the next few days) to try and express some of her concerns about how libinput will handle pen pressure. The two of us have had some lengthy discussions, and though I'm not sure I agree on all points, I'll try to argue them as best I can. The idea behind the X driver's automatic preload detection was to provide a way to handle the pen-specific pressure offsets without requiring the user to configure or calibrate anything. The minimum pressure seen from a pen is a fairly reliable measure of the offset, and the X driver attempts to measure this as the pen hovers in proximity. This works well in most circumstances, but obviously fails if the pen is "stabbed" at the tablet so quickly that it comes into contact before it can report an unloaded pressure value. This kind of wanton hardware abuse isn't something we encourage ;) Making the pressure offset a configuration option like you propose here doesn't suffer from mis-detection, but does require the user to periodically run a tool to update the UDEV HWDB. Updates to the DB won't take immediate effect[1], won't propagate across systems[2], and are incapable of distinguishing between tools without a serial number. One change that could be made to the automatic method that would make it a bit more reliable would be to define a maximum pressure that it would consider to be a sane preload. A 'stabbed' pen would almost certainly overshoot the ceiling and we could simply assume an arbitrary preload of our choosing (zero? the ceiling?). A very light 'stab' could still cause issues, but its quite difficult to both move the pen quickly enough to enter and exit prox at a high enough speed to not get an unloaded pressure reading *and* only lightly come into contact with the surface. A second issue that Ping brought up is the tying of pressure information to the "down" state (patch 4). Its possible that a user would want to have the maximum possible dynamic range for pressure (after accounting for the preload) in a drawing app so that the lightest strokes were useful, while simultaneously wanting UI elements like buttons and menus to only respond to more deliberate (and high-pressure) pen events. In terms of protocol and library, this would mean allowing applications to see non-zero pressure values even before the pen is "down". If we want to do this, we would have to be very deliberate in documenting that the behavior so that programmers understand the pressure data is useful and should not be discarded (or if absolutely necessary, rescaled so that the click threshold is reported as 0 pressure). Right now I don't think any toolkits or applications make use of pressure prior to click, though TBH I haven't actually checked... [1]: I know you can use `udevadm --reload`, but that doesn't affect already-connected devices [2]: The automatic detection doesn't require re-calibrating a pen on every system its used on Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > --- > doc/device-configuration-via-udev.dox| 4 + > doc/tablet-support.dox | 30 ++ > src/evdev-tablet.c | 71 +- > src/libinput-private.h | 2 + > test/litest-device-wacom-intuos-tablet.c | 12 +++ > test/tablet.c| 155 > ++- > 6 files changed, 270 insertions(+), 4 deletions(-) > > diff --git a/doc/device-configuration-via-udev.dox > b/doc/device-configuration-via-udev.dox > index f615cc1..ba44e58 100644 > --- a/doc/device-configuration-via-udev.dox > +++ b/doc/device-configuration-via-udev.dox > @@ -63,6 +63,10 @@ libinput_pointer_get_axis_source() for details. > POINTINGSTICK_CONST_ACCEL > A constant (linear) acceleration factor to apply to pointingstick deltas > to normalize them. > +TABLET_TOOL_PRESSURE_OFFSET_* > +Specifies the pressure offset in device coordinates for the tool whose > +name is given as part of the property name. See @ref tablet-pressure-offset > +for deta
Re: [PATCH wayland-protocols] Add the tablet protocol
On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> Having read this more carefully, the cursor scheme absolutely will not work.
>
> The main problem is that the client may want to choose a cursor for a tool
> based on the location at which it came into proximity. It cannot set this
> cursor until after it gets the proximity event. If this desired cursor is
> different than the one the tool currently has set then that incorrect cursor
> will be seen, at least briefly.
>
I'm afraid I don't understand what meaningful difference there is
between the scheme here and wl_pointer. As you point out, there is a
brief window of time when the incorrect cursor can be seen with _both_
protocols. Its a simple result of the fact that a client _can't_ know
that it needs to change the cursor until _after_ it receives some kind
of focus event ('enter' or 'proximity_in'). I suppose the client could
provide a reference to the surface over which a particular
'set_cursor' should take effect (and then have the compositor keep
track of all those references) but I'm sure that has its own issues.
> A further problem is that there has to be an easy transition between clients
> that don't use the tablet api and those that do. Operation of gui widgets
> that work equally well with mouse or tablet should not change just because
> the client has decided to enable the tablet interface. The primary problem
> is that the pointer position must move to the last tablet tool positiion
> whether or not the client is using the tablet interface. This then means
> there cannot be more than one cursor (since they would be right atop each
> other).
>
While I absolutely agree that GUI widgets should work equally well
with a tablet as a pointer, the "primary problem" is not that the
pointer has to be moved; widgets can work just fine if they're aware
of the tablet protocol. The fundamental problem that prevents things
from "just working" is that tablets don't send wl_pointer events of
any kind.
There's certainly a compatibility benefit to having the tablet
controlling the pointer, but it isn't always appropriate. Although you
can get away with it in the most common case of a non-display tablet
mapped to the entire desktop, it gets annoying _fast_ when a tablet
which is mapped to just a portion of the desktop (e.g. a display
tablet on a multi-head system) since you /don't/ generally want the
mouse cursor to move: you just want the UI elements you click on to
respond. Putting tablets into separate seats might be a solution to
this, but it seems like its ripe for causing other unintended problems
(e.g. clicking on a text box and then not being able to type since the
keyboard focus isn't associated with the same seat as the tablet).
Leaving support for the tablet protocol up to the client gives me
pause, but its less frightening once you consider that practically any
non-toy application will be written with the aid of a toolkit. As long
as the toolkits do the right thing, so will applications built on
them. Its the same situation with touch: authors who don't use a
toolkit can write applications that don't function with a touchscreen,
but most applications will work fine since toolkits know they need to
handle wl_touch.
> My recommendation:
>
> - Proximity-in jumps the cursor and pointer position to the location but
> does not change the cursor. It will however send proximity-in events to the
> client (it will also send proximity-out to other clients using the tablet
> interface, and normal wl_pointer exit events to clients not using the tablet
> interface).
>
> - Client should respond to proximity-in by setting the wl_pointer cursor to
> whatever is desired. Notice this is identical to how clients not using the
> tablet interface respond to wl_pointer::enter events.
>
> This will 'blink' still, as the current cursor is also possibly not equal to
> the desired cursor. This could be fixed, but if so the exact same fix must
> be done to enter events or you really are not solving anything. Also note
> that hiding the cursor is not acceptable, it will be perceived as a blink if
> the cursor was correct and near the location of the proximity-in.
>
Disagree with these two recommendations as outlined above.
> - Proximity-in and enter events "freeze" the cursor at it's current
> location, and it does not move until the client sets the cursor image.
>
Wouldn't this alone solve the issue of the wrong pointer being
displayed for a split-second? I'm not sure if its the compositor's
place to "freeze" the cursor until a client responds (that sounds a
little dicey, especially with hung clients), but it could be an
interesting approach.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> On Thu, Nov 5, 2015 at 8:24 PM, Peter Hutterer
> wrote:
>>
>> Signed-off-by: Peter Hutterer
>> ---
>> This is the
Re: [PATCH libinput 6/6] tablet: rename all tool types to LIBINPUT_TOOL_TYPE_*
On Thu, Nov 5, 2015 at 8:55 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
The weston patches are going to have to be modified to work with this
API change, but otherwise...
For the series:
Reviewed-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> ---
> src/evdev-tablet.c | 54
> ++---
> src/evdev-tablet.h | 18 +-
> src/libinput.h | 27 ++-
> test/tablet.c | 8
> tools/event-debug.c | 16
> 5 files changed, 62 insertions(+), 61 deletions(-)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 851d49d..04cd082 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -341,8 +341,8 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
> /* ROTATION_Z is higher than TILT_X/Y so we know that the
>tilt axes are already normalized and set */
> if (a == LIBINPUT_TABLET_AXIS_ROTATION_Z &&
> - (tablet->current_tool_type == LIBINPUT_TOOL_MOUSE ||
> - tablet->current_tool_type == LIBINPUT_TOOL_LENS)) {
> + (tablet->current_tool_type == LIBINPUT_TOOL_TYPE_MOUSE ||
> + tablet->current_tool_type == LIBINPUT_TOOL_TYPE_LENS)) {
> convert_tilt_to_rotation(tablet);
> axes[LIBINPUT_TABLET_AXIS_TILT_X] = 0;
> axes[LIBINPUT_TABLET_AXIS_TILT_Y] = 0;
> @@ -459,14 +459,14 @@ tablet_evcode_to_tool(int code)
> enum libinput_tool_type type;
>
> switch (code) {
> - case BTN_TOOL_PEN: type = LIBINPUT_TOOL_PEN; break;
> - case BTN_TOOL_RUBBER: type = LIBINPUT_TOOL_ERASER;break;
> - case BTN_TOOL_BRUSH:type = LIBINPUT_TOOL_BRUSH; break;
> - case BTN_TOOL_PENCIL: type = LIBINPUT_TOOL_PENCIL;break;
> - case BTN_TOOL_AIRBRUSH: type = LIBINPUT_TOOL_AIRBRUSH; break;
> - case BTN_TOOL_FINGER: type = LIBINPUT_TOOL_FINGER;break;
> - case BTN_TOOL_MOUSE:type = LIBINPUT_TOOL_MOUSE; break;
> - case BTN_TOOL_LENS: type = LIBINPUT_TOOL_LENS; break;
> + case BTN_TOOL_PEN: type = LIBINPUT_TOOL_TYPE_PEN; break;
> + case BTN_TOOL_RUBBER: type = LIBINPUT_TOOL_TYPE_ERASER; break;
> + case BTN_TOOL_BRUSH:type = LIBINPUT_TOOL_TYPE_BRUSH;break;
> + case BTN_TOOL_PENCIL: type = LIBINPUT_TOOL_TYPE_PENCIL; break;
> + case BTN_TOOL_AIRBRUSH: type = LIBINPUT_TOOL_TYPE_AIRBRUSH; break;
> + case BTN_TOOL_FINGER: type = LIBINPUT_TOOL_TYPE_FINGER; break;
> + case BTN_TOOL_MOUSE:type = LIBINPUT_TOOL_TYPE_MOUSE;break;
> + case BTN_TOOL_LENS: type = LIBINPUT_TOOL_TYPE_LENS; break;
> default:
> abort();
> }
> @@ -676,11 +676,11 @@ tool_set_bits(const struct tablet_dispatch *tablet,
>anyway.
> */
> switch (type) {
> - case LIBINPUT_TOOL_PEN:
> - case LIBINPUT_TOOL_ERASER:
> - case LIBINPUT_TOOL_PENCIL:
> - case LIBINPUT_TOOL_BRUSH:
> - case LIBINPUT_TOOL_AIRBRUSH:
> + case LIBINPUT_TOOL_TYPE_PEN:
> + case LIBINPUT_TOOL_TYPE_ERASER:
> + case LIBINPUT_TOOL_TYPE_PENCIL:
> + case LIBINPUT_TOOL_TYPE_BRUSH:
> + case LIBINPUT_TOOL_TYPE_AIRBRUSH:
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_PRESSURE);
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_DISTANCE);
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_TILT_X);
> @@ -688,8 +688,8 @@ tool_set_bits(const struct tablet_dispatch *tablet,
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_SLIDER);
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_ROTATION_Z);
> break;
> - case LIBINPUT_TOOL_MOUSE:
> - case LIBINPUT_TOOL_LENS:
> + case LIBINPUT_TOOL_TYPE_MOUSE:
> + case LIBINPUT_TOOL_TYPE_LENS:
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_ROTATION_Z);
> copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_REL_WHEEL);
> break;
> @@ -700,17 +700,17 @@ tool_set_bits(const struct tablet_dispatch *tablet,
> /* If we don't have libwacom, copy all pen-related ones from the
>tablet vs all mouse-related ones */
> switch (type) {
> - case LIBINPUT_TOOL_PEN:
>
Re: [PATCH wayland-protocols] Add the tablet protocol
ore the > + wp_tablet_tool.done event. > + > + > + > + > + > + > + If the tool can be identified by a unique 64-bit serial number, this > + event notifies the client of the serial number. > + > + If multiple tablets are available in the same seat and the tool is > + uniquely identifiable by the serial number, that tool may move > + between tablets. > + > + Otherwise, if the tool has no serial number and this event is > + missing, the tool is tied to the tablet it first comes into > + proximity with. Even if the physical tool is used on multiple > + tablets, separate wp_tablet_tool objects will be created, one per > + tablet. > + > + This event is sent in the initial burst of events before the > + wp_tablet_tool.done event. > + > + > + > + > + > + > + > + Specifies the format of the hardware id in the > + wp_tablet_tool.hardware_id event. > + > + A wacom_stylus_id format indicates a hardware id as the id used by > + graphics tablet made by Wacom Inc. For example, on Wacom tablets the > + hardware id of a Grip Pen (a stylus) is 0x802. > + > + > + > + > + > + > + This event notifies the client of a hardware id available on this > tool. > + > + The hardware id is a device-specific 64-bit id that provides extra > + information about the tool in use, beyond the wl_tool.type > + enumeration. The format of the id is device-specific. > + > + This event is sent in the initial burst of events before the > + wp_tablet_tool.done event. > + > + > + > + > + > + > + > + > + > + Describes extra capabilities on a tablet. > + > + Any tool must provide x and y values, extra axes are > + device-specific. > + > + > + > + > + > + > + > + > + This event notifies the client of any capabilities of this tool, > + beyond the main set of x/y axes and tip up/down detection. > + > + One event is sent for each extra capability available on this tool. > + > + This event is sent in the initial burst of events before the > + wp_tablet_tool.done event. > + > + > + > + > + > + > + This event signals the end of the initial burst of descriptive > + events. A client may consider the static description of the tool to > + be complete and finalize initialization of the tool. > + > + > + > + > + > + This event is sent when the tool is removed from the system. The > client > + should not expect the resource it currently has associated with the > + tool to be used again if the tool comes back into proximity later. > + > + It is compositor-dependent when a tool is removed. Some tools are > + associated with a single tablet only and may get removed when the > + respective tablet is removed. Other tools may be used on multiple > + tablets and removing a tablet may not remove this tool. > + > + When this event is received, the client must wp_tablet_tool.destroy > + the object. > + > + > + > + > + > + Notification that this tool is focused on a certain surface. > + > + This event can be received when the tool has moved from one surface to > + another, or when the tool has come back into proximity above the > + surface. > + > + Any button events sent within the same wp_tablet.frame as a > + proximity_in event indicate the button state of the tool at the time > + of proximity in. > + > + > + > + > + > + > + > + > + Notification that this tool has either left proximity, or is no > + longer focused on a certain surface. > + > + When the tablet tool leaves proximity of the tablet, button release > + events are sent for each button that was held down at the time of > + leaving proximity. These events are sent in the same wp_tablet.frame > + of the proximity_out event. > + > + If the tool stays within proximity of the tablet, but the focus > + changes from one surface to another, a button release event may not > + be sent until the button is actually released or the tool leaves the > + proximity of the tablet. > + > + > + > + > + > + Sent whenever the tablet tool comes in contact with the surface
Re: [PATCH weston 00/13] Add tablet support
On Thu, Nov 5, 2015 at 8:31 PM, Peter Hutterer wrote: > > This set adds support for graphics tablets to weston. It's not fully > complete, there are a couple of fixmes in it but the patchset is getting a > bit unwieldly. And there are some discussions on how to do things anyway. > > Note: This needs the tablet-support branch from libinput to work. And it is > on top of Jonas's wip/wayland-protocols github branch (ff0452cea150c). > > Tablet events are sent serially, terminated by a frame event. A toolkit > should accumulate them and then pass them on as one struct to the client. We > don't do that atm, it may be beyond libtoytoolkit's scope to really > integrate this properly. > > The tablet has a separate cursor. That's a conscious decision since the > focus handling on tablets closer to an absolute touch screen than a mouse, > but unlike touch you usually want a cursor shape to indicate the precise > position. > > The rest is fairly straightforward, though as said above, some details are > missing. Implementing this also showed that libinput needs a few extra > things added to it. > > Cheers, > Peter Having trouble getting this patchset to work properly for me. Of the many times I've launched 'weston-tablet', only once did it work as expected. The rest of the time I get no response and more often than not a segfault when the pen leaves proximity (first backtrace). I've also seen a segfault when simply trying to exit Weston with CTRL+ALT+BACKSPACE (second backgrace). Haven't had time to track down the cause; all I know at the moment is that it seems the demo client's proximity_in_handler isn't actually being called for some reason... Program received signal SIGSEGV, Segmentation fault. 0x0041596f in default_grab_tablet_tool_proximity_out (grab=0x20e8388, time=23980253) at src/input.c:812 812 if (weston_surface_is_mapped(tool->sprite->surface)) (gdb) bt #0 0x0041596f in default_grab_tablet_tool_proximity_out (grab=0x20e8388, time=23980253) at src/input.c:812 #1 0x00418ffb in notify_tablet_tool_proximity_out (tool=0x20e82d0, time=23980253) at src/input.c:2307 #2 0x7fe3699a6ce1 in handle_tablet_proximity (libinput_device=0x1c1d7c0, proximity_event=0x20e0580) at src/libinput-device.c:320 #3 0x7fe3699a7587 in evdev_device_process_event (event=0x20e0580) at src/libinput-device.c:543 #4 0x7fe3699a5cf3 in process_event (event=0x20e0580) at src/libinput-seat.c:169 #5 0x7fe3699a5d14 in process_events (input=0x1b07c88) at src/libinput-seat.c:179 #6 0x7fe3699a5d79 in udev_input_dispatch (input=0x1b07c88) at src/libinput-seat.c:190 #7 0x7fe3699a5da6 in libinput_source_dispatch (fd=16, mask=1, data=0x1b07c88) at src/libinput-seat.c:200 #8 0x7fe36b3bcc72 in wl_event_loop_dispatch (loop=0x1aef220, timeout=timeout@entry=-1) at src/event-loop.c:422 #9 0x7fe36b3bb5e5 in wl_display_run (display=0x1aef190) at src/wayland-server.c:1004 #10 0x004275c6 in main (argc=1, argv=0x7ffe86bcca88) at src/main.c:871 Program received signal SIGSEGV, Segmentation fault. 0x7f3f3e63a0e7 in wl_list_remove (elm=0x195a910) at src/wayland-util.c:57 57 elm->prev->next = elm->next; (gdb) bt #0 0x7f3f3e63a0e7 in wl_list_remove (elm=0x195a910) at src/wayland-util.c:57 #1 0x0041550f in weston_tablet_destroy (tablet=0x195a8e0) at src/input.c:699 #2 0x0041a9df in weston_seat_release_tablet (tablet=0x195a8e0) at src/input.c:3116 #3 0x7f3f3cc22ff3 in evdev_device_destroy (device=0x19acc80) at src/libinput-device.c:867 #4 0x7f3f3cc20bc6 in udev_seat_remove_devices (seat=0x19a8fa0) at src/libinput-seat.c:126 #5 0x7f3f3cc21427 in udev_seat_destroy (seat=0x19a8fa0) at src/libinput-seat.c:397 #6 0x7f3f3cc211b0 in udev_input_destroy (input=0x1852c88) at src/libinput-seat.c:333 #7 0x7f3f3cc1f5f7 in drm_destroy (ec=0x183bfc0) at src/compositor-drm.c:2712 #8 0x0041379f in weston_compositor_destroy (compositor=0x183bfc0) at src/compositor.c:4780 #9 0x004275f1 in main (argc=1, argv=0x7ffdd6f32308) at src/main.c:882 Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] doc: fix more typos
Signed-off-by: Jason Gerecke --- doc/absolute-axes.dox | 2 +- doc/faqs.dox | 2 +- doc/gestures.dox | 2 +- doc/palm-detection.dox | 4 ++-- doc/reporting-bugs.dox | 2 +- doc/seats.dox | 4 ++-- doc/tapping.dox| 2 +- doc/tools.dox | 4 ++-- doc/touchpads.dox | 2 +- 9 files changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/absolute-axes.dox b/doc/absolute-axes.dox index 7d205f6..664c616 100644 --- a/doc/absolute-axes.dox +++ b/doc/absolute-axes.dox @@ -67,7 +67,7 @@ or height. Note that rotation applies to the device's origin, rotation usually requires an offset to move the coordinates back into the original range. -The most comon matrices are: +The most common matrices are: - 90 degree clockwise: @f$ diff --git a/doc/faqs.dox b/doc/faqs.dox index 9a78dea..0e49dac 100644 --- a/doc/faqs.dox +++ b/doc/faqs.dox @@ -30,7 +30,7 @@ scroll_sources. @section faq_gpl Is libinput GPL-licensed? No, libinput is MIT licensed. The Linux kernel header file linux/input.h in -libinput's tree is provded to ensure the same behavior regardless of which +libinput's tree is provided to ensure the same behavior regardless of which kernel version libinput is built on. It does not make libinput GPL-licensed. @section faq_config_options Where is the configuration stored? diff --git a/doc/gestures.dox b/doc/gestures.dox index a8cef36..02ef09a 100644 --- a/doc/gestures.dox +++ b/doc/gestures.dox @@ -82,7 +82,7 @@ screen as well as the context of those virtual objects: @image html touchscreen-gestures.svg "Context-sensitivity of touchscreen gestures" In this example, the finger movements are identical but in the left case -both fingers are located within the same window, thus suggesting an attemp +both fingers are located within the same window, thus suggesting an attempt to zoom. In the right case both fingers are located on a window border, thus suggesting a window movement. libinput only has knowledge of the finger coordinates (and even then only in device coordinates, not in screen diff --git a/doc/palm-detection.dox b/doc/palm-detection.dox index 1a5e657..d30a207 100644 --- a/doc/palm-detection.dox +++ b/doc/palm-detection.dox @@ -46,10 +46,10 @@ will generate a button event for this touch. If a device provides a http://en.wikipedia.org/wiki/Pointing_stick";>trackpoint, it is -usually located above the touchpad. This increases the likelyhood of +usually located above the touchpad. This increases the likelihood of accidental touches whenever the trackpoint is used. -libinput disables the touchpad whenver it detects trackpoint activity for a +libinput disables the touchpad whenever it detects trackpoint activity for a certain timeout until after trackpoint activity stops. Touches generated during this timeout will not move the pointer, and touches started during this timeout will likewise not move the pointer (allowing for a user to rest diff --git a/doc/reporting-bugs.dox b/doc/reporting-bugs.dox index 0755a9e..ec0ef9b 100644 --- a/doc/reporting-bugs.dox +++ b/doc/reporting-bugs.dox @@ -8,7 +8,7 @@ When reporting bugs against libinput, please follow the instructions below and provide the required data. This will speed up triage, resulting in a quicker bugfix. -First, try to identify the bugi by reproducing it reliably. The more +First, try to identify the bug by reproducing it reliably. The more specific a bug description is, the easier it is to fix. The @ref libinput-debug-events helper tool can help identify whether the bug is in libinput at all. This tool is a direct hook to libinput without a desktop diff --git a/doc/seats.dox b/doc/seats.dox index 5eec5de..f67de6b 100644 --- a/doc/seats.dox +++ b/doc/seats.dox @@ -5,7 +5,7 @@ Each device in libinput is assigned to one seat. A seat has two identifiers, the physical name and the logical name. The physical name is summarized as the list of devices a process on the same physical seat has access to. The logical seat name is the seat name for a -logical group of devices. A compositor may use that to create additonal +logical group of devices. A compositor may use that to create additional seats as independent device sets. Alternatively, a compositor may limit itself to a single logical seat, leaving a second compositor to manage devices on the other logical seats. @@ -32,7 +32,7 @@ libinput_seat, all other devices reference their own respective seats. @section seats_and_features The effect of seat assignment -A logical set is interprested as a group of devices that usually belong to a +A logical set is interpreted as a group of devices that usually belong to a single user that interacts with a computer. Thus, the devices are semantically related. This means for devices within the same logical seat: diff --git a/doc/tapping.dox b/doc/tapping.dox index 483219a..e704400 100644 --- a/doc/tapping.dox +++ b/doc/tapping.do
Re: [PATCH libinput] tablet: Do not create a tablet device for Wacom touchscreens
On 8/17/2015 7:21 PM, Peter Hutterer wrote:
> On Mon, Aug 17, 2015 at 05:29:14PM -0700, Jason Gerecke wrote:
>> Similar to the issue mentioned in the commit message of 2365f7d, libwacom
>> assigns both ID_INPUT_TABLET and ID_INPUT_TOUCHSCREEN to touchscreens like
>> the Cintiq 24HDT. This patch ensures that neither touchpads nor touchscreens
>> will accidentally be handled by the tablet code.
>
> I'm confused, isnt this the same as 10ca39cf80698cedf92?
>
> Cheers,
>Peter
>
Looks like my wires got crossed. I was apparently working off of your
Github repository instead of FDO. Pardon the noise.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
>>
>> Signed-off-by: Jason Gerecke
>> ---
>> src/evdev.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/evdev.c b/src/evdev.c
>> index bbc3dce..a4bdb9a 100644
>> --- a/src/evdev.c
>> +++ b/src/evdev.c
>> @@ -1495,8 +1495,10 @@ evdev_configure_device(struct evdev_device *device)
>> /* libwacom assigns touchpad _and_ tablet to the tablet touch bits,
>> so make sure we don't initialize the tablet interface for the
>> touch device */
>> -if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD)) ==
>> - EVDEV_UDEV_TAG_TABLET) {
>> +if ((udev_tags & (EVDEV_UDEV_TAG_TABLET |
>> + EVDEV_UDEV_TAG_TOUCHPAD |
>> + EVDEV_UDEV_TAG_TOUCHSCREEN)) ==
>> +EVDEV_UDEV_TAG_TABLET) {
>> device->dispatch = evdev_tablet_create(device);
>> device->seat_caps |= EVDEV_DEVICE_TABLET;
>> log_info(libinput,
>> --
>> 2.5.0
>>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] tablet: Do not create a tablet device for Wacom touchscreens
Similar to the issue mentioned in the commit message of 2365f7d, libwacom
assigns both ID_INPUT_TABLET and ID_INPUT_TOUCHSCREEN to touchscreens like
the Cintiq 24HDT. This patch ensures that neither touchpads nor touchscreens
will accidentally be handled by the tablet code.
Signed-off-by: Jason Gerecke
---
src/evdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index bbc3dce..a4bdb9a 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1495,8 +1495,10 @@ evdev_configure_device(struct evdev_device *device)
/* libwacom assigns touchpad _and_ tablet to the tablet touch bits,
so make sure we don't initialize the tablet interface for the
touch device */
- if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD)) ==
-EVDEV_UDEV_TAG_TABLET) {
+ if ((udev_tags & (EVDEV_UDEV_TAG_TABLET |
+ EVDEV_UDEV_TAG_TOUCHPAD |
+ EVDEV_UDEV_TAG_TOUCHSCREEN)) ==
+ EVDEV_UDEV_TAG_TABLET) {
device->dispatch = evdev_tablet_create(device);
device->seat_caps |= EVDEV_DEVICE_TABLET;
log_info(libinput,
--
2.5.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] touchpad: count the tapping fingers separately from the main touchpad code
On 4/7/2015 8:54 PM, Peter Hutterer wrote:
tp->nfingers_down gives us the current state of the touchpad but in the case
of the tapping state we need the touchpoints separately. If all touchpoints
end in the same SYN_REPORT frame, tp->nfingers_down is 0 when we handle the
touch releases. This changes the tap state to IDLE on the first release and
then logs a bug when the remaining touches are released while the touchpad is
in IDLE.
Avoid this by counting the fingers separately for the tap state, this way we
can count up/down with the down/up events as we process them for the tapping
state machine.
This also adds tests for 4 and 5-finger tapping which is how the bug was
discovered in the first place.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer
The summary doesn't seem to jive with what I see. In particular, the
scenario it describes doesn't seem to apply: I can have four touches go
up across two frames and see the error, or three touches all disappear
in a single frame and not see it. Additionally, it doesn't seem like
"tp->nfingers_down gives us the current state of the touchpad" since the
value is reset to 0 if five or more fingers are physically present (due
to the behavior of 'tp_unhover_touches' mentioned in the bug report).
That said, the patch *does* prevent the error messages from appearing,
so at the very least:
Tested-by: Jason Gerecke
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours
---
src/evdev-mt-touchpad-tap.c | 5 +-
src/evdev-mt-touchpad.h | 1 +
test/touchpad.c | 233
3 files changed, 238 insertions(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index 4ba4ad2..78d4a0f 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src/evdev-mt-touchpad-tap.c
@@ -452,7 +452,7 @@ tp_tap_dead_handle_event(struct tp_dispatch *tp,
switch (event) {
case TAP_EVENT_RELEASE:
- if (tp->nfingers_down == 0)
+ if (tp->tap.tap_finger_count == 0)
tp->tap.state = TAP_STATE_IDLE;
break;
case TAP_EVENT_TOUCH:
@@ -567,10 +567,12 @@ tp_tap_handle_state(struct tp_dispatch *tp, uint64_t time)
t->tap.state = TAP_TOUCH_STATE_DEAD;
if (t->state == TOUCH_BEGIN) {
+ tp->tap.tap_finger_count++;
t->tap.state = TAP_TOUCH_STATE_TOUCH;
t->tap.initial = t->point;
tp_tap_handle_event(tp, t, TAP_EVENT_TOUCH, time);
} else if (t->state == TOUCH_END) {
+ tp->tap.tap_finger_count--;
tp_tap_handle_event(tp, t, TAP_EVENT_RELEASE, time);
t->tap.state = TAP_TOUCH_STATE_IDLE;
} else if (tp->tap.state != TAP_STATE_IDLE &&
@@ -754,6 +756,7 @@ tp_release_all_taps(struct tp_dispatch *tp, uint64_t now)
}
tp->tap.state = tp->nfingers_down ? TAP_STATE_DEAD : TAP_STATE_IDLE;
+ tp->tap.tap_finger_count = 0;
}
void
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 19a262e..b88dadd 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -255,6 +255,7 @@ struct tp_dispatch {
struct libinput_timer timer;
enum tp_tap_state state;
uint32_t buttons_pressed;
+ unsigned int tap_finger_count;
} tap;
struct {
diff --git a/test/touchpad.c b/test/touchpad.c
index 6fa2301..b06e00d 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -369,6 +369,38 @@ START_TEST(touchpad_2fg_tap_inverted)
}
END_TEST
+START_TEST(touchpad_2fg_tap_quickrelease)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev->libinput;
+
+ libinput_device_config_tap_set_enabled(dev->libinput_device,
+ LIBINPUT_CONFIG_TAP_ENABLED);
+
+ litest_drain_events(dev->libinput);
+
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_down(dev, 1, 70, 70);
+ litest_event(dev, EV_ABS, ABS_MT_SLOT, 0);
+ litest_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
+ litest_event(dev, EV_ABS, ABS_MT_SLOT, 1);
+ litest_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
+ litest_event(dev, EV_KEY, BTN_TOOL_DOUBLETAP, 0);
+ litest_event(dev, EV_KEY, BTN_TOUCH, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_RIGHT,
+ L
Re: [PATCH libinput v2 0/4] touchpad gestures support
On 3/26/2015 2:04 AM, Hans de Goede wrote: Hi All, Here is v2 of my touchpad gestures support patch series, changes since v1: - Merge the gesture capability flag and event-debug patched into the "touchpad: Add an API for touchpad gesture events" - Update the swipe and pinch/rotate implementations to work with the new typesafe device and normalized coordinates (rebased on latest master), this results in a nice cleanup Regards, Hans Gave these a spin with an Intuos Pro. Aside from an unrelated issue when using 5+ fingers[1], the patchset seems to work well. I have some trouble with the 3 cm heuristic (about half the time I try to scroll, its interpreted as a pinch) but I'd probably get used to it after a little use. Acked-by: Jason Gerecke [1]: https://bugs.freedesktop.org/show_bug.cgi?id=89800 Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] tools: List relative wheel among axis capabilities
Signed-off-by: Jason Gerecke
---
For Peter's tablet-support branch.
tools/event-debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/event-debug.c b/tools/event-debug.c
index d2ac415..e8e49cd 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -480,6 +480,8 @@ print_proximity_event(struct libinput_event *ev)
printf("r");
if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_SLIDER))
printf("s");
+ if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_REL_WHEEL))
+ printf("w");
printf("\tbtn:");
if (libinput_tool_has_button(tool, BTN_TOUCH))
--
2.3.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] evdev: Do not mark tablet touchscreens as tablets
Devices like the Cintiq 24HDT are marked with both ID_INPUT_TABLET and
ID_INPUT_TOUCHSCREEN in udev. Be sure that we don't try to use such a
device as a tablet.
Signed-off-by: Jason Gerecke
---
For Peter's tablet-support branch.
src/evdev.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 19226fe..c57ac4f 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1636,11 +1636,11 @@ evdev_configure_device(struct evdev_device *device)
}
}
- /* libwacom assigns touchpad _and_ tablet to the tablet touch bits,
- so make sure we don't initialize the tablet interface for the
- touch device */
- if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD)) ==
-EVDEV_UDEV_TAG_TABLET) {
+ /* libwacom assigns touchpad (or touchscreen) _and_ tablet to the
+ tablet touch bits, so make sure we don't initialize the tablet
+ interface for the touch device */
+ if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD|
+ EVDEV_UDEV_TAG_TOUCHSCREEN)) == EVDEV_UDEV_TAG_TABLET) {
device->dispatch = evdev_tablet_create(device);
device->seat_caps |= EVDEV_DEVICE_TABLET;
log_info(libinput,
--
2.3.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2 libinput 2/2] buttonset: implement buttonset handling for Wacom tablet pads
Did some practical testing of these patches and noticed two issues with
the touchstrips:
On 3/17/2015 11:58 PM, Peter Hutterer wrote:
From: Benjamin Tissoires
Same approach as evdev-tablet (started as copy/paste), with axis and buttons
adjusted. Wacom's handling of pad devices requires a lot of non-obvious
handling, e.g. ABS_THROTTLE is the second ring, ABS_RX is the strip, etc.
This is not generic buttonset code, if we start supporting other devices for
buttonsets we'll factor out a couple of the functions.
The wheel and strip events are a bit of a problem: Wacom sends a 0 event on the
axis when the finger is released. We can detect this if there is an ABS_MISC 0
present in the same event and suppress it. Won't work if any finger is down
on any other wheel, strip or button but that's a kernel bug we'll fix once we
figure out how.
Signed-off-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
src/Makefile.am | 2 +
src/evdev-buttonset-wacom.c | 533
src/evdev-buttonset-wacom.h | 63 ++
src/evdev.c | 18 +-
src/evdev.h | 3 +
src/libinput-private.h | 16 ++
src/libinput.c | 65 ++
7 files changed, 691 insertions(+), 9 deletions(-)
create mode 100644 src/evdev-buttonset-wacom.c
create mode 100644 src/evdev-buttonset-wacom.h
[...]
>
+static inline double
+normalize_strip(const struct input_absinfo *absinfo)
+{
+ /* strip axes don't use a proper value, they just shift the bit left
+* for each position. 0 isn't a real value either, it's only sent on
+* finger release */
+ double min = 1,
Min should be set to 0 (i.e., log2(1)) here.
+ max = log2(absinfo->maximum);
+ double range = max - min;
+ double value = (log2(absinfo->value) - min) / range;
+
+ return value;
+}
+
+/* Detect ring wraparound, current and old are normalized to [0, 1[ */
+static inline double
+guess_ring_delta(double current, double old)
+{
+ double d1, d2, d3;
+
+ d1 = current - old;
+ d2 = (current + 1) - old;
+ d3 = current - (old + 1);
+
+ if (fabs(d2) < fabs(d1))
+ d1 = d2;
+
+ if (fabs(d3) < fabs(d1))
+ d1 = d3;
+
+ return d1;
+}
+
+static void
+buttonset_check_notify_axes(struct buttonset_dispatch *buttonset,
+ struct evdev_device *device,
+ uint32_t time)
+{
+ struct libinput_device *base = &device->base;
+ bool axis_update_needed = false;
+ double deltas[LIBINPUT_BUTTONSET_MAX_NUM_AXES] = {0};
+ double deltas_discrete[LIBINPUT_BUTTONSET_MAX_NUM_AXES] = {0};
+ unsigned int a;
+ unsigned int code;
+
+ for (a = 0; a <= buttonset->naxes; a++) {
+ const struct input_absinfo *absinfo;
+
+ if (!bit_is_set(buttonset->changed_axes, a))
+ continue;
+
+ code = buttonset->axis_map[a];
+ assert(code != 0);
+ absinfo = libevdev_get_abs_info(device->evdev, code);
+ assert(absinfo);
+
+ switch (buttonset->types[a]) {
+ case LIBINPUT_BUTTONSET_AXIS_RING:
+ buttonset->axes[a] = normalize_ring(absinfo);
+ deltas[a] = guess_ring_delta(buttonset->axes[a],
+buttonset->axes_prev[a]);
+ deltas_discrete[a] = unnormalize_ring_value(absinfo,
+ deltas[a]);
+ break;
+ case LIBINPUT_BUTTONSET_AXIS_STRIP:
+ buttonset->axes[a] = normalize_strip(absinfo);
+ deltas[a] = buttonset->axes[a] -
buttonset->axes_prev[a];
+ break;
When a touch goes up, normalize_strip will return a normalized value of
negative infinity. You should add suppression logic like for the
ABS_MISC case since it isn't a real value.
+ default:
+ log_bug_libinput(device->base.seat->libinput,
+"Invalid axis update: %u\n", a);
+ break;
+ }
+
+ if (buttonset->have_abs_misc_terminator) {
+ /* Suppress the reset to 0 on finger up. See the
+ comment in buttonset_process_absolute */
+ if (libevdev_get_event_value(device->evdev,
+EV_ABS,
+ABS_MISC) == 0) {
+ clear_bit(buttonset->changed_axes, a);
+ buttonset->axes[a] = buttonset->axes_prev[a];
+ continue;
+ /* on finger down, reset the delta to 0 */
+
Re: [RFC v2 libinput 2/2] buttonset: implement buttonset handling for Wacom tablet pads
David's already asked the API questions that popped in my head, so I'll
just wait for feedback on his thread. As far as this patch goes, things
look pretty good though there are two comments:
On 3/17/2015 11:58 PM, Peter Hutterer wrote:
From: Benjamin Tissoires
Same approach as evdev-tablet (started as copy/paste), with axis and buttons
adjusted. Wacom's handling of pad devices requires a lot of non-obvious
handling, e.g. ABS_THROTTLE is the second ring, ABS_RX is the strip, etc.
This is not generic buttonset code, if we start supporting other devices for
buttonsets we'll factor out a couple of the functions.
The wheel and strip events are a bit of a problem: Wacom sends a 0 event on the
axis when the finger is released. We can detect this if there is an ABS_MISC 0
present in the same event and suppress it. Won't work if any finger is down
on any other wheel, strip or button but that's a kernel bug we'll fix once we
figure out how.
Signed-off-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
src/Makefile.am | 2 +
src/evdev-buttonset-wacom.c | 533
src/evdev-buttonset-wacom.h | 63 ++
src/evdev.c | 18 +-
src/evdev.h | 3 +
src/libinput-private.h | 16 ++
src/libinput.c | 65 ++
7 files changed, 691 insertions(+), 9 deletions(-)
create mode 100644 src/evdev-buttonset-wacom.c
create mode 100644 src/evdev-buttonset-wacom.h
diff --git a/src/Makefile.am b/src/Makefile.am
index d5cd4f4..3e36f63 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -10,6 +10,8 @@ libinput_la_SOURCES = \
libinput-private.h \
evdev.c \
evdev.h \
+ evdev-buttonset-wacom.c \
+ evdev-buttonset-wacom.h \
evdev-tablet.c \
evdev-tablet.h \
evdev-mt-touchpad.c \
diff --git a/src/evdev-buttonset-wacom.c b/src/evdev-buttonset-wacom.c
new file mode 100644
index 000..402c6f5
--- /dev/null
+++ b/src/evdev-buttonset-wacom.c
@@ -0,0 +1,533 @@
+/*
+ * Copyright © 2015 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission. The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose. It is provided "as is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "config.h"
+#include "evdev-buttonset-wacom.h"
+
+#include
+#include
+#include
+
+#define buttonset_set_status(buttonset_,s_) (buttonset_)->status |= (s_)
+#define buttonset_unset_status(buttonset_,s_) (buttonset_)->status &= ~(s_)
+#define buttonset_has_status(buttonset_,s_) (!!((buttonset_)->status & (s_)))
+
+static unsigned long *
+buttonset_get_pressed_buttons(struct buttonset_dispatch *buttonset)
+{
+ struct button_state *state = &buttonset->button_state;
+ struct button_state *prev_state = &buttonset->prev_button_state;
+ unsigned int i;
+
+ for (i = 0; i < NLONGS(KEY_CNT); i++)
+ state->buttons_pressed[i] = state->buttons[i]
+ & ~(prev_state->buttons[i]);
+
+ return state->buttons_pressed;
+}
+
+static unsigned long *
+buttonset_get_released_buttons(struct buttonset_dispatch *buttonset)
+{
+ struct button_state *state = &buttonset->button_state;
+ struct button_state *prev_state = &buttonset->prev_button_state;
+ unsigned int i;
+
+ for (i = 0; i < NLONGS(KEY_CNT); i++)
+ state->buttons_pressed[i] = prev_state->buttons[i]
+ & ~(state->buttons[i]);
+
+ return state->buttons_pressed;
+}
+
+static void
+buttonset_process_absolute(struct buttonset_dispatch *buttonset,
+ struct evdev_device *device,
+ struct input_event *e,
+ uint32_t time)
+{
+ unsigned int axis;
+
+ switch (e->code) {
Re: [PATCH v2 libinput 00/26] tablet: support the remaining tools
On 2/23/2015 10:21 PM, Peter Hutterer wrote: This is a v2 of the patchset here http://lists.freedesktop.org/archives/wayland-devel/2015-February/020036.html but reshuffled, rebased and a couple of things merged in. Notable: libinput now uses libwacom to get tool/tablet information. This is complete for this set yet, but a few more fixes are due to go into libwacom (e.g. axis listing) so we can remove this knowledge from libinput. Likewise, the missing eraser stylus buttons Lyude pointed out in the other thread will be fixed in libwacom. If libwacom isn't available, we fall back on basic logic to set the various bits on the tools. mouse buttons and the mouse wheel are now handled. art pen rotation is fixed, was relying on BTN_TOOL_BRUSH first - the art pen is a BTN_TOOL_PEN. other patches have seen a rebase and reshuffle and thus seen slight changes. added get_axis_delta and get_axis_delta_discrete(). The latter for the mouse wheel, the former allows the caller to make a decision about the tablet mode on a per-event or per-client basis. The couple of libwacom issues aside, this should make the tablet-support branch feature-complete. branch available for testing: https://github.com/whot/libinput/tree/wip/wacom-extra-tool-support Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel I've run through all the tools I could get my hands on with an Intuos Pro and everything largely behaves as it should. I do see that the event-debug program aborts upon removing a tool that was in proximity before it started (in print_proximity_event, libnput_tool_get_type returns 0) but haven't been able to track it down further. It also doesn't seem to acknowledge the scroll wheel on my Graphire4 puck, but that's not exactly a high priority (aside from being my daily driver :D) Aside from the in-line patch comments, consider this Reviewed-by. -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 23/26] tools: only print the tablet axes we have on the tool
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
This doesn't really have an effect, since we don't set the per-tool axes
correctly yet.
Signed-off-by: Peter Hutterer
---
tools/event-debug.c | 106 +++-
1 file changed, 56 insertions(+), 50 deletions(-)
diff --git a/tools/event-debug.c b/tools/event-debug.c
index 225e12f..94a90ec 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -288,48 +288,77 @@ tablet_axis_changed_sym(struct libinput_event_tablet *t,
}
static void
-print_tablet_axis_event(struct libinput_event *ev)
+print_tablet_axes(struct libinput_event_tablet *t)
{
- struct libinput_event_tablet *t = libinput_event_get_tablet_event(ev);
+ struct libinput_tool *tool = libinput_event_tablet_get_tool(t);
double x, y;
double dist, pressure;
double rotation, slider;
- print_event_time(libinput_event_tablet_get_time(t));
-
Nitpick: Should be in a separate change or mentioned in the description.
x = libinput_event_tablet_get_axis_value(t, LIBINPUT_TABLET_AXIS_X);
y = libinput_event_tablet_get_axis_value(t, LIBINPUT_TABLET_AXIS_Y);
printf("\t%.2f%s/%.2f%s",
x, tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_X),
y, tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_Y));
- x = libinput_event_tablet_get_axis_value(t, LIBINPUT_TABLET_AXIS_TILT_X);
- y = libinput_event_tablet_get_axis_value(t,
LIBINPUT_TABLET_AXIS_TILT_Y);
- printf("\ttilt: %.2f%s/%.2f%s ",
- x, tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_TILT_X),
- y, tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_TILT_Y));
+ if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_TILT_X) ||
+ libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_TILT_Y)) {
+ x = libinput_event_tablet_get_axis_value(t,
+LIBINPUT_TABLET_AXIS_TILT_X);
+ y = libinput_event_tablet_get_axis_value(t,
+LIBINPUT_TABLET_AXIS_TILT_Y);
+ printf("\ttilt: %.2f%s/%.2f%s ",
+ x, tablet_axis_changed_sym(t,
+ LIBINPUT_TABLET_AXIS_TILT_X),
+ y, tablet_axis_changed_sym(t,
+ LIBINPUT_TABLET_AXIS_TILT_Y));
+ }
- dist = libinput_event_tablet_get_axis_value(t, LIBINPUT_TABLET_AXIS_DISTANCE);
- pressure = libinput_event_tablet_get_axis_value(t,
LIBINPUT_TABLET_AXIS_PRESSURE);
- if (dist)
- printf("distance: %.2f%s",
- dist, tablet_axis_changed_sym(t,
LIBINPUT_TABLET_AXIS_DISTANCE));
- else
- printf("pressure: %.2f%s",
- pressure, tablet_axis_changed_sym(t,
LIBINPUT_TABLET_AXIS_PRESSURE));
+ if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_DISTANCE) ||
+ libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_PRESSURE)) {
+ dist = libinput_event_tablet_get_axis_value(t,
+ LIBINPUT_TABLET_AXIS_DISTANCE);
+ pressure = libinput_event_tablet_get_axis_value(t,
+ LIBINPUT_TABLET_AXIS_PRESSURE);
+ if (dist) {
+ printf("\tdistance: %.2f%s",
+ dist,
+ tablet_axis_changed_sym(t,
+ LIBINPUT_TABLET_AXIS_DISTANCE));
+ } else {
+ printf("\tpressure: %.2f%s",
+ pressure,
+ tablet_axis_changed_sym(t,
+ LIBINPUT_TABLET_AXIS_PRESSURE));
+ }
+ }
- rotation = libinput_event_tablet_get_axis_value(t,
+ if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_ROTATION_Z)) {
+ rotation = libinput_event_tablet_get_axis_value(t,
LIBINPUT_TABLET_AXIS_ROTATION_Z);
- printf(" rotation: %.2f%s",
- rotation,
- tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_ROTATION_Z));
+ printf("\trotation: %.2f%s",
+ rotation,
+ tablet_axis_changed_sym(t,
+ LIBINPUT_TABLET_AXIS_ROTATION_Z));
+ }
- slider = libinput_event_tablet_get_axis_value(t,
+ if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_SLIDER)) {
+ slider = libinput_event_tablet_get_axis_value(t,
LIBINPUT_TABLET_AXIS_SLIDER);
- printf(" slider: %.2f%s",
- slider,
- tablet_axis_changed_sym(t, LIBINPUT_TABLET_AXIS_SLIDER));
+ printf("\tslider: %.2f%s",
+ slider,
+ tablet_axis_cha
Re: [PATCH libinput 21/26] tablet: support artpen rotation
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer
---
src/evdev-tablet.c | 35 +++-
src/evdev-tablet.h | 6
src/libinput.h | 3 +-
test/tablet.c | 95 ++
4 files changed, 130 insertions(+), 9 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 143d618..d05b6c2 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -103,6 +103,7 @@ tablet_process_absolute(struct tablet_dispatch *tablet,
switch (e->code) {
case ABS_X:
case ABS_Y:
+ case ABS_Z:
case ABS_PRESSURE:
case ABS_TILT_X:
case ABS_TILT_Y:
@@ -240,6 +241,16 @@ convert_tilt_to_rotation(struct tablet_dispatch *tablet)
set_bit(tablet->changed_axes, LIBINPUT_TABLET_AXIS_ROTATION_Z);
}
+static double
+convert_to_degrees(const struct input_absinfo *absinfo, double offset)
+{
+ /* range is [0, 360[, i.e. range + 1 */
+ double range = absinfo->maximum - absinfo->minimum + 1;
+ double value = (absinfo->value - absinfo->minimum) / range;
+
+ return fmod(value * 360.0 + offset, 360.0);
+}
+
static void
tablet_check_notify_axes(struct tablet_dispatch *tablet,
struct evdev_device *device,
@@ -263,14 +274,13 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
/* ROTATION_Z is higher than TILT_X/Y so we know that the
tilt axes are already normalized and set */
- if (a == LIBINPUT_TABLET_AXIS_ROTATION_Z) {
- if (tablet->current_tool_type == LIBINPUT_TOOL_MOUSE ||
- tablet->current_tool_type == LIBINPUT_TOOL_LENS) {
- convert_tilt_to_rotation(tablet);
- axes[LIBINPUT_TABLET_AXIS_TILT_X] = 0;
- axes[LIBINPUT_TABLET_AXIS_TILT_Y] = 0;
- axes[a] = tablet->axes[a];
- }
+ if (a == LIBINPUT_TABLET_AXIS_ROTATION_Z &&
+ (tablet->current_tool_type == LIBINPUT_TOOL_MOUSE ||
+ tablet->current_tool_type == LIBINPUT_TOOL_LENS)) {
+ convert_tilt_to_rotation(tablet);
+ axes[LIBINPUT_TABLET_AXIS_TILT_X] = 0;
+ axes[LIBINPUT_TABLET_AXIS_TILT_Y] = 0;
+ axes[a] = tablet->axes[a];
Nitpick: Squash into patch 19 ("support z-rotation for the mouse/lens tool")
continue;
}
@@ -294,6 +304,10 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
case LIBINPUT_TABLET_AXIS_TILT_Y:
tablet->axes[a] = normalize_tilt(absinfo);
break;
+ case LIBINPUT_TABLET_AXIS_ROTATION_Z:
+ /* artpen has 0 with buttons pointing east */
+ tablet->axes[a] = convert_to_degrees(absinfo, 90);
+ break;
default:
log_bug_libinput(device->base.seat->libinput,
"Invalid axis update: %d\n", a);
@@ -506,6 +520,10 @@ tool_set_bits_from_libwacom(const struct tablet_dispatch
*tablet,
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_SLIDER);
/* fall-through */
case WSTYLUS_MARKER:
+ if (type == WSTYLUS_MARKER)
+ copy_axis_cap(tablet, tool,
+ LIBINPUT_TABLET_AXIS_ROTATION_Z);
+ /* fallthrough */
case WSTYLUS_GENERAL:
case WSTYLUS_INKING:
case WSTYLUS_CLASSIC:
@@ -555,6 +573,7 @@ tool_set_bits(const struct tablet_dispatch *tablet,
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_TILT_X);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_TILT_Y);
copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_SLIDER);
+ copy_axis_cap(tablet, tool, LIBINPUT_TABLET_AXIS_ROTATION_Z);
break;
case LIBINPUT_TOOL_MOUSE:
case LIBINPUT_TOOL_LENS:
diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
index d86bf9e..7c472cf 100644
--- a/src/evdev-tablet.h
+++ b/src/evdev-tablet.h
@@ -75,6 +75,9 @@ evcode_to_axis(const uint32_t evcode)
case ABS_Y:
axis = LIBINPUT_TABLET_AXIS_Y;
break;
+ case ABS_Z:
+ axis = LIBINPUT_TABLET_AXIS_ROTATION_Z;
+ break;
case ABS_DISTANCE:
axis = LIBINPUT_TABLET_AXIS_DISTANCE;
break;
@@ -122,6 +125,9 @@ axis_to_evcode(const enum libinput_tablet_axis axis)
case LIBINPUT_TABLET_AXIS_TILT_Y:
evcode = ABS_TILT_Y;
break;
+ case LIBINPUT_TABLET_AXIS_ROTATION_Z:
+ evcode = ABS_Z;
+ break;
case LIBINPUT_TABLET_AX
Re: [PATCH libinput 19/26] tablet: support z-rotation for the mouse/lens tool
On 2/23/2015 10:21 PM, Peter Hutterer wrote:
Needs to be calculated from the x/y tilt values, the mouse has a fixed offset
of 175 degrees counterclockwise.
Signed-off-by: Peter Hutterer
---
src/evdev-tablet.c | 88 +-
src/libinput-private.h | 2 +-
src/libinput.c | 1 +
src/libinput.h | 6
test/tablet.c | 77 +++
tools/event-debug.c| 8 +
6 files changed, 173 insertions(+), 9 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 52742cf..dce7ced 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -71,12 +71,25 @@ static int
tablet_device_has_axis(struct tablet_dispatch *tablet,
enum libinput_tablet_axis axis)
{
+ struct libevdev *evdev = tablet->device->evdev;
+ bool has_axis = false;
unsigned int code;
- code = axis_to_evcode(axis);
- return libevdev_has_event_code(tablet->device->evdev,
- EV_ABS,
- code);
+ if (axis == LIBINPUT_TABLET_AXIS_ROTATION_Z) {
+ has_axis = (libevdev_has_event_code(evdev,
+ EV_ABS,
+ ABS_TILT_X) &&
+ libevdev_has_event_code(evdev,
+ EV_ABS,
+ ABS_TILT_Y));
+ } else {
+ code = axis_to_evcode(axis);
+ has_axis = libevdev_has_event_code(evdev,
+ EV_ABS,
+ code);
+ }
+
+ return has_axis;
}
static void
@@ -201,6 +214,32 @@ invert_axis(const struct input_absinfo *absinfo)
}
static void
+convert_tilt_to_rotation(struct tablet_dispatch *tablet)
+{
+ const int offset = 5;
Does this offset actually exist? The I4 mouse I'm testing with behaves
as there is no offset, and nothing I can find internally suggests that
one actually exists. I'm almost tempted to say that its a bug despite
being in linuxwacom since seemingly the dawn of time. If either you or
Benjamin (or anyone else) has an I4 mouse, I'd be interested in knowing
what results you get.
+ double x, y;
+ double angle = 0.0;
+
+ /* Wacom Intuos 4, 5, Pro mouse calculates rotation from the x/y tilt
+ values. The device has a 175 degree CCW hardware offset but since we
use
+ atan2 the effective offset is just 5 degrees.
+ */
+ x = tablet->axes[LIBINPUT_TABLET_AXIS_TILT_X];
+ y = tablet->axes[LIBINPUT_TABLET_AXIS_TILT_Y];
+ clear_bit(tablet->changed_axes, LIBINPUT_TABLET_AXIS_TILT_X);
+ clear_bit(tablet->changed_axes, LIBINPUT_TABLET_AXIS_TILT_Y);
+
+ /* atan2 is CCW, we want CW -> negate x */
+ if (x || y)
+ angle = ((180.0 * atan2(-x, y)) / M_PI);
Strictly speaking, atan2 should be fed the sine of the x and y tilt
angles (...another longstanding linuxwacom bug?)
+
+ angle = fmod(360 + angle - offset, 360);
+
+ tablet->axes[LIBINPUT_TABLET_AXIS_ROTATION_Z] = angle;
+ set_bit(tablet->changed_axes, LIBINPUT_TABLET_AXIS_ROTATION_Z);
+}
+
+static void
tablet_check_notify_axes(struct tablet_dispatch *tablet,
struct evdev_device *device,
uint32_t time,
@@ -209,12 +248,30 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
struct libinput_device *base = &device->base;
bool axis_update_needed = false;
int a;
+ double axes[LIBINPUT_TABLET_AXIS_MAX + 1] = {0};
for (a = LIBINPUT_TABLET_AXIS_X; a <= LIBINPUT_TABLET_AXIS_MAX; a++) {
const struct input_absinfo *absinfo;
- if (!bit_is_set(tablet->changed_axes, a))
+ if (!bit_is_set(tablet->changed_axes, a)) {
+ axes[a] = tablet->axes[a];
continue;
+ }
+
+ axis_update_needed = true;
+
+ /* ROTATION_Z is higher than TILT_X/Y so we know that the
+ tilt axes are already normalized and set */
+ if (a == LIBINPUT_TABLET_AXIS_ROTATION_Z) {
+ if (tablet->current_tool_type == LIBINPUT_TOOL_MOUSE ||
+ tablet->current_tool_type == LIBINPUT_TOOL_LENS) {
+ convert_tilt_to_rotation(tablet);
+ axes[LIBINPUT_TABLET_AXIS_TILT_X] = 0;
+ axes[LIBINPUT_TABLET_AXIS_TILT_Y] = 0;
+ axes[a] = tablet->axes[a];
+ }
+ continue;
+ }
absinfo = libevdev_get_abs_info(device->evdev,
axis
Re: [PATCH libinput 12/26] tablet: explicitly ignore ABS_THROTTLE, ABS_RX, ABS_RY, and ABS_RZ
On 2/23/2015 10:21 PM, Peter Hutterer wrote: ABS_THROTTLE: Tablets still advertise this axis but the mouse itself isn't available anymore. The Pad sends the second wheel as ABS_THROTTLE but that's a task for the buttonset interface. Explanation of what the throttle did on page http://101.wacom.com/productsupport/manual/Intuos2UsersManual.pdf ABS_RX/ABS_RY: These only happen on the Intuos3 device and only on the Pad device (kernel >= 3.17) ABS_RZ: The 4D mouse for the Intuos2, obsolete. No functional changes, this is to clarify why we're only handling a subset of codes. Signed-off-by: Peter Hutterer --- src/evdev-tablet.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c index 14fb44f..820473f 100644 --- a/src/evdev-tablet.c +++ b/src/evdev-tablet.c @@ -71,6 +71,17 @@ tablet_process_absolute(struct tablet_dispatch *tablet, case ABS_MISC: tablet->current_tool_id = e->value; break; + /* Intuos 3 strip data. Should only happen on the Pad device, not on + the Pen device. */ + case ABS_RX: + case ABS_RY: + /* Only on the 4D mouse (Intuos2), obsolete */ + case ABS_RZ: + /* Only on the 4D mouse (Intuos2), obsolete. + The 24HD sends ABS_THROTTLE on the Pad device for the second + wheel but we shouldn't get here on kernel >= 3.17. + */ + case ABS_THROTTLE: default: log_info(device->base.seat->libinput, "Unhandled ABS event code %#x\n", e->code); Just to confirm: these axes aren't ignored because they're problematic, but because supporting those old tools isn't worth the effort? I don't think I can complain :) -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC libinput 1/2] Add a "buttonset" interface for button-only devices
On Wed, Feb 18, 2015 at 5:29 PM, Peter Hutterer wrote: > On Wed, Feb 18, 2015 at 01:57:17PM -0800, Jason Gerecke wrote: >> >> On 2/16/2015 9:11 PM, Peter Hutterer wrote: >> >On Mon, Feb 16, 2015 at 08:13:01AM +0100, Hans de Goede wrote: >> >>Hi, >> >> >> >>On 16-02-15 04:50, Peter Hutterer wrote: >> >> >> >> >> >> >> >>>ok, I've played around with the ideas in this thread and discussed it with >> >>>Benjamin this morning. Short summary: I think we should go with the >> >>>original >> >>>patch, with an optional extension for numbered axes later. >> >>> >> >>>I tried the enum spacing first, providing an API where we have >> >>>LIBINPUT_BUTTONSET_AXIS_TYPE_COUNT = 512 >> >>>LIBINPUT_BUTTONSET_AXIS_RING = 512 >> >>>LIBINPUT_BUTTONSET_AXIS_STRIP = 1024 >> >>> >> >>>so the caller can use code like >> >>>libinput_event_buttonset_get_axis_value(event, >> >>>LIBINPUT_BUTTONSET_AXIS_RING + 2); >> >>>to get the third axis. switching event-debug showed the issues with this >> >>>approach: to effectively go through the axes, the client needs two loops, >> >>>one for the type one for the number and mask the enum into a type and a >> >>>number component, something that's prone to bugs. >> >>> >> >>>Next attempt was to split value and axis number explicitly in the API: >> >>>libinput_event_buttonset_get_axis_value(event, >> >>>LIBINPUT_BUTTONSET_AXIS_RING, >> >>>2); >> >>>Better than the above as it's less error-prone. >> >>>It still doesn't remove the above issue though, nested loops everywhere to >> >>>access the type and the number. >> >>>event-debug is a special case in that it doesn't care about the content >> >>>and >> >>>cares more about listing/printing everything. However I suspect that any >> >>>generic toolkit will require the same. >> >>> >> >>>[Internally both changes are a bit of a nightmare as both would require >> >>>some >> >>>rewriting, but that's solveable] >> >>> >> >>>So the question is now: what does this gain us? better handling of truly >> >>>generic devices with random axes. Which leads into the next question: what >> >>>are random axes? >> >>>The above approach is over-engineered because there's a group of axes >> >>>that only exists once. I don't think there's a device with two X axes on >> >>>the >> >>>same device for example. Likewise, there are axes that have more use being >> >>>semantically labelled than just numbered. The ring axes are a good >> >>>example, >> >>>the current RING and RING2 naming is bad, we should name it RING_LEFT, >> >>>RING_RIGHT instead. >> >>> >> >>>Other than say a mix table we'll likely find semantic naming for a >> >>>majority >> >>>of the device. For the other devices, we can use a hybrid approach: >> >>>leave the current API to use enums but in the future, when we require more >> >>>flexible axes or devices with multiple identical axes we can add calls >> >>>like: >> >>>libinput_device_buttonset_has_axis_by_offset(event, axis_number); >> >>>libinput_device_buttonset_get_axis_type_by_offset(event, axis_number); >> >>>libinput_event_buttonset_get_axis_value_by_offset(event, >> >>> axis_number); >> >>> >> >>>etc. this would require a duplication of the buttonset API with a >> >>>by_offset >> >>>prefix but is otherwise straightforward and leaves the most expressive API >> >>>as the default one. >> >>> >> >>>We also discussed making an axis an object (struct >> >>>libinput_buttonset_axis) >> >>>and providing a get_axis(enum) and a get_axis_by_offset(number) call. That >> >>>object could've then be used in the API. I don't think it's a good idea to >> >>>do this, it adds complexity (ref, unref, userdata)
Re: [PATCH libinput 00/15] tablet: support the remaining tools
On 2/17/2015 9:45 PM, Peter Hutterer wrote: This patchset adds the remaining tools to the tablet branch (at least for Wacom tools). The notable additions are: * rotation support for mouse/lens cursor * rotation support for the artpen * 'wheel' support for the airbrush * correct per-tool capabilities (including buttons) If you have one of those tools handy, give it a test, most of this was lifted from memory, specs and code I had written in the past - not with an actual physical device at hand. Branch is available for testing here: https://github.com/whot/libinput/tree/wip/wacom-extra-tool-support Cheers, Peter I've got another project currently eating my time, but I'll try to start on a test-drive and review of these patches sometime next week if I can. -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC libinput 1/2] Add a "buttonset" interface for button-only devices
On 2/16/2015 9:11 PM, Peter Hutterer wrote: On Mon, Feb 16, 2015 at 08:13:01AM +0100, Hans de Goede wrote: Hi, On 16-02-15 04:50, Peter Hutterer wrote: ok, I've played around with the ideas in this thread and discussed it with Benjamin this morning. Short summary: I think we should go with the original patch, with an optional extension for numbered axes later. I tried the enum spacing first, providing an API where we have LIBINPUT_BUTTONSET_AXIS_TYPE_COUNT = 512 LIBINPUT_BUTTONSET_AXIS_RING = 512 LIBINPUT_BUTTONSET_AXIS_STRIP = 1024 so the caller can use code like libinput_event_buttonset_get_axis_value(event, LIBINPUT_BUTTONSET_AXIS_RING + 2); to get the third axis. switching event-debug showed the issues with this approach: to effectively go through the axes, the client needs two loops, one for the type one for the number and mask the enum into a type and a number component, something that's prone to bugs. Next attempt was to split value and axis number explicitly in the API: libinput_event_buttonset_get_axis_value(event, LIBINPUT_BUTTONSET_AXIS_RING, 2); Better than the above as it's less error-prone. It still doesn't remove the above issue though, nested loops everywhere to access the type and the number. event-debug is a special case in that it doesn't care about the content and cares more about listing/printing everything. However I suspect that any generic toolkit will require the same. [Internally both changes are a bit of a nightmare as both would require some rewriting, but that's solveable] So the question is now: what does this gain us? better handling of truly generic devices with random axes. Which leads into the next question: what are random axes? The above approach is over-engineered because there's a group of axes that only exists once. I don't think there's a device with two X axes on the same device for example. Likewise, there are axes that have more use being semantically labelled than just numbered. The ring axes are a good example, the current RING and RING2 naming is bad, we should name it RING_LEFT, RING_RIGHT instead. Other than say a mix table we'll likely find semantic naming for a majority of the device. For the other devices, we can use a hybrid approach: leave the current API to use enums but in the future, when we require more flexible axes or devices with multiple identical axes we can add calls like: libinput_device_buttonset_has_axis_by_offset(event, axis_number); libinput_device_buttonset_get_axis_type_by_offset(event, axis_number); libinput_event_buttonset_get_axis_value_by_offset(event, axis_number); etc. this would require a duplication of the buttonset API with a by_offset prefix but is otherwise straightforward and leaves the most expressive API as the default one. We also discussed making an axis an object (struct libinput_buttonset_axis) and providing a get_axis(enum) and a get_axis_by_offset(number) call. That object could've then be used in the API. I don't think it's a good idea to do this, it adds complexity (ref, unref, userdata) and effectively reduces the API to magic numbers/variable names again. so long story short, I think we should go with the enum after all and leave numbered/offset axes for the future when we need it. And I do still believe we need an UNKNOWN axis, at XDC we were talking about these button boxes people could buy to use with midi-apps, which were just a bunch of dials, I don't want to do a database of those, so for such a device we should just end up saying this is a buttonbox with UNKNOWN axis, which when absolute must be used with get_transformed only, and the deltas are in an unknown unit, but we can cross that bridge when we get there. once the axis is labelled once, it effectively becomes ABI. if we label something as unknown and then fix it in a later version of libinput we will break things. so we should hide anything we don't know enough about. Nothing stops us from adding a LINEAR_ACTUATOR, MIDI_DIAL, etc. though. Hmm, I still have the feeling the end result is going to be way less generic then what we had in mind when we introduced the buttonset concept, it seems that you're more solving the tablet buttons problem here then introducing a general buttonset API. But if you and Benjamin believe that this is the right way forward lets go with this, we can always extend the API later. yeah, tbh the tablet case is the most obvious for now, it's likely to be the prime use-case for this interface. A truly generic interface with just numbered axes is IMO a lot easier to tack on top than the other way round. Cheers, Peter I'm also somewhat wary of proposed semantic interface. Sure, if the controls had silkscreened labels indicating what they do, then it'd make a lot of sense. Generally speaking th
Re: [PATCH libinput 2/3] Implement support for pen barrel rotation
My primary complaint is that "X" and "Y" are both translational axes,
and by analogy "Z" should be as well. Using it as the name for a
rotational axis just muddies things, especially when we already have
"DISTANCE". My second complaint is the same as Peter's: it should be
clear that is axis is in the tool's frame of reference. I chose
"TWIST" because it suffers from neither issue, though I admit "ROLL"
is probably the better term :)
The use of 'Z' for rotation elsewhere is mostly because other bits of
code have followed our (poor) lead. The kernel's Wacom driver has been
using ABS_Z for rotation for more than 6 years, but mostly only
because there's been no more semantically-correct axis for us to use.
Our pucks* use ABS_RZ to report their rotation angle (which is fine
since they're used parallel to the tablet), but there's nothing that
quite semantically means "rotation about the tool's Z axis" so we went
with the best option available: ABS_Z.
Speaking of the pucks... I'm assuming that when I get around to adding
them, we want to have an "RZ" (a'la HID) or "ORIENTATION" (a'la evdev
MT) axis for their rotation since it's not really about the tool's own
major axis.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
On Mon, Dec 8, 2014 at 4:12 PM, Bill Spitzak wrote:
> You are right that the fact that it is along the pen is not obvious from
> "Z". However this is actually true of "X" and "Y" (one of them could be the
> angle in the plane defined by the other tilt).
>
> Roll probably is good, but it still seems to me that Z is more common, also
> it looks like the evdev library is using "Z" from your code.
>
>
> On 12/08/2014 03:24 PM, Peter Hutterer wrote:
>>
>> On Mon, Dec 08, 2014 at 12:13:17PM -0800, Bill Spitzak wrote:
>>>
>>> Why not call it Z instead of TWIST?
>>>
>>> I'm pretty certain that is a common term for this movement, and that
>>> "twist"
>>> is a rather strange term ("roll" is used more). And Z has the advantage
>>> that
>>> it also implies that counter-clockwise is positive.
>>
>>
>> my main issue with Z is that it's not immediately clear what it refers to
>> in
>> the context of a tablet. x/y is relative to the tablet itself, not the
>> stylus, so Z could be interpreted to be the same. twist isn't though, it
>> relates to the stylus rotation regardless of tilt.
>>
>> Having said, I do like the term roll, better than twist.
>>
>> Cheers,
>> Peter
>>
>>>
>>> On 12/08/2014 09:59 AM, Jason Gerecke wrote:
>>>
>>>> --- a/src/libinput.h
>>>> +++ b/src/libinput.h
>>>> @@ -277,7 +277,8 @@ enum libinput_tablet_axis {
>>>> LIBINPUT_TABLET_AXIS_PRESSURE = 3,
>>>> LIBINPUT_TABLET_AXIS_TILT_X = 4,
>>>> LIBINPUT_TABLET_AXIS_TILT_Y = 5,
>>>> - LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TILT_Y + 1
>>>> + LIBINPUT_TABLET_AXIS_TWIST = 6,
>>>> + LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TWIST + 1
>>>> };
>>>
>>> ___
>>> wayland-devel mailing list
>>> wayland-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/3] Add tests for pen rotation
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
test/litest-wacom-intuos-tablet.c | 3 +++
test/tablet.c | 41 +--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/test/litest-wacom-intuos-tablet.c
b/test/litest-wacom-intuos-tablet.c
index 2d95ad1..aa38090 100644
--- a/test/litest-wacom-intuos-tablet.c
+++ b/test/litest-wacom-intuos-tablet.c
@@ -36,6 +36,7 @@ static void litest_wacom_intuos_tablet_setup(void)
static struct input_event proximity_in[] = {
{ .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Z, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_DISTANCE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_TILT_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_TILT_Y, .value = LITEST_AUTO_ASSIGN },
@@ -49,6 +50,7 @@ static struct input_event proximity_in[] = {
static struct input_event proximity_out[] = {
{ .type = EV_ABS, .code = ABS_X, .value = 0 },
{ .type = EV_ABS, .code = ABS_Y, .value = 0 },
+ { .type = EV_ABS, .code = ABS_Z, .value = 0 },
{ .type = EV_ABS, .code = ABS_DISTANCE, .value = 0 },
{ .type = EV_ABS, .code = ABS_TILT_X, .value = 0 },
{ .type = EV_ABS, .code = ABS_TILT_Y, .value = 0 },
@@ -62,6 +64,7 @@ static struct input_event proximity_out[] = {
static struct input_event motion[] = {
{ .type = EV_ABS, .code = ABS_X, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_Y, .value = LITEST_AUTO_ASSIGN },
+ { .type = EV_ABS, .code = ABS_Z, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_DISTANCE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_PRESSURE, .value = LITEST_AUTO_ASSIGN },
{ .type = EV_ABS, .code = ABS_TILT_X, .value = LITEST_AUTO_ASSIGN },
diff --git a/test/tablet.c b/test/tablet.c
index 367c4db..c52ae43 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -354,16 +354,19 @@ START_TEST(normalization)
struct libinput_event *event;
double pressure,
tilt_vertical,
- tilt_horizontal;
+ tilt_horizontal,
+ twist;
const struct input_absinfo *pressure_absinfo,
*tilt_vertical_absinfo,
- *tilt_horizontal_absinfo;
+ *tilt_horizontal_absinfo,
+ *twist_absinfo;
litest_drain_events(dev->libinput);
pressure_absinfo = libevdev_get_abs_info(dev->evdev, ABS_PRESSURE);
tilt_vertical_absinfo = libevdev_get_abs_info(dev->evdev, ABS_TILT_X);
tilt_horizontal_absinfo = libevdev_get_abs_info(dev->evdev, ABS_TILT_Y);
+ twist_absinfo = libevdev_get_abs_info(dev->evdev, ABS_Z);
/* Test minimum */
if (pressure_absinfo != NULL)
@@ -384,6 +387,12 @@ START_TEST(normalization)
ABS_TILT_Y,
tilt_horizontal_absinfo->minimum);
+ if (twist_absinfo != NULL)
+ litest_event(dev,
+EV_ABS,
+ABS_Z,
+twist_absinfo->minimum);
+
litest_event(dev, EV_SYN, SYN_REPORT, 0);
libinput_dispatch(li);
@@ -422,6 +431,17 @@ START_TEST(normalization)
litest_assert_double_eq(tilt_horizontal, -1);
}
+
+ if (libinput_event_tablet_axis_has_changed(
+ tablet_event,
+ LIBINPUT_TABLET_AXIS_TWIST)) {
+ twist =
+ libinput_event_tablet_get_axis_value(
+ tablet_event,
+ LIBINPUT_TABLET_AXIS_TWIST);
+
+ litest_assert_double_eq(twist, -1);
+ }
}
libinput_event_destroy(event);
@@ -446,6 +466,12 @@ START_TEST(normalization)
ABS_TILT_Y,
tilt_horizontal_absinfo->maximum);
+ if (twist_absinfo != NULL)
+ litest_event(dev,
+EV_ABS,
+ABS_Z,
+twist_absinfo->maximum);
+
litest_event(dev, EV_SYN, SYN_REPORT, 0);
libinput_dispatch(li);
@@ -484,6 +510,17 @@ START_TEST(normalization)
litest_assert_double_eq(tilt_horizontal, 1);
}
+
+ if (libinput_event_tablet_axis_has_changed(
+ tablet_event,
+
[PATCH libinput 2/3] Implement support for pen barrel rotation
Some Wacom tablets can report the rotation of the pen about its barrel
in the ABS_Z axis. Report this via LIBINPUT_TABLET_AXIS_TWIST.
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
src/evdev-tablet.c | 6 ++
src/evdev-tablet.h | 6 ++
src/libinput.c | 1 +
src/libinput.h | 5 -
4 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index b924800..a7101da 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -47,6 +47,7 @@ tablet_process_absolute(struct tablet_dispatch *tablet,
switch (e->code) {
case ABS_X:
case ABS_Y:
+ case ABS_Z:
case ABS_PRESSURE:
case ABS_TILT_X:
case ABS_TILT_Y:
@@ -147,6 +148,7 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
break;
case LIBINPUT_TABLET_AXIS_TILT_X:
case LIBINPUT_TABLET_AXIS_TILT_Y:
+ case LIBINPUT_TABLET_AXIS_TWIST:
tablet->axes[a] = normalize_double_ended(absinfo);
break;
default:
@@ -332,6 +334,10 @@ tablet_get_tool(struct tablet_dispatch *tablet,
LIBINPUT_TABLET_AXIS_TILT_Y))
set_bit(tool->axis_caps,
LIBINPUT_TABLET_AXIS_TILT_Y);
+ if (bit_is_set(tablet->axis_caps,
+ LIBINPUT_TABLET_AXIS_TWIST))
+ set_bit(tool->axis_caps,
+ LIBINPUT_TABLET_AXIS_TWIST);
break;
default:
break;
diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
index cb37577..73c178d 100644
--- a/src/evdev-tablet.h
+++ b/src/evdev-tablet.h
@@ -72,6 +72,9 @@ evcode_to_axis(const uint32_t evcode)
case ABS_Y:
axis = LIBINPUT_TABLET_AXIS_Y;
break;
+ case ABS_Z:
+ axis = LIBINPUT_TABLET_AXIS_TWIST;
+ break;
case ABS_DISTANCE:
axis = LIBINPUT_TABLET_AXIS_DISTANCE;
break;
@@ -116,6 +119,9 @@ axis_to_evcode(const enum libinput_tablet_axis axis)
case LIBINPUT_TABLET_AXIS_TILT_Y:
evcode = ABS_TILT_Y;
break;
+ case LIBINPUT_TABLET_AXIS_TWIST:
+ evcode = ABS_Z;
+ break;
default:
abort();
}
diff --git a/src/libinput.c b/src/libinput.c
index d6c1685..64b0f95 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -532,6 +532,7 @@ libinput_event_tablet_get_axis_value(struct
libinput_event_tablet *event,
case LIBINPUT_TABLET_AXIS_PRESSURE:
case LIBINPUT_TABLET_AXIS_TILT_X:
case LIBINPUT_TABLET_AXIS_TILT_Y:
+ case LIBINPUT_TABLET_AXIS_TWIST:
return event->axes[axis];
default:
return 0;
diff --git a/src/libinput.h b/src/libinput.h
index 78bb9ef..03df3bb 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -277,7 +277,8 @@ enum libinput_tablet_axis {
LIBINPUT_TABLET_AXIS_PRESSURE = 3,
LIBINPUT_TABLET_AXIS_TILT_X = 4,
LIBINPUT_TABLET_AXIS_TILT_Y = 5,
- LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TILT_Y + 1
+ LIBINPUT_TABLET_AXIS_TWIST = 6,
+ LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TWIST + 1
};
/**
@@ -1022,6 +1023,8 @@ libinput_event_tablet_axis_has_changed(struct
libinput_event_tablet *event,
* - @ref LIBINPUT_TABLET_AXIS_TILT_X and @ref LIBINPUT_TABLET_AXIS_TILT_Y -
* normalized value between -1 and 1 that indicates the X or Y tilt of the
* tool
+ * - @ref LIBINPUT_TABLET_AXIS_TWIST - normalized value between -1 and 1
+ * that indicates the rotation of the tool about its long axis
*
* @param event The libinput tablet event
* @param axis The axis to retrieve the value of
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/3] Deduplicate and rename normalization functionality
Changes the names to reflect the functionality, not the use case. Also
defines one in terms of the other so that we aren't repeating ourselves.
Signed-off-by: Jason Gerecke
Acked-by: Peter Hutterer
---
src/evdev-tablet.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 4f1bc76..b924800 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -104,7 +104,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
}
static inline double
-normalize_pressure_or_dist(const struct input_absinfo * absinfo) {
+normalize_single_ended(const struct input_absinfo * absinfo) {
double range = absinfo->maximum - absinfo->minimum;
double value = (absinfo->value - absinfo->minimum) / range;
@@ -112,12 +112,9 @@ normalize_pressure_or_dist(const struct input_absinfo *
absinfo) {
}
static inline double
-normalize_tilt(const struct input_absinfo * absinfo) {
- double range = absinfo->maximum - absinfo->minimum;
- double value = (absinfo->value - absinfo->minimum) / range;
-
- /* Map to the (-1, 1) range */
- return (value * 2) - 1;
+normalize_double_ended(const struct input_absinfo * absinfo) {
+ /* Map from (0, 1) to the (-1, 1) range */
+ return (normalize_single_ended(absinfo) * 2) - 1;
}
static void
@@ -146,11 +143,11 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
break;
case LIBINPUT_TABLET_AXIS_DISTANCE:
case LIBINPUT_TABLET_AXIS_PRESSURE:
- tablet->axes[a] = normalize_pressure_or_dist(absinfo);
+ tablet->axes[a] = normalize_single_ended(absinfo);
break;
case LIBINPUT_TABLET_AXIS_TILT_X:
case LIBINPUT_TABLET_AXIS_TILT_Y:
- tablet->axes[a] = normalize_tilt(absinfo);
+ tablet->axes[a] = normalize_double_ended(absinfo);
break;
default:
log_bug_libinput(device->base.seat->libinput,
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Remove spurious addition from range normalization calculation
The presence of a "+1" in the range calculation prevents the
normalization functions from returning a value of "1.0" when
absinfo->value has reached its maximum.
Signed-off-by: Jason Gerecke
---
src/evdev-tablet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index ff5f737..9921823 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -105,7 +105,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
static inline double
normalize_pressure_or_dist(const struct input_absinfo * absinfo) {
- double range = absinfo->maximum - absinfo->minimum + 1;
+ double range = absinfo->maximum - absinfo->minimum;
double value = (absinfo->value - absinfo->minimum) / range;
return value;
@@ -113,7 +113,7 @@ normalize_pressure_or_dist(const struct input_absinfo *
absinfo) {
static inline double
normalize_tilt(const struct input_absinfo * absinfo) {
- double range = absinfo->maximum - absinfo->minimum + 1;
+ double range = absinfo->maximum - absinfo->minimum;
double value = (absinfo->value - absinfo->minimum) / range;
/* Map to the (-1, 1) range */
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] Fix normalization functions
We need to *subtract*, not *add* the minimum to determine the
range-effective value. For example: if (min, current, max) is
(100, 100, 1000) then the normalized value would be 0.0, not 0.2.
Signed-off-by: Jason Gerecke
---
This patch should be applied to the 'tablet-support' branch, obviously.
...Re-sending since I messed up the mailinglist address.
src/evdev-tablet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index a63b734..ff5f737 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -106,7 +106,7 @@ tablet_update_tool(struct tablet_dispatch *tablet,
static inline double
normalize_pressure_or_dist(const struct input_absinfo * absinfo) {
double range = absinfo->maximum - absinfo->minimum + 1;
- double value = (absinfo->value + absinfo->minimum) / range;
+ double value = (absinfo->value - absinfo->minimum) / range;
return value;
}
@@ -114,7 +114,7 @@ normalize_pressure_or_dist(const struct input_absinfo *
absinfo) {
static inline double
normalize_tilt(const struct input_absinfo * absinfo) {
double range = absinfo->maximum - absinfo->minimum + 1;
- double value = (absinfo->value + absinfo->minimum) / range;
+ double value = (absinfo->value - absinfo->minimum) / range;
/* Map to the (-1, 1) range */
return (value * 2) - 1;
--
2.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Aug 19, 2014 5:04 AM, "Pekka Paalanen" wrote: > > On Wed, 6 Aug 2014 19:07:50 -0400 > Stephen Chandler Paul wrote: > > > Hi! As some of you have been aware, I have been working on implementing tablet > > ssupport in libinput, the wayland protocol and weston. This patchset adds basic > > tablet support to weston, along with support in the shell and the window > > manager. It should be noted that these patches rely on one of the earlier > > patches to libinput that I posted on the mailing list: "tablet: Add > > libinput_tablet_has_axis()", along with the tablet-support branch in the git repository for libinput. > > > > As of right now, the following things are still missing/haven't been finished > > yet: > > * Tablet objects don't ever send a removed event, right now it's up to the > > clients to free the resources for each tool object. > > * Tablet tool objects should be separate for each tablet connected that doesn't > > report serial numbers. Right now tablet objects are shared by all tablets > > connected to the system unconditionally. > > * The tablet cursor disappears occasionally when moving a window and causing > > the mouse pointer to change images, but reappears the next time a client sets > > a cursor image. > > * weston-flower can crash the shell for some reason. It seems that if a tablet > > is turned on, and the first surface the tool comes into focus on belongs to a > > weston-flower instance, the desktop-shell runs into an error and exits. I > > haven't noticed this with anything other then weston-flower though. > > * Held down buttons are released when the tool changes focus from one surface > > to another, instead of being held down until they're released. > > * Some of the declarations for structs in my code might need to be moved > > around, I'm not sure what the expected guidelines for this in weston's code > > are though. > > * A surface argument needs to be added to the proximity_out event, so we can > > tell if the tablet tool is leaving proximity to switch focus to another > > surface, or if it's just exiting proximity. > > > > Review/critique would be appreciated, thank you! ^^ > > > > Cheers, > > Lyude > > > > Stephen Chandler Paul (19): > > tablet: Add XML for wl_tablet and wl_tablet_manager > > tablet: Add initial tablet support to weston > > client: Add support for handling motion events in toytoolkit > > client: Add support for handling proximity_in/out events in > > libtoytoolkit > > tablet: Add support for setting/changing the tablet cursor in weston > > client: Add tablet cursor support into libtoytoolkit > > tablet: Add support for tablet tool objects > > client: Add support for tool objects in libtoytoolkit > > client: Add support for tablet cursor motion to window frames in > > libtoytoolkit > > tablet: Add support for button presses to weston > > client: Add support for handling button presses to libtoytoolkit > > tablet: Add support for up/down events to weston > > client: Add up/down event support into libtoytoolkit > > tablet: Add support for moving windows around using the stylus > > tablet: Add support for reporting pressure, distance, and tilt in > > weston > > client: Add support for pressure, distance, and tilt into > > libtoytoolkit > > tablet: Add tablet support to the top panel of the desktop shell > > tablet: Add binding to activate surfaces using the tablet tool > > tablet: Add demo application for tablets > > > > .gitignore | 1 + > > Makefile.am | 23 +- > > clients/desktop-shell.c | 55 > > clients/tablet.c| 341 > > clients/window.c| 607 > > clients/window.h| 102 ++ > > desktop-shell/shell.c | 282 + > > protocol/wayland-tablet.xml | 310 +++ > > shared/cairo-util.h | 4 + > > shared/frame.c | 38 +++ > > src/bindings.c | 37 +++ > > src/compositor.c| 1 + > > src/compositor.h| 171 ++ > > src/input.c | 736 > > src/libinput-device.c | 317 +++ > > src/libinput-device.h | 4 +- > > 16 files changed, 3024 insertions(+), 5 deletions(-) > > create mode 100644 clients/tablet.c > > create mode 100644 protocol/wayland-tablet.xml > > > > Hi, > > just a heads-up, do I get the right impression that this is not yet in > a shape to merge into Weston, so won't be included in 1.6? > > Could an input person review this and suggest whether this should in > his opinion get merged for 1.6 and is it reasonable to assume, that all > the remaining known bugs can be sufficiently fixed within the couple > of weeks or so that our alpha and RC phase lasts? > > I still haven't read the latest protocol discussion thread, so I'm not > sure where t
Re: wl_tablet draft v2
On Sat, Aug 2, 2014 at 12:31 PM, Lyude wrote: > I'm sorry I took so long to reply to this! I only just found this e-mail > while I was cleaning my inbox up. > > On Wed, 2014-07-30 at 17:33 -0700, Jason Gerecke wrote: >> On Tue, Jul 29, 2014 at 12:44 PM, Lyude wrote: >> > I'm more then willing to add something to get the resolution >> > information, it wouldn't be too difficult to implement. I think I'm >> > missing or forgetting something here though; why wouldn't we be able to >> > get an actual value in degrees from the normalized values we're getting >> > from the compositor? The value should be mapped from (-65535.0) - >> > 65535.0 by the compositor (libinput is the portion that maps it from >> > (-1.0) - 1.0), couldn't we just map that to 0-180°? I would have thought >> > the max value tilt value on a tool should always be equal to 180°, and >> > the minimum 0°. >> > >> It is my understanding that libinput normalizes the values so that the >> minimum tilt => -1.0 and maximum tilt => +1.0. This data is then >> up-scaled by the compositor so that -1.0 => 65535 and +1.0 => +65535. >> This alone does not provide enough information to an application to >> recover the physical angle. One tablet may have a maximum tilt from >> vertical of 45°, another 60°, and yet another 90°. In each case >> maximum tilt would be represented by +1.0 or +65535, but there's no >> way an application can figure out how many degrees that corresponds >> to. > Okay, I had assumed that all tablets just provided values between 0° and > 180°. > >> One solution -- as you suggest -- is to have libinput/Wayland define a >> unit system and send what I call "canonicalized" instead of >> "normalized" data. You could define that in libinput -1.0 == 0° and >> +1.0 == 180°; in Wayland -65535 == 0° and +65535 == 180°. In this >> case, reports of 0.50/0.67/1.0 and 32768/43690/65535 would be sent >> when my hypothetical tablets above were at maximum tilt. As long as >> the correspondences were documented, a programmer would have enough >> information to convert the values to whatever values they want. >> >> Of course, the unit system you define for your canonical data is >> arbitrary, as you point out: >> >> > Also, since we're talking about getting the value in degrees, it might >> > be worth it just to have the Wayland protocol return the values in >> > degrees by default to save some time for the clients. >> > >> >> This is one of the downsides of canonical data. There's always someone >> out there who disagrees on units and so needs to perform a conversion. >> Degrees would make things easy for Qt and could be expressed directly >> in Wayland's 24.8 fixed-point format with a fair amount of precision. >> Radians are used natively by all the trigonometric functions, are the >> unit of choice for Android, and are the front-runner in designing >> Enlightenment's pen API. The "half-turn" is an uncommon units, but >> it's what GTK+ applications like GIMP and Inkscape assume they've been >> handed. >> >> There are other reasons I'm not a big fan of passing around data in >> canonical forms as well (can't send data from devices that don't >> advertise a resolution, inconsistent API, doesn't really cut down on >> the amount of data that needs to be exposed, etc.). As an alternative >> to the canonical route, you can leave the data normalized but provide >> a function that returns a scale factor defining what +1.0 (or +65535) >> means in physical units. Whatever program receives the value /may/ do >> a conversion if they wish, or can leave the value normalized for >> others further down the line. >> >> I wouldn't have libinput use degrees, but it might make some sense for >> Wayland. The downsides probably don't outweigh the ugliness involved >> with shuttling normalized data across the wire*. > I actually think using degrees might be a good idea if we have the > guarantee that they're accurate enough most of the time. To be honest, > the more that I think about it, I think it would be better to try to > avoid the use of normalized values when we can convert them to something > better. And, like you said, the number of clients that want the value in > something other than degrees is in the minority. Of course this brings > up the issue you just mentioned though: not all tablets report > resolution information, and this has the potential of limiting the API. > &g
Re: wl_tablet draft v2
On Tue, Jul 29, 2014 at 12:44 PM, Lyude wrote: > I'm more then willing to add something to get the resolution > information, it wouldn't be too difficult to implement. I think I'm > missing or forgetting something here though; why wouldn't we be able to > get an actual value in degrees from the normalized values we're getting > from the compositor? The value should be mapped from (-65535.0) - > 65535.0 by the compositor (libinput is the portion that maps it from > (-1.0) - 1.0), couldn't we just map that to 0-180°? I would have thought > the max value tilt value on a tool should always be equal to 180°, and > the minimum 0°. > It is my understanding that libinput normalizes the values so that the minimum tilt => -1.0 and maximum tilt => +1.0. This data is then up-scaled by the compositor so that -1.0 => 65535 and +1.0 => +65535. This alone does not provide enough information to an application to recover the physical angle. One tablet may have a maximum tilt from vertical of 45°, another 60°, and yet another 90°. In each case maximum tilt would be represented by +1.0 or +65535, but there's no way an application can figure out how many degrees that corresponds to. One solution -- as you suggest -- is to have libinput/Wayland define a unit system and send what I call "canonicalized" instead of "normalized" data. You could define that in libinput -1.0 == 0° and +1.0 == 180°; in Wayland -65535 == 0° and +65535 == 180°. In this case, reports of 0.50/0.67/1.0 and 32768/43690/65535 would be sent when my hypothetical tablets above were at maximum tilt. As long as the correspondences were documented, a programmer would have enough information to convert the values to whatever values they want. Of course, the unit system you define for your canonical data is arbitrary, as you point out: > Also, since we're talking about getting the value in degrees, it might > be worth it just to have the Wayland protocol return the values in > degrees by default to save some time for the clients. > This is one of the downsides of canonical data. There's always someone out there who disagrees on units and so needs to perform a conversion. Degrees would make things easy for Qt and could be expressed directly in Wayland's 24.8 fixed-point format with a fair amount of precision. Radians are used natively by all the trigonometric functions, are the unit of choice for Android, and are the front-runner in designing Enlightenment's pen API. The "half-turn" is an uncommon units, but it's what GTK+ applications like GIMP and Inkscape assume they've been handed. There are other reasons I'm not a big fan of passing around data in canonical forms as well (can't send data from devices that don't advertise a resolution, inconsistent API, doesn't really cut down on the amount of data that needs to be exposed, etc.). As an alternative to the canonical route, you can leave the data normalized but provide a function that returns a scale factor defining what +1.0 (or +65535) means in physical units. Whatever program receives the value /may/ do a conversion if they wish, or can leave the value normalized for others further down the line. I wouldn't have libinput use degrees, but it might make some sense for Wayland. The downsides probably don't outweigh the ugliness involved with shuttling normalized data across the wire*. * Seriously, can anyone explain why the wire protocol doesn't have a floating-point type? Practically every system supports the 32-bit IEEE754 single-precision binary format, and to for those that don't, we can pull a play from the fixed-point playbook and define a "wl_single_t" and associated conversion functions (which would just do a cast unless you happen to be on one of those weird architectures). Should I just make a patch for this already? :P Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours > On Tue, 2014-07-29 at 10:07 -0700, Jason Gerecke wrote: >> On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak wrote: >> > On 07/28/2014 09:41 AM, Jason Gerecke wrote: >> > >> >> Normalizing the data is fine, but the resolution data needs to be >> >> available somewhere as well. The GTK+ API doesn't require anything >> >> more than the former, but Qt requires that there be some way to turn >> >> the normalized value into degrees. For libinput this could be >> >> something as simple as a "get_axis_resolution" function that returns >> >> the number of radians (or mm, or newtons, or some other physical unit) >> >> that the normalized value +1.0 corresp
Re: wl_tablet draft v2
On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak wrote: > On 07/28/2014 09:41 AM, Jason Gerecke wrote: > >> Normalizing the data is fine, but the resolution data needs to be >> available somewhere as well. The GTK+ API doesn't require anything >> more than the former, but Qt requires that there be some way to turn >> the normalized value into degrees. For libinput this could be >> something as simple as a "get_axis_resolution" function that returns >> the number of radians (or mm, or newtons, or some other physical unit) >> that the normalized value +1.0 corresponds to. I suppose Wayland would >> let make the value available through the wl_tablet_manager somehow. > > > Are you sure about these terms? I would think "resolution" should be used to > identify how many discreet positions the device can obtain. What you are > asking for I think would be better to call a "range" or "scale". > Yeah, good catch. Looks like I'm getting imprecise with my terminology *wince* I think I prefer "scale" over "range" personally, since it's only a single logical-to-physical scaling factor (not the physical minimum and maximum extents of the axis). Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_tablet draft v2
On Wed, Jul 16, 2014 at 5:08 PM, Lyude wrote: > On Mon, 2014-07-14 at 13:25 -0700, Jason Gerecke wrote: >> On Sun, Jul 13, 2014 at 12:17 PM, Lyude wrote: >> >wl_tablet specifications >> > Version 2 >> > >> > General notes: >> > - Many of the axis values in this are normalized to either 0-65535 or >> > (-65535)-65535. I would leave the axis values as-is since libinput >> > reports >> > them as doubles, but since we only have 8 bits of precision we'd lose way >> > too many values. 65535 seemed like the best choice since it's the maximum >> > length of a signed short, it's a whole number, it's way higher then the >> > range of any of the axes (with the exception of X and Y, but these aren't >> > normalized anyway) and we can do just about any basic arithmetic with it >> > without having to worry about overflowing. Plus, all we have to do is >> > multiply the value by 65535 after we get it from libinput. >> > >> Speaking of overflow, what's Wayland's stance on whether the >> compositor or client is responsible for dealing with it? I remember >> Google mentioned that while working on Android's input driver, they >> noticed some input devices could be "turned up to 11" and report >> values beyond the kernel-indicated minimum/maximum. They decided to >> punt the problem to app developers and documented that an app may e.g. >> see 110% pressure if that's what the hardware reported. The question >> is mostly academic since the Wacom kernel driver shouldn't be an >> offender, but I might as well ask :) > If it comes down to handling overflow, it'll probably be up to the > client. I'm hoping it shouldn't though. The reason I choose 65535 in the > first place is because it can more then cover any of the axes (other > then the X and Y axes, but those aren't normalized anyway so I'm not > worried about that), and it's difficult to accidentally overflow doing > general arithmetic with a value of 65535. In most situations, addition, > subtraction, multiplication, etc. shouldn't overflow. In fact you can > (almost) square it at least once without overflowing. I'm assuming if > there's a chance they might, then the client's doing something that the > developers understand the risk of. It's just a number though, so we can > always turn it down if we need to. > >> >> > Changes since the last version: >> > - The surface argument is now only included in the proximity-in events >> > - wl_tablet_manager has been added. Events no longer have a separate id >> > argument, and instead rely on wl_tablet objects to differentiate each >> > tablet >> > from each other. A lot of it was copied from Peter's initial wl_tablet >> > proposal, but a few additions have been made; I've added an argument for >> > each of the axis events that a tablet supports to the device_added event. >> > - Axis changes have been split up into a couple different events >> > - Added a generic frame event. Because of the different kinds of click >> > emulations done with tablets, having each event packed into a frame is >> > convenient. >> > - All of the starting values for each axis are provided as normal events in >> > the same frame as a proximity_in event. The same goes for the status of >> > each >> > button on the tool. This makes the protocol a lot cleaner >> > >> > Definitions: >> > - WL_TABLET_AXIS_MAX = 65535 >> > - WL_TABLET_AXIS_MIN = (-65535) >> > >> > Interfaces: >> > - wl_tablet >> > Enumerators: >> > - wl_tablet_tool_type: >> > - pen >> > - eraser >> > - brush >> > - pencil >> > - airbrush >> > - finger >> > - mouse >> > - lens >> > - wl_tablet_button >> > - stylus_1 >> > - stylus_2 >> > - wl_tablet_button_state >> > - pressed >> > - released >> > >> > Events: >> > - proximity_in >> > Sent when the tool comes into proximity above the client surface, >> > either by the tool coming into proximity or a tool being >> >
Re: wl_tablet draft v2
On Sun, Jul 13, 2014 at 12:17 PM, Lyude wrote: >wl_tablet specifications > Version 2 > > General notes: > - Many of the axis values in this are normalized to either 0-65535 or > (-65535)-65535. I would leave the axis values as-is since libinput reports > them as doubles, but since we only have 8 bits of precision we'd lose way > too many values. 65535 seemed like the best choice since it's the maximum > length of a signed short, it's a whole number, it's way higher then the > range of any of the axes (with the exception of X and Y, but these aren't > normalized anyway) and we can do just about any basic arithmetic with it > without having to worry about overflowing. Plus, all we have to do is > multiply the value by 65535 after we get it from libinput. > Speaking of overflow, what's Wayland's stance on whether the compositor or client is responsible for dealing with it? I remember Google mentioned that while working on Android's input driver, they noticed some input devices could be "turned up to 11" and report values beyond the kernel-indicated minimum/maximum. They decided to punt the problem to app developers and documented that an app may e.g. see 110% pressure if that's what the hardware reported. The question is mostly academic since the Wacom kernel driver shouldn't be an offender, but I might as well ask :) > Changes since the last version: > - The surface argument is now only included in the proximity-in events > - wl_tablet_manager has been added. Events no longer have a separate id > argument, and instead rely on wl_tablet objects to differentiate each tablet > from each other. A lot of it was copied from Peter's initial wl_tablet > proposal, but a few additions have been made; I've added an argument for > each of the axis events that a tablet supports to the device_added event. > - Axis changes have been split up into a couple different events > - Added a generic frame event. Because of the different kinds of click > emulations done with tablets, having each event packed into a frame is > convenient. > - All of the starting values for each axis are provided as normal events in > the same frame as a proximity_in event. The same goes for the status of each > button on the tool. This makes the protocol a lot cleaner > > Definitions: > - WL_TABLET_AXIS_MAX = 65535 > - WL_TABLET_AXIS_MIN = (-65535) > > Interfaces: > - wl_tablet > Enumerators: > - wl_tablet_tool_type: > - pen > - eraser > - brush > - pencil > - airbrush > - finger > - mouse > - lens > - wl_tablet_button > - stylus_1 > - stylus_2 > - wl_tablet_button_state > - pressed > - released > > Events: > - proximity_in > Sent when the tool comes into proximity above the client surface, > either by the tool coming into proximity or a tool being > in-proximity and moving to the client surface. If a tablet tool > makes contact with the tablet at the same time that the tool comes > into proximity, the proximity event comes first and the down event > comes afterwards. > A proximity_in event is immediately followed by the following > sequence of events in the same frame: > - motion > - down (if the tool is touching the tablet's surface at the > same time it comes into proximity) > - a button press event for each button held down on the tool > as it comes into proximity > - pressure (if supported by the tablet) > - distance (if supported by the tablet) > - tilt (if supported by the tablet) > This allows a client to get the starting values for all of the axes, > along with the starting coordinates of the tool, and the state of > each button on the tool. > > Arguments: > - Name: id > Type: uint > the id of the tablet sending this event. > > - Name: type > Type: uint > The type of tool that came into proximity, e.g. pen, > airbrush, etc. > > - Name: serial > Type: uint > The serial number of the tool that came into proximity. On > tablets where this isn't provided, this value will always be > 0. > > - Name: surface > Type: object > Interface: wl_surface > The current surface the tablet tool is over > > - Name: time > Type: uint > The time of the event
Re: Window placement
On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey wrote: >> "The question is: what action triggers it to make this ring of icons >> appear?" > A global shortkey (and yes I know it's not yet possible on Wayland, that's > another problem on its own). > >> "What's the application doing? Does it have keyboard focus but is >> potentially not under the mouse pointer? Do you have a screenshot or video >> of this feature you can share?" > I'm not the developper of it, I actually don't even use it ^^ I was just > thinking of it to see how it would fit in Wayland, what's potentially > missing now in the protocol. > Here is an article about it: > http://www.webupd8.org/2011/10/gnome-pie-02-released.html and a video: > https://www.youtube.com/watch?v=TFQDyZyMxO4. > Basically, it appears under the mouse when you trigger the shortkey, and you > can also use the keyboard to navigate in the items. > So I see 2 main points here: > - it places its window not relatively to a parent (which there is not), but > to the mouse > - it takes the (keyboard) focus when it appears > The second point is not related to this topic, so we can probably think of > it later. > > > This reminds me of a something similar[1] that comes with the Wacom drivers on Windows and Mac. Its not a normal application that you would open, interact with, (possibly switch away from temporarily), and close. Rather, the application sits in the background and waits for some button/mouse/hotkey to be pressed before spawning a window under the mouse that you interact with for only a moment before returning to your original task. I do not mean to put words into Pekka's mouth, but I believe what he means when saying that things like this are "a DE-component" he's speaking conceptually more than anything else. Alternative menu systems like this and desklets essentially exist to augment the desktop itself. Just because they can be written in a DE-agnostic manner and run on GNOME, KDE, or TWM (all hail xeyes?) doesn't change that. They have fundamentally different needs than the average application, and -- at least as far as I understand Wayland -- it makes sense to leave some of these things up to the desktops to define. [1]: https://www.youtube.com/watch?v=McJMnMJydes Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours > 2014-07-02 21:26 GMT+02:00 Bill Spitzak : > >> >> >> On 07/02/2014 11:39 AM, Fabrice Rey wrote: >>> >>> > "I am not sure if wayland should allow this, and whether there are >>> clients that expect this to work" >>> Well, there is at least one application that exists and displays a ring >>> of icons under the mouse. So, it needs to tell the compositor to place >>> its window to (dx;dy) relatively to the mouse. >> >> >> The question is: what action triggers it to make this ring of icons >> appear? >> >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_tablet specification draft
On Mon, Jun 30, 2014 at 3:46 AM, Peter Hutterer wrote: > On 30/06/2014 20:23 , Pekka Paalanen wrote: >> >> On Mon, 30 Jun 2014 09:33:15 +0300 >> Pekka Paalanen wrote: >> >>> On Mon, 30 Jun 2014 11:08:35 +1000 >>> Peter Hutterer wrote: >>> On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paalanen wrote: > > On Fri, 27 Jun 2014 13:04:59 -0700 > Bill Spitzak wrote: > >> On 06/26/2014 09:38 PM, Ping Cheng wrote: >> >>> With my experience, mapping whole tablet to a window or a >>> specific display area is preferred. That is how mapping works on >>> Windows >>> and Mac too. >> >> >> First this is *only* when the drawing program wants it to happen. >> There >> is some kind of mode switch so the user can use the pen to do things >> outside the drawing area. When the drawing program is not controlling >> it >> the user wants to be able to use the pen instead of the mouse for all >> mouse actions. >> >> I would also love to see addressed the ability to get "square" >> movement >> out of the pad, and to automatically switch to "mouse mode" if the >> outputs are a significantly different shape than the tablet. Though >> Linux was by far the worst, all three systems (OS/X and Windows) fell >> down badly here, mostly by making it impossible to mode-switch between >> mouse and tablet mode, and on Windows it is impossible to change the >> scale of mouse mode. None of them would change how the mapping is done >> when outputs are added/removed. I believe "limit to one monitor" is >> not >> necessary and is only being provided as a work-around for the >> non-square >> mappings that should be avoided in a different way. >> >> Even though it sounds like it is disagreeing with me, there is no need >> for "mouse emulations". Wayland clients should all be written to know >> that they could get pen events just like mouse events and to handle >> them >> the same if they don't want to do anything smarter with the pen. > > > First you said that... > >> Vaguely thinking of this from a Wayland client's pov it seems like >> what >> should happen is this: >> >> - The pen moves the seat's mouse cursor, always. If more than one >> cursor >> is wanted the pen should be in a different seat. The user is not >> manipulating more than one device at a time and does not want to see >> two >> cursors. > > > ...and then you said the exact opposite, plus you require the > broken case where the same hardware events map to multiple > completely different protocols (wl_pointer *and* tablet). that's not necessarily the worst thing, provided it doesn't happen at the same time. with a "mode toggle" button the compositor could switch between tablet events and absolute motion on-the-fly. >>> >>> >>> That I completely agree with, but Bill did write "The pen moves the >>> seat's mouse cursor, always." Always - implies that you sometimes get >>> pointer and tablet events for the same action. >>> This is a change how tablets currently work in Linux but aside from that it's actually the easiest and cleanest to implement. >>> >>> >>> It sounds like it would work: just use wl_pointer protocol when the >>> tablet controls the pointer, and tablet protocol when it is used as >>> a... tablet, and let the compositor switch between the two modes. Still, >>> never the both at the same time for same physical user action, right? >>> >>> That way the tablet protocol could be exclusively for the "whole tablet >>> maps to the client/window/app-custom region", and you can ignore the >>> "tablet maps to whole/all outputs" case as that would be handled by the >>> wl_pointer mode alone. How would that sound? >> >> >> Some more thoughts... >> >> Switching is just one option, but it has the benefit that if the >> compositor is using wl_pointer appropriately, you can still use >> toolkits that do not explicitly support tablet protocol. >> >> Another option is to make tablet protocol completely separate, like >> wl_touch (touchscreen) is. Explicit support would be required in >> toolkits, but at least there would not be too difficult interaction >> problems with wl_pointer et al. so it would sound safer. > > > tbh this is currently my favourite idea and that's what Lyude is working on > atm. given that wayland is fairly young and has a bigger emphasis on > toolkits (compared to X anyway) pushing this down to the client does make > sense. toolkits are much more flexible and can use better abstractions to > make tablet events look like pointer events where needed. > > >> Some reasons why wl_touch is completely separate from wl_pointer, is >> that wl_touch is absolute while wl_pointer uses relative motion. >> wl_pointer needs a cursor, wl_touch not. > >> >> >> I suppose tablets are usually absolute position
Re: [PATCH libinput] Add functions to get the device name, PID and VID
On Thu, Jun 26, 2014 at 8:02 PM, Peter Hutterer
wrote:
> Those three are the ones that matter for logging or device identification in
> callers, so let's provide them.
>
> Signed-off-by: Peter Hutterer
Have you thought about how to handle identification for non-USB
devices? We're starting to see tablet PC OEMs use I2C hardware, and
from the little bit I've looked into things see that they use
ACPI-style rather than USB-style IDs (e.g. WCOM0009 instead of
056a:0123). I think its possible to get USB-style IDs from the
hardware, but TBH I've not yet been successful in getting any of those
systems to boot into Linux to check :/
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> ---
> src/evdev.c| 18 ++
> src/evdev.h| 9 +
> src/libinput.c | 18 ++
> src/libinput.h | 34 ++
> test/misc.c| 20
> 5 files changed, 99 insertions(+)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index f72bd43..183c200 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -857,6 +857,24 @@ evdev_device_get_sysname(struct evdev_device *device)
> return device->sysname;
> }
>
> +const char *
> +evdev_device_get_name(struct evdev_device *device)
> +{
> + return device->devname;
> +}
> +
> +unsigned int
> +evdev_device_get_id_product(struct evdev_device *device)
> +{
> + return libevdev_get_id_product(device->evdev);
> +}
> +
> +unsigned int
> +evdev_device_get_id_vendor(struct evdev_device *device)
> +{
> + return libevdev_get_id_vendor(device->evdev);
> +}
> +
> void
> evdev_device_calibrate(struct evdev_device *device, float calibration[6])
> {
> diff --git a/src/evdev.h b/src/evdev.h
> index 4a83a78..fad1f84 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -141,6 +141,15 @@ evdev_device_get_output(struct evdev_device *device);
> const char *
> evdev_device_get_sysname(struct evdev_device *device);
>
> +const char *
> +evdev_device_get_name(struct evdev_device *device);
> +
> +unsigned int
> +evdev_device_get_id_product(struct evdev_device *device);
> +
> +unsigned int
> +evdev_device_get_id_vendor(struct evdev_device *device);
> +
> void
> evdev_device_calibrate(struct evdev_device *device, float calibration[6]);
>
> diff --git a/src/libinput.c b/src/libinput.c
> index 44f4f23..1918b48 100644
> --- a/src/libinput.c
> +++ b/src/libinput.c
> @@ -1162,6 +1162,24 @@ libinput_device_get_sysname(struct libinput_device
> *device)
> }
>
> LIBINPUT_EXPORT const char *
> +libinput_device_get_name(struct libinput_device *device)
> +{
> + return evdev_device_get_name((struct evdev_device *) device);
> +}
> +
> +LIBINPUT_EXPORT unsigned int
> +libinput_device_get_id_product(struct libinput_device *device)
> +{
> + return evdev_device_get_id_product((struct evdev_device *) device);
> +}
> +
> +LIBINPUT_EXPORT unsigned int
> +libinput_device_get_id_vendor(struct libinput_device *device)
> +{
> + return evdev_device_get_id_vendor((struct evdev_device *) device);
> +}
> +
> +LIBINPUT_EXPORT const char *
> libinput_device_get_output_name(struct libinput_device *device)
> {
> return evdev_device_get_output((struct evdev_device *) device);
> diff --git a/src/libinput.h b/src/libinput.h
> index 99a3b2f..e8b87da 100644
> --- a/src/libinput.h
> +++ b/src/libinput.h
> @@ -1257,6 +1257,40 @@ libinput_device_get_sysname(struct libinput_device
> *device);
> /**
> * @ingroup device
> *
> + * The lifetime of the returned string is tied to the struct
> + * libinput_device.
> + *
> + * @param device A previously obtained device
> + * @return The device name
> + */
> +const char *
> +libinput_device_get_name(struct libinput_device *device);
> +
> +/**
> + * @ingroup device
> + *
> + * Get the product ID for this device.
> + *
> + * @param device A previously obtained device
> + * @return The product ID of this device
> + */
> +unsigned int
> +libinput_device_get_id_product(struct libinput_device *device);
> +
> +/**
> + * @ingroup device
> + *
> + * Get the vendor ID for this device.
> + *
> + * @param device A previously obtained device
> + * @return The vendor ID of this device
> + */
> +unsigned int
> +libinput_device_get_id_vendor(struct libinput_device *device);
> +
> +/**
> + * @ingroup device
> + *
> * A device may be mapped to a single output, or all available outputs. If a
> * device is mapped to a single output only, a relative device may not move
> * beyond the boundaries of this output. An absolute device has its input
> diff --git a/test/misc.c b/test/misc.c
> index bea7e88..e467a5c 100644
> --- a/test/misc.c
> +++ b/test/misc.c
> @@ -390,6 +390,25 @@ START_TEST(context_ref_counting)
> }
> END_TEST
>
> +START_TEST(device_ids)
> +{
> + struct litest_device *dev = litest_current_device();
> + c
Re: Comments about adding tablet support to Wayland
On Wed, Jun 25, 2014 at 5:50 PM, Peter Hutterer wrote: > Replying to three emails at once here to keep the thread a bit more > managable. > > On Wed, Jun 25, 2014 at 01:38:22PM -0700, Jason Gerecke wrote: >> On Wed, Jun 25, 2014 at 12:38 AM, Lyude wrote: >> > On Wed, 2014-06-25 at 11:06 +0400, Dmitry Kazakov wrote: >> >> Hi, all! >> >> >> >> >> >> I am a developer from Krita painting application team. We recently did >> >> quite much work on incorporating better tablet support in Krita. I >> >> have several comments about your proposal of the tablet protocol >> >> (sorry for nor replying directly, since I wasn't subscribed to the >> >> list before). >> > >> > Benjamin commented on this as I was writing this e-mail, and I figured I >> > should too: yes, it's awesome to see developers commenting on the >> > protocol. A lot of the quirks around this protocol are going to be >> > difficult to see without the help of people who have programmed on the >> > client side of things as opposed to the compositor side of things. So >> > yes, your input is very much appreciated and I thank you for it! >> > >> >> >> >> 1) Axes. There should also be an axis for rotation of the stylus >> >> (Artpen) and Tangential Pressure (for the wheel of the Airbrush). >> >> >> >> 2) There is also Artpen type of stylus. In Qt it is called "Rotational >> >> Stylus". >> > >> > Don't worry, we haven't forgotten about these. These will eventually be >> > added into the protocol. The reason why they're not in this draft is >> > because I'm doing this as my Google Summer of Code project, and as such >> > I'm on a deadline and I have to focus on just getting the basics done >> > first before I can focus on all of the other features. > > Our current approach, both in libinput and the WL protocol should make these > additions little more than adding a couple of enum, so I think we're good > here. > >> >> 3) Fingers. There is a complication in XInput2 right now, since touch >> >> enabled Wacom devices have a special Finger XInput2 device, which >> >> provides both interfaces: tablet and touch and therefore generates >> >> both types of events. Right now Qt5 still cannot handle it properly, >> >> but the work is in progress. From Krita point of view, the main >> >> usecase for us is to distinguish whether the user paints with a finger >> >> of with the stylus. Because most of the users prefer to disable >> >> painting with fingers and use it for gestures/UI only (yes, palm >> >> detection works with non-100% probability). >> > >> > Right now libinput handles the finger device as another touchpad, since >> > that's usually what it is. Your use-case sounds perfectly valid though, >> > but IMO a better approach would be to add something to the protocol for >> > touchpads on wayland so that it can be known that they belong to a >> > tablet and provide any other sorts of data you might be need, so >> > programs like yours can treat them differently. > > Dmitry, are you talking about pen/touch arbitration, i.e. don't send touch > events when the pen is in use. If so, that's definitely on the plan, we need > it for touchpads (disable while typing feature), and we need it for the > pen/touch interference. > > This will be hidden away so you or event the compositor don't have to worry > about it. > >> >> 4) Button Press/Release events should come in both cases: when the >> >> user clicks on the stylus' buttons and when the stylus touches the >> >> surface of the tablet. >> > >> > I'm not entirely sure that's a good idea. If I'm reading this right, you >> > mean that additional button presses should be sent when the tool touches >> > the surface of the tablet. [...] > > We're already sending out BTN_TOUCH when the tip touches the surface, so I > think we're good here. Unless Dmitry was referring to something else. > > >> >> 6) It might be a good idea to define the physical properties of the >> >> axes. E.g. for tilt, rotation and tangential pressure. Afair, Wacom >> >> driver for XInput returns some not-very-obvious values right now. One >> >> would need to experiment to know what these numbers mean. >> > >> > We would all love for this to be the case I promise you, but >>
Re: wl_tablet specification draft
On Thu, Jun 26, 2014 at 12:12 AM, Peter Hutterer wrote: > On Thu, Jun 26, 2014 at 09:48:37AM +0300, Pekka Paalanen wrote: >> Hi, >> >> it seems you forgot to reply-to-all, so I have re-added everyone and >> not trimmed the quotation. >> >> On Wed, 25 Jun 2014 18:37:08 -0400 >> Lyude wrote: >> >> > On Wed, 2014-06-25 at 15:19 +0300, Pekka Paalanen wrote: >> > > On Tue, 24 Jun 2014 21:56:09 -0400 >> > > Chandler Paul wrote: >> > > >> > > > Hello! As you all know I've been working on adding drawing tablet >> > > > support to the Wayland protocol. Now that we've added support for >> > > > tablets to libinput, the next step is writing the actual protocol that >> > > > will be implemented by the compositor. Following this blurb is the >> > > > current draft of the tablet protocol we have. Feel free to critique it. >> > > > >> > > > Cheers, >> > > > Lyude >> > > > >> > > > >> > > > >> > > >wl_tablet specifications >> > > > >> > > > General notes: >> > > > - Many of the axis values in this are normalized to either 0-65535 or >> > > > (-65535)-65535. I would leave the axis values as-is since libinput >> > > > reports >> > > > them as doubles, but since we only have 8 bits of precision we'd >> > > > lose way >> > > > too many values. 65535 seemed like the best choice since it's the >> > > > maximum >> > > > length of a signed short, it's a whole number, it's way higher then >> > > > the >> > > > range of any of the axes (with the exception of X and Y, but these >> > > > aren't >> > > > normalized anyway) and we can do just about any basic arithmatic >> > > > with it >> > > > without having to worry about overflowing. plus, all we have to do is >> > > > multiply the value by 65535 after we get it from libinput. >> > > > >> > > > Definitions: >> > > > - WL_TABLET_AXIS_MAX = 65535 >> > > > - WL_TABLET_AXIS_MIN = (-65535) >> > > > >> > > > Enumerators: >> > > > - wl_tablet_axis: >> > > > - WL_TABLET_AXIS_X >> > > > - WL_TABLET_AXIS_Y >> > > > Represents the X and Y axes respectively. Only used in >> > > > bitfields to >> > > > indicate whether or not they've changed since the last event. >> > > > >> > > > - WL_TABLET_AXIS_DISTANCE >> > > > Represents the distance axis on a tablet. Normalized from 0 >> > > > to >> > > > WL_TABLET_AXIS_MAX. For tablets that do not support >> > > > reporting the >> > > > distance, this will always be 0. >> > > > >> > > > - WL_TABLET_AXIS_PRESSURE >> > > > Represents the pressure axis on a tablet. Normalized from 0 >> > > > to >> > > > WL_TABLET_AXIS_MAX. For tablets that do not support >> > > > reporting the >> > > > pressure, this will always be WL_TABLET_AXIS_MAX. >> > > > >> > > > - WL_TABLET_AXIS_TILT_VERTICAL >> > > > - WL_TABLET_AXIS_TILT_HORIZONTAL >> > > > Each represents the vertical and horizontal tilt axes >> > > > respectfully. >> > > > Normalized from WL_TABLET_AXIS_MIN to WL_TABLET_AXIS_MAX. For >> > > > tablets that do not support this, this value will always be >> > > > 0. >> > > > >> > > > - WL_TABLET_AXIS_CNT >> > > > Represents the number of axes >> > > > - wl_tablet_tool_type: >> > > > - pen >> > > > - eraser >> > > > - brush >> > > > - pencil >> > > > - airbrush >> > > > - finger >> > > > - mouse >> > > > - lens >> > > > - wl_tablet_button_state >> > > > - pressed >> > > > - released >> > > > >> > > > Events: >> > > > - proximity_in >> > > > Sent when the tool comes into proximity above the client surface, >> > > > either by >> > > > the tool coming into proximity or a tool being in-proximity and >> > > > moving to >> > > > the client surface. If a tablet tool makes contact with the tablet >> > > > at the >> > > > same time that the tool comes into proximity, the proximity event >> > > > comes >> > > > first and the down event comes afterwards. >> > > > Arguments: >> > > > - Name: id >> > > > Type: uint >> > > > the id of the tablet sending this event. >> > > > >> > > > - Name: type >> > > > Type: uint >> > > > The type of tool that came into proximity, e.g. pen, >> > > > airbrush, etc. >> > > > >> > > > - Name: serial >> > > > Type: uint >> > > > The serial number of the tool that came into proximity. On >> > > > tablets >> > > > where this isn't provided, this value will always be 0. >> > > > >> > > > - Name: x >> > > > Type: fixed >> > > > Surface relative x coordinate >> > > > >> > > > - Name: y >> > > > Type: fixed >> > > > Surface relative y coordinate >> > > > >> > > > - Name: surface >> > > >
Re: Comments about adding tablet support to Wayland
On Wed, Jun 25, 2014 at 12:38 AM, Lyude wrote: > On Wed, 2014-06-25 at 11:06 +0400, Dmitry Kazakov wrote: >> Hi, all! >> >> >> I am a developer from Krita painting application team. We recently did >> quite much work on incorporating better tablet support in Krita. I >> have several comments about your proposal of the tablet protocol >> (sorry for nor replying directly, since I wasn't subscribed to the >> list before). > > Benjamin commented on this as I was writing this e-mail, and I figured I > should too: yes, it's awesome to see developers commenting on the > protocol. A lot of the quirks around this protocol are going to be > difficult to see without the help of people who have programmed on the > client side of things as opposed to the compositor side of things. So > yes, your input is very much appreciated and I thank you for it! > >> >> 1) Axes. There should also be an axis for rotation of the stylus >> (Artpen) and Tangential Pressure (for the wheel of the Airbrush). >> >> 2) There is also Artpen type of stylus. In Qt it is called "Rotational >> Stylus". > > Don't worry, we haven't forgotten about these. These will eventually be > added into the protocol. The reason why they're not in this draft is > because I'm doing this as my Google Summer of Code project, and as such > I'm on a deadline and I have to focus on just getting the basics done > first before I can focus on all of the other features. > >> >> 3) Fingers. There is a complication in XInput2 right now, since touch >> enabled Wacom devices have a special Finger XInput2 device, which >> provides both interfaces: tablet and touch and therefore generates >> both types of events. Right now Qt5 still cannot handle it properly, >> but the work is in progress. From Krita point of view, the main >> usecase for us is to distinguish whether the user paints with a finger >> of with the stylus. Because most of the users prefer to disable >> painting with fingers and use it for gestures/UI only (yes, palm >> detection works with non-100% probability). > > Right now libinput handles the finger device as another touchpad, since > that's usually what it is. Your use-case sounds perfectly valid though, > but IMO a better approach would be to add something to the protocol for > touchpads on wayland so that it can be known that they belong to a > tablet and provide any other sorts of data you might be need, so > programs like yours can treat them differently. > >> >> 4) Button Press/Release events should come in both cases: when the >> user clicks on the stylus' buttons and when the stylus touches the >> surface of the tablet. > > I'm not entirely sure that's a good idea. If I'm reading this right, you > mean that additional button presses should be sent when the tool touches > the surface of the tablet. This could be done, but this would result in > us either having to: > - Send release events for all the currently held down buttons when the > stylus makes contact with the surface of the tablet, then immediately > send press events for all of the buttons or > - Just send redundant press events when the tool makes contact with the > surface > > The issue with this is that it's very misleading to a wayland client as > to when the buttons are actually being pressed or not, and it doesn't > provide much in the way of extra useful information for the majority of > use cases. > >> >> 6) It might be a good idea to define the physical properties of the >> axes. E.g. for tilt, rotation and tangential pressure. Afair, Wacom >> driver for XInput returns some not-very-obvious values right now. One >> would need to experiment to know what these numbers mean. > > We would all love for this to be the case I promise you, but > unfortunately it's not that simple for all of the axes. The distance > axis reports a seemingly meaningless value that can't be converted to > millimeters very easily. That being said, I have come up with a few ways > that we could actually convert it to millimeters, but this will have to > wait until I've fulfilled the goals for my Google Summer of Code Project > (unless anyone else wants to implement this in the mean time in libinput > of course). > > I'll write up the method I've come up with for converting this wild > value to actual millimeters at some point when I get the chance. > While I'm interested in seeing what you've come up with, I would be very hesitant to integrate the code into libinput. We make *no* claims about the physical resolution or accuracy of the distance axis. I've seen the value change by more than 10 units just by switching to a different pen... There's absolutely nothing stopping us from introducing a tablet that invalidates any clever code you may come up with. > As for the tilt axes of the tools, this is something that could be > represented in a more meaningful value. We could normalize it to a > number between 0 and 180°, so you can get the actual tilt in degrees as > opposed to what we currently have. This is som
Re: [PATCH libinput 0/24] Tablet support
On Thu, May 29, 2014 at 11:45 PM, Daniel Stone wrote: > On 29 May 2014 18:54, Jason Gerecke wrote: >> >> If that's the case though, I have to ask -- *why* on Earth is >> 'li_fixed_t' even being considered as libinput's output type? I know >> I'm missing something because the thought seems like such a blindingly >> terrible choice. Its not an intrinsic type, is ill-suited to the task >> of representing normalized data, and can't be directly used without >> very real overflow concerns. By contrast 'float' is a standard type >> which takes up the same space, offers sufficient precision of >> normalized data, and can be freely operated on without concern. Is >> there some crazy reason that floats aren't viable as the output type? >> Are we communicating over the Wayland protocol despite being a >> library? Targeting hardware with no FPU? libinput seems like it could >> be useful to more than just Wayland compositors, so I _really_ hope >> the reason isn't to maximize the degree of integration between the >> two. > > > Both Wayland and X11 use fixed-point types over the wire. Obviously none of > this is driven by no-FPU, because even on ARM that isn't a thing. But why should libinput care about that fact? Does it communicate over the wire itself? If not, then why wouldn't defining the API to return a normalized 'float' or 'double' be more appropriate? If Qt, EFL, or Android decided to replace the code they currently have for gathering and filtering events from evdev with libinput, do you think they'd honestly prefer to be handed full-range rather than normalized data? Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three,/ So you look at the sixty-fours ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/24] Tablet support
On Wed, May 28, 2014 at 6:39 PM, Peter Hutterer wrote: > On Wed, May 28, 2014 at 10:23:00AM -0700, Jason Gerecke wrote: >> On Tue, May 27, 2014 at 8:32 PM, Chandler Paul wrote: >> > On Wed, 2014-05-28 at 12:48 +1000, Peter Hutterer wrote: >> >> On Tue, May 27, 2014 at 03:40:07PM -0700, Jason Gerecke wrote: >> >> > On Tue, May 27, 2014 at 3:20 PM, Peter Hutterer >> >> > wrote: >> >> > > On Tue, May 27, 2014 at 04:32:14PM -0400, Chandler Paul wrote: >> >> > >> On Tue, 2014-05-27 at 13:11 -0700, Jason Gerecke wrote: >> >> > >> > I've been away from my computer for most of the (long) weekend up >> >> > >> > here, so apologies for being a bit quiet :) >> >> > >> >> >> > >> > There's a subtlety on the protocol side of things that can't be >> >> > >> > ignored. When normalizing data, you want to be careful to preserve >> >> > >> > information about the zero point. Without that, you can't >> >> > >> > meaningfully >> >> > >> > pass the data along. Lets imagine that we have some sensor that >> >> > >> > will >> >> > >> > report values between 10 and 100, with a resolution of 1 unit = 1 >> >> > >> > elbow per square ounce. If we normalize that to the range [0, >> >> > >> > UINT32_MAX] we've lost information about where "zero" is. A >> >> > >> > normalized >> >> > >> > value of zero does not correspond to zero elbows per square ounce >> >> > >> > as >> >> > >> > you might expect, and the resolution info is insufficient to >> >> > >> > correct >> >> > >> > the offset. >> >> > >> > >> >> > >> > Now, if we've done our jobs properly in libinput, that shouldn't >> >> > >> > be a >> >> > >> > problem. We would have normalized that sensor's values to [0.1, 1] >> >> > >> > and >> >> > >> > announced the axis to have a resolution of 1 unit = 100 elbows per >> >> > >> > square ounce. Because the zero point is offset like it originally >> >> > >> > was, >> >> > >> > it's preserved through the scaling done for the protocol and so the >> >> > >> > original 10-100 range can be recovered. The only amendment I'd >> >> > >> > make is >> >> > >> > to use a signed integer type rather than an unsigned one, since we >> >> > >> > may >> >> > >> > have negative normalized values that need to be sent through the >> >> > >> > protocol. >> >> > >> I just wrote code to normalize it to INT_MAX, but since everything's >> >> > >> in >> >> > >> fixed point integers the actual values it's being scaled to are >> >> > >> 0-8388607.99609375 when the fixed point axis value is converted back >> >> > >> into a double, which as I'm sure you probably realize is kind of a >> >> > >> strange value, and I'm starting to think something like 0.1-1.0 >> >> > >> would be >> >> > >> a lot better, trying to normalize to INT_MAX results in something >> >> > >> that >> >> > >> sounds really weird to work with. >> >> > > >> >> > > we need a LI_FIXED_MAX then. Normalising to 0-1 in a 24.8 fixed point >> >> > > only >> >> > > leaves us with 256 value per axis. >> >> > > >> >> > Yeah, we don't want to pass a value like that through the fixed type. >> >> > It either needs to be re-scaled to use the full range (be that >> >> > [INT_MIN, INT_MAX] or [FIXED_MIN, FIXED_MAX]) or sent with a type that >> >> > won't loose quite as many bits :D >> >> >> >> didn't think of it until after I sent the previous email: >> >> >> >> there's a side-effect that we need to be aware of: if we scale an axis to >> >> LI_FIXED_MAX, we're effectively guaranteed to get 32-bit integer overflows >> >> on operations with that value. So we're effectively forcing the caller to
Re: [PATCH libinput 0/24] Tablet support
On Tue, May 27, 2014 at 8:32 PM, Chandler Paul wrote: > On Wed, 2014-05-28 at 12:48 +1000, Peter Hutterer wrote: >> On Tue, May 27, 2014 at 03:40:07PM -0700, Jason Gerecke wrote: >> > On Tue, May 27, 2014 at 3:20 PM, Peter Hutterer >> > wrote: >> > > On Tue, May 27, 2014 at 04:32:14PM -0400, Chandler Paul wrote: >> > >> On Tue, 2014-05-27 at 13:11 -0700, Jason Gerecke wrote: >> > >> > I've been away from my computer for most of the (long) weekend up >> > >> > here, so apologies for being a bit quiet :) >> > >> >> > >> > There's a subtlety on the protocol side of things that can't be >> > >> > ignored. When normalizing data, you want to be careful to preserve >> > >> > information about the zero point. Without that, you can't meaningfully >> > >> > pass the data along. Lets imagine that we have some sensor that will >> > >> > report values between 10 and 100, with a resolution of 1 unit = 1 >> > >> > elbow per square ounce. If we normalize that to the range [0, >> > >> > UINT32_MAX] we've lost information about where "zero" is. A normalized >> > >> > value of zero does not correspond to zero elbows per square ounce as >> > >> > you might expect, and the resolution info is insufficient to correct >> > >> > the offset. >> > >> > >> > >> > Now, if we've done our jobs properly in libinput, that shouldn't be a >> > >> > problem. We would have normalized that sensor's values to [0.1, 1] and >> > >> > announced the axis to have a resolution of 1 unit = 100 elbows per >> > >> > square ounce. Because the zero point is offset like it originally was, >> > >> > it's preserved through the scaling done for the protocol and so the >> > >> > original 10-100 range can be recovered. The only amendment I'd make is >> > >> > to use a signed integer type rather than an unsigned one, since we may >> > >> > have negative normalized values that need to be sent through the >> > >> > protocol. >> > >> I just wrote code to normalize it to INT_MAX, but since everything's in >> > >> fixed point integers the actual values it's being scaled to are >> > >> 0-8388607.99609375 when the fixed point axis value is converted back >> > >> into a double, which as I'm sure you probably realize is kind of a >> > >> strange value, and I'm starting to think something like 0.1-1.0 would be >> > >> a lot better, trying to normalize to INT_MAX results in something that >> > >> sounds really weird to work with. >> > > >> > > we need a LI_FIXED_MAX then. Normalising to 0-1 in a 24.8 fixed point >> > > only >> > > leaves us with 256 value per axis. >> > > >> > Yeah, we don't want to pass a value like that through the fixed type. >> > It either needs to be re-scaled to use the full range (be that >> > [INT_MIN, INT_MAX] or [FIXED_MIN, FIXED_MAX]) or sent with a type that >> > won't loose quite as many bits :D >> >> didn't think of it until after I sent the previous email: >> >> there's a side-effect that we need to be aware of: if we scale an axis to >> LI_FIXED_MAX, we're effectively guaranteed to get 32-bit integer overflows >> on operations with that value. So we're effectively forcing the caller to >> work with int64_t to be on the safe side. >> >> which isn't the worst of all things: on fixed 24.8 with current devices >> overflows aren't _that_ hard to trigger so we pretty much get to pick >> whether they happen sometimes for some devices or all the time, effectively >> forcing all callers to handle this correctly from day 1. I thought that scaling-up the range to LI_FIXED_MAX was purely an intermediate form that would then be scaled-back to either a normalized or canonical value by the wl-client. I don't know who in their right mind would try to use the full-range 24.8 data directly without first dividing it down. > I've already implemented scaling to LI_FIXED_MAX in my tree, but I agree > this is something we should probably try to avoid. My thought here is > that we could scale it to a smaller value that's extremely unlikely to > ever overflow. My idea is to scale it to a 16.8 bit value. I don't think > it's likely that we'll ever be encountering anythin
Re: [PATCH libinput 0/24] Tablet support
On Tue, May 27, 2014 at 3:52 PM, Peter Hutterer wrote: > On Tue, May 27, 2014 at 01:11:31PM -0700, Jason Gerecke wrote: >> I've been away from my computer for most of the (long) weekend up >> here, so apologies for being a bit quiet :) >> >> >> On Sun, May 25, 2014 at 7:13 PM, Peter Hutterer >> wrote: >> > On Fri, May 23, 2014 at 10:34:10PM -0400, Chandler Paul wrote: >> >> On Fri, 2014-05-23 at 17:00 +1000, Peter Hutterer wrote: >> >> > I'm almost sold on normalization since it does reduce the likelihood of >> >> > things going wrong. We need to provide the axis resolution to convert >> >> > back >> >> > to the real data though where needed. >> >> > >> >> > once you provide the axis resolution, it doesn't matter if you provide >> >> > raw >> >> > data unless you also want to provide "raw" resolution, which is >> >> > excessive.. >> >> > >> >> > so, given that this would be sent down the protocol (and for the limited >> >> > resolution) the range should be normalised to uint16_t or uint32_t max, >> >> > with >> >> > the resolution in units/mm or canonicalized where more appropriate. This >> >> > would be what goes on the wayland protocol as well then. >> >> > >> >> > helper functions to convert that back to doubles, or elbows per square >> >> > ounce >> >> > would be part of the wl-client package that parses that protcol, not >> >> > libinput. >> >> > >> >> > that doesn't seem like the worst architecture for both libinput and the >> >> > protocol, any comments? >> >> >> >> There's a subtlety on the protocol side of things that can't be >> ignored. When normalizing data, you want to be careful to preserve >> information about the zero point. Without that, you can't meaningfully >> pass the data along. Lets imagine that we have some sensor that will >> report values between 10 and 100, with a resolution of 1 unit = 1 >> elbow per square ounce. If we normalize that to the range [0, >> UINT32_MAX] we've lost information about where "zero" is. A normalized >> value of zero does not correspond to zero elbows per square ounce as >> you might expect, and the resolution info is insufficient to correct >> the offset. > > good point, keeping the zero point is important. > >> Now, if we've done our jobs properly in libinput, that shouldn't be a >> problem. We would have normalized that sensor's values to [0.1, 1] and >> announced the axis to have a resolution of 1 unit = 100 elbows per >> square ounce. Because the zero point is offset like it originally was, >> it's preserved through the scaling done for the protocol and so the >> original 10-100 range can be recovered. The only amendment I'd make is >> to use a signed integer type rather than an unsigned one, since we may >> have negative normalized values that need to be sent through the >> protocol. >> >> >> Seems fine to me. As for normalizing values to units/mm or the like, is >> >> there any known conversion for the units the tablet returns for distance >> >> to metric? >> > >> > Benjamin answered that on IRC, but for the archives: the distance is in mm, >> > though in reality the data is inprecise. >> > >> > Cheers, >> >Peter >> > >> >> I would avoid attaching units or resolution to axes which do not >> already declare them. The distance values on our pens do roughly >> correspond to millimeters from the sensor (which itself is usually a >> few mm below the surface) but we should be reporting a non-zero >> resolution through evdev if the data were reasonably accurate :D >> >> Also, libinput shouldn't generally be "normalizing values to units/mm >> or the like." Data should be normalized to some range within [-1, 1] >> so that the zero point is preserved. Resolution data should be >> provided through another means which relates normalized values to >> real-world units (and should probably be documented to be zero if the >> resolution is unknown). The only exception to this /might/ be >> something like tilt or rotation (though the more I think about it, the >> less I believe it to be worthy of exception given how apps actually >> use the data). > > looking at linux/input.h, the axes where we should attach resolut
