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

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

[Jason Gerecke]

Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
hardware supported by the Wacom driver. The DIRECT property is
assigned to devices with an embedded screen (i.e. touchscreens
and display tablets). The POINTER property is assigned to those
without embedded screens.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
 drivers/hid/hid-wacom.c                 |    2 ++
 drivers/input/tablet/wacom_wac.c        |   25 ++++++++++++++++++++++++-
 drivers/input/touchscreen/wacom_w8001.c |    2 ++
 3 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index 0688832..5b9267d 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -383,6 +383,8 @@ move_on:
 	hidinput = list_entry(hdev->inputs.next, struct hid_input, list);
 	input = hidinput->input;
 
+	__set_bit(INPUT_PROP_POINTER, input->propbit);
+
 	/* Basics */
 	input->evbit[0] |= BIT(EV_KEY) | BIT(EV_ABS) | BIT(EV_REL);
 
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 87b0e0d..a28d48c 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1098,6 +1098,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 		__set_bit(BTN_TOOL_MOUSE, input_dev->keybit);
 		__set_bit(BTN_STYLUS, input_dev->keybit);
 		__set_bit(BTN_STYLUS2, input_dev->keybit);
+
+		__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
 		break;
 
 	case WACOM_21UX2:
@@ -1126,6 +1128,9 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 		}
 
 		input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
+
+		__set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
+
 		wacom_setup_cintiq(wacom_wac);
 		break;
 
@@ -1150,6 +1155,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 		/* fall through */
 
 	case INTUOS:
+		__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
+
 		wacom_setup_intuos(wacom_wac);
 		break;
 
@@ -1165,6 +1172,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 
 		input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
 		wacom_setup_intuos(wacom_wac);
+
+		__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
 		break;
 
 	case TABLETPC2FG:
@@ -1183,14 +1192,24 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 	case TABLETPC:
 		__clear_bit(ABS_MISC, input_dev->absbit);
 
+		__set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
+
 		if (features->device_type != BTN_TOOL_PEN)
 			break;  /* no need to process stylus stuff */
 
 		/* fall through */
 
 	case PL:
-	case PTU:
 	case DTU:
+		__set_bit(BTN_TOOL_PEN, input_dev->keybit);
+		__set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
+		__set_bit(BTN_STYLUS, input_dev->keybit);
+		__set_bit(BTN_STYLUS2, input_dev->keybit);
+
+		__set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
+		break;
+
+	case PTU:
 		__set_bit(BTN_STYLUS2, input_dev->keybit);
 		/* fall through */
 
@@ -1198,11 +1217,15 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 		__set_bit(BTN_TOOL_PEN, input_dev->keybit);
 		__set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
 		__set_bit(BTN_STYLUS, input_dev->keybit);
+
+		__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
 		break;
 
 	case BAMBOO_PT:
 		__clear_bit(ABS_MISC, input_dev->absbit);
 
