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