On Thu, Mar 17, 2011 at 3:49 PM, Ping Cheng <[email protected]> wrote:
> On Thu, Mar 17, 2011 at 9:41 AM, Chris Bagwell <[email protected]> wrote:
>>
>> >>
>> >> finger event never toggled back to zero. Its serial
>> >> number also never transition to zero.
>> >>
>> >> This approach had some issues in user land when switching
>> >> between stylus and pad buttons and initial event was usually
>> >> sent before user apps ever started. This could be improved
>> >> by toggling BTN_TOOL_FINGER back to zero when all buttons
>> >> released; like most other wacom drivers are doing.
>> >>
>> >> Instead, convert to more "standard" approach where tablet pad buttons
>> >> are sent always without announcing them as tools. This aligns
>> >> with newer Bamboo P&T in same file.
>> >>
>> >> Note: REL_WHEEL can be on both mouse tool and tablet pad.
>> >> Userland must always treat them as coming from tablet pad to avoid
>> >> confusion (don't ignore while mouse tool is out of proximity).
>> >
>> > Can we use another bit for the pad wheel, such are REL_HWHEEL so both
>> > wheels can be reported and processed in the userland?
>>
>> I thought about it but from generic point of view it doesn't help. As
>> long as xf86-input-wacom knows make and model of tablet then yes we
>
> I am with you on this idea. I want to treat them as generic as possible too.
> No tablet model or id is involved here, or in the user land.
>
>>
>> can say "this tablet uses REL_HWHEEL on pad and REL_WHEEL on mouse"
>> but in generic view were we do not hard code make/model then REL_WHEEL
>> and REL_HWHEEL are both valid mouse events with the later more for
>> those +1/-1 movements when pushing scroll wheel sideways.
>
> REL_WHEEL is from mouse/puck for all existing models that support relative
> wheel. That's why I want to keep REL_WHEEL for mouse. We do not need to
> check the tablet model or id to decide this.
>
>> In addition, we still have user land issue where BTN_LEFT/RIGHT could
>> be a mouse of a pad.
>
> You suggested we stay with BTN_# for pad, right? So, if we do not move PAD
> buttons to BTN_LEFT/RIGHT. No issues here either.
Because Bamboo's are using BTN_LEFT/RIGHT on bad, all "generic"'s are
routing those buttons to PAD. So unless code is added, the Graphire
generic will route mouse puck's buttons to PAD.
>
>> In other email, I mentioned I think its easier to treat REL_WHEEL as
>> PAD event *always* in xf86-input-wacom. User won't know difference.
>
> You mentioned this idea above in your commit message too.
>
> User will see the difference since they get a PAD tool when there is no pad
> on the tablet. For example, Graphire 1, 2, and 3 all have relative wheel
> mouse. If we treat REL_WHEEL as a pad button, we are adding a pad tool for
> those devices.
I *think* all devices with wheels (REL and ABS) also have PAD tools.
But I'm not positive.
>
> However, if we use REL_HWHEEL for pad, there would be no confusion. We do
> not need to guess where REL_HWHEEL came from. It is from pad for sure since
> we've never used it anywhere else.
Agree it solves the problem... but its kinda arbitrary. REL_HWHEEL is
very mousy and we'de be stealing that event away from any future mouse
usage.
I'm not totally opposed to this approach but if you combine Bamboo
LEFT/RIGHT vs. Graphire LEFT/RIGHT then I hope we find similar
solution for both.
>
> I have a rough patch to show what's in my mind. Please take a look and let
> me know what you think. I'll make an official one if you are ok with it.
In the end, real code plus real testing wins. So if you can do both
then its your call how to proceed.
Chris
>
> Thank you.
>
> Ping
>
> diff --git a/drivers/input/tablet/wacom_wac.c
> b/drivers/input/tablet/wacom_wac.c
> index 5597637..9b9fbc3 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -199,11 +199,10 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
> struct input_dev *input = wacom->input;
> int prox;
> int rw = 0;
> - int retval = 0;
>
> if (data[0] != WACOM_REPORT_PENABLED) {
> dbg("wacom_graphire_irq: received unknown report #%d", data[0]);
> - goto exit;
> + return 0;
> }
>
> prox = data[1] & 0x80;
> @@ -213,12 +212,10 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
>
> case 0: /* Pen */
> wacom->tool[0] = BTN_TOOL_PEN;
> - wacom->id[0] = STYLUS_DEVICE_ID;
> break;
>
> case 1: /* Rubber */
> wacom->tool[0] = BTN_TOOL_RUBBER;
> - wacom->id[0] = ERASER_DEVICE_ID;
> break;
>
> case 2: /* Mouse with wheel */
> @@ -227,7 +224,6 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
>
> case 3: /* Mouse without wheel */
> wacom->tool[0] = BTN_TOOL_MOUSE;
> - wacom->id[0] = CURSOR_DEVICE_ID;
> break;
> }
> }
> @@ -252,52 +248,27 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
> input_report_rel(input, REL_WHEEL, rw);
> }
>
> - if (!prox)
> - wacom->id[0] = 0;
> - input_report_abs(input, ABS_MISC, wacom->id[0]); /* report tool id
> */
> input_report_key(input, wacom->tool[0], prox);
> - input_sync(input); /* sync last event */
> }
>
> /* send pad data */
> switch (features->type) {
> case WACOM_G4:
> - prox = data[7] & 0xf8;
> - if (prox || wacom->id[1]) {
> - wacom->id[1] = PAD_DEVICE_ID;
> - input_report_key(input, BTN_0, (data[7] & 0x40));
> - input_report_key(input, BTN_4, (data[7] & 0x80));
> - rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3);
> - input_report_rel(input, REL_WHEEL, rw);
> - 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);
> - retval = 1;
> - }
> + input_report_key(input, BTN_0, (data[7] & 0x40));
> + input_report_key(input, BTN_4, (data[7] & 0x80));
> + rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3);
> + input_report_rel(input, REL_HWHEEL, rw);
> break;
>
> case WACOM_MO:
> - prox = (data[7] & 0xf8) || data[8];
> - 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);
> - }
> - retval = 1;
> + 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));
> break;
> }
> -exit:
> - return retval;
> + return 1;
> }
>
> static int wacom_intuos_inout(struct wacom_wac *wacom)
> @@ -1066,9 +1037,9 @@ void wacom_setup_input_capabilities(struct input_dev
> *input_dev,
> /* fall through */
>
> case WACOM_G4:
> - input_set_capability(input_dev, EV_MSC, MSC_SERIAL);
> + __clear_bit(ABS_MISC, input_dev->absbit);
> + input_set_capability(input_dev, EV_REL, REL_HWHEEL);
>
> - __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> __set_bit(BTN_0, input_dev->keybit);
> __set_bit(BTN_4, input_dev->keybit);
> /* fall through */
>
>
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
