[PATCH] Set buttonpad property on those bcm5974 devices that have a physical button.

[PATCH] Set buttonpad property on those bcm5974 devices that have a physical button.

[Jussi Pakkanen]

---
 drivers/input/mouse/bcm5974.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 5ec617e..df3fd85 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -876,6 +876,9 @@ static int bcm5974_probe(struct usb_interface *iface,
 
 	input_dev->name = "bcm5974";
 	input_dev->phys = dev->phys;
+	if (bcm5974_get_config(dev->udev)->caps & HAS_INTEGRATED_BUTTON) {
+		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
+	}
 	usb_to_input_id(dev->udev, &input_dev->id);
 	/* report driver capabilities via the version field */
 	input_dev->id.version = cfg->caps;
-- 
1.7.5.4

Re: [PATCH] Set buttonpad property on those bcm5974 devices that have a physical button.

[Henrik Rydberg]

Jussi,

On Tue, Jan 10, 2012 at 11:36:04AM +0200, Jussi Pakkanen wrote:
> ---
>  drivers/input/mouse/bcm5974.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
> index 5ec617e..df3fd85 100644
> --- a/drivers/input/mouse/bcm5974.c
> +++ b/drivers/input/mouse/bcm5974.c
> @@ -876,6 +876,9 @@ static int bcm5974_probe(struct usb_interface *iface,
>  
>  	input_dev->name = "bcm5974";
>  	input_dev->phys = dev->phys;
> +	if (bcm5974_get_config(dev->udev)->caps & HAS_INTEGRATED_BUTTON) {
> +		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
> +	}
>  	usb_to_input_id(dev->udev, &input_dev->id);
>  	/* report driver capabilities via the version field */
>  	input_dev->id.version = cfg->caps;
> -- 
> 1.7.5.4
> 

Besides being put in the wrong place, the already-defined local
variable is not used. Any particular reason for it? Otherwise, please
bundle the change with the rest in setup_events_to_report().

Thanks,
Henrik

[PATCH v2] Set buttonpad property on those bcm5974 devices that have a physical button.

[Jussi Pakkanen]

---
 drivers/input/mouse/bcm5974.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 5ec617e..88fabfb 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -434,6 +434,10 @@ static void setup_events_to_report(struct input_dev *input_dev,
 	__set_bit(BTN_LEFT, input_dev->keybit);
 
 	input_set_events_per_packet(input_dev, 60);
+
+	if (cfg->caps & HAS_INTEGRATED_BUTTON) {
+		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
+	}
 }
 
 /* report button data as logical button state */
-- 
1.7.5.4

Re: [PATCH v2] Set buttonpad property on those bcm5974 devices that have a physical button.

[Henrik Rydberg]

On Tue, Jan 10, 2012 at 12:08:30PM +0200, Jussi Pakkanen wrote:
> ---
>  drivers/input/mouse/bcm5974.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
> index 5ec617e..88fabfb 100644
> --- a/drivers/input/mouse/bcm5974.c
> +++ b/drivers/input/mouse/bcm5974.c
> @@ -434,6 +434,10 @@ static void setup_events_to_report(struct input_dev *input_dev,
>  	__set_bit(BTN_LEFT, input_dev->keybit);
>  
>  	input_set_events_per_packet(input_dev, 60);
> +
> +	if (cfg->caps & HAS_INTEGRATED_BUTTON) {
> +		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
> +	}
>  }
>  
>  /* report button data as logical button state */
> -- 
> 1.7.5.4
> 

Please move the lines above input_set_events_per_packet(), since that
function may depend on the device properties in the future. Also,
please remove the braces. The subject does not say why the change is
made, and you are also missing the signed-off-by line. Please run
checkpatch before submitting.

Henrik

[PATCH v3] bcm5974: Set BUTTONPAD property

[Jussi Pakkanen]

Some bcm5974 trackpads have a physical button beneath the physical surface.
This patch sets the property bit so user space applications can
detect the trackpad type and act accordingly.

Signed-off-by: Jussi Pakkanen <jussi.pakkanen@canonical.com>
Cc: stable@vger.kernel.org
---
 drivers/input/mouse/bcm5974.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 5ec617e..913e9fa 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -433,6 +433,9 @@ static void setup_events_to_report(struct input_dev *input_dev,
 	__set_bit(BTN_TOOL_QUADTAP, input_dev->keybit);
 	__set_bit(BTN_LEFT, input_dev->keybit);
 
+	if (cfg->caps & HAS_INTEGRATED_BUTTON)
+		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
+
 	input_set_events_per_packet(input_dev, 60);
 }
 
-- 
1.7.5.4

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Henrik Rydberg]

On Tue, Jan 10, 2012 at 12:56:49PM +0200, Jussi Pakkanen wrote:
> Some bcm5974 trackpads have a physical button beneath the physical surface.
> This patch sets the property bit so user space applications can
> detect the trackpad type and act accordingly.
> 
> Signed-off-by: Jussi Pakkanen <jussi.pakkanen@canonical.com>
> Cc: stable@vger.kernel.org
> ---
>  drivers/input/mouse/bcm5974.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
> index 5ec617e..913e9fa 100644
> --- a/drivers/input/mouse/bcm5974.c
> +++ b/drivers/input/mouse/bcm5974.c
> @@ -433,6 +433,9 @@ static void setup_events_to_report(struct input_dev *input_dev,
>  	__set_bit(BTN_TOOL_QUADTAP, input_dev->keybit);
>  	__set_bit(BTN_LEFT, input_dev->keybit);
>  
> +	if (cfg->caps & HAS_INTEGRATED_BUTTON)
> +		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
> +
>  	input_set_events_per_packet(input_dev, 60);
>  }
>  
> -- 
> 1.7.5.4
> 

    Reviewed-by: Henrik Rydberg <rydberg@euromail.se>

Thanks,
Henrik

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Tue, Jan 10, 2012 at 12:42:12PM +0100, Henrik Rydberg wrote:
> On Tue, Jan 10, 2012 at 12:56:49PM +0200, Jussi Pakkanen wrote:
> > Some bcm5974 trackpads have a physical button beneath the physical surface.
> > This patch sets the property bit so user space applications can
> > detect the trackpad type and act accordingly.
> > 
> > Signed-off-by: Jussi Pakkanen <jussi.pakkanen@canonical.com>
> > Cc: stable@vger.kernel.org

Applied, however I removed stable notation as this change IMO does not
qualify for the stable since it does not address a regression.

Thanks.

> > ---
> >  drivers/input/mouse/bcm5974.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
> > index 5ec617e..913e9fa 100644
> > --- a/drivers/input/mouse/bcm5974.c
> > +++ b/drivers/input/mouse/bcm5974.c
> > @@ -433,6 +433,9 @@ static void setup_events_to_report(struct input_dev *input_dev,
> >  	__set_bit(BTN_TOOL_QUADTAP, input_dev->keybit);
> >  	__set_bit(BTN_LEFT, input_dev->keybit);
> >  
> > +	if (cfg->caps & HAS_INTEGRATED_BUTTON)
> > +		__set_bit(INPUT_PROP_BUTTONPAD, input_dev->propbit);
> > +
> >  	input_set_events_per_packet(input_dev, 60);
> >  }
> >  
> > -- 
> > 1.7.5.4
> > 
> 
>     Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
> 
> Thanks,
> Henrik

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/11/2012 08:38 AM, Dmitry Torokhov wrote:
> On Tue, Jan 10, 2012 at 12:42:12PM +0100, Henrik Rydberg wrote:
>> On Tue, Jan 10, 2012 at 12:56:49PM +0200, Jussi Pakkanen wrote:
>>> Some bcm5974 trackpads have a physical button beneath the physical surface.
>>> This patch sets the property bit so user space applications can
>>> detect the trackpad type and act accordingly.
>>>
>>> Signed-off-by: Jussi Pakkanen <jussi.pakkanen@canonical.com>
>>> Cc: stable@vger.kernel.org
> 
> Applied, however I removed stable notation as this change IMO does not
> qualify for the stable since it does not address a regression.

It's not a regression per-se, but we want to fix buttonpad support, and
we can't do that without this patch. It's a clear bug that when the
property was added we did not set the property in the devices that need it.

I believe this is exactly what the stable queue is for. Are you saying
you will still NACK this patch if we submit it to the stable queue?
Otherwise, we'll have to distro-patch it for our next Ubuntu release.

I wish you had asked about this before committing it to your tree
without the stable Cc. If we convince you that it makes sense for
stable, we now have quite a bit more work to do to get it into stable...

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Henrik Rydberg]

> > Applied, however I removed stable notation as this change IMO does not
> > qualify for the stable since it does not address a regression.
> 
> It's not a regression per-se, but we want to fix buttonpad support, and
> we can't do that without this patch. It's a clear bug that when the
> property was added we did not set the property in the devices that need it.

The current behavior depends on userspace and is not a kernel bug,
please stop the nonsense already.

For bcm5974 devices, extracting buttonpad properties has been possible
since early 2009 (158e9287). The mechanism, predating the input
properties interface by nearly two years, has been used in the
multitouch and mtrack X drivers ever since. To those users, the
present patch has no effect at all.

Henrik

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
>>> Applied, however I removed stable notation as this change IMO does not
>>> qualify for the stable since it does not address a regression.
>>
>> It's not a regression per-se, but we want to fix buttonpad support, and
>> we can't do that without this patch. It's a clear bug that when the
>> property was added we did not set the property in the devices that need it.
> 
> The current behavior depends on userspace and is not a kernel bug,
> please stop the nonsense already.
> 
> For bcm5974 devices, extracting buttonpad properties has been possible
> since early 2009 (158e9287). The mechanism, predating the input
> properties interface by nearly two years, has been used in the
> multitouch and mtrack X drivers ever since. To those users, the
> present patch has no effect at all.

Just because an alternative interface has existed does not mean there
isn't a bug. A device that has a physical property, but does not set the
property bit in the driver is a real bug that needs to be fixed.
Userspace should not have to quirk around broken implementations.

It's true that userspace can quirk around things in a kernel that
predates the property bits, but where the property bits are available
the devices *must* set them or else things will break.

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Wed, Jan 11, 2012 at 11:09:18AM +0100, Chase Douglas wrote:
> On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
> >>> Applied, however I removed stable notation as this change IMO does not
> >>> qualify for the stable since it does not address a regression.
> >>
> >> It's not a regression per-se, but we want to fix buttonpad support, and
> >> we can't do that without this patch. It's a clear bug that when the
> >> property was added we did not set the property in the devices that need it.
> > 
> > The current behavior depends on userspace and is not a kernel bug,
> > please stop the nonsense already.
> > 
> > For bcm5974 devices, extracting buttonpad properties has been possible
> > since early 2009 (158e9287). The mechanism, predating the input
> > properties interface by nearly two years, has been used in the
> > multitouch and mtrack X drivers ever since. To those users, the
> > present patch has no effect at all.
> 
> Just because an alternative interface has existed does not mean there
> isn't a bug. 

No, there isn't a bug. The driver simply does not support new interface
yet. In all our discussions, AFAIR, property bits were always supposed
to carry only advisory role, i.e. if a driver sets them up then
userspace has it easy and can act upon them. Absence of a property does
not guarantee anything.

Hmm, speaking of properties, shouldn't we set INPUT_PROP_POINTER on
bcm5974 while we are at it?

> A device that has a physical property, but does not set the
> property bit in the driver is a real bug that needs to be fixed.
> Userspace should not have to quirk around broken implementations.
> 
> It's true that userspace can quirk around things in a kernel that
> predates the property bits, but where the property bits are available
> the devices *must* set them or else things will break.

If you are already supporting older kernels that do not support property
bits then you should already be set.

Anyway, this is not a regression and not even new hardware enablement:

" - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short,
   something critical.
 - New device IDs and quirks are also accepted."

Therefore I do not feel that stable nomination is warranted. You may
still send it to stable, I'll add similar comment to that request and
leave it up to Greg to decide if he still wants to put it into stable.

Thanks.

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/11/2012 06:18 PM, Dmitry Torokhov wrote:
> On Wed, Jan 11, 2012 at 11:09:18AM +0100, Chase Douglas wrote:
>> On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
>>>>> Applied, however I removed stable notation as this change IMO does not
>>>>> qualify for the stable since it does not address a regression.
>>>>
>>>> It's not a regression per-se, but we want to fix buttonpad support, and
>>>> we can't do that without this patch. It's a clear bug that when the
>>>> property was added we did not set the property in the devices that need it.
>>>
>>> The current behavior depends on userspace and is not a kernel bug,
>>> please stop the nonsense already.
>>>
>>> For bcm5974 devices, extracting buttonpad properties has been possible
>>> since early 2009 (158e9287). The mechanism, predating the input
>>> properties interface by nearly two years, has been used in the
>>> multitouch and mtrack X drivers ever since. To those users, the
>>> present patch has no effect at all.
>>
>> Just because an alternative interface has existed does not mean there
>> isn't a bug. 
> 
> No, there isn't a bug. The driver simply does not support new interface
> yet. In all our discussions, AFAIR, property bits were always supposed
> to carry only advisory role, i.e. if a driver sets them up then
> userspace has it easy and can act upon them. Absence of a property does
> not guarantee anything.

The problem is that we can't determine "absence" from "false". If
EVIOCGPROP returned an error when the driver did not support property
bits, then that would be different. However, if a driver does not set
property bits it appears to userspace as though all properties are false.

Henrik's proposal of using the bcm5974-specific driver capabilities
interface would require code like:

