All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Douglas <chasedouglas@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Jason Gerecke <killertofu@gmail.com>,
	Ping Cheng <pinglinux@gmail.com>,
	Mohamed Ikbel Boulabiar <boulabiar@gmail.com>,
	Linux Input <linux-input@vger.kernel.org>
Subject: Re: [PATCH] Input: wacom - Add POINTER and DIRECT device properties
Date: Mon, 19 Sep 2011 16:40:46 -0700	[thread overview]
Message-ID: <4E77D2FE.8060709@gmail.com> (raw)
In-Reply-To: <20110917112114.GA3015@polaris.bitmath.org>

On 09/17/2011 04:21 AM, Henrik Rydberg wrote:
> Hi Jason,
> 
>>>> 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

  reply	other threads:[~2011-09-19 23:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01 16:00 [PATCH] Input: wacom - Add POINTER and DIRECT device properties Jason Gerecke
2011-09-01 19:31 ` Ping Cheng
2011-09-13  8:09 ` Henrik Rydberg
2011-09-13  8:19   ` Mohamed Ikbel Boulabiar
2011-09-13 14:13   ` Chris Bagwell
2011-09-13 17:36     ` Ping Cheng
2011-09-13 20:54       ` Chris Bagwell
2011-09-16 23:10     ` Jeffrey Brown
2011-09-17 11:44       ` Henrik Rydberg
     [not found]   ` <CAPHpN5OAPdPQ1SmwrGT6pMvgWESBOSnRvb0jKUszkU_31MFXWg@mail.gmail.com>
2011-09-14  7:15     ` Henrik Rydberg
2011-09-15 16:16       ` Ping Cheng
2011-09-16 10:50         ` Henrik Rydberg
2011-09-16 21:45           ` Jason Gerecke
2011-09-17 11:21             ` Henrik Rydberg
2011-09-19 23:40               ` Chase Douglas [this message]
2011-09-20  1:05                 ` Jeffrey Brown
2011-09-20  2:49                   ` Chase Douglas
2011-09-21 11:42                     ` Henrik Rydberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E77D2FE.8060709@gmail.com \
    --to=chasedouglas@gmail.com \
    --cc=boulabiar@gmail.com \
    --cc=killertofu@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=pinglinux@gmail.com \
    --cc=rydberg@euromail.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.