On Tue, Sep 27, 2011 at 2:03 PM, Eduard Hasenleithner
<ehase...@gmail.com> wrote:
>> Yes, and no. Yes for the led to provide new app functions. No if you
>> think we are going to report the LED through XInput valuators. Due to
>> backward compatibility, we will not report LED as a new axis. It will
>> only be reported as a Wacom property through xsetwacom.
>
> Ah, ok, so we have no XInput valuator then.
Right. That's also what Peter suggested
>>> Please find attached how I see it what happens when the toggle button
>>> is pressed.
>>
>> I agree with you except one step: we do not ignore the round button
>> event. It will still be reported to the userland. There is no need to
>> prevent userland to assign a new function for it.
>
> I guessed that it is the X11 input driver (xf86-input-wacom) which
> increases the LED number when the toggle button is pressed. This
> cannot be influenced by the X11 app, right?
No. X driver gets the button event directly from the kernel before any
apps. Whatever the app does after the button event is posted to the
userland won't affect anything inside the X driver.
> No, I meant synthesizing the valuator event. Reading the patch you
> attached, the axis is synthesized in the kernel. And I'm asking, why
> not synthesize it in the xf86-input-wacom driver? I still have the
> feeling, I have a misconception on how this status led reporting is
> planned work in the end.
Oh, do you mean we manupulate led.select in xf86-input-wacom and let
kernel driver post it as is to the device? I was doing that in my
code. But I saw you did that in the kernel. So, I made my patch closer
to yours. We can definitely change that.
> Sorry, I wanted to test the patch, but I couldn't because the
> indentation is garbled. Please see the inline comments. In principle,
> I'm ok with the patch. I just want to test it.
I'll email you as an attachment.
>> ----------------
>>
>> diff --git a/drivers/input/tablet/wacom.h b/drivers/input/tablet/wacom.h
>> index 00332d66..3cb80cc 100644
>> --- a/drivers/input/tablet/wacom.h
>> +++ b/drivers/input/tablet/wacom.h
>
>> @@ -93,7 +93,7 @@
>> /*
>> * Version Information
>> */
>> -#define DRIVER_VERSION "v1.52"
>> +#define DRIVER_VERSION "v1.53"
>> #define DRIVER_AUTHOR "Vojtech Pavlik <vojt...@ucw.cz>"
>> #define DRIVER_DESC "USB Wacom tablet driver"
>> #define DRIVER_LICENSE "GPL"
>> @@ -115,7 +115,8 @@ struct wacom {
>> bool open;
>> char phys[32];
>> struct wacom_led {
>> - u8 select; /* status led selector (0..3, -1=none) */
>> + /* 0xf0 for LEDs on the left; 0x0f on the right */
>> + u8 select; /* status led selector (1..4, 0=none) */
>
> Dmitry explicitly wanted me to have all values as separate properties.
> I guess he will want these two also separate. For me, the separation
> is not important.
I see your point. But we will need to merge them together since they
will be sent to the device as one byte. I'll see if I can convince
Dmitry or not.
> Nevertheless, the ABI documentation will also need to be updated.
Ok, I'll update that.
> For the Intuos4 at least, the counting starts from 0 (zero). This
> patch makes it starting from 1, but no translation here. So the LEDs
> would be lit in this order: 2, 3, 4, 1. I guess, you should "add" -1
> to the right_id and left_id values.
I changed the "no led" to 0 since "adding" -1 to a 4-bits data isn't
as clear as assigning it to 0. Also, how the led will be
switched/ordered is not decided by this code. It will be decided by
the client who sends the sysfsctl. If they send 0x0 first, 1 will be
the first to be on. Then 0x1, 0x2... If we move this part to
xf86-input-wacom, we don't need to worry about it here.
Thank you for the comments. Let me know if you have other suggestions.
Ping
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
