On Tue, Jan 17, 2012 at 11:21 AM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxx> 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.
--
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