Get props
if (props == 0) {
  try bcm5974-specific interface
  try ...-specific interface
  try ...-specific interface
}

This is not a reasonable solution for userspace. If you're going to
argue that we need a thread-safe ioctl to get the current touch slot
state, you can't honestly ask userspace to do this :).

Because we can't determine "absence" separate from "falseness", the
interface can't really be "advisory", which I don't remember being the
case anyways. To illustrate the point, proper click and drag support in
X will require knowing whether a trackpad is a buttonpad. It may be
required for multitouch support (we're still working out the details for
trackpads). We will be filing more patches to add buttonpad properties
to hid-magicmouse, synaptics, and maybe more.

Any distro that will ship a new X.org with multitouch support and a
kernel that is 3.2 or earlier will require these patches to function
properly. Think of all the android devices out there with older kernels.
People may want to flash distros with latest X.org on top of android
kernels. Locked bootloaders means we can't be sure we can replace the
kernel, even when we actually get the sources :).

> Hmm, speaking of properties, shouldn't we set INPUT_PROP_POINTER on
> bcm5974 while we are at it?

I'm still confused on what INPUT_PROP_POINTER means, and how it is
different from INPUT_PROP_DIRECT. I *think* we all agree on what
INPUT_PROP_DIRECT means, but I don't want to set INPUT_PROP_POINTER on
any devices before we have a clear definition.

Henrik, can you comment on the documentation patches? You wrote the
patch, so you hopefully know what's going on :).

>> A device that has a physical property, but does not set the
>> property bit in the driver is a real bug that needs to be fixed.
>> Userspace should not have to quirk around broken implementations.
>>
>> It's true that userspace can quirk around things in a kernel that
>> predates the property bits, but where the property bits are available
>> the devices *must* set them or else things will break.
> 
> If you are already supporting older kernels that do not support property
> bits then you should already be set.
>
> Anyway, this is not a regression and not even new hardware enablement:
> 
> " - It must fix a problem that causes a build error (but not for things
>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>    security issue, or some "oh, that's not good" issue.  In short,
>    something critical.
>  - New device IDs and quirks are also accepted."
> 
> Therefore I do not feel that stable nomination is warranted. You may
> still send it to stable, I'll add similar comment to that request and
> leave it up to Greg to decide if he still wants to put it into stable.

It doesn't fit exactly any of the categories, but stable isn't really
cut-and-dry. What do you think should happen if a patch is not
"critical" according to the above definitions, but would nonetheless be
required by many distros because without it things would not work
properly. Should every distro apply the patch individually, after
hitting bugs and spending valuable developer time tracking down the fix,
or should the patch be sent through the stable queue so everyone can
benefit?

Obviously, I think it makes sense to send a safe patch like this through
the stable queue so everyone benefits (and I still believe this is a
"bug fix" due to the inability to determine "absence" of a property). If
you disagree, we can easily distro-patch this and every other patch we
send for property bits.

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Wed, Jan 11, 2012 at 10:36:16PM +0100, Chase Douglas wrote:
> On 01/11/2012 06:18 PM, Dmitry Torokhov wrote:
> > On Wed, Jan 11, 2012 at 11:09:18AM +0100, Chase Douglas wrote:
> >> On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
> >>>>> Applied, however I removed stable notation as this change IMO does not
> >>>>> qualify for the stable since it does not address a regression.
> >>>>
> >>>> It's not a regression per-se, but we want to fix buttonpad support, and
> >>>> we can't do that without this patch. It's a clear bug that when the
> >>>> property was added we did not set the property in the devices that need it.
> >>>
> >>> The current behavior depends on userspace and is not a kernel bug,
> >>> please stop the nonsense already.
> >>>
> >>> For bcm5974 devices, extracting buttonpad properties has been possible
> >>> since early 2009 (158e9287). The mechanism, predating the input
> >>> properties interface by nearly two years, has been used in the
> >>> multitouch and mtrack X drivers ever since. To those users, the
> >>> present patch has no effect at all.
> >>
> >> Just because an alternative interface has existed does not mean there
> >> isn't a bug. 
> > 
> > No, there isn't a bug. The driver simply does not support new interface
> > yet. In all our discussions, AFAIR, property bits were always supposed
> > to carry only advisory role, i.e. if a driver sets them up then
> > userspace has it easy and can act upon them. Absence of a property does
> > not guarantee anything.
> 
> The problem is that we can't determine "absence" from "false". If
> EVIOCGPROP returned an error when the driver did not support property
> bits, then that would be different. However, if a driver does not set
> property bits it appears to userspace as though all properties are false.

Here is what I said earlier when we discussed Henrik's patch:

'As long as we document that !pointer && !direct means "unknown" or
"unspecified" so as to avoid having to update all devices at once that
should be OK.'

The same is applicable to other properties as well. If device is telling
you that it is a "buttonpad" you can trust it, but if it does not you
need to decide for yourself how to treat it.

> 
> Henrik's proposal of using the bcm5974-specific driver capabilities
> interface would require code like:
> 
> Get props
> if (props == 0) {
>   try bcm5974-specific interface
>   try ...-specific interface
>   try ...-specific interface
> }

Right, except that there are no more "xxx-specific" interfaces, only bcm
one.

> 
> This is not a reasonable solution for userspace. If you're going to
> argue that we need a thread-safe ioctl to get the current touch slot
> state, you can't honestly ask userspace to do this :).

Yes, I honestly can.

> 
> Because we can't determine "absence" separate from "falseness", the
> interface can't really be "advisory", which I don't remember being the
> case anyways. To illustrate the point, proper click and drag support in
> X will require knowing whether a trackpad is a buttonpad. It may be
> required for multitouch support (we're still working out the details for
> trackpads). We will be filing more patches to add buttonpad properties
> to hid-magicmouse, synaptics, and maybe more.
> 
> Any distro that will ship a new X.org with multitouch support and a
> kernel that is 3.2 or earlier will require these patches to function
> properly.

So are you trying to make an argument that we need to backport this
patch all the way to 2.6.30? Along with the EVIOCGPROP itself since it
was only added to 2.6.38 and therefore your new userspace would fail
miserably on kernels earlier than .38?

> Think of all the android devices out there with older kernels.
> People may want to flash distros with latest X.org on top of android
> kernels. Locked bootloaders means we can't be sure we can replace the
> kernel, even when we actually get the sources :).

Exactly, so here you give the perfect argument why the patch is not
needed for stable. Design your userspace as if kernel isn't upgradable.

> 
> > Hmm, speaking of properties, shouldn't we set INPUT_PROP_POINTER on
> > bcm5974 while we are at it?
> 
> I'm still confused on what INPUT_PROP_POINTER means, and how it is
> different from INPUT_PROP_DIRECT. I *think* we all agree on what
> INPUT_PROP_DIRECT means, but I don't want to set INPUT_PROP_POINTER on
> any devices before we have a clear definition.

I'll make it a bit easier - synaptics is already marked as pointer
device (which it is), so making other touchpads report
INPUT_PROP_POINTER makes things not only right but consistent.

> 
> Henrik, can you comment on the documentation patches? You wrote the
> patch, so you hopefully know what's going on :).
> 
> >> A device that has a physical property, but does not set the
> >> property bit in the driver is a real bug that needs to be fixed.
> >> Userspace should not have to quirk around broken implementations.
> >>
> >> It's true that userspace can quirk around things in a kernel that
> >> predates the property bits, but where the property bits are available
> >> the devices *must* set them or else things will break.
> > 
> > If you are already supporting older kernels that do not support property
> > bits then you should already be set.
> >
> > Anyway, this is not a regression and not even new hardware enablement:
> > 
> > " - It must fix a problem that causes a build error (but not for things
> >    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> >    security issue, or some "oh, that's not good" issue.  In short,
> >    something critical.
> >  - New device IDs and quirks are also accepted."
> > 
> > Therefore I do not feel that stable nomination is warranted. You may
> > still send it to stable, I'll add similar comment to that request and
> > leave it up to Greg to decide if he still wants to put it into stable.
> 
> It doesn't fit exactly any of the categories, but stable isn't really
> cut-and-dry. What do you think should happen if a patch is not
> "critical" according to the above definitions, but would nonetheless be
> required by many distros because without it things would not work
> properly. Should every distro apply the patch individually, after
> hitting bugs and spending valuable developer time tracking down the fix,
> or should the patch be sent through the stable queue so everyone can
> benefit?
> 
> Obviously, I think it makes sense to send a safe patch like this through
> the stable queue so everyone benefits (and I still believe this is a
> "bug fix" due to the inability to determine "absence" of a property). If
> you disagree, we can easily distro-patch this and every other patch we
> send for property bits.

You are doing a disservice to your users by producing userspace that
makes EVIOCGPROP mandatory (disservice because they can not easily
downgrade the kernel) but it is your choice.

Thanks.

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/11/2012 10:59 PM, Dmitry Torokhov wrote:
> On Wed, Jan 11, 2012 at 10:36:16PM +0100, Chase Douglas wrote:
>> On 01/11/2012 06:18 PM, Dmitry Torokhov wrote:
>>> On Wed, Jan 11, 2012 at 11:09:18AM +0100, Chase Douglas wrote:
>>>> On 01/11/2012 11:04 AM, Henrik Rydberg wrote:
>>>>>>> Applied, however I removed stable notation as this change IMO does not
>>>>>>> qualify for the stable since it does not address a regression.
>>>>>>
>>>>>> It's not a regression per-se, but we want to fix buttonpad support, and
>>>>>> we can't do that without this patch. It's a clear bug that when the
>>>>>> property was added we did not set the property in the devices that need it.
>>>>>
>>>>> The current behavior depends on userspace and is not a kernel bug,
>>>>> please stop the nonsense already.
>>>>>
>>>>> For bcm5974 devices, extracting buttonpad properties has been possible
>>>>> since early 2009 (158e9287). The mechanism, predating the input
>>>>> properties interface by nearly two years, has been used in the
>>>>> multitouch and mtrack X drivers ever since. To those users, the
>>>>> present patch has no effect at all.
>>>>
>>>> Just because an alternative interface has existed does not mean there
>>>> isn't a bug. 
>>>
>>> No, there isn't a bug. The driver simply does not support new interface
>>> yet. In all our discussions, AFAIR, property bits were always supposed
>>> to carry only advisory role, i.e. if a driver sets them up then
>>> userspace has it easy and can act upon them. Absence of a property does
>>> not guarantee anything.
>>
>> The problem is that we can't determine "absence" from "false". If
>> EVIOCGPROP returned an error when the driver did not support property
>> bits, then that would be different. However, if a driver does not set
>> property bits it appears to userspace as though all properties are false.
> 
> Here is what I said earlier when we discussed Henrik's patch:
> 
> 'As long as we document that !pointer && !direct means "unknown" or
> "unspecified" so as to avoid having to update all devices at once that
> should be OK.'

Ok, where's the documentation?

However, conflation of meanings is a bad thing. I've written multiple
implementations of MT evdev clients, and having tracking ID conflated
with touch slot begin/end is a pain and ends up with code that doesn't
make sense without commenting it to explain yourself. This would require
the same thing.

AFAIK, pointer is not equal to the inverse of direct. Pointer means
"Needs a pointer". This applies to drawing tablets, but it does not
apply to touchscreens, where you do not need a pointer because the input
device is physically the same as the display. Both are direct devices,
however.

Here's what I believe the meanings should be:

Touchpad: pointer, !direct
Touchscreen: !pointer, direct
Drawing tablet: pointer, direct
Magic mouse-like devices: !pointer, !direct

However, there is a further problem in that we can't easily support
multiple tools with different behavior on the same evdev device. What
would you say a bamboo touch+pen is, which I believe is used as an
indirect device for touch but a direct device for tools. Thus, in the
thread I linked from back in September, Henrik and I agreed that direct
should only apply when the tool is touch, and pointer should apply for
all other tools. This would result in the following:

Touchpad: !pointer, !direct
Touchscreen: !pointer, direct
Drawing tablet (no touch): pointer, !direct
Pen+touch tablet: pointer, direct
Magic mouse-like devices: !pointer, !direct

The properties weren't documented when they were merged, and they
obviously aren't clear. However, if either table above is correct, then
we can't assume that !pointer && !direct means "unknown".

There is a way to fix this in a backwards compatible way: add a new
property bit called something like "PROPERTIES_AVAILABLE". If any bits
are set, then it implies that the properties are available (which covers
older kernels). If no bits are set, then the properties are unknown.
What do you think?

> The same is applicable to other properties as well. If device is telling
> you that it is a "buttonpad" you can trust it, but if it does not you
> need to decide for yourself how to treat it.
> 
>>
>> Henrik's proposal of using the bcm5974-specific driver capabilities
>> interface would require code like:
>>
>> Get props
>> if (props == 0) {
>>   try bcm5974-specific interface
>>   try ...-specific interface
>>   try ...-specific interface
>> }
> 
> Right, except that there are no more "xxx-specific" interfaces, only bcm
> one.

I didn't know whether that was the case. I couldn't know that was the
case without auditing the code of all the drivers (or having the input
maintainer telling me :).