+		__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
+
 		if (features->device_type == BTN_TOOL_DOUBLETAP) {
 			__set_bit(BTN_LEFT, input_dev->keybit);
 			__set_bit(BTN_FORWARD, input_dev->keybit);
diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c
index c14412e..9941d39 100644
--- a/drivers/input/touchscreen/wacom_w8001.c
+++ b/drivers/input/touchscreen/wacom_w8001.c
@@ -383,6 +383,8 @@ static int w8001_setup(struct w8001 *w8001)
 	dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
 	strlcat(w8001->name, "Wacom Serial", sizeof(w8001->name));
 
+	__set_bit(INPUT_PROP_DIRECT, dev->propbit);
+
 	/* penabled? */
 	error = w8001_command(w8001, W8001_CMD_QUERY, true);
 	if (!error) {
-- 
1.7.6

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

[Ping Cheng]

On Thu, Sep 1, 2011 at 9:00 AM, Jason Gerecke <killertofu@gmail.com> wrote:
>
> Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
> hardware supported by the Wacom driver. The DIRECT property is
> assigned to devices with an embedded screen (i.e. touchscreens
> and display tablets). The POINTER property is assigned to those
> without embedded screens.
>
> Signed-off-by: Jason Gerecke <killertofu@gmail.com>

Reviewed-by: Ping Cheng <pingc@wacom.com>

Ping

> ---
>  drivers/hid/hid-wacom.c                 |    2 ++
>  drivers/input/tablet/wacom_wac.c        |   25 ++++++++++++++++++++++++-
>  drivers/input/touchscreen/wacom_w8001.c |    2 ++
>  3 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
> index 0688832..5b9267d 100644
> --- a/drivers/hid/hid-wacom.c
> +++ b/drivers/hid/hid-wacom.c
> @@ -383,6 +383,8 @@ move_on:
>        hidinput = list_entry(hdev->inputs.next, struct hid_input, list);
>        input = hidinput->input;
>
> +       __set_bit(INPUT_PROP_POINTER, input->propbit);
> +
>        /* Basics */
>        input->evbit[0] |= BIT(EV_KEY) | BIT(EV_ABS) | BIT(EV_REL);
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index 87b0e0d..a28d48c 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -1098,6 +1098,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>                __set_bit(BTN_TOOL_MOUSE, input_dev->keybit);
>                __set_bit(BTN_STYLUS, input_dev->keybit);
>                __set_bit(BTN_STYLUS2, input_dev->keybit);
> +
> +               __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>                break;
>
>        case WACOM_21UX2:
> @@ -1126,6 +1128,9 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>                }
>
>                input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
> +
> +               __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
> +
>                wacom_setup_cintiq(wacom_wac);
>                break;
>
> @@ -1150,6 +1155,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>                /* fall through */
>
>        case INTUOS:
> +               __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> +
>                wacom_setup_intuos(wacom_wac);
>                break;
>
> @@ -1165,6 +1172,8 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>
>                input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
>                wacom_setup_intuos(wacom_wac);
> +
> +               __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>                break;
>
>        case TABLETPC2FG:
> @@ -1183,14 +1192,24 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>        case TABLETPC:
>                __clear_bit(ABS_MISC, input_dev->absbit);
>
> +               __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
> +
>                if (features->device_type != BTN_TOOL_PEN)
>                        break;  /* no need to process stylus stuff */
>
>                /* fall through */
>
>        case PL:
> -       case PTU:
>        case DTU:
> +               __set_bit(BTN_TOOL_PEN, input_dev->keybit);
> +               __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
> +               __set_bit(BTN_STYLUS, input_dev->keybit);
> +               __set_bit(BTN_STYLUS2, input_dev->keybit);
> +
> +               __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
> +               break;
> +
> +       case PTU:
>                __set_bit(BTN_STYLUS2, input_dev->keybit);
>                /* fall through */
>
> @@ -1198,11 +1217,15 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>                __set_bit(BTN_TOOL_PEN, input_dev->keybit);
>                __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
>                __set_bit(BTN_STYLUS, input_dev->keybit);
> +
> +               __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>                break;
>
>        case BAMBOO_PT:
>                __clear_bit(ABS_MISC, input_dev->absbit);
>
> +               __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> +
>                if (features->device_type == BTN_TOOL_DOUBLETAP) {
>                        __set_bit(BTN_LEFT, input_dev->keybit);
>                        __set_bit(BTN_FORWARD, input_dev->keybit);
> diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c
> index c14412e..9941d39 100644
> --- a/drivers/input/touchscreen/wacom_w8001.c
> +++ b/drivers/input/touchscreen/wacom_w8001.c
> @@ -383,6 +383,8 @@ static int w8001_setup(struct w8001 *w8001)
>        dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
>        strlcat(w8001->name, "Wacom Serial", sizeof(w8001->name));
>
> +       __set_bit(INPUT_PROP_DIRECT, dev->propbit);
> +
>        /* penabled? */
>        error = w8001_command(w8001, W8001_CMD_QUERY, true);
>        if (!error) {
> --
> 1.7.6
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Henrik Rydberg]

Hi Jason,

> Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
> hardware supported by the Wacom driver. The DIRECT property is
> assigned to devices with an embedded screen (i.e. touchscreens
> and display tablets). The POINTER property is assigned to those
> without embedded screens.
> 
> Signed-off-by: Jason Gerecke <killertofu@gmail.com>
> ---

According to the discussion leading up to the properties interface
(https://lkml.org/lkml/2010/12/15/263), a tablet is a direct pointer
device, as opposed to a touchpad, which is an indirect pointer
device. The distinction determines the direction of two-finger scroll,
for instance. The question is then what behavior should be assigned to
a large tablet without an embedded screen. It should have POINTER set
for sure, but should it also have DIRECT set?

Thanks,
Henrik

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

[Mohamed Ikbel Boulabiar]

Hi,

On Tue, Sep 13, 2011 at 10:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> The question is then what behavior should be assigned to
> a large tablet without an embedded screen. It should have POINTER set
> for sure, but should it also have DIRECT set?

Any large tablet without an embedded screen can be used in the 2 different ways:
1. The projection on top of it so it becomes a direct device.
(this case is also used when you project 3d 120hz on top of multitouch
devices: iMuts)

2. Simple indirect device, even if it's large:
http://10gui.com/video/

i

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

[Chris Bagwell]

On Tue, Sep 13, 2011 at 3:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Jason,
>
>> Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
>> hardware supported by the Wacom driver. The DIRECT property is
>> assigned to devices with an embedded screen (i.e. touchscreens
>> and display tablets). The POINTER property is assigned to those
>> without embedded screens.
>>
>> Signed-off-by: Jason Gerecke <killertofu@gmail.com>
>> ---
>
> According to the discussion leading up to the properties interface
> (https://lkml.org/lkml/2010/12/15/263), a tablet is a direct pointer
> device, as opposed to a touchpad, which is an indirect pointer
> device. The distinction determines the direction of two-finger scroll,
> for instance. The question is then what behavior should be assigned to
> a large tablet without an embedded screen. It should have POINTER set
> for sure, but should it also have DIRECT set?

Here are all the possible combinations based on my understanding of
their intended usage.

  * Touch interface without screen should have POINTER only to
indicate pointer needed and to treat absolute coordinates as relative
movement.  Relative movement is product's default behavior as
documented in its own manual and what I think should be advertised by
default.
 * Pen interface without screen should have both POINTER and DIRECT to
indicate pointer needed and to treat absolute coordinates as absolute
movement.
 * Touch interfaces with screen should have DIRECT only to indicate no
pointer displayed and absolute coordinates as absolute movement.
 * Pen interface with screen should have DIRECT only to indicate no
pointer displayed and absolute coordinates as absolute movement.
* A Pen+Touch touchscreen (only the wacom_w8001.c), should have DIRECT
only to indicate no pointer displayed and absolute coordinates as
absolute movement.

Assuming we all agree on those combination, then in the patch the
Graphire and Intuos tablets are missing a DIRECT, the touchscreens are
correct, and the Bamboo's need to add DIRECT for the PEN interface
only.

Chris

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

[Ping Cheng]

On Tue, Sep 13, 2011 at 7:13 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> On Tue, Sep 13, 2011 at 3:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> Hi Jason,
>>
>>> Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
>>> hardware supported by the Wacom driver. The DIRECT property is
>>> assigned to devices with an embedded screen (i.e. touchscreens
>>> and display tablets). The POINTER property is assigned to those
>>> without embedded screens.
>>>
>>> Signed-off-by: Jason Gerecke <killertofu@gmail.com>
>>> ---
>>
>> According to the discussion leading up to the properties interface
>> (https://lkml.org/lkml/2010/12/15/263), a tablet is a direct pointer
>> device, as opposed to a touchpad, which is an indirect pointer
>> device. The distinction determines the direction of two-finger scroll,
>> for instance. The question is then what behavior should be assigned to
>> a large tablet without an embedded screen. It should have POINTER set
>> for sure, but should it also have DIRECT set?

We have discussed and debated the above before the patch was posted.

As Ikbel pointed out, a standalone tablet can be DIRECT or INDIRECT,
depending on how it is used. So, it is more a property that is decided
by the client than by the kernel driver.

> Here are all the possible combinations based on my understanding of
> their intended usage.
>
>  * Touch interface without screen should have POINTER only to
> indicate pointer needed and to treat absolute coordinates as relative
> movement.  Relative movement is product's default behavior as
> documented in its own manual and what I think should be advertised by
> default.
>  * Pen interface without screen should have both POINTER and DIRECT to
> indicate pointer needed and to treat absolute coordinates as absolute
> movement.

Reporting it as DIRECT indicates it can only be used as DIRECT. We
don't want client to make that assumption. User-land clients can
distinguish a touch POINTER from a pen POINTER by the tool types.

>  * Touch interfaces with screen should have DIRECT only to indicate no
> pointer displayed and absolute coordinates as absolute movement.
>  * Pen interface with screen should have DIRECT only to indicate no
> pointer displayed and absolute coordinates as absolute movement.
> * A Pen+Touch touchscreen (only the wacom_w8001.c), should have DIRECT
> only to indicate no pointer displayed and absolute coordinates as
> absolute movement.
>
> Assuming we all agree on those combination, then in the patch the
> Graphire and Intuos tablets are missing a DIRECT, the touchscreens are
> correct, and the Bamboo's need to add DIRECT for the PEN interface
> only.

I agree with all the other assumptions except this one.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Chris Bagwell]

On Tue, Sep 13, 2011 at 12:36 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> On Tue, Sep 13, 2011 at 7:13 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>> On Tue, Sep 13, 2011 at 3:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>>> Hi Jason,
>>>
>>>> Adds INPUT_PROP_POINTER or INPUT_PROP_DIRECT as necessary to the
>>>> hardware supported by the Wacom driver. The DIRECT property is
>>>> assigned to devices with an embedded screen (i.e. touchscreens
>>>> and display tablets). The POINTER property is assigned to those
>>>> without embedded screens.
>>>>
>>>> Signed-off-by: Jason Gerecke <killertofu@gmail.com>
>>>> ---
>>>
>>> According to the discussion leading up to the properties interface
>>> (https://lkml.org/lkml/2010/12/15/263), a tablet is a direct pointer
>>> device, as opposed to a touchpad, which is an indirect pointer
>>> device. The distinction determines the direction of two-finger scroll,
>>> for instance. The question is then what behavior should be assigned to
>>> a large tablet without an embedded screen. It should have POINTER set
>>> for sure, but should it also have DIRECT set?
>
> We have discussed and debated the above before the patch was posted.
>
> As Ikbel pointed out, a standalone tablet can be DIRECT or INDIRECT,
> depending on how it is used. So, it is more a property that is decided
> by the client than by the kernel driver.

I've a couple questions that would help me decide how things should be declared.

Can DIRECT be translated to mean treat coordinates as absolute
coordinates mapped to screen?  Or is it meant to be reserved only for
the more specific touchscreen-like application were the touch is laid
directly on top of the object being manipulated (or picture is
overlaid the touch for projector case)?

If some company shipped a touchpad+projector, would that ideally
declare DIRECT and not declare POINTER since user is directly touching
objects and the display of a pointer would serve no purpose?

What I'm getting at with the second question is if user pairs up a
touch tablet/touchpad with a projector then declaring even POINTER may
be just as wrong as not declaring DIRECT.

I don't think we can every get custom HW applications declared
correctly, so do we punish all cases and not declare anything?

>
>> Here are all the possible combinations based on my understanding of
>> their intended usage.
>>
>>  * Touch interface without screen should have POINTER only to
>> indicate pointer needed and to treat absolute coordinates as relative
>> movement.  Relative movement is product's default behavior as
>> documented in its own manual and what I think should be advertised by
>> default.
>>  * Pen interface without screen should have both POINTER and DIRECT to
>> indicate pointer needed and to treat absolute coordinates as absolute
>> movement.
>
> Reporting it as DIRECT indicates it can only be used as DIRECT. We
> don't want client to make that assumption. User-land clients can
> distinguish a touch POINTER from a pen POINTER by the tool types.

I see your logic now and patch does follow that logic.

I can actually buy into that although it seems to make the need for
both POINTER and DIRECT redundant. Touchscreen = DIRECT while Tablet
(pen, touch, or both) = POINTER.  No overlap.

If we do allow DIRECT on tablets then I do see now it becomes a
relaxed DIRECT since application will most likely still offer
switching pens to relative mode.

Chris

>
>>  * Touch interfaces with screen should have DIRECT only to indicate no
>> pointer displayed and absolute coordinates as absolute movement.
>>  * Pen interface with screen should have DIRECT only to indicate no
>> pointer displayed and absolute coordinates as absolute movement.
>> * A Pen+Touch touchscreen (only the wacom_w8001.c), should have DIRECT
>> only to indicate no pointer displayed and absolute coordinates as
>> absolute movement.
>>
>> Assuming we all agree on those combination, then in the patch the
>> Graphire and Intuos tablets are missing a DIRECT, the touchscreens are
>> correct, and the Bamboo's need to add DIRECT for the PEN interface
>> only.
>
> I agree with all the other assumptions except this one.
>
> Ping
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jeffrey Brown]

I disagree with this assignment somewhat because it creates ambiguities.

On Tue, Sep 13, 2011 at 7:13 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>  * Touch interface without screen should have POINTER only to
> indicate pointer needed and to treat absolute coordinates as relative
> movement.  Relative movement is product's default behavior as
> documented in its own manual and what I think should be advertised by
> default.

Yes.

>  * Pen interface without screen should have both POINTER and DIRECT to
> indicate pointer needed and to treat absolute coordinates as absolute
> movement.

No.  DIRECT should not be set because the Pen is not directly touching
the objects on a screen.  The motions must still be translated through
some indirect means (a mapping function) onto the plane of the screen.

Therefore should only specify POINTER.

>  * Touch interfaces with screen should have DIRECT only to indicate no
> pointer displayed and absolute coordinates as absolute movement.
>  * Pen interface with screen should have DIRECT only to indicate no
> pointer displayed and absolute coordinates as absolute movement.
> * A Pen+Touch touchscreen (only the wacom_w8001.c), should have DIRECT
> only to indicate no pointer displayed and absolute coordinates as
> absolute movement.

Yes, but not for this reason.  Touch interfaces with screen should
have DIRECT to indicate that touches are directly upon objects on the
screen.

It happens that the absolute coordinates of a tablet are usually
mapped 1-1 with the screen, but that's not what is meant by a direct
input device.  It's the usage that matters, not the mapping function
itself.

Note that a tablet's mapping function need not be precisely 1-1.  It
could be constrained to part of a window on the display, or it could
be rotated or skewed with respect to the display.  This is a
fundamental difference between direct and indirect input devices.  The
mapping function for a direct input devices must be a natural mapping
based on what is actually seen and directly touches.  The mapping
function for an indirect input device can be almost anything because a
pointer is being used to provide visual feedback so it is not
constrained by the physical position of objects on screen.

> Assuming we all agree on those combination, then in the patch the
> Graphire and Intuos tablets are missing a DIRECT, the touchscreens are
> correct, and the Bamboo's need to add DIRECT for the PEN interface
> only.

I disagree.

A touchscreen is DIRECT.
A tablet or trackpad is INDIRECT (and POINTER).

Further absolute/relative distinctions need to be made by tool.
Finger / mouse on tablet uses relative motion.  Pen uses absolute
motion.  Essentially the tool types qualify the mapping function used
by indirect devices.

This isn't a concern for direct devices because there's really only
one sensible mapping function to use... touch the thing under the
finger.  :)

Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Henrik Rydberg]

> >  * Pen interface without screen should have both POINTER and DIRECT to
> > indicate pointer needed and to treat absolute coordinates as absolute
> > movement.
> 
> No.  DIRECT should not be set because the Pen is not directly touching
> the objects on a screen.  The motions must still be translated through
> some indirect means (a mapping function) onto the plane of the screen.
> 
> Therefore should only specify POINTER.

This is wrong given the intended semantics. Regardless of if DIRECT
means "absolute coordinates" or "one-to-one with screen", the result
is the same.

> >  * Touch interfaces with screen should have DIRECT only to indicate no
> > pointer displayed and absolute coordinates as absolute movement.
> >  * Pen interface with screen should have DIRECT only to indicate no
> > pointer displayed and absolute coordinates as absolute movement.
> > * A Pen+Touch touchscreen (only the wacom_w8001.c), should have DIRECT
> > only to indicate no pointer displayed and absolute coordinates as
> > absolute movement.
> 
> Yes, but not for this reason.  Touch interfaces with screen should
> have DIRECT to indicate that touches are directly upon objects on the
> screen.

A one-to-one correspondence should suffice.

> It happens that the absolute coordinates of a tablet are usually
> mapped 1-1 with the screen, but that's not what is meant by a direct
> input device.  It's the usage that matters, not the mapping function
> itself.

Precisely - it is the usage that matters here.

> Note that a tablet's mapping function need not be precisely 1-1.  It
> could be constrained to part of a window on the display, or it could
> be rotated or skewed with respect to the display.  This is a
> fundamental difference between direct and indirect input devices.  The
> mapping function for a direct input devices must be a natural mapping
> based on what is actually seen and directly touches.  The mapping
> function for an indirect input device can be almost anything because a
> pointer is being used to provide visual feedback so it is not
> constrained by the physical position of objects on screen.

The fundamental difference between a touchscreen and the mapping you
describe here is POINTER, not DIRECT. There is no reason why a device
physically separated from the screen, and guided by one or several
markers, cannot behave the same way as a touchscreen.

> > Assuming we all agree on those combination, then in the patch the
> > Graphire and Intuos tablets are missing a DIRECT, the touchscreens are
> > correct, and the Bamboo's need to add DIRECT for the PEN interface
> > only.
> 
> I disagree.
> 
> A touchscreen is DIRECT.
> A tablet or trackpad is INDIRECT (and POINTER).

Based on your assmumptions on the semantics, you are of course
right. Given the actual intended semantics, this is wrong. It is as
far as we get.

> Further absolute/relative distinctions need to be made by tool.
> Finger / mouse on tablet uses relative motion.  Pen uses absolute
> motion.  Essentially the tool types qualify the mapping function used
> by indirect devices.

Aggred, the pen tablets we see today behave this way, and we do not
break anything by skipping the DIRECT property here.

Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Henrik Rydberg]

On Tue, Sep 13, 2011 at 10:18:28AM +0200, Mohamed Ikbel Boulabiar wrote:
> Hi,
> 
> On Tue, Sep 13, 2011 at 10:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> >
> > . The question is then what behavior should be assigned to
> > a large tablet without an embedded screen. It should have POINTER set
> > for sure, but should it also have DIRECT set?
> 
> Any large tablet without an embedded screen can be used in the 2 different ways:
> 1. The projection on top of it so it becomes a direct device.
> (this case is also used when you project 3d 120hz on top of multitouch
> devices: iMuts)
> 
> 2. Simple indirect device, even if it's large:
> http://10gui.com/video/

Two-finger scroll is actually used in a direct manner in that
video. (Which, btw, does display some fresh concepts. :-))

