#177 Eraser does not work with button events generated from evrouter

[The Compiler]

For some reason, the second button on my Thinkpad X1 Yoga's pen does not work out of the box.

I tried using evrouter to map the event to a button:

"Wacom Co.,Ltd. Pen and multitouch sensor Pen" "/dev/input/event*" none key/321 "XButton/3"

According to evrouter's docs, this generates an event via the XTEST extension.

When I try to use that key for Xournal's eraser, the cursor changes to the white square (and the tool in the toolbar changes to the eraser), but I can't actually erase anything. When I disable xinput in the menu, it works fine though.

[Denis Auroux]

Hi there,

1. The general issue about the second side button should be reported
   against linuxwacom -- the wacom driver already contains specifics about
   various models of wacom tablets/pens and should presumably be patched to
   learn about the second side button on the X1 Yoga pen.
   (Regarding why you also have eraser devices and more buttons configured
   in some places, it's because your tablet device is compatible with
   various models of pens, and some of those pens may have eraser tips. So
   the driver creates all the devices that may be needed, just in case you
   bring a compatible wacom eraser tip into contact with the screen at some
   future time. (I don't know if this applies to the new AES pens on
   current Yogas, as I don't know any that come equipped with an eraser
   tip, but eg. my Yoga S1 has a pen without eraser tip, but I can use the
   older pen from my previous Thinkpad which has an eraser).

The wacom driver has many settings to remap buttons etc., and I
imagine that there might be some config options for it that make the X1
Yoga pen side buttons work completely -- but wouldn't know where to
point you. If there are no such options yet then the wacom driver
developers should work on it.

1. XTEST vs XInput: I'll try to look into it at some point, but I think
   it's out of my control, and basically I don't think evrouter is the
   right way to deal with your problem -- because it doesn't generate
   XInput events, so xournal can't identify where the third button press
   came from and in fact never receives it altogether when xinput handling
   is enabled.

Older versions of GTK2 used to let xournal receive core (non-XInput)
button events and process them (subject to the
"discard_corepointer=false" setting in the config file) when no xinput
event comes in, but GTK2 developers have decided in their great wisdom
that xinput-aware windows should never ever receive any core events. I
had a workaround for this in the xournal code that worked up to GTK 2.16
(many years ago) by setting up two windows with different xinput
awareness; this no longer works since GTK 2.17 and we have to choose to
receive either core or xinput events, can't get both.

Anyway: my advice would be to look into the wacom driver options and any
recent patches they may have released for this.

Sorry!
Denis

[The Compiler]

Thanks for the answer! Any chance you could shed some light on how those drivers work, i.e. what project does what? I first thought xf86-input-wacom would be the right place, but then I discovered I can actually uninstall that and things still work fine (via xf86-input-evdev?).

Is linuxwacom the kernel part of this which does all the heavy lifting (and would thus be the right place to report this), and xf86-input-{evdev,wacom} are just simple userspace utilities interpreting the data from /dev/input/eventX (so what evrouter does too essentially)?

[Denis Auroux]

On 12/20/2016 11:16 AM, The Compiler wrote:

Thanks for the answer! Any chance you could shed some light on how those
drivers work, i.e. what project does what? I first thought
xf86-input-wacom would be the right place, but then I discovered I can
actually uninstall that and things still work fine (via xf86-input-evdev?).

evdev is a generic driver for all sorts of
tablets/pads/touchscreens/etc., including wacom (probably relying on
wacom kernel driver).
wacom is just for wacom tablets (and wacom pens on tablet PCs) and
should have more advanced wacom-specific features.

See http://linuxwacom.sourceforge.net/wiki/index.php/Downloads
for a sense of the respective roles of the kernel driver and the X input
driver.

I suspect that the linuxwacom project is more responsive for support of
specific models of wacom pens, but I have very little experience with
evdev. Anyway, I'd say that xf86-input-wacom is the place to look,
unless it's the wacom kernel module.

(In fact... does the side button issue comes up differently depending on
whether you are using the wacom or evdev drivers? if not then it might
mean that the issue is on the kernel driver side).

Also, I forgot if you've looked into xsetwacom configuration options,
including button mapping -- though it might be hard to figure out what
kind of button mapping would help in your situation.
http://linuxwacom.sourceforge.net/wiki/index.php/Xsetwacom

Good luck!
Denis

[The Compiler]

I found those related bugs:

https://sourceforge.net/p/linuxwacom/bugs/321/
https://bugzilla.kernel.org/show_bug.cgi?id=119941

Apparently that didn't make it into 4.9, but for some reason my second button now actually erases in Xournal after I updated to that (when used together with the tip button only, i.e. the tool doesn't switch immediately when I press it)! Still don't see anything in Xev though :D