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@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.
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!