I think the bottom line is that even if the "directness" of a device
is configurable, it still needs to have a default. Moreover, the
notion of kernel mode settings could be applicable here too.

Henrik

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

[Ping Cheng]

On Wed, Sep 14, 2011 at 12:15 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> On Tue, Sep 13, 2011 at 10:18:28AM +0200, Mohamed Ikbel Boulabiar wrote:
>> Hi,
>>
>> On Tue, Sep 13, 2011 at 10:09 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> >
>> > . The question is then what behavior should be assigned to
>> > a large tablet without an embedded screen. It should have POINTER set
>> > for sure, but should it also have DIRECT set?
>>
>> Any large tablet without an embedded screen can be used in the 2 different ways:
>> 1. The projection on top of it so it becomes a direct device.
>> (this case is also used when you project 3d 120hz on top of multitouch
>> devices: iMuts)
>>
>> 2. Simple indirect device, even if it's large:
>> http://10gui.com/video/
>
> Two-finger scroll is actually used in a direct manner in that
> video. (Which, btw, does display some fresh concepts. :-))
>
> I think the bottom line is that even if the "directness" of a device
> is configurable, it still needs to have a default. Moreover, the
> notion of kernel mode settings could be applicable here too.

Talking about default mode, there are cases that the mode is decided
by the tools running on the device/tablet, instead of the tablet
itself.

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...).