>> Because we can't determine "absence" separate from "falseness", the
>> interface can't really be "advisory", which I don't remember being the
>> case anyways. To illustrate the point, proper click and drag support in
>> X will require knowing whether a trackpad is a buttonpad. It may be
>> required for multitouch support (we're still working out the details for
>> trackpads). We will be filing more patches to add buttonpad properties
>> to hid-magicmouse, synaptics, and maybe more.
>>
>> Any distro that will ship a new X.org with multitouch support and a
>> kernel that is 3.2 or earlier will require these patches to function
>> properly.
> 
> So are you trying to make an argument that we need to backport this
> patch all the way to 2.6.30? Along with the EVIOCGPROP itself since it
> was only added to 2.6.38 and therefore your new userspace would fail
> miserably on kernels earlier than .38?

No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
that I believe there was no way to determine unknown properties. If
unknown properties is equivalent to magic-mouse like devices, then we're
going to treat a lot of devices wrong. Or, we have to use heuristics to
determine what a device is, like no properties and MT and REL_{X,Y} ==
magic-mouse like. Properties was supposed to resolve this once and for
all, so we didn't need heuristics.

>> Think of all the android devices out there with older kernels.
>> People may want to flash distros with latest X.org on top of android
>> kernels. Locked bootloaders means we can't be sure we can replace the
>> kernel, even when we actually get the sources :).
> 
> Exactly, so here you give the perfect argument why the patch is not
> needed for stable. Design your userspace as if kernel isn't upgradable.

If you can't tell "unknown, might be type A" from "type B", then we've
got a problem no matter what.

>>> Hmm, speaking of properties, shouldn't we set INPUT_PROP_POINTER on
>>> bcm5974 while we are at it?
>>
>> I'm still confused on what INPUT_PROP_POINTER means, and how it is
>> different from INPUT_PROP_DIRECT. I *think* we all agree on what
>> INPUT_PROP_DIRECT means, but I don't want to set INPUT_PROP_POINTER on
>> any devices before we have a clear definition.
> 
> I'll make it a bit easier - synaptics is already marked as pointer
> device (which it is), so making other touchpads report
> INPUT_PROP_POINTER makes things not only right but consistent.

Document it first, please.

>> Henrik, can you comment on the documentation patches? You wrote the
>> patch, so you hopefully know what's going on :).
>>
>>>> A device that has a physical property, but does not set the
>>>> property bit in the driver is a real bug that needs to be fixed.
>>>> Userspace should not have to quirk around broken implementations.
>>>>
>>>> It's true that userspace can quirk around things in a kernel that
>>>> predates the property bits, but where the property bits are available
>>>> the devices *must* set them or else things will break.
>>>
>>> If you are already supporting older kernels that do not support property
>>> bits then you should already be set.
>>>
>>> Anyway, this is not a regression and not even new hardware enablement:
>>>
>>> " - It must fix a problem that causes a build error (but not for things
>>>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>>>    security issue, or some "oh, that's not good" issue.  In short,
>>>    something critical.
>>>  - New device IDs and quirks are also accepted."
>>>
>>> Therefore I do not feel that stable nomination is warranted. You may
>>> still send it to stable, I'll add similar comment to that request and
>>> leave it up to Greg to decide if he still wants to put it into stable.
>>
>> It doesn't fit exactly any of the categories, but stable isn't really
>> cut-and-dry. What do you think should happen if a patch is not
>> "critical" according to the above definitions, but would nonetheless be
>> required by many distros because without it things would not work
>> properly. Should every distro apply the patch individually, after
>> hitting bugs and spending valuable developer time tracking down the fix,
>> or should the patch be sent through the stable queue so everyone can
>> benefit?
>>
>> Obviously, I think it makes sense to send a safe patch like this through
>> the stable queue so everyone benefits (and I still believe this is a
>> "bug fix" due to the inability to determine "absence" of a property). If
>> you disagree, we can easily distro-patch this and every other patch we
>> send for property bits.
> 
> You are doing a disservice to your users by producing userspace that
> makes EVIOCGPROP mandatory (disservice because they can not easily
> downgrade the kernel) but it is your choice.

I certainly don't want to do that, but I don't see how we can with the
current interface. Maybe if we get stuff documented it will be clear.

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Henrik Rydberg]

> Here's what I believe the meanings should be:
> 
> Touchpad: pointer, !direct
> Touchscreen: !pointer, direct
> Drawing tablet: pointer, direct
> Magic mouse-like devices: !pointer, !direct

Yes, this is what everyone is saying, except !pointer && !direct means
"default" or "figure it out some other way".

> However, there is a further problem in that we can't easily support
> multiple tools with different behavior on the same evdev device. What
> would you say a bamboo touch+pen is, which I believe is used as an
> indirect device for touch but a direct device for tools. Thus, in the
> thread I linked from back in September, Henrik and I agreed that direct
> should only apply when the tool is touch, and pointer should apply for
> all other tools. This would result in the following:

To try to move back to a sane track, try this, where the word "apply"
in the previous paragraph has been changed to "care" instead:

> Touchpad: !pointer, !direct

pointer && !direct, since pointer is "dont care".

> Touchscreen: !pointer, direct

Yes, !pointer && direct.

> Drawing tablet (no touch): pointer, !direct

pointer && direct, but the tool is not touch, so direct is "dont care".

> Pen+touch tablet: pointer, direct

Yes, pointer && direct

> Magic mouse-like devices: !pointer, !direct

Both pointer and direct are "dont care", and the device needs to be
detected some other way. If there ever will be a special driver for
magic-mouse-like devices, using both relative pointer and touch data,
it will make sense to add a special property for such devices.

Hopefully the above is showing clearly that what was "documented" in
the threads enclosing the protocol patches still holds, and that there
is no use to dwell on it further.

> The properties weren't documented when they were merged, and they
> obviously aren't clear. However, if either table above is correct, then
> we can't assume that !pointer && !direct means "unknown".

If all devices fell in the pointer or direct or both categories, we
could. If not all devices do, the problem is rather that some property
bits are missing (or excluded) from the description.

> There is a way to fix this in a backwards compatible way: add a new
> property bit called something like "PROPERTIES_AVAILABLE". If any bits
> are set, then it implies that the properties are available (which covers
> older kernels). If no bits are set, then the properties are unknown.
> What do you think?

It is rather the special properties of the magic mouse that are
missing. All types of devices do not _have_ to use properties; most
types can be figured out by other means.

Saying "prop == 0" is equivalent to "figure out some other way" makes
sense, but it is also sensible to say "(prop & some_subclass_of_bits)
== 0", since some properties are bound to describe totally different
things. This is what we did with "!direct && !pointer".

> > The same is applicable to other properties as well. If device is telling
> > you that it is a "buttonpad" you can trust it, but if it does not you
> > need to decide for yourself how to treat it.

Yes, and this will always be true. Old devices or systems that become
used in new ways cannot always adapt to a "if property not present
then dont use that way" policy.

> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
> that I believe there was no way to determine unknown properties. If
> unknown properties is equivalent to magic-mouse like devices, then we're
> going to treat a lot of devices wrong. Or, we have to use heuristics to
> determine what a device is, like no properties and MT and REL_{X,Y} ==
> magic-mouse like. Properties was supposed to resolve this once and for
> all, so we didn't need heuristics.

Properties were added to be able to distinguish usecases that could
not be distinguished at all before. It was never meant to replace
everything else.

> >> Henrik, can you comment on the documentation patches? You wrote the
> >> patch, so you hopefully know what's going on :).

I wasn't copied in on the conversation, but they seem fairly well
commented on already.

Henrik

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>> Here's what I believe the meanings should be:
>>
>> Touchpad: pointer, !direct
>> Touchscreen: !pointer, direct
>> Drawing tablet: pointer, direct
>> Magic mouse-like devices: !pointer, !direct
> 
> Yes, this is what everyone is saying, except !pointer && !direct means
> "default" or "figure it out some other way".
> 
>> However, there is a further problem in that we can't easily support
>> multiple tools with different behavior on the same evdev device. What
>> would you say a bamboo touch+pen is, which I believe is used as an
>> indirect device for touch but a direct device for tools. Thus, in the
>> thread I linked from back in September, Henrik and I agreed that direct
>> should only apply when the tool is touch, and pointer should apply for
>> all other tools. This would result in the following:
> 
> To try to move back to a sane track, try this, where the word "apply"
> in the previous paragraph has been changed to "care" instead:

I am still having trouble understanding what you are saying. If I
literally try to insert "care" into the paragraph, I am confused because
it's not quite correct grammar. I'm really trying to understand though.
Also, maybe a better term than "don't care" is "not applicable"?

It would help me most if you could explicitly provide your own
definition of the properties.

>> Touchpad: !pointer, !direct
> 
> pointer && !direct, since pointer is "dont care".

Here you say !direct if "don't care".

>> Touchscreen: !pointer, direct
> 
> Yes, !pointer && direct.
> 
>> Drawing tablet (no touch): pointer, !direct
> 
> pointer && direct, but the tool is not touch, so direct is "dont care".

Here you say direct if "don't care".

Why the difference?

>> Pen+touch tablet: pointer, direct
> 
> Yes, pointer && direct
> 
>> Magic mouse-like devices: !pointer, !direct
> 
> Both pointer and direct are "dont care", and the device needs to be
> detected some other way. If there ever will be a special driver for
> magic-mouse-like devices, using both relative pointer and touch data,
> it will make sense to add a special property for such devices.

Right now we are missing a property for a magic-mouse like device. It's
valid to have neither direct nor pointer set from kernels 2.6.38 through
3.2 (at least).

> Hopefully the above is showing clearly that what was "documented" in
> the threads enclosing the protocol patches still holds, and that there
> is no use to dwell on it further.
> 
>> The properties weren't documented when they were merged, and they
>> obviously aren't clear. However, if either table above is correct, then
>> we can't assume that !pointer && !direct means "unknown".
> 
> If all devices fell in the pointer or direct or both categories, we
> could. If not all devices do, the problem is rather that some property
> bits are missing (or excluded) from the description.

Given my last statement above, we have a problem because previously
released kernels are reporting the magic mouse correctly, and yet we
still can't distinguish it from another device that merely does not have
the property bits set. This is the crux of the issue as I see it. We
cannot differentiate between "unknown" and a specific type of device
given the interfaces from 2.6.38 through 3.2.

>> There is a way to fix this in a backwards compatible way: add a new
>> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>> are set, then it implies that the properties are available (which covers
>> older kernels). If no bits are set, then the properties are unknown.
>> What do you think?
> 
> It is rather the special properties of the magic mouse that are
> missing. All types of devices do not _have_ to use properties; most
> types can be figured out by other means.
> 
> Saying "prop == 0" is equivalent to "figure out some other way" makes
> sense, but it is also sensible to say "(prop & some_subclass_of_bits)
> == 0", since some properties are bound to describe totally different
> things. This is what we did with "!direct && !pointer".

This may work, but we need to document the classes. The next time any
properties are added the documentation must be included :).

>>> The same is applicable to other properties as well. If device is telling
>>> you that it is a "buttonpad" you can trust it, but if it does not you
>>> need to decide for yourself how to treat it.
> 
> Yes, and this will always be true. Old devices or systems that become
> used in new ways cannot always adapt to a "if property not present
> then dont use that way" policy.
> 
>> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>> that I believe there was no way to determine unknown properties. If
>> unknown properties is equivalent to magic-mouse like devices, then we're
>> going to treat a lot of devices wrong. Or, we have to use heuristics to
>> determine what a device is, like no properties and MT and REL_{X,Y} ==
>> magic-mouse like. Properties was supposed to resolve this once and for
>> all, so we didn't need heuristics.
> 
> Properties were added to be able to distinguish usecases that could
> not be distinguished at all before. It was never meant to replace
> everything else.

Why shouldn't we use it for that? The code in evdev for determining the
type of device is just a big hack. We'll obviously need it for a while
since we don't have all drivers with all necessary properties set, but
it seems a waste to have the interface and not fully use it.

>>>> Henrik, can you comment on the documentation patches? You wrote the
>>>> patch, so you hopefully know what's going on :).
> 
> I wasn't copied in on the conversation, but they seem fairly well
> commented on already.

