Re: [PATCH v3] bcm5974: Set BUTTONPAD property

On Tue, Jan 17, 2012 at 11:21 AM, Dmitry Torokhov
[off-list ref] wrote:

On Tue, Jan 17, 2012 at 10:24:25AM -0800, Jason Gerecke wrote:

quoted

On Tue, Jan 17, 2012 at 10:06 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Thu, Jan 12, 2012 at 11:19:40AM +0100, Chase Douglas wrote:

quoted

On 01/12/2012 01:22 AM, Henrik Rydberg wrote:

quoted

quoted

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

quoted

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.

quoted

quoted

Touchpad: !pointer, !direct

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

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

quoted

quoted

Touchscreen: !pointer, direct

Yes, !pointer && direct.

quoted

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?

quoted

quoted

Pen+touch tablet: pointer, direct

Yes, pointer && direct

quoted

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

quoted

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.

quoted

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.

quoted

quoted

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

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.