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,
though.
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. ;^)
Thanks!
--
John J. Karcher
devuser at alternateapproach.com
More information about the users
mailing list