On Mon, Mar 14, 2011 at 2:08 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:

> Hi all,
>
> This is related to thread on linuxwacom-discuss about older Bamboo's
> PAD not working right with recent xf86-input-wacom's.  This device is
> handled by Graphire driver in kernel.

The reason is related to interaction of multiple recent code
> submissions.  But the root issue to me is a kernel side issue that
> xf86-input-wacom was trying to hopelessly work around.
>
 The major difference, and root cuase, lies in the ABS_MISC bit. We used to
reply on ABS_MISC for tool type and in/out prox events. We can not do that
any more unless we leave protocol 4 devices in the old path.


> Take a look at this kernel code that is executed when either a) a PAD
> device needs to send a button press or wheel movement or b) one last
> time when buttons/wheel are released.
>
>                if (prox || wacom->id[1]) {
>                        wacom->id[1] = PAD_DEVICE_ID;
>                        input_report_key(input, BTN_0, (data[7] & 0x08));
>                        input_report_key(input, BTN_1, (data[7] & 0x20));
>                        input_report_key(input, BTN_4, (data[7] & 0x10));
>                        input_report_key(input, BTN_5, (data[7] & 0x40));
>                        input_report_abs(input, ABS_WHEEL, (data[8] &
> 0x7f));
>                        input_report_key(input, BTN_TOOL_FINGER, 0xf0);
>                        if (!prox)
>                                wacom->id[1] = 0;
>                        input_report_abs(input, ABS_MISC, wacom->id[1]);
>                        input_event(input, EV_MSC, MSC_SERIAL, 0xf0);
>                }
>
If we make a kernel patch, we need to remove both BTN_TOOL_FINGER and
ABS_MISC. MSC_SERIAL will be  removed for Graphire too.

Once we touch BTN_TOOL_FINGER, I'd like to remove  BTN_TOOL_FINGER for
Intuos/Citniq series as well. That's why I didn't start working on it yet. I
still have issue with serial ISDV4 kernel driver working with the current
xf86-input-wacom at this moment. I have a few patches to submit. But I need
to test the patches on different systems (w/o touch, ST, MT) first.

So, I'd prefer we leave Graphire and non-touch Bamboo's at protocol 4
path in xf86-input-wacom. Cleaning up everything for Generic protocol in its
own path without affecting P4 offers me sometime to catch up. I can only
work on one set of devices at a time ;).



> I obviously need some help here since I'm flying blind without the
> problem device.  I can make a kernel patch but can't test it.
>
> Part of this email is also to make sure no one thinks we should try to
> solve this purely on userland side.


If you feel the urge to update the kernel driver, you can defintely do so
for Graphire. There is one minor detail you might need to pay a bit extra
attention in xf86-input-wacom and/or the kernel driver: Graphire 4 has a
relative wheel on the tablet. That is, for Graphire 4, the PAD and the Wacom
mouse both have relative wheels. You'll need to fingure out a way to report
them differently to support the case when the mouse is placed on the tablet
while users uses the PAD.

Ping
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to