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