It's still not clear to me what the definitions are. It seems it won't
be clear until either you or Dmitry give your own definitions in an
explicit manner (something that could be copied into the formal
documentation). Please help me out :).

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/12/2012 11:19 AM, Chase Douglas wrote:
> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>>> Here's what I believe the meanings should be:
>>>
>>> Touchpad: pointer, !direct
>>> Touchscreen: !pointer, direct
>>> Drawing tablet: pointer, direct
>>> Magic mouse-like devices: !pointer, !direct
>>
>> Yes, this is what everyone is saying, except !pointer && !direct means
>> "default" or "figure it out some other way".
>>
>>> However, there is a further problem in that we can't easily support
>>> multiple tools with different behavior on the same evdev device. What
>>> would you say a bamboo touch+pen is, which I believe is used as an
>>> indirect device for touch but a direct device for tools. Thus, in the
>>> thread I linked from back in September, Henrik and I agreed that direct
>>> should only apply when the tool is touch, and pointer should apply for
>>> all other tools. This would result in the following:
>>
>> To try to move back to a sane track, try this, where the word "apply"
>> in the previous paragraph has been changed to "care" instead:
> 
> I am still having trouble understanding what you are saying. If I
> literally try to insert "care" into the paragraph, I am confused because
> it's not quite correct grammar. I'm really trying to understand though.
> Also, maybe a better term than "don't care" is "not applicable"?
> 
> It would help me most if you could explicitly provide your own
> definition of the properties.
> 
>>> Touchpad: !pointer, !direct
>>
>> pointer && !direct, since pointer is "dont care".
> 
> Here you say !direct if "don't care".
> 
>>> Touchscreen: !pointer, direct
>>
>> Yes, !pointer && direct.
>>
>>> Drawing tablet (no touch): pointer, !direct
>>
>> pointer && direct, but the tool is not touch, so direct is "dont care".
> 
> Here you say direct if "don't care".
> 
> Why the difference?
> 
>>> Pen+touch tablet: pointer, direct
>>
>> Yes, pointer && direct
>>
>>> Magic mouse-like devices: !pointer, !direct
>>
>> Both pointer and direct are "dont care", and the device needs to be
>> detected some other way. If there ever will be a special driver for
>> magic-mouse-like devices, using both relative pointer and touch data,
>> it will make sense to add a special property for such devices.
> 
> Right now we are missing a property for a magic-mouse like device. It's
> valid to have neither direct nor pointer set from kernels 2.6.38 through
> 3.2 (at least).
> 
>> Hopefully the above is showing clearly that what was "documented" in
>> the threads enclosing the protocol patches still holds, and that there
>> is no use to dwell on it further.
>>
>>> The properties weren't documented when they were merged, and they
>>> obviously aren't clear. However, if either table above is correct, then
>>> we can't assume that !pointer && !direct means "unknown".
>>
>> If all devices fell in the pointer or direct or both categories, we
>> could. If not all devices do, the problem is rather that some property
>> bits are missing (or excluded) from the description.
> 
> Given my last statement above, we have a problem because previously
> released kernels are reporting the magic mouse correctly, and yet we
> still can't distinguish it from another device that merely does not have
> the property bits set. This is the crux of the issue as I see it. We
> cannot differentiate between "unknown" and a specific type of device
> given the interfaces from 2.6.38 through 3.2.
> 
>>> There is a way to fix this in a backwards compatible way: add a new
>>> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>>> are set, then it implies that the properties are available (which covers
>>> older kernels). If no bits are set, then the properties are unknown.
>>> What do you think?
>>
>> It is rather the special properties of the magic mouse that are
>> missing. All types of devices do not _have_ to use properties; most
>> types can be figured out by other means.
>>
>> Saying "prop == 0" is equivalent to "figure out some other way" makes
>> sense, but it is also sensible to say "(prop & some_subclass_of_bits)
>> == 0", since some properties are bound to describe totally different
>> things. This is what we did with "!direct && !pointer".
> 
> This may work, but we need to document the classes. The next time any
> properties are added the documentation must be included :).
> 
>>>> The same is applicable to other properties as well. If device is telling
>>>> you that it is a "buttonpad" you can trust it, but if it does not you
>>>> need to decide for yourself how to treat it.
>>
>> Yes, and this will always be true. Old devices or systems that become
>> used in new ways cannot always adapt to a "if property not present
>> then dont use that way" policy.
>>
>>> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>>> that I believe there was no way to determine unknown properties. If
>>> unknown properties is equivalent to magic-mouse like devices, then we're
>>> going to treat a lot of devices wrong. Or, we have to use heuristics to
>>> determine what a device is, like no properties and MT and REL_{X,Y} ==
>>> magic-mouse like. Properties was supposed to resolve this once and for
>>> all, so we didn't need heuristics.
>>
>> Properties were added to be able to distinguish usecases that could
>> not be distinguished at all before. It was never meant to replace
>> everything else.
> 
> Why shouldn't we use it for that? The code in evdev for determining the
> type of device is just a big hack. We'll obviously need it for a while
> since we don't have all drivers with all necessary properties set, but
> it seems a waste to have the interface and not fully use it.
> 
>>>>> Henrik, can you comment on the documentation patches? You wrote the
>>>>> patch, so you hopefully know what's going on :).
>>
>> I wasn't copied in on the conversation, but they seem fairly well
>> commented on already.
> 
> It's still not clear to me what the definitions are. It seems it won't
> be clear until either you or Dmitry give your own definitions in an
> explicit manner (something that could be copied into the formal
> documentation). Please help me out :).

Ping?

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
> >> Here's what I believe the meanings should be:
> >>
> >> Touchpad: pointer, !direct
> >> Touchscreen: !pointer, direct
> >> Drawing tablet: pointer, direct
> >> Magic mouse-like devices: !pointer, !direct
> > 
> > Yes, this is what everyone is saying, except !pointer && !direct means
> > "default" or "figure it out some other way".
> > 
> >> However, there is a further problem in that we can't easily support
> >> multiple tools with different behavior on the same evdev device. What
> >> would you say a bamboo touch+pen is, which I believe is used as an
> >> indirect device for touch but a direct device for tools. Thus, in the
> >> thread I linked from back in September, Henrik and I agreed that direct
> >> should only apply when the tool is touch, and pointer should apply for
> >> all other tools. This would result in the following:
> > 
> > To try to move back to a sane track, try this, where the word "apply"
> > in the previous paragraph has been changed to "care" instead:
> 
> I am still having trouble understanding what you are saying. If I
> literally try to insert "care" into the paragraph, I am confused because
> it's not quite correct grammar. I'm really trying to understand though.
> Also, maybe a better term than "don't care" is "not applicable"?
> 
> It would help me most if you could explicitly provide your own
> definition of the properties.
> 
> >> Touchpad: !pointer, !direct
> > 
> > pointer && !direct, since pointer is "dont care".
> 
> Here you say !direct if "don't care".
> 
> >> Touchscreen: !pointer, direct
> > 
> > Yes, !pointer && direct.
> > 
> >> Drawing tablet (no touch): pointer, !direct
> > 
> > pointer && direct, but the tool is not touch, so direct is "dont care".
> 
> Here you say direct if "don't care".
> 
> Why the difference?
> 
> >> Pen+touch tablet: pointer, direct
> > 
> > Yes, pointer && direct
> > 
> >> Magic mouse-like devices: !pointer, !direct
> > 
> > Both pointer and direct are "dont care", and the device needs to be
> > detected some other way. If there ever will be a special driver for
> > magic-mouse-like devices, using both relative pointer and touch data,
> > it will make sense to add a special property for such devices.
> 
> Right now we are missing a property for a magic-mouse like device. It's
> valid to have neither direct nor pointer set from kernels 2.6.38 through
> 3.2 (at least).
> 
> > Hopefully the above is showing clearly that what was "documented" in
> > the threads enclosing the protocol patches still holds, and that there
> > is no use to dwell on it further.
> > 
> >> The properties weren't documented when they were merged, and they
> >> obviously aren't clear. However, if either table above is correct, then
> >> we can't assume that !pointer && !direct means "unknown".
> > 
> > If all devices fell in the pointer or direct or both categories, we
> > could. If not all devices do, the problem is rather that some property
> > bits are missing (or excluded) from the description.
> 
> Given my last statement above, we have a problem because previously
> released kernels are reporting the magic mouse correctly, and yet we
> still can't distinguish it from another device that merely does not have
> the property bits set. This is the crux of the issue as I see it. We
> cannot differentiate between "unknown" and a specific type of device
> given the interfaces from 2.6.38 through 3.2.
> 
> >> There is a way to fix this in a backwards compatible way: add a new
> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
> >> are set, then it implies that the properties are available (which covers
> >> older kernels). If no bits are set, then the properties are unknown.
> >> What do you think?
> > 
> > It is rather the special properties of the magic mouse that are
> > missing. All types of devices do not _have_ to use properties; most
> > types can be figured out by other means.
> > 
> > Saying "prop == 0" is equivalent to "figure out some other way" makes
> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
> > == 0", since some properties are bound to describe totally different
> > things. This is what we did with "!direct && !pointer".
> 
> This may work, but we need to document the classes. The next time any
> properties are added the documentation must be included :).
> 
> >>> The same is applicable to other properties as well. If device is telling
> >>> you that it is a "buttonpad" you can trust it, but if it does not you
> >>> need to decide for yourself how to treat it.
> > 
> > Yes, and this will always be true. Old devices or systems that become
> > used in new ways cannot always adapt to a "if property not present
> > then dont use that way" policy.
> > 
> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
> >> that I believe there was no way to determine unknown properties. If
> >> unknown properties is equivalent to magic-mouse like devices, then we're
> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
> >> magic-mouse like. Properties was supposed to resolve this once and for
> >> all, so we didn't need heuristics.
> > 
> > Properties were added to be able to distinguish usecases that could
> > not be distinguished at all before. It was never meant to replace
> > everything else.
> 
> Why shouldn't we use it for that? The code in evdev for determining the
> type of device is just a big hack. We'll obviously need it for a while
> since we don't have all drivers with all necessary properties set, but
> it seems a waste to have the interface and not fully use it.
> 
> >>>> Henrik, can you comment on the documentation patches? You wrote the
> >>>> patch, so you hopefully know what's going on :).
> > 
> > I wasn't copied in on the conversation, but they seem fairly well
> > commented on already.
> 
> It's still not clear to me what the definitions are. It seems it won't
> be clear until either you or Dmitry give your own definitions in an
> explicit manner (something that could be copied into the formal
> documentation). Please help me out :).
> 

OK, so how about this:

INPUT_PROP_DIRECT:

This property idicates that device coordinates can be directly mapped to
screen coordinates (not taking into account trivial transformations,
such as scaling, flipping and rotating). Non-direct input devices
require non-trivial transformation, such as absolute to relative
transformation for touchpads. Typical direct input devices:
touchscreens, drawing tablets; non-direct devices: touchpads, mice.

INPUT_PROP_POINTER:

This property indicates that the device is not transposed on the screen
and thus requires use of an on-screen pointer to trace user's movements.
Typical pointer devices: touchpads, tablets, mice; non-pointer device:
touchscreen.

How does this sound?

Thanks.

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Henrik Rydberg]

> OK, so how about this:
> 
> INPUT_PROP_DIRECT:
> 
> This property idicates that device coordinates can be directly mapped to
> screen coordinates (not taking into account trivial transformations,
> such as scaling, flipping and rotating). Non-direct input devices
> require non-trivial transformation, such as absolute to relative
> transformation for touchpads. Typical direct input devices:
> touchscreens, drawing tablets; non-direct devices: touchpads, mice.
> 
> INPUT_PROP_POINTER:
> 
> This property indicates that the device is not transposed on the screen
> and thus requires use of an on-screen pointer to trace user's movements.
> Typical pointer devices: touchpads, tablets, mice; non-pointer device:
> touchscreen.
> 
> How does this sound?

Excellent, thanks for that. Fits nicely in a documentation patch - you or me?

Now, let's move on. ;-)

Thanks,
Henrik

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Jason Gerecke]

On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
>> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>> >> Here's what I believe the meanings should be:
>> >>
>> >> Touchpad: pointer, !direct
>> >> Touchscreen: !pointer, direct
>> >> Drawing tablet: pointer, direct
>> >> Magic mouse-like devices: !pointer, !direct
>> >
>> > Yes, this is what everyone is saying, except !pointer && !direct means
>> > "default" or "figure it out some other way".
>> >
>> >> However, there is a further problem in that we can't easily support
>> >> multiple tools with different behavior on the same evdev device. What
>> >> would you say a bamboo touch+pen is, which I believe is used as an
>> >> indirect device for touch but a direct device for tools. Thus, in the
>> >> thread I linked from back in September, Henrik and I agreed that direct
>> >> should only apply when the tool is touch, and pointer should apply for
>> >> all other tools. This would result in the following:
>> >
>> > To try to move back to a sane track, try this, where the word "apply"
>> > in the previous paragraph has been changed to "care" instead:
>>
>> I am still having trouble understanding what you are saying. If I
>> literally try to insert "care" into the paragraph, I am confused because
>> it's not quite correct grammar. I'm really trying to understand though.
>> Also, maybe a better term than "don't care" is "not applicable"?
>>
>> It would help me most if you could explicitly provide your own
>> definition of the properties.
>>
>> >> Touchpad: !pointer, !direct
>> >
>> > pointer && !direct, since pointer is "dont care".
>>
>> Here you say !direct if "don't care".
>>
>> >> Touchscreen: !pointer, direct
>> >
>> > Yes, !pointer && direct.
>> >
>> >> Drawing tablet (no touch): pointer, !direct
>> >
>> > pointer && direct, but the tool is not touch, so direct is "dont care".
>>
>> Here you say direct if "don't care".
>>
>> Why the difference?
>>
>> >> Pen+touch tablet: pointer, direct
>> >
>> > Yes, pointer && direct
>> >
>> >> Magic mouse-like devices: !pointer, !direct
>> >
>> > Both pointer and direct are "dont care", and the device needs to be
>> > detected some other way. If there ever will be a special driver for
>> > magic-mouse-like devices, using both relative pointer and touch data,
>> > it will make sense to add a special property for such devices.
>>
>> Right now we are missing a property for a magic-mouse like device. It's
>> valid to have neither direct nor pointer set from kernels 2.6.38 through
>> 3.2 (at least).
>>
>> > Hopefully the above is showing clearly that what was "documented" in
>> > the threads enclosing the protocol patches still holds, and that there
>> > is no use to dwell on it further.
>> >
>> >> The properties weren't documented when they were merged, and they
>> >> obviously aren't clear. However, if either table above is correct, then
>> >> we can't assume that !pointer && !direct means "unknown".
>> >
>> > If all devices fell in the pointer or direct or both categories, we
>> > could. If not all devices do, the problem is rather that some property
>> > bits are missing (or excluded) from the description.
>>
>> Given my last statement above, we have a problem because previously
>> released kernels are reporting the magic mouse correctly, and yet we
>> still can't distinguish it from another device that merely does not have
>> the property bits set. This is the crux of the issue as I see it. We
>> cannot differentiate between "unknown" and a specific type of device
>> given the interfaces from 2.6.38 through 3.2.
>>
>> >> There is a way to fix this in a backwards compatible way: add a new
>> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>> >> are set, then it implies that the properties are available (which covers
>> >> older kernels). If no bits are set, then the properties are unknown.
>> >> What do you think?
>> >
>> > It is rather the special properties of the magic mouse that are
>> > missing. All types of devices do not _have_ to use properties; most
>> > types can be figured out by other means.
>> >
>> > Saying "prop == 0" is equivalent to "figure out some other way" makes
>> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
>> > == 0", since some properties are bound to describe totally different
>> > things. This is what we did with "!direct && !pointer".
>>
>> This may work, but we need to document the classes. The next time any
>> properties are added the documentation must be included :).
>>
>> >>> The same is applicable to other properties as well. If device is telling
>> >>> you that it is a "buttonpad" you can trust it, but if it does not you
>> >>> need to decide for yourself how to treat it.
>> >
>> > Yes, and this will always be true. Old devices or systems that become
>> > used in new ways cannot always adapt to a "if property not present
>> > then dont use that way" policy.
>> >
>> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>> >> that I believe there was no way to determine unknown properties. If
>> >> unknown properties is equivalent to magic-mouse like devices, then we're
>> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
>> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
>> >> magic-mouse like. Properties was supposed to resolve this once and for
>> >> all, so we didn't need heuristics.
>> >
>> > Properties were added to be able to distinguish usecases that could
>> > not be distinguished at all before. It was never meant to replace
>> > everything else.
>>
>> Why shouldn't we use it for that? The code in evdev for determining the
>> type of device is just a big hack. We'll obviously need it for a while
>> since we don't have all drivers with all necessary properties set, but
>> it seems a waste to have the interface and not fully use it.
>>
>> >>>> Henrik, can you comment on the documentation patches? You wrote the
>> >>>> patch, so you hopefully know what's going on :).
>> >
>> > I wasn't copied in on the conversation, but they seem fairly well
>> > commented on already.
>>
>> It's still not clear to me what the definitions are. It seems it won't
>> be clear until either you or Dmitry give your own definitions in an
>> explicit manner (something that could be copied into the formal
>> documentation). Please help me out :).
>>
>
> OK, so how about this:
>
> INPUT_PROP_DIRECT:
>
> This property idicates that device coordinates can be directly mapped to
"Can", or "should"? A number of touchpads "can" be directly mapped,
but aren't because it goes against the user's expectation.

