On Tue, Aug 24, 2010 at 7:11 AM, Mike Auty <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24/08/10 10:26, Ping Cheng wrote:
>>
>> Thank you Mike for looking into the details.
>>
>
> Hiya Ping, thanks very much for getting back to me. 5:)
>
>>
>> The code was:
>>
>> rw = data[7] & 0x04 ? (data[7] & 0x03)-4 : (data[7] & 0x03);
>> wacom_report_rel(wcombo, REL_WHEEL, -rw);
>>
>> it is changed to:
>>
>> rw = (signed)(data[7] & 0x04) - (data[7] & 0x03);
>> input_report_rel(input, REL_WHEEL, rw);
>>
>> I guess they should report the same value? I don't have a graphire to test
>> with.
>>
>
> I looked at that code too and tried to figure it out, and from what I
> can tell the two calculations do add up to the same results. The only
> difference I could see from the patch was that further down, the old
> code sent the following (in the switch features->type, case WACOM_G4, if
> data[7] & 0xf8):
>
> wacom_report_rel(wcombo, REL_WHEEL, 0);
> wacom_report_key(wcombo, BTN_TOOL_FINGER, 0);
>
> while the new code sends (both for data[7] & 0xf8 and for wacom->id[1])
>
> rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3);
> wacom_report_rel(wcombo, REL_WHEEL, rw);
> wacom_report_key(wcombo, BTN_TOOL_FINGER, 0xf0);
>
> Would that have affect the buttons returned? I couldn't see any
> difference between calls using BTN_4 or BTN_5 which is where I expected
> to see the problem...
>
>>
>> What was going on? I am not sure (I am not kidding :). I guess we
>> wanted to simplify the logical?
>>
>
> It looks like there was a lot of duplicated code, so the cleanup
> should've been fine, but given the lines above, I'm not sure they work
> identically. The problem is, I don't know which of the calls is
> important and which isn't, so I can't easily produce a fix myself.
>
> I'm happy to try out patches against whichever kernel version you'd like?
>
Can you try the following? This Graphire is the only code path that
hard codes the BTN_TOOL_FINGER to a value of 0xf0. The bisect shows a
time period when it was not fixed to 0xf0 so I suspect that is your
issue.
All other code paths set it to either 0xf0/0 or 1/0 based on proximity
values. I guess currently it means you could get a garbage value
right at going out-of-proximity which could explain unwanted button
presses.
Look for this in WACOM_C4 case statement:
input_report_key(input, BTN_TOOL_FINGER, 0xf0);
if (!prox)
wacom->id[1] = 0;
And change to:
input_report_key(input, BTN_TOOL_FINGER, prox != 0);
if (!prox)
wacom->id[1] = 0;
You could change that a little if you still want to send 0xf0 during
in-proximity but xf86-input-wacom can handle either I believe since
other code is doing 1/0. Also, if this fixes things then WACOM_MO
case needs similar change.
Chris
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
