You are not logged in.

#1 2017-02-04 02:08:19

eevee
Member
Registered: 2012-04-14
Posts: 2

Touch strip on a Wacom tablet with libinput (+binding button to shift)

I have an old Wacom Intuous3, which I've been using for a while with xf86-input-wacom.  After upgrading to xorg 1.19.1, I started getting spurious X crashes, which a couple other threads blamed on the wacom driver.  libinput boasts tablet support, so I decided to give it a spin.  (No more crashes yet, so... so far, so good.)

Pen position, pressure, tilt, switching between pen and eraser, and so forth all work splendidly.  The buttons act as regular mouse buttons — i.e., the tablet's first button acts as left click — but I remapped them with xinput set-button-map and bound them to keyboard shortcuts with xbindkeys without much fuss.

There are two remaining behaviors I had with the wacom driver that I've been unable to replicate.



The big one is the touch strip next to the buttons.  With the wacom driver, sliding a finger along the strip acts exactly like an extra mouse wheel out of the box, and I used it fairly heavily for zooming while drawing.  With libinput, it does nothing.

I can see the strip (both, in fact) listed as a valuator in xinput list for the pad; its current value is shown in xinput query-state; touching it causes "motion" events in xinput test; and it produces TABLET_PAD_STRIP events for libinput-debug-events.

However, it produces no events whatsoever for xev, and touching it doesn't do anything in any application.  I can't find any documentation or utilities, anywhere, for binding a valuator to do anything.

This is kind of inconvenient, since the strip was the only way I had to zoom with my left hand while drawing with my right.  But so far the closest I've found to a solution is a script that scrapes events from libinput-debug-events's output (!).



The other problem is binding a button to a modifier key.  I had one of the tablet buttons bound to shift using xsetwacom set $pad Button 8 key +shift, which was handy in Krita, where shift-drag changes the size of the brush.  I tried to replicate this with xbindkeys:

"xte 'keydown Shift_L'"
  b:18
"xte 'keyup Shift_L'"
  b:18 + shift + release

This...  doesn't work.  (Nor does the xdotool equivalent.)  While holding the button, Krita doesn't do anything at all, not even repaint.

I can hold the button and press a key to get a capital letter, so using it with the keyboard works.  If I hold it and click in a text field, nothing happens (rather than extending the selection), so it seems to only be broken in combination with other mouse buttons.

xev shows spurious LeaveNotify and EnterNotify events — which indicate the pointer has left or re-entered the window, even though it didn't move while I tested the button — so my best guess is that those are interfering?  No other mouse events are fired while the button is held down.  I found a stackoverflow question blaming those events on XGrabButton, which xbindkeys apparently uses, but nothing about a workaround.

This one isn't too big a deal, since I can just as well use the left shift key, but I'm curious why it doesn't work.  I've found a number of people trying to do this, but no solutions (short of reading /dev/event/... directly or something similarly clumsy).

Last edited by eevee (2017-02-04 02:11:25)

Offline

Board footer

Powered by FluxBB