> screen coordinates (not taking into account trivial transformations,
> such as scaling, flipping and rotating). Non-direct input devices
> require non-trivial transformation, such as absolute to relative
> transformation for touchpads. Typical direct input devices:
> touchscreens, drawing tablets; non-direct devices: touchpads, mice.
This doesn't match what the wacom driver already exposes. Display
tablets set the DIRECT bit, but non-display tablets do not.

> INPUT_PROP_POINTER:
>
> This property indicates that the device is not transposed on the screen
> and thus requires use of an on-screen pointer to trace user's movements.
> Typical pointer devices: touchpads, tablets, mice; non-pointer device:
> touchscreen.
>
> How does this sound?
>
> Thanks.
>
> --
> Dmitry
> --
> 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


Jason

---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
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 v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Tue, Jan 17, 2012 at 10:24:25AM -0800, Jason Gerecke wrote:
> On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
> >> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
> >> >> Here's what I believe the meanings should be:
> >> >>
> >> >> Touchpad: pointer, !direct
> >> >> Touchscreen: !pointer, direct
> >> >> Drawing tablet: pointer, direct
> >> >> Magic mouse-like devices: !pointer, !direct
> >> >
> >> > Yes, this is what everyone is saying, except !pointer && !direct means
> >> > "default" or "figure it out some other way".
> >> >
> >> >> However, there is a further problem in that we can't easily support
> >> >> multiple tools with different behavior on the same evdev device. What
> >> >> would you say a bamboo touch+pen is, which I believe is used as an
> >> >> indirect device for touch but a direct device for tools. Thus, in the
> >> >> thread I linked from back in September, Henrik and I agreed that direct
> >> >> should only apply when the tool is touch, and pointer should apply for
> >> >> all other tools. This would result in the following:
> >> >
> >> > To try to move back to a sane track, try this, where the word "apply"
> >> > in the previous paragraph has been changed to "care" instead:
> >>
> >> I am still having trouble understanding what you are saying. If I
> >> literally try to insert "care" into the paragraph, I am confused because
> >> it's not quite correct grammar. I'm really trying to understand though.
> >> Also, maybe a better term than "don't care" is "not applicable"?
> >>
> >> It would help me most if you could explicitly provide your own
> >> definition of the properties.
> >>
> >> >> Touchpad: !pointer, !direct
> >> >
> >> > pointer && !direct, since pointer is "dont care".
> >>
> >> Here you say !direct if "don't care".
> >>
> >> >> Touchscreen: !pointer, direct
> >> >
> >> > Yes, !pointer && direct.
> >> >
> >> >> Drawing tablet (no touch): pointer, !direct
> >> >
> >> > pointer && direct, but the tool is not touch, so direct is "dont care".
> >>
> >> Here you say direct if "don't care".
> >>
> >> Why the difference?
> >>
> >> >> Pen+touch tablet: pointer, direct
> >> >
> >> > Yes, pointer && direct
> >> >
> >> >> Magic mouse-like devices: !pointer, !direct
> >> >
> >> > Both pointer and direct are "dont care", and the device needs to be
> >> > detected some other way. If there ever will be a special driver for
> >> > magic-mouse-like devices, using both relative pointer and touch data,
> >> > it will make sense to add a special property for such devices.
> >>
> >> Right now we are missing a property for a magic-mouse like device. It's
> >> valid to have neither direct nor pointer set from kernels 2.6.38 through
> >> 3.2 (at least).
> >>
> >> > Hopefully the above is showing clearly that what was "documented" in
> >> > the threads enclosing the protocol patches still holds, and that there
> >> > is no use to dwell on it further.
> >> >
> >> >> The properties weren't documented when they were merged, and they
> >> >> obviously aren't clear. However, if either table above is correct, then
> >> >> we can't assume that !pointer && !direct means "unknown".
> >> >
> >> > If all devices fell in the pointer or direct or both categories, we
> >> > could. If not all devices do, the problem is rather that some property
> >> > bits are missing (or excluded) from the description.
> >>
> >> Given my last statement above, we have a problem because previously
> >> released kernels are reporting the magic mouse correctly, and yet we
> >> still can't distinguish it from another device that merely does not have
> >> the property bits set. This is the crux of the issue as I see it. We
> >> cannot differentiate between "unknown" and a specific type of device
> >> given the interfaces from 2.6.38 through 3.2.
> >>
> >> >> There is a way to fix this in a backwards compatible way: add a new
> >> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
> >> >> are set, then it implies that the properties are available (which covers
> >> >> older kernels). If no bits are set, then the properties are unknown.
> >> >> What do you think?
> >> >
> >> > It is rather the special properties of the magic mouse that are
> >> > missing. All types of devices do not _have_ to use properties; most
> >> > types can be figured out by other means.
> >> >
> >> > Saying "prop == 0" is equivalent to "figure out some other way" makes
> >> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
> >> > == 0", since some properties are bound to describe totally different
> >> > things. This is what we did with "!direct && !pointer".
> >>
> >> This may work, but we need to document the classes. The next time any
> >> properties are added the documentation must be included :).
> >>
> >> >>> The same is applicable to other properties as well. If device is telling
> >> >>> you that it is a "buttonpad" you can trust it, but if it does not you
> >> >>> need to decide for yourself how to treat it.
> >> >
> >> > Yes, and this will always be true. Old devices or systems that become
> >> > used in new ways cannot always adapt to a "if property not present
> >> > then dont use that way" policy.
> >> >
> >> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
> >> >> that I believe there was no way to determine unknown properties. If
> >> >> unknown properties is equivalent to magic-mouse like devices, then we're
> >> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
> >> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
> >> >> magic-mouse like. Properties was supposed to resolve this once and for
> >> >> all, so we didn't need heuristics.
> >> >
> >> > Properties were added to be able to distinguish usecases that could
> >> > not be distinguished at all before. It was never meant to replace
> >> > everything else.
> >>
> >> Why shouldn't we use it for that? The code in evdev for determining the
> >> type of device is just a big hack. We'll obviously need it for a while
> >> since we don't have all drivers with all necessary properties set, but
> >> it seems a waste to have the interface and not fully use it.
> >>
> >> >>>> Henrik, can you comment on the documentation patches? You wrote the
> >> >>>> patch, so you hopefully know what's going on :).
> >> >
> >> > I wasn't copied in on the conversation, but they seem fairly well
> >> > commented on already.
> >>
> >> It's still not clear to me what the definitions are. It seems it won't
> >> be clear until either you or Dmitry give your own definitions in an
> >> explicit manner (something that could be copied into the formal
> >> documentation). Please help me out :).
> >>
> >
> > OK, so how about this:
> >
> > INPUT_PROP_DIRECT:
> >
> > This property idicates that device coordinates can be directly mapped to
> "Can", or "should"? A number of touchpads "can" be directly mapped,
> but aren't because it goes against the user's expectation.

"Can". The property bits are advisory; IIRC there were discussed a few
potential uses of input devices that would go against their "normal"
properties. However we are aiming at providing hints to userspace to
support auto-configuration for standard uses.

> 
> > screen coordinates (not taking into account trivial transformations,
> > such as scaling, flipping and rotating). Non-direct input devices
> > require non-trivial transformation, such as absolute to relative
> > transformation for touchpads. Typical direct input devices:
> > touchscreens, drawing tablets; non-direct devices: touchpads, mice.
> This doesn't match what the wacom driver already exposes. Display
> tablets set the DIRECT bit, but non-display tablets do not.

Then wacom driver should be adjusted so we are consistent.

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Jason Gerecke]

On Tue, Jan 17, 2012 at 11:21 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 10:24:25AM -0800, Jason Gerecke wrote:
>> On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
>> >> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>> >> >> Here's what I believe the meanings should be:
>> >> >>
>> >> >> Touchpad: pointer, !direct
>> >> >> Touchscreen: !pointer, direct
>> >> >> Drawing tablet: pointer, direct
>> >> >> Magic mouse-like devices: !pointer, !direct
>> >> >
>> >> > Yes, this is what everyone is saying, except !pointer && !direct means
>> >> > "default" or "figure it out some other way".
>> >> >
>> >> >> However, there is a further problem in that we can't easily support
>> >> >> multiple tools with different behavior on the same evdev device. What
>> >> >> would you say a bamboo touch+pen is, which I believe is used as an
>> >> >> indirect device for touch but a direct device for tools. Thus, in the
>> >> >> thread I linked from back in September, Henrik and I agreed that direct
>> >> >> should only apply when the tool is touch, and pointer should apply for
>> >> >> all other tools. This would result in the following:
>> >> >
>> >> > To try to move back to a sane track, try this, where the word "apply"
>> >> > in the previous paragraph has been changed to "care" instead:
>> >>
>> >> I am still having trouble understanding what you are saying. If I
>> >> literally try to insert "care" into the paragraph, I am confused because
>> >> it's not quite correct grammar. I'm really trying to understand though.
>> >> Also, maybe a better term than "don't care" is "not applicable"?
>> >>
>> >> It would help me most if you could explicitly provide your own
>> >> definition of the properties.
>> >>
>> >> >> Touchpad: !pointer, !direct
>> >> >
>> >> > pointer && !direct, since pointer is "dont care".
>> >>
>> >> Here you say !direct if "don't care".
>> >>
>> >> >> Touchscreen: !pointer, direct
>> >> >
>> >> > Yes, !pointer && direct.
>> >> >
>> >> >> Drawing tablet (no touch): pointer, !direct
>> >> >
>> >> > pointer && direct, but the tool is not touch, so direct is "dont care".
>> >>
>> >> Here you say direct if "don't care".
>> >>
>> >> Why the difference?
>> >>
>> >> >> Pen+touch tablet: pointer, direct
>> >> >
>> >> > Yes, pointer && direct
>> >> >
>> >> >> Magic mouse-like devices: !pointer, !direct
>> >> >
>> >> > Both pointer and direct are "dont care", and the device needs to be
>> >> > detected some other way. If there ever will be a special driver for
>> >> > magic-mouse-like devices, using both relative pointer and touch data,
>> >> > it will make sense to add a special property for such devices.
>> >>
>> >> Right now we are missing a property for a magic-mouse like device. It's
>> >> valid to have neither direct nor pointer set from kernels 2.6.38 through
>> >> 3.2 (at least).
>> >>
>> >> > Hopefully the above is showing clearly that what was "documented" in
>> >> > the threads enclosing the protocol patches still holds, and that there
>> >> > is no use to dwell on it further.
>> >> >
>> >> >> The properties weren't documented when they were merged, and they
>> >> >> obviously aren't clear. However, if either table above is correct, then
>> >> >> we can't assume that !pointer && !direct means "unknown".
>> >> >
>> >> > If all devices fell in the pointer or direct or both categories, we
>> >> > could. If not all devices do, the problem is rather that some property
>> >> > bits are missing (or excluded) from the description.
>> >>
>> >> Given my last statement above, we have a problem because previously
>> >> released kernels are reporting the magic mouse correctly, and yet we
>> >> still can't distinguish it from another device that merely does not have
>> >> the property bits set. This is the crux of the issue as I see it. We
>> >> cannot differentiate between "unknown" and a specific type of device
>> >> given the interfaces from 2.6.38 through 3.2.
>> >>
>> >> >> There is a way to fix this in a backwards compatible way: add a new
>> >> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>> >> >> are set, then it implies that the properties are available (which covers
>> >> >> older kernels). If no bits are set, then the properties are unknown.
>> >> >> What do you think?
>> >> >
>> >> > It is rather the special properties of the magic mouse that are
>> >> > missing. All types of devices do not _have_ to use properties; most
>> >> > types can be figured out by other means.
>> >> >
>> >> > Saying "prop == 0" is equivalent to "figure out some other way" makes
>> >> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
>> >> > == 0", since some properties are bound to describe totally different
>> >> > things. This is what we did with "!direct && !pointer".
>> >>
>> >> This may work, but we need to document the classes. The next time any
>> >> properties are added the documentation must be included :).
>> >>
>> >> >>> The same is applicable to other properties as well. If device is telling
>> >> >>> you that it is a "buttonpad" you can trust it, but if it does not you
>> >> >>> need to decide for yourself how to treat it.
>> >> >
>> >> > Yes, and this will always be true. Old devices or systems that become
>> >> > used in new ways cannot always adapt to a "if property not present
>> >> > then dont use that way" policy.
>> >> >
>> >> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>> >> >> that I believe there was no way to determine unknown properties. If
>> >> >> unknown properties is equivalent to magic-mouse like devices, then we're
>> >> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
>> >> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
>> >> >> magic-mouse like. Properties was supposed to resolve this once and for
>> >> >> all, so we didn't need heuristics.
>> >> >
>> >> > Properties were added to be able to distinguish usecases that could
>> >> > not be distinguished at all before. It was never meant to replace
>> >> > everything else.
>> >>
>> >> Why shouldn't we use it for that? The code in evdev for determining the
>> >> type of device is just a big hack. We'll obviously need it for a while
>> >> since we don't have all drivers with all necessary properties set, but
>> >> it seems a waste to have the interface and not fully use it.
>> >>
>> >> >>>> Henrik, can you comment on the documentation patches? You wrote the
>> >> >>>> patch, so you hopefully know what's going on :).
>> >> >
>> >> > I wasn't copied in on the conversation, but they seem fairly well
>> >> > commented on already.
>> >>
>> >> It's still not clear to me what the definitions are. It seems it won't
>> >> be clear until either you or Dmitry give your own definitions in an
>> >> explicit manner (something that could be copied into the formal
>> >> documentation). Please help me out :).
>> >>
>> >
>> > OK, so how about this:
>> >
>> > INPUT_PROP_DIRECT:
>> >
>> > This property idicates that device coordinates can be directly mapped to
>> "Can", or "should"? A number of touchpads "can" be directly mapped,
>> but aren't because it goes against the user's expectation.
>
> "Can". The property bits are advisory; IIRC there were discussed a few
> potential uses of input devices that would go against their "normal"
> properties. However we are aiming at providing hints to userspace to
> support auto-configuration for standard uses.
>
Are you saying that (absolute) touchpads would be one of these
exceptions that go against their "normal" properties and leave
INPUT_PROP_DIRECT un-set anyway? Otherwise, I'm afraid that I don't
understand what you're getting at...

