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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
