wizardpen-testers team mailing list archive

[Kyōken <launchpad.maddog@xxxxxxx>]

On 11/14/10 15:28, Martin Owens wrote:
> Hey Kyōken,
>
> Any help you can provide will be most welcome... I will try and answer
> your questions below:

I've been doing background research the last couple of weeks (not full time :).
The gist of my enlightenment:
 o HAL is dead;
 o udev is the preferred device management paradigm (on linux);
 o kernel drivers provide linux 'input' devices;
 o xorg userspace drivers connect to those devices and do X stuff;
 o xorg.conf.d and InputClass sections handle input device configuration
   (after discovery via udev).

Some more wizardpen questions below:

> On Sun, 2010-11-14 at 09:42 -0500, Kyōken:
...
> The code for this driver is in launchpad, bugs are here:
>
> https://bugs.launchpad.net/wizardpen
>
> Trunk code:
>
> https://code.launchpad.net/~wizardpen-devs/wizardpen/trunk
...
> >    o What's the state of the glue code?  E.g. hotplugging?
> >      I saw a mention of moving the driver from xorg's userspace
> >      into a kernelspace input driver?  (True?)
>
> There is a new kernel driver which hotplugs into the wacom user space,
> so there is no need for this driver once it's complete. It's based on
> the wal code.

Where is the code for the new kernel driver?  (wizardpen/trunk's src
looks to be the same as 0.7.4's.)

Why plug into the xserver-xorg-input-wacom driver?  I got the impression
that the vanilla evdev driver was capable of handling simple, single-tool
tablets.  Conversely, I got the impression
 o Are there features of the wizardpen tablets that are not handled
    by the vanilla evdev input handling?
 o Will the wacom driver(s) developers/maintainers know/care that another
    kernel driver is going to use their protocol (and thus have a dependency
    on it)?

What is "the wal code"?

-m