Unless I'm mistaken, the use of ABS_X and ABS_Y already implies that a
device "can" be trivially mapped to screen space, and their absence
implies the inability. Having the flag provide the same meaning seems
pointless. If we're aiming to help the userspace with
auto-configuration for standard use, we should be exposing
*additional* (i.e. "should"), not *redundant* (i.e. "can") advisory
information.

>>
>> > screen coordinates (not taking into account trivial transformations,
>> > such as scaling, flipping and rotating). Non-direct input devices
>> > require non-trivial transformation, such as absolute to relative
>> > transformation for touchpads. Typical direct input devices:
>> > touchscreens, drawing tablets; non-direct devices: touchpads, mice.
>> This doesn't match what the wacom driver already exposes. Display
>> tablets set the DIRECT bit, but non-display tablets do not.
>
> Then wacom driver should be adjusted so we are consistent.
>
> --
> Dmitry



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 v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Tue, Jan 17, 2012 at 12:27:08PM -0800, Jason Gerecke wrote:
> On Tue, Jan 17, 2012 at 11:21 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, Jan 17, 2012 at 10:24:25AM -0800, Jason Gerecke wrote:
> >> On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
> >> >> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
> >> >> >> Here's what I believe the meanings should be:
> >> >> >>
> >> >> >> Touchpad: pointer, !direct
> >> >> >> Touchscreen: !pointer, direct
> >> >> >> Drawing tablet: pointer, direct
> >> >> >> Magic mouse-like devices: !pointer, !direct
> >> >> >
> >> >> > Yes, this is what everyone is saying, except !pointer && !direct means
> >> >> > "default" or "figure it out some other way".
> >> >> >
> >> >> >> However, there is a further problem in that we can't easily support
> >> >> >> multiple tools with different behavior on the same evdev device. What
> >> >> >> would you say a bamboo touch+pen is, which I believe is used as an
> >> >> >> indirect device for touch but a direct device for tools. Thus, in the
> >> >> >> thread I linked from back in September, Henrik and I agreed that direct
> >> >> >> should only apply when the tool is touch, and pointer should apply for
> >> >> >> all other tools. This would result in the following:
> >> >> >
> >> >> > To try to move back to a sane track, try this, where the word "apply"
> >> >> > in the previous paragraph has been changed to "care" instead:
> >> >>
> >> >> I am still having trouble understanding what you are saying. If I
> >> >> literally try to insert "care" into the paragraph, I am confused because
> >> >> it's not quite correct grammar. I'm really trying to understand though.
> >> >> Also, maybe a better term than "don't care" is "not applicable"?
> >> >>
> >> >> It would help me most if you could explicitly provide your own
> >> >> definition of the properties.
> >> >>
> >> >> >> Touchpad: !pointer, !direct
> >> >> >
> >> >> > pointer && !direct, since pointer is "dont care".
> >> >>
> >> >> Here you say !direct if "don't care".
> >> >>
> >> >> >> Touchscreen: !pointer, direct
> >> >> >
> >> >> > Yes, !pointer && direct.
> >> >> >
> >> >> >> Drawing tablet (no touch): pointer, !direct
> >> >> >
> >> >> > pointer && direct, but the tool is not touch, so direct is "dont care".
> >> >>
> >> >> Here you say direct if "don't care".
> >> >>
> >> >> Why the difference?
> >> >>
> >> >> >> Pen+touch tablet: pointer, direct
> >> >> >
> >> >> > Yes, pointer && direct
> >> >> >
> >> >> >> Magic mouse-like devices: !pointer, !direct
> >> >> >
> >> >> > Both pointer and direct are "dont care", and the device needs to be
> >> >> > detected some other way. If there ever will be a special driver for
> >> >> > magic-mouse-like devices, using both relative pointer and touch data,
> >> >> > it will make sense to add a special property for such devices.
> >> >>
> >> >> Right now we are missing a property for a magic-mouse like device. It's
> >> >> valid to have neither direct nor pointer set from kernels 2.6.38 through
> >> >> 3.2 (at least).
> >> >>
> >> >> > Hopefully the above is showing clearly that what was "documented" in
> >> >> > the threads enclosing the protocol patches still holds, and that there
> >> >> > is no use to dwell on it further.
> >> >> >
> >> >> >> The properties weren't documented when they were merged, and they
> >> >> >> obviously aren't clear. However, if either table above is correct, then
> >> >> >> we can't assume that !pointer && !direct means "unknown".
> >> >> >
> >> >> > If all devices fell in the pointer or direct or both categories, we
> >> >> > could. If not all devices do, the problem is rather that some property
> >> >> > bits are missing (or excluded) from the description.
> >> >>
> >> >> Given my last statement above, we have a problem because previously
> >> >> released kernels are reporting the magic mouse correctly, and yet we
> >> >> still can't distinguish it from another device that merely does not have
> >> >> the property bits set. This is the crux of the issue as I see it. We
> >> >> cannot differentiate between "unknown" and a specific type of device
> >> >> given the interfaces from 2.6.38 through 3.2.
> >> >>
> >> >> >> There is a way to fix this in a backwards compatible way: add a new
> >> >> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
> >> >> >> are set, then it implies that the properties are available (which covers
> >> >> >> older kernels). If no bits are set, then the properties are unknown.
> >> >> >> What do you think?
> >> >> >
> >> >> > It is rather the special properties of the magic mouse that are
> >> >> > missing. All types of devices do not _have_ to use properties; most
> >> >> > types can be figured out by other means.
> >> >> >
> >> >> > Saying "prop == 0" is equivalent to "figure out some other way" makes
> >> >> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
> >> >> > == 0", since some properties are bound to describe totally different
> >> >> > things. This is what we did with "!direct && !pointer".
> >> >>
> >> >> This may work, but we need to document the classes. The next time any
> >> >> properties are added the documentation must be included :).
> >> >>
> >> >> >>> The same is applicable to other properties as well. If device is telling
> >> >> >>> you that it is a "buttonpad" you can trust it, but if it does not you
> >> >> >>> need to decide for yourself how to treat it.
> >> >> >
> >> >> > Yes, and this will always be true. Old devices or systems that become
> >> >> > used in new ways cannot always adapt to a "if property not present
> >> >> > then dont use that way" policy.
> >> >> >
> >> >> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
> >> >> >> that I believe there was no way to determine unknown properties. If
> >> >> >> unknown properties is equivalent to magic-mouse like devices, then we're
> >> >> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
> >> >> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
> >> >> >> magic-mouse like. Properties was supposed to resolve this once and for
> >> >> >> all, so we didn't need heuristics.
> >> >> >
> >> >> > Properties were added to be able to distinguish usecases that could
> >> >> > not be distinguished at all before. It was never meant to replace
> >> >> > everything else.
> >> >>
> >> >> Why shouldn't we use it for that? The code in evdev for determining the
> >> >> type of device is just a big hack. We'll obviously need it for a while
> >> >> since we don't have all drivers with all necessary properties set, but
> >> >> it seems a waste to have the interface and not fully use it.
> >> >>
> >> >> >>>> Henrik, can you comment on the documentation patches? You wrote the
> >> >> >>>> patch, so you hopefully know what's going on :).
> >> >> >
> >> >> > I wasn't copied in on the conversation, but they seem fairly well
> >> >> > commented on already.
> >> >>
> >> >> It's still not clear to me what the definitions are. It seems it won't
> >> >> be clear until either you or Dmitry give your own definitions in an
> >> >> explicit manner (something that could be copied into the formal
> >> >> documentation). Please help me out :).
> >> >>
> >> >
> >> > OK, so how about this:
> >> >
> >> > INPUT_PROP_DIRECT:
> >> >
> >> > This property idicates that device coordinates can be directly mapped to
> >> "Can", or "should"? A number of touchpads "can" be directly mapped,
> >> but aren't because it goes against the user's expectation.
> >
> > "Can". The property bits are advisory; IIRC there were discussed a few
> > potential uses of input devices that would go against their "normal"
> > properties. However we are aiming at providing hints to userspace to
> > support auto-configuration for standard uses.
> >
> Are you saying that (absolute) touchpads would be one of these
> exceptions that go against their "normal" properties and leave
> INPUT_PROP_DIRECT un-set anyway? Otherwise, I'm afraid that I don't
> understand what you're getting at...

Right, absolute touchpads should not set INPUT_PROP_DIRECT as the user
expectation is that touchpad behaves similarly to a mouse, i.e.
absolute-to-relative conversion is performed.

> 
> Unless I'm mistaken, the use of ABS_X and ABS_Y already implies that a
> device "can" be trivially mapped to screen space, and their absence
> implies the inability. Having the flag provide the same meaning seems
> pointless. If we're aiming to help the userspace with
> auto-configuration for standard use, we should be exposing
> *additional* (i.e. "should"), not *redundant* (i.e. "can") advisory
> information.

I think we are splitting hair here with must/should/can. What I am
trying to say is that INPUT_PROP_DIRECT device can have its coordinates
mapped directly to a screen and if your application wants to configure
for the default behavior it should do such mapping.

Please provide your version if you'd like to adjust the wording.

Thanks.

-- 
Dmitry

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Jason Gerecke]

