On 09/05/2010 12:37 AM, Chris Bagwell wrote:
> Can you briefly say how those three BTN_* are used?  For example, does
> one represent when your using certain end of the pen (eraser)?  Or
> does BTN_TOUCH represent when pen is touching and others represent the
> buttons on the pen?
Well, quite naturally and simple:
BTN_TOUCH   - the tip is touching
BTN_STYLUS  - the first barell button
BTN_STYLUS2 - the second barell button

Like this:

     | |
     | |: -- BTN_STYLUS2
     | |
     | |: -- BTN_STYLUS
     | |
     `v' --- BTN_TOUCH
____________
/ / / / / /

> Yeah, its really udev doing the work here for MatchIsTablet.  See
> test_pointers() from this file:
>
> http://udev.sourcearchive.com/documentation/148/input__id_8c-source.html
>
> So anything reporting BTN_STYLUS or BTN_TOOL_PEN is considered a tablet.
Thanks for the reference :)

>> Could you say that the basic issue is solved from what I've written above?
>> Because I'm not sure I understood everything right.
>
> I think we can say its answered.  It sounds like drivers your working
> on will be detected as IS_INPUT_TABLET by udev because they all have
> common thread of BTN_STYLUS and one also has BTN_TOOL_PEN.
>
> So one initial update to xf86-input-wacom to make it more generic
> would require places were it check to see if this is a pen vs. mouse
> vs. whatever tool that it can say BTN_TOOL_PEN || BTN_STYLUS.
Thanks, that sounds great :) I'll continue reading the sources and then will
try to provide a patch, if nobody does it before me.

>> Also, from what I've seen in the code, I came to the conclusion that
>> MSC_SERIAL is necessary for selecting a channel. Am I wrong? Plus, it seems
>> BTN_TOOL_PEN is necessary too, but there is some additional check for
>> "_source" option in wcmIsAValidType which I don't yet understand, but which
>> allows the device to not have it. Could you please explain in short what
>> does it do and what "_source" option exactly is?
>
> Let me first point you to this following post.  It explains kernel
> side interface for wacom devices and may help to decode what
> xf86-input-wacom is trying to parse.
>
> http://www.mail-archive.com/[email protected]/msg00959.html
>
> A channel in xf86-input-wacom is loosely defined as maximum # of
> multiplexed tools on single input device that can be in proximity at
> the same time. MSC_SERIAL is not strictly required and it will default
> to channel 0 (see wcmUSB.c:usbChooseChannel).
Thanks. I got the impression it defaults to -1, which is considered invalid
and leads to an ignored event. Oh, well, I will recheck that.

> Most dumb devices can get away with single channel but we will
> eventually need to figure out how they report button presses on
> physical tablet because thats what second channel is mostly for.  For
> these simple devices, I think there must be some way we can allow
> buttons to be associated with the PEN channel and not required to be a
> fully independent device.
Wouldn't it be better to route such buttons to a separate /dev/input/event*
and deal with them separately either in the wacom or in some other driver?

> The wcmIsValidType is used during initialization time.  X driver
> creates internally a device for each of the multiplex tools reported
> over single input device.
What do you mean by the "X driver" - the wacom driver, or some generic X
code?

> The _source helps detect if its a real device or a fake device that X
> created.  Your devices will only have BTN_TOOL_PEN/BTN_STYLUS so it won't
> hit the logic to create this other devices...
Aha, thanks :)

Sincerely,
Nick

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to