Re: [PATCH] Input: wacom - Add POINTER and DIRECT device properties

On 09/17/2011 04:21 AM, Henrik Rydberg wrote:

Hi Jason,

quoted

quoted

quoted

Take Wacom's Intuos and Graphire series for example, those tablets
support both styli and mice. For styli, the default is absolute mode;
while for mice, it is relative. So, only valid property the tablet can
tell the user-land is: I am a tablet, i.e., not a touchscreen. Clients
have to check the tool types to set the default mode to relative
(BTN_TOOL_MOUSE/LENS) or absolute (BTN_TOOL_PEN/AIRBRUSH/RUBBER...).

And those modes can be determined using the available axes. However,
when all axes are the same, a statement like "I am a tablet" does not
exist. In that case, distinguishing between touchscreen, touchpad and
tablet becomes a question of interpreting the properties. Such a
distinction cannot be achieved using a single bit of information, and
that was never the intention.

It is certainly true that you cannot separate out the different cases
with a single bit. The more properties and hints we can expose to
userspace the better. However, at the device level, there's only so
much information we *can* expose. We know if its a direct input device
or not. We don't know if its relative or absolute, since that depends
on the tool in use at any given moment.

It seems the various arguments we have seen in this thread are all
logical and well founded, but they originate in different assumptions
about the semantics of POINTER and DIRECT. Such a debate does
obviously not satisfy everyone.

The original intention of the properties are these:

POINTER - The device needs a visual guide in order to be useful. In
most cirumstances, this is equivalent to not having a screen directly
beneath the surface.

DIRECT - The input device is to be used as if it was overlaying a
sreen. It could be separate from the screen, but the expected behavior
should be the same.

From these definitions, it follows that a device could well be both
POINTER and DIRECT. For instance, a multitouch tablet designed to
replace the keyboard would fall into this category.

I think these are the clearest definitions I've seen of these
properties. It would be good to get them documented in
Documentation/input. Henrik, would you be able to do this?

-- Chase