On Tue, Jan 17, 2012 at 12:40 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 12:27:08PM -0800, Jason Gerecke wrote:
>> On Tue, Jan 17, 2012 at 11:21 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Tue, Jan 17, 2012 at 10:24:25AM -0800, Jason Gerecke wrote:
>> >> On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
>> >> >> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>> >> >> >> Here's what I believe the meanings should be:
>> >> >> >>
>> >> >> >> Touchpad: pointer, !direct
>> >> >> >> Touchscreen: !pointer, direct
>> >> >> >> Drawing tablet: pointer, direct
>> >> >> >> Magic mouse-like devices: !pointer, !direct
>> >> >> >
>> >> >> > Yes, this is what everyone is saying, except !pointer && !direct means
>> >> >> > "default" or "figure it out some other way".
>> >> >> >
>> >> >> >> However, there is a further problem in that we can't easily support
>> >> >> >> multiple tools with different behavior on the same evdev device. What
>> >> >> >> would you say a bamboo touch+pen is, which I believe is used as an
>> >> >> >> indirect device for touch but a direct device for tools. Thus, in the
>> >> >> >> thread I linked from back in September, Henrik and I agreed that direct
>> >> >> >> should only apply when the tool is touch, and pointer should apply for
>> >> >> >> all other tools. This would result in the following:
>> >> >> >
>> >> >> > To try to move back to a sane track, try this, where the word "apply"
>> >> >> > in the previous paragraph has been changed to "care" instead:
>> >> >>
>> >> >> I am still having trouble understanding what you are saying. If I
>> >> >> literally try to insert "care" into the paragraph, I am confused because
>> >> >> it's not quite correct grammar. I'm really trying to understand though.
>> >> >> Also, maybe a better term than "don't care" is "not applicable"?
>> >> >>
>> >> >> It would help me most if you could explicitly provide your own
>> >> >> definition of the properties.
>> >> >>
>> >> >> >> Touchpad: !pointer, !direct
>> >> >> >
>> >> >> > pointer && !direct, since pointer is "dont care".
>> >> >>
>> >> >> Here you say !direct if "don't care".
>> >> >>
>> >> >> >> Touchscreen: !pointer, direct
>> >> >> >
>> >> >> > Yes, !pointer && direct.
>> >> >> >
>> >> >> >> Drawing tablet (no touch): pointer, !direct
>> >> >> >
>> >> >> > pointer && direct, but the tool is not touch, so direct is "dont care".
>> >> >>
>> >> >> Here you say direct if "don't care".
>> >> >>
>> >> >> Why the difference?
>> >> >>
>> >> >> >> Pen+touch tablet: pointer, direct
>> >> >> >
>> >> >> > Yes, pointer && direct
>> >> >> >
>> >> >> >> Magic mouse-like devices: !pointer, !direct
>> >> >> >
>> >> >> > Both pointer and direct are "dont care", and the device needs to be
>> >> >> > detected some other way. If there ever will be a special driver for
>> >> >> > magic-mouse-like devices, using both relative pointer and touch data,
>> >> >> > it will make sense to add a special property for such devices.
>> >> >>
>> >> >> Right now we are missing a property for a magic-mouse like device. It's
>> >> >> valid to have neither direct nor pointer set from kernels 2.6.38 through
>> >> >> 3.2 (at least).
>> >> >>
>> >> >> > Hopefully the above is showing clearly that what was "documented" in
>> >> >> > the threads enclosing the protocol patches still holds, and that there
>> >> >> > is no use to dwell on it further.
>> >> >> >
>> >> >> >> The properties weren't documented when they were merged, and they
>> >> >> >> obviously aren't clear. However, if either table above is correct, then
>> >> >> >> we can't assume that !pointer && !direct means "unknown".
>> >> >> >
>> >> >> > If all devices fell in the pointer or direct or both categories, we
>> >> >> > could. If not all devices do, the problem is rather that some property
>> >> >> > bits are missing (or excluded) from the description.
>> >> >>
>> >> >> Given my last statement above, we have a problem because previously
>> >> >> released kernels are reporting the magic mouse correctly, and yet we
>> >> >> still can't distinguish it from another device that merely does not have
>> >> >> the property bits set. This is the crux of the issue as I see it. We
>> >> >> cannot differentiate between "unknown" and a specific type of device
>> >> >> given the interfaces from 2.6.38 through 3.2.
>> >> >>
>> >> >> >> There is a way to fix this in a backwards compatible way: add a new
>> >> >> >> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>> >> >> >> are set, then it implies that the properties are available (which covers
>> >> >> >> older kernels). If no bits are set, then the properties are unknown.
>> >> >> >> What do you think?
>> >> >> >
>> >> >> > It is rather the special properties of the magic mouse that are
>> >> >> > missing. All types of devices do not _have_ to use properties; most
>> >> >> > types can be figured out by other means.
>> >> >> >
>> >> >> > Saying "prop == 0" is equivalent to "figure out some other way" makes
>> >> >> > sense, but it is also sensible to say "(prop & some_subclass_of_bits)
>> >> >> > == 0", since some properties are bound to describe totally different
>> >> >> > things. This is what we did with "!direct && !pointer".
>> >> >>
>> >> >> This may work, but we need to document the classes. The next time any
>> >> >> properties are added the documentation must be included :).
>> >> >>
>> >> >> >>> The same is applicable to other properties as well. If device is telling
>> >> >> >>> you that it is a "buttonpad" you can trust it, but if it does not you
>> >> >> >>> need to decide for yourself how to treat it.
>> >> >> >
>> >> >> > Yes, and this will always be true. Old devices or systems that become
>> >> >> > used in new ways cannot always adapt to a "if property not present
>> >> >> > then dont use that way" policy.
>> >> >> >
>> >> >> >> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>> >> >> >> that I believe there was no way to determine unknown properties. If
>> >> >> >> unknown properties is equivalent to magic-mouse like devices, then we're
>> >> >> >> going to treat a lot of devices wrong. Or, we have to use heuristics to
>> >> >> >> determine what a device is, like no properties and MT and REL_{X,Y} ==
>> >> >> >> magic-mouse like. Properties was supposed to resolve this once and for
>> >> >> >> all, so we didn't need heuristics.
>> >> >> >
>> >> >> > Properties were added to be able to distinguish usecases that could
>> >> >> > not be distinguished at all before. It was never meant to replace
>> >> >> > everything else.
>> >> >>
>> >> >> Why shouldn't we use it for that? The code in evdev for determining the
>> >> >> type of device is just a big hack. We'll obviously need it for a while
>> >> >> since we don't have all drivers with all necessary properties set, but
>> >> >> it seems a waste to have the interface and not fully use it.
>> >> >>
>> >> >> >>>> Henrik, can you comment on the documentation patches? You wrote the
>> >> >> >>>> patch, so you hopefully know what's going on :).
>> >> >> >
>> >> >> > I wasn't copied in on the conversation, but they seem fairly well
>> >> >> > commented on already.
>> >> >>
>> >> >> It's still not clear to me what the definitions are. It seems it won't
>> >> >> be clear until either you or Dmitry give your own definitions in an
>> >> >> explicit manner (something that could be copied into the formal
>> >> >> documentation). Please help me out :).
>> >> >>
>> >> >
>> >> > OK, so how about this:
>> >> >
>> >> > INPUT_PROP_DIRECT:
>> >> >
>> >> > This property idicates that device coordinates can be directly mapped to
>> >> "Can", or "should"? A number of touchpads "can" be directly mapped,
>> >> but aren't because it goes against the user's expectation.
>> >
>> > "Can". The property bits are advisory; IIRC there were discussed a few
>> > potential uses of input devices that would go against their "normal"
>> > properties. However we are aiming at providing hints to userspace to
>> > support auto-configuration for standard uses.
>> >
>> Are you saying that (absolute) touchpads would be one of these
>> exceptions that go against their "normal" properties and leave
>> INPUT_PROP_DIRECT un-set anyway? Otherwise, I'm afraid that I don't
>> understand what you're getting at...
>
> Right, absolute touchpads should not set INPUT_PROP_DIRECT as the user
> expectation is that touchpad behaves similarly to a mouse, i.e.
> absolute-to-relative conversion is performed.
>
>>
>> Unless I'm mistaken, the use of ABS_X and ABS_Y already implies that a
>> device "can" be trivially mapped to screen space, and their absence
>> implies the inability. Having the flag provide the same meaning seems
>> pointless. If we're aiming to help the userspace with
>> auto-configuration for standard use, we should be exposing
>> *additional* (i.e. "should"), not *redundant* (i.e. "can") advisory
>> information.
>
> I think we are splitting hair here with must/should/can. What I am
> trying to say is that INPUT_PROP_DIRECT device can have its coordinates
> mapped directly to a screen and if your application wants to configure
> for the default behavior it should do such mapping.
>
> Please provide your version if you'd like to adjust the wording.
>
> Thanks.
>
> --
> Dmitry

OK, I wasn't sure if you were implying that or not. The only change
I'd make is changing "can" to "should" to more strongly indicate that
the flag is less about the hardware's physical capabilities than the
correct auto-configuration.

Or, for easier copy/paste:

INPUT_PROP_DIRECT:

 This property indicates that device coordinates should be directly mapped to
 screen coordinates (not taking into account trivial transformations,
 such as scaling, flipping and rotating). Non-direct input devices
 require non-trivial transformation, such as absolute to relative
 transformation for touchpads. Typical direct input devices:
 touchscreens, drawing tablets; non-direct devices: touchpads, mice.

 INPUT_PROP_POINTER:

 This property indicates that the device is not transposed on the screen
 and thus requires use of an on-screen pointer to trace user's movements.
 Typical pointer devices: touchpads, tablets, mice; non-pointer device:
 touchscreen.

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 v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/17/2012 07:06 PM, Dmitry Torokhov wrote:
> On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
>> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
>>>> Here's what I believe the meanings should be:
>>>>
>>>> Touchpad: pointer, !direct
>>>> Touchscreen: !pointer, direct
>>>> Drawing tablet: pointer, direct
>>>> Magic mouse-like devices: !pointer, !direct
>>>
>>> Yes, this is what everyone is saying, except !pointer && !direct means
>>> "default" or "figure it out some other way".
>>>
>>>> However, there is a further problem in that we can't easily support
>>>> multiple tools with different behavior on the same evdev device. What
>>>> would you say a bamboo touch+pen is, which I believe is used as an
>>>> indirect device for touch but a direct device for tools. Thus, in the
>>>> thread I linked from back in September, Henrik and I agreed that direct
>>>> should only apply when the tool is touch, and pointer should apply for
>>>> all other tools. This would result in the following:
>>>
>>> To try to move back to a sane track, try this, where the word "apply"
>>> in the previous paragraph has been changed to "care" instead:
>>
>> I am still having trouble understanding what you are saying. If I
>> literally try to insert "care" into the paragraph, I am confused because
>> it's not quite correct grammar. I'm really trying to understand though.
>> Also, maybe a better term than "don't care" is "not applicable"?
>>
>> It would help me most if you could explicitly provide your own
>> definition of the properties.
>>
>>>> Touchpad: !pointer, !direct
>>>
>>> pointer && !direct, since pointer is "dont care".
>>
>> Here you say !direct if "don't care".
>>
>>>> Touchscreen: !pointer, direct
>>>
>>> Yes, !pointer && direct.
>>>
>>>> Drawing tablet (no touch): pointer, !direct
>>>
>>> pointer && direct, but the tool is not touch, so direct is "dont care".
>>
>> Here you say direct if "don't care".
>>
>> Why the difference?
>>
>>>> Pen+touch tablet: pointer, direct
>>>
>>> Yes, pointer && direct
>>>
>>>> Magic mouse-like devices: !pointer, !direct
>>>
>>> Both pointer and direct are "dont care", and the device needs to be
>>> detected some other way. If there ever will be a special driver for
>>> magic-mouse-like devices, using both relative pointer and touch data,
>>> it will make sense to add a special property for such devices.
>>
>> Right now we are missing a property for a magic-mouse like device. It's
>> valid to have neither direct nor pointer set from kernels 2.6.38 through
>> 3.2 (at least).
>>
>>> Hopefully the above is showing clearly that what was "documented" in
>>> the threads enclosing the protocol patches still holds, and that there
>>> is no use to dwell on it further.
>>>
>>>> The properties weren't documented when they were merged, and they
>>>> obviously aren't clear. However, if either table above is correct, then
>>>> we can't assume that !pointer && !direct means "unknown".
>>>
>>> If all devices fell in the pointer or direct or both categories, we
>>> could. If not all devices do, the problem is rather that some property
>>> bits are missing (or excluded) from the description.
>>
>> Given my last statement above, we have a problem because previously
>> released kernels are reporting the magic mouse correctly, and yet we
>> still can't distinguish it from another device that merely does not have
>> the property bits set. This is the crux of the issue as I see it. We
>> cannot differentiate between "unknown" and a specific type of device
>> given the interfaces from 2.6.38 through 3.2.
>>
>>>> There is a way to fix this in a backwards compatible way: add a new
>>>> property bit called something like "PROPERTIES_AVAILABLE". If any bits
>>>> are set, then it implies that the properties are available (which covers
>>>> older kernels). If no bits are set, then the properties are unknown.
>>>> What do you think?
>>>
>>> It is rather the special properties of the magic mouse that are
>>> missing. All types of devices do not _have_ to use properties; most
>>> types can be figured out by other means.
>>>
>>> Saying "prop == 0" is equivalent to "figure out some other way" makes
>>> sense, but it is also sensible to say "(prop & some_subclass_of_bits)
>>> == 0", since some properties are bound to describe totally different
>>> things. This is what we did with "!direct && !pointer".
>>
>> This may work, but we need to document the classes. The next time any
>> properties are added the documentation must be included :).
>>
>>>>> The same is applicable to other properties as well. If device is telling
>>>>> you that it is a "buttonpad" you can trust it, but if it does not you
>>>>> need to decide for yourself how to treat it.
>>>
>>> Yes, and this will always be true. Old devices or systems that become
>>> used in new ways cannot always adapt to a "if property not present
>>> then dont use that way" policy.
>>>
>>>> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
>>>> that I believe there was no way to determine unknown properties. If
>>>> unknown properties is equivalent to magic-mouse like devices, then we're
>>>> going to treat a lot of devices wrong. Or, we have to use heuristics to
>>>> determine what a device is, like no properties and MT and REL_{X,Y} ==
>>>> magic-mouse like. Properties was supposed to resolve this once and for
>>>> all, so we didn't need heuristics.
>>>
>>> Properties were added to be able to distinguish usecases that could
>>> not be distinguished at all before. It was never meant to replace
>>> everything else.
>>
>> Why shouldn't we use it for that? The code in evdev for determining the
>> type of device is just a big hack. We'll obviously need it for a while
>> since we don't have all drivers with all necessary properties set, but
>> it seems a waste to have the interface and not fully use it.
>>
>>>>>> Henrik, can you comment on the documentation patches? You wrote the
>>>>>> patch, so you hopefully know what's going on :).
>>>
>>> I wasn't copied in on the conversation, but they seem fairly well
>>> commented on already.
>>
>> It's still not clear to me what the definitions are. It seems it won't
>> be clear until either you or Dmitry give your own definitions in an
>> explicit manner (something that could be copied into the formal
>> documentation). Please help me out :).
>>
> 
> OK, so how about this:
> 
> INPUT_PROP_DIRECT:
> 
> This property idicates that device coordinates can be directly mapped to
> screen coordinates (not taking into account trivial transformations,
> such as scaling, flipping and rotating). Non-direct input devices
> require non-trivial transformation, such as absolute to relative
> transformation for touchpads. Typical direct input devices:
> touchscreens, drawing tablets; non-direct devices: touchpads, mice.
> 
> INPUT_PROP_POINTER:
> 
> This property indicates that the device is not transposed on the screen
> and thus requires use of an on-screen pointer to trace user's movements.
> Typical pointer devices: touchpads, tablets, mice; non-pointer device:
> touchscreen.
> 
> How does this sound?

These definitions sound fine to me. We also need definitions of what it
means when a bit is set versus when it is not set. Does an unset bit
mean "unknown"? As stated before, I don't like that definition because:

* It means we can never get away from device type heuristics in user-space.
* There's no negative version of the properties. For example, there's no
way to say "this device is indirect" because it looks the same as "unknown".

Imagine a tablet driver only has INPUT_PROP_DIRECT set. According to the
"unknown" definition, it's ok to leave INPUT_PROP_POINTER as unset. But
then userspace will end up treating it like a touchscreen instead of a
tablet.

If you are unwilling to backport property bits to stable kernels, then I
don't think we have any other choice than to leave the definition as
"unset bits are unknown", but it clearly puts userspace in a bind.
Because the evdev event codes are clear (BTN_TOUCH means touchscreen,
BTN_TOOL_FINGER means touchpad) and these property bits are not, I doubt
userspace will ever rely on the direct and pointer property bits.

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Henrik Rydberg]

> Imagine a tablet driver only has INPUT_PROP_DIRECT set. According to the
> "unknown" definition, it's ok to leave INPUT_PROP_POINTER as unset. But
> then userspace will end up treating it like a touchscreen instead of a
> tablet.

INPUT_PROP_DIRECT and INPUT_PROP_POINTER go together, remember? Thus,
there is no problem using the input properties to determine the
(touchscreen, touchpad, tablet) types.

> If you are unwilling to backport property bits to stable kernels, then I
> don't think we have any other choice than to leave the definition as
> "unset bits are unknown", but it clearly puts userspace in a bind.
> Because the evdev event codes are clear (BTN_TOUCH means touchscreen,
> BTN_TOOL_FINGER means touchpad) and these property bits are not, I doubt
> userspace will ever rely on the direct and pointer property bits.

BUTTONPAD

If set, treat as button pad. If not set and bcm5974, look at result of
older method. Else, treat as not button pad.

SEMIMT

If set, treat as semimt device. If not set, treat as not semimt
device.

There, all four types are now fully defined and backwards compatible.

Henrik

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Chase Douglas]

On 01/17/2012 07:57 PM, Henrik Rydberg wrote:
>> Imagine a tablet driver only has INPUT_PROP_DIRECT set. According to the
>> "unknown" definition, it's ok to leave INPUT_PROP_POINTER as unset. But
>> then userspace will end up treating it like a touchscreen instead of a
>> tablet.
> 
> INPUT_PROP_DIRECT and INPUT_PROP_POINTER go together, remember? Thus,
> there is no problem using the input properties to determine the
> (touchscreen, touchpad, tablet) types.

Sorry, I forgot. Which means this needs to be documented too :).

>> If you are unwilling to backport property bits to stable kernels, then I
>> don't think we have any other choice than to leave the definition as
>> "unset bits are unknown", but it clearly puts userspace in a bind.
>> Because the evdev event codes are clear (BTN_TOUCH means touchscreen,
>> BTN_TOOL_FINGER means touchpad) and these property bits are not, I doubt
>> userspace will ever rely on the direct and pointer property bits.
> 
> BUTTONPAD
> 
> If set, treat as button pad. If not set and bcm5974, look at result of
> older method. Else, treat as not button pad.
> 
> SEMIMT
> 
> If set, treat as semimt device. If not set, treat as not semimt
> device.
> 
> There, all four types are now fully defined and backwards compatible.

These two are more straightforward. We can easily handle these
properties as "unknown" without breaking things. It's the other bits
that are problematic.

-- Chase

Re: [PATCH v3] bcm5974: Set BUTTONPAD property

[Dmitry Torokhov]

On Tue, Jan 17, 2012 at 07:25:42PM +0100, Chase Douglas wrote:
> On 01/17/2012 07:06 PM, Dmitry Torokhov wrote:
> > On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:
> >> On 01/12/2012 01:22 AM, Henrik Rydberg wrote:
> >>>> Here's what I believe the meanings should be:
> >>>>
> >>>> Touchpad: pointer, !direct
> >>>> Touchscreen: !pointer, direct
> >>>> Drawing tablet: pointer, direct
> >>>> Magic mouse-like devices: !pointer, !direct
> >>>
> >>> Yes, this is what everyone is saying, except !pointer && !direct means
> >>> "default" or "figure it out some other way".
> >>>
> >>>> However, there is a further problem in that we can't easily support
> >>>> multiple tools with different behavior on the same evdev device. What
> >>>> would you say a bamboo touch+pen is, which I believe is used as an
> >>>> indirect device for touch but a direct device for tools. Thus, in the
> >>>> thread I linked from back in September, Henrik and I agreed that direct
> >>>> should only apply when the tool is touch, and pointer should apply for
> >>>> all other tools. This would result in the following:
> >>>
> >>> To try to move back to a sane track, try this, where the word "apply"
> >>> in the previous paragraph has been changed to "care" instead:
> >>
> >> I am still having trouble understanding what you are saying. If I
> >> literally try to insert "care" into the paragraph, I am confused because
> >> it's not quite correct grammar. I'm really trying to understand though.
> >> Also, maybe a better term than "don't care" is "not applicable"?
> >>
> >> It would help me most if you could explicitly provide your own
> >> definition of the properties.
> >>
> >>>> Touchpad: !pointer, !direct
> >>>
> >>> pointer && !direct, since pointer is "dont care".
> >>
> >> Here you say !direct if "don't care".
> >>
> >>>> Touchscreen: !pointer, direct
> >>>
> >>> Yes, !pointer && direct.
> >>>
> >>>> Drawing tablet (no touch): pointer, !direct
> >>>
> >>> pointer && direct, but the tool is not touch, so direct is "dont care".
> >>
> >> Here you say direct if "don't care".
> >>
> >> Why the difference?
> >>
> >>>> Pen+touch tablet: pointer, direct
> >>>
> >>> Yes, pointer && direct
> >>>
> >>>> Magic mouse-like devices: !pointer, !direct
> >>>
> >>> Both pointer and direct are "dont care", and the device needs to be
> >>> detected some other way. If there ever will be a special driver for
> >>> magic-mouse-like devices, using both relative pointer and touch data,
> >>> it will make sense to add a special property for such devices.
> >>
> >> Right now we are missing a property for a magic-mouse like device. It's
> >> valid to have neither direct nor pointer set from kernels 2.6.38 through
> >> 3.2 (at least).
> >>
> >>> Hopefully the above is showing clearly that what was "documented" in
> >>> the threads enclosing the protocol patches still holds, and that there
> >>> is no use to dwell on it further.
> >>>
> >>>> The properties weren't documented when they were merged, and they
> >>>> obviously aren't clear. However, if either table above is correct, then
> >>>> we can't assume that !pointer && !direct means "unknown".
> >>>
> >>> If all devices fell in the pointer or direct or both categories, we
> >>> could. If not all devices do, the problem is rather that some property
> >>> bits are missing (or excluded) from the description.
> >>
> >> Given my last statement above, we have a problem because previously
> >> released kernels are reporting the magic mouse correctly, and yet we
> >> still can't distinguish it from another device that merely does not have
> >> the property bits set. This is the crux of the issue as I see it. We
> >> cannot differentiate between "unknown" and a specific type of device
> >> given the interfaces from 2.6.38 through 3.2.
> >>
> >>>> There is a way to fix this in a backwards compatible way: add a new
> >>>> property bit called something like "PROPERTIES_AVAILABLE". If any bits
> >>>> are set, then it implies that the properties are available (which covers
> >>>> older kernels). If no bits are set, then the properties are unknown.
> >>>> What do you think?
> >>>
> >>> It is rather the special properties of the magic mouse that are
> >>> missing. All types of devices do not _have_ to use properties; most
> >>> types can be figured out by other means.
> >>>
> >>> Saying "prop == 0" is equivalent to "figure out some other way" makes
> >>> sense, but it is also sensible to say "(prop & some_subclass_of_bits)
> >>> == 0", since some properties are bound to describe totally different
> >>> things. This is what we did with "!direct && !pointer".
> >>
> >> This may work, but we need to document the classes. The next time any
> >> properties are added the documentation must be included :).
> >>
> >>>>> The same is applicable to other properties as well. If device is telling
> >>>>> you that it is a "buttonpad" you can trust it, but if it does not you
> >>>>> need to decide for yourself how to treat it.
> >>>
> >>> Yes, and this will always be true. Old devices or systems that become
> >>> used in new ways cannot always adapt to a "if property not present
> >>> then dont use that way" policy.
> >>>
> >>>> No, in kernels previous to 2.6.38 it's clearly unknown. My problem is
> >>>> that I believe there was no way to determine unknown properties. If
> >>>> unknown properties is equivalent to magic-mouse like devices, then we're
> >>>> going to treat a lot of devices wrong. Or, we have to use heuristics to
> >>>> determine what a device is, like no properties and MT and REL_{X,Y} ==
> >>>> magic-mouse like. Properties was supposed to resolve this once and for
> >>>> all, so we didn't need heuristics.
> >>>
> >>> Properties were added to be able to distinguish usecases that could
> >>> not be distinguished at all before. It was never meant to replace
> >>> everything else.
> >>
> >> Why shouldn't we use it for that? The code in evdev for determining the
> >> type of device is just a big hack. We'll obviously need it for a while
> >> since we don't have all drivers with all necessary properties set, but
> >> it seems a waste to have the interface and not fully use it.
> >>
> >>>>>> Henrik, can you comment on the documentation patches? You wrote the
> >>>>>> patch, so you hopefully know what's going on :).
> >>>
> >>> I wasn't copied in on the conversation, but they seem fairly well
> >>> commented on already.
> >>
> >> It's still not clear to me what the definitions are. It seems it won't
> >> be clear until either you or Dmitry give your own definitions in an
> >> explicit manner (something that could be copied into the formal
> >> documentation). Please help me out :).
> >>
> > 
> > OK, so how about this:
> > 
> > INPUT_PROP_DIRECT:
> > 
> > This property idicates that device coordinates can be directly mapped to
> > screen coordinates (not taking into account trivial transformations,
> > such as scaling, flipping and rotating). Non-direct input devices
> > require non-trivial transformation, such as absolute to relative
> > transformation for touchpads. Typical direct input devices:
> > touchscreens, drawing tablets; non-direct devices: touchpads, mice.
> > 
> > INPUT_PROP_POINTER:
> > 
> > This property indicates that the device is not transposed on the screen
> > and thus requires use of an on-screen pointer to trace user's movements.
> > Typical pointer devices: touchpads, tablets, mice; non-pointer device:
> > touchscreen.
> > 
> > How does this sound?
> 
> These definitions sound fine to me. We also need definitions of what it
> means when a bit is set versus when it is not set. Does an unset bit
> mean "unknown"? As stated before, I don't like that definition because:
> 
> * It means we can never get away from device type heuristics in user-space.
> * There's no negative version of the properties. For example, there's no
> way to say "this device is indirect" because it looks the same as "unknown".
> 

However treating unset as negative will not allow us introducing new
properties without doing mass-updates of all in-kernel (and out of tree)
drivers.

> Imagine a tablet driver only has INPUT_PROP_DIRECT set. According to the
> "unknown" definition, it's ok to leave INPUT_PROP_POINTER as unset. But
> then userspace will end up treating it like a touchscreen instead of a
> tablet.

That would be a not too smart on part of tablet driver, as these 2
properties were designed to work in tandem.

> 
> If you are unwilling to backport property bits to stable kernels, then I
> don't think we have any other choice than to leave the definition as
> "unset bits are unknown", but it clearly puts userspace in a bind.
> Because the evdev event codes are clear (BTN_TOUCH means touchscreen,
> BTN_TOOL_FINGER means touchpad) and these property bits are not, I doubt
> userspace will ever rely on the direct and pointer property bits.
> 

Right, since we can not commit that we'll never add more properties and
you have to support both newer and older kernels there will always be a
certain level of heuristic involved.

Thanks.

-- 
Dmitry