Chromium can't differentiate between pen tip and eraser input

[Janderhacker]

First, sorry if this is the wrong repository.

The pen and eraser support works perfectly in xournal++. Now, I tried using Obsidian with the excalidraw extension to make notes. After trying it out, I noticed that the eraser is not working.

I opened an issue in their repository, and they suggested that I should try this command:

function ppe(e) {console.log(e);}; window.addEventListener('pointerdown',ppe);

The command reported that chromium detects both inputs as button 1. Under windows, the pen tip is recognized as button 1 and the eraser as button 32.

[StollD]

We follow the standard linux convention of sending BTN_TOUCH when the pen touches the display, as well as BTN_TOOL_PEN when the pen is the active tool and BTN_TOOL_RUBBER.

For the fun of it I made iptsd not send the BTN_TOOL_PEN event. The result was that chromium would ignore the inputs, unless I used the eraser (but it would still draw like the pen).

To me this means that chromium can correctly detect the BTN_TOOL_RUBBER event, but at some point decides that it is actually a pen, not an eraser.

[StollD]

So I took a dive into the Chromium source code. The TL;DR; is: I have no idea what they are doing.

So Chromium has code which handles the BTN_TOOL_RUBBER and BTN_TOOL_PEN events just fine, by using the kernels evdev API. However, this code is not used at all in the Chromium backends for X11 or Wayland. Instead, it is only used when running Chromium without a display server or window management system at all.

While the X11 backend seems to ignore touch events entirely (which makes sense, because X11 is from the 80's and doesn't know touchscreens or pens), the Wayland backend does have support for them. But: The only code that can handle the stylus tools appears to use a Wayland protocol that literally exists nowhere, except for the Chromium repository.

Further digging revealed, that Chromium includes a Wayland compositor! Because of couse it would.

So my assumption is that the only way that Chromium can interpret these stylus tool events on a linux based system is by running Chromium bare-metal as a Wayland compositor, having it translate all the standard events from the evdev API to its own custom API, and then run a second Chromium as a Wayland client of this compositor.

Which is probably exactly what ChromeOS is doing...

[StollD]

I am going to close this as I don't believe this is an iptsd issue.