Hello,
I was just wondering if anyone has had the itch to finish converting the Wacom touchscreen / pen driver, possibly with the benefit of the newer Linux driver conversion tools?
I've tried a couple of times, but it's beyond my skill set (and time to learn).
Thanks!
Hi John,
On Mon, Nov 22, 2021 at 19:19:01 CET, John J. Karcher wrote:
I was just wondering if anyone has had the itch to finish converting the Wacom touchscreen / pen driver, possibly with the benefit of the newer Linux driver conversion tools?
I've tried a couple of times, but it's beyond my skill set (and time to learn).
I do not know of anybody working on Wacom drivers or considering to integrate any missing pieces to the current usb_hid driver. We have plans to put device drivers for Intel notebook platforms on our agenda again in 2022. I'm not entirely sure if USB HID should be part of this, at least not highest priority, as the current implementation supports all devices available to us very well. First, we will concentrate on the base drivers (e.g., XHCI) to support recent notebook platforms.
Do you have experiments to share or just some details what is missing from the current driver? Is Linux 4.16.3 supporting the device your adressing? Are we talking about [1]?
[1] https://github.com/genodelabs/genode/issues/3997
Best regards
On 11/23/21 03:15, Christian Helmuth wrote:
Hi John,
On Mon, Nov 22, 2021 at 19:19:01 CET, John J. Karcher wrote:
I was just wondering if anyone has had the itch to finish converting the Wacom touchscreen / pen driver, possibly with the benefit of the newer Linux driver conversion tools?
I've tried a couple of times, but it's beyond my skill set (and time to learn).
I do not know of anybody working on Wacom drivers or considering to integrate any missing pieces to the current usb_hid driver. We have plans to put device drivers for Intel notebook platforms on our agenda again in 2022. I'm not entirely sure if USB HID should be part of this, at least not highest priority, as the current implementation supports all devices available to us very well. First, we will concentrate on the base drivers (e.g., XHCI) to support recent notebook platforms.
Do you have experiments to share or just some details what is missing from the current driver? Is Linux 4.16.3 supporting the device your addressing? Are we talking about [1]?
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).
Unfortunately, I just tried using brute force (before the Genodians articles about the new tooling), and don't have any useful results.
Do you think I might be able to borrow code from another driver? I could try that, and see what happens. (I'm running a newer version of Linux, but I assume that it's worked there for quite a while.)
Any ideas are welcome!
Thanks!
John J. Karcher devuser@alternateapproach.com
Gesendet: Mittwoch, 24. November 2021 um 02:10 Uhr Von: "John J. Karcher" devuser@alternateapproach.com An: users@lists.genode.org Betreff: Re: Wacom Touchscreen / Pen Driver
On 11/23/21 03:15, Christian Helmuth 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).
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.
Unfortunately, I just tried using brute force (before the Genodians articles about the new tooling), and don't have any useful results.
Do you think I might be able to borrow code from another driver? I could try that, and see what happens. (I'm running a newer version of Linux, but I assume that it's worked there for quite a while.)
Any ideas are welcome!
Thanks!
John J. Karcher devuser@alternateapproach.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
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.
[1] https://github.com/genodelabs/genode/issues/4146
Best regards Johannes
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!
-
Christian Helmuth -
Johannes Schlatow -
John J. Karcher -
Uwe