Wacom Touchscreen / Pen Driver

John J. Karcher devuser at alternateapproach.com
Sun Nov 28 04:09:29 CET 2021

Two replies in one...

On 11/24/21 07:26, Johannes Schlatow wrote:
> Hi John,
> On Tue, 23 Nov 2021 20:10:23 -0500
> "John J. Karcher" <devuser at alternateapproach.com> wrote:
>> It's related to that issue, but the crash has been fixed.  The
>> remaining problem is that the hardware generates a variety of
>> non-standard events, which confuse nitpicker (e.g., puts it into a
>> state where it no longer responds to mouse clicks).
>> [...]
>> Any ideas are welcome!
> This reminds me of an issue [1] that I had with a certain keyboard. Are
> you sure that the non-standard events you see are correct, i.e. do they
> appear on Linux as well? In my case, the hardware was triggered to
> generate some sort of an extra status report that got misinterpreted as
> input events.
> [1] https://github.com/genodelabs/genode/issues/4146

I haven't debugged it in depth, assuming that porting the missing files 
from the Linux code would solve the problem.

Your status report idea is a possibility.  Looking at the #defines, most 
of the event codes look "normal" (e.g., pressure, tilt, extra buttons, 
etc.), but there are a couple of battery-related codes, for example.  I 
do note that Nitpicker doesn't get confused until the screen is touched, 

On 11/24/21 01:44, Uwe wrote:
> If they are really non-standard events (real events not covered in an
> applicable standard, e.g. pressure change), and not merely duplicate
> events encoded in a non-standard way. I would opt for defining a
> (genode) standard for encoding these events and implementing them in
> nitpicker and encoding them in the driver in the (now new) standard
> way.

That does sound nice, but it's a little beyond my purview. ;^)


   John J. Karcher
   devuser at alternateapproach.com

More information about the users mailing list