Ping

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

[Henrik Rydberg]

> > I think the bottom line is that even if the "directness" of a device
> > is configurable, it still needs to have a default. Moreover, the
> > notion of kernel mode settings could be applicable here too.
> 
> Talking about default mode, there are cases that the mode is decided
> by the tools running on the device/tablet, instead of the tablet
> itself.
> 
> 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.

In short: I think Chris' comments are spot on, and incorporating them
into the patch would be good to avoid further confusion.

Thanks,
Henrik

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

[Jason Gerecke]

On Fri, Sep 16, 2011 at 3:50 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> > I think the bottom line is that even if the "directness" of a device
>> > is configurable, it still needs to have a default. Moreover, the
>> > notion of kernel mode settings could be applicable here too.
>>
>> Talking about default mode, there are cases that the mode is decided
>> by the tools running on the device/tablet, instead of the tablet
>> itself.
>>
>> 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.

To be honest, I'm not sure why we need to further disambiguate
touchpads and tablets (though I'd be interested in finding out). From
what I can tell, the difference between a touchpad and a tablet is in
the tools they use; identical tools (i.e. BTN_TOOL_FINGER) should have
identical absoluteness. The absoluteness of tool would depends on what
it is (BTN_TOOL_FINGER is relative, BTN_TOOL_PEN is absolute) and if
the underlying device is a direct input device (if it is, all tools
are absolute) -- not on some arbitrarily distinction between
"touchpad" and "tablet".

On Tue, Sep 13, 2011 at 1:54 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>> Reporting it as DIRECT indicates it can only be used as DIRECT. We
>> don't want client to make that assumption. User-land clients can
> > distinguish a touch POINTER from a pen POINTER by the tool types.
>
> I see your logic now and patch does follow that logic.
>
> I can actually buy into that although it seems to make the need for
> both POINTER and DIRECT redundant. Touchscreen = DIRECT while Tablet
> (pen, touch, or both) = POINTER.  No overlap.

I agree that this interpretation makes having both POINTER and DIRECT
set somewhat redundant. However, displaying a pointer for direct input
devices can be useful provided the tool does not obscure the pointer.
Devices which are designed for use with fine-tipped tools but suffer
from parallax error may wish to display the pointer by default to
improve usability.

Jason

---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.

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

[Henrik Rydberg]

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.

Now, people may have different opinions about the semantics as
presented above. Bike sheds tend to have that effect. Nevertheless,
this is how it was intended.

> To be honest, I'm not sure why we need to further disambiguate
> touchpads and tablets (though I'd be interested in finding out). From
> what I can tell, the difference between a touchpad and a tablet is in
> the tools they use; identical tools (i.e. BTN_TOOL_FINGER) should have
> identical absoluteness. The absoluteness of tool would depends on what
> it is (BTN_TOOL_FINGER is relative, BTN_TOOL_PEN is absolute) and if
> the underlying device is a direct input device (if it is, all tools
> are absolute) -- not on some arbitrarily distinction between
> "touchpad" and "tablet".

Your patch is already merged, and for pen devices, the distinction may
well be made as you describe. In other words, setting DIRECT for a pen
device is not strictly necessary. I wanted it in there to make clear
that in general, POINTER and DIRECT are not to be considered mutually
exclusive. Perhaps the discussion will continue when the first
"multi-touch tablet" appears, but hopefully not. ;-)

Cheers,
Henrik

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

[Chase Douglas]

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

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

[Jeffrey Brown]

On Mon, Sep 19, 2011 at 4:40 PM, Chase Douglas <chasedouglas@gmail.com> wrote:
> 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?

Agreed, but I feel we also need some clarity around the desired
interpretations of different tools in relation to direct / indirect
motion and these bits.

For example:

BTN_TOOL_FINGER / MT_FINGER:
- Positions are absolute is INPUT_PROP_DIRECT, or relative otherwise.
- Shows a pointer only if INPUT_PROP_POINTER is set.

(IMHO, relative motion should be preferred for touch pads that are not
physically coupled to a particular display.  Trackpad-like vs.
tablet-like behavior, especially if "hovering" is not supported or if
the touch pad is small.)

BTN_TOOL_PEN / BTN_TOOL_BRUSH / MT_PEN:
- Positions are always one-to-one with screen coordinates regardless
of INPUT_PROP_DIRECT.  If INPUT_PROP_DIRECT is set then we can take it
as a stronger indication of the pen being coupled to a particular
display (rather than spanning all displays or being bound to a
specific window, perhaps).
- Shows a pointer only if INPUT_PROP_POINTER is set.

BTN_TOOL_MOUSE / BTN_TOOL_LENS:
- Positions are always relative, regardless of INPUT_PROP_DIRECT.
- Shows a pointer, regardless of INPUT_PROP_POINTER.

We should also define heuristics for legacy devices that don't set
either INPUT_PROP_DIRECT or INPUT_PROP_POINTER.

Jeff.

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

[Chase Douglas]

On 09/19/2011 06:05 PM, Jeffrey Brown wrote:
> On Mon, Sep 19, 2011 at 4:40 PM, Chase Douglas <chasedouglas@gmail.com> wrote:
>> 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?
> 
> Agreed, but I feel we also need some clarity around the desired
> interpretations of different tools in relation to direct / indirect
> motion and these bits.
> 
> For example:
> 
> BTN_TOOL_FINGER / MT_FINGER:
> - Positions are absolute is INPUT_PROP_DIRECT, or relative otherwise.
> - Shows a pointer only if INPUT_PROP_POINTER is set.

This is actually my main grip with INPUT_PROP_POINTER. It really means
"the touchscreen and display are not integrated". A device may not have
INPUT_PROP_POINTER set (touchscreen and display are integrated), but may
still want to show the pointer (for example, you may want a cursor to
show when you are hovering). But, the name is set now.

I suppose my point in bringing this up is that the properties are
descriptions of the device, not specifications of what the evdev
consumer must do with the data. We can provide best-practices
guidelines, though, which is really what this list is.

> (IMHO, relative motion should be preferred for touch pads that are not
> physically coupled to a particular display.  Trackpad-like vs.
> tablet-like behavior, especially if "hovering" is not supported or if
> the touch pad is small.)
> 
> BTN_TOOL_PEN / BTN_TOOL_BRUSH / MT_PEN:
> - Positions are always one-to-one with screen coordinates regardless
> of INPUT_PROP_DIRECT.  If INPUT_PROP_DIRECT is set then we can take it
> as a stronger indication of the pen being coupled to a particular
> display (rather than spanning all displays or being bound to a
> specific window, perhaps).

Evdev doesn't know about displays, and it's well outside what it can do.
I don't think it helps to say that INPUT_PROP_DIRECT has extra meaning
in this case.

> - Shows a pointer only if INPUT_PROP_POINTER is set.
> 
> BTN_TOOL_MOUSE / BTN_TOOL_LENS:
> - Positions are always relative, regardless of INPUT_PROP_DIRECT.
> - Shows a pointer, regardless of INPUT_PROP_POINTER.

To condense all of the above, we can generalize the rules to:

* INPUT_PROP_DIRECT only has meaning for BTN_TOOL_FINGER etc.
* INPUT_PROP_POINTER only has meaning for BTN_TOOL_PEN / BTN_TOOL_BRUSH etc.

> We should also define heuristics for legacy devices that don't set
> either INPUT_PROP_DIRECT or INPUT_PROP_POINTER.

The above generalization should take care of this.

-- Chase

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

[Henrik Rydberg]

> To condense all of the above, we can generalize the rules to:
> 
> * INPUT_PROP_DIRECT only has meaning for BTN_TOOL_FINGER etc.
> * INPUT_PROP_POINTER only has meaning for BTN_TOOL_PEN / BTN_TOOL_BRUSH etc.
> 
> > We should also define heuristics for legacy devices that don't set
> > either INPUT_PROP_DIRECT or INPUT_PROP_POINTER.
> 
> The above generalization should take care of this.

Yes, I believe this will work nicely.

Thanks,
Henrik