On Tue, Nov 23, 2010 at 8:52 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Tue, Nov 23, 2010 at 02:40:00PM -0800, Ping Cheng wrote: >> On Tue, Nov 23, 2010 at 2:30 PM, Dmitry Torokhov >> <dmitry.torokhov@xxxxxxxxx> wrote: >> > On Tue, Nov 23, 2010 at 12:48:07PM -0800, Ping Cheng wrote: >> >> Hi all, >> >> >> >> I am not going to write a patch for this request before I get the >> >> permission for the new tool type. It affects all touch screen devices >> >> (under drivers/input/touchscreen) that support both pen and touch. >> >> >> >> Right now, in the user land, BTN_TOUCH is used to indicate a single >> >> touch events. BTN_TOUCH and !BTN_TOOL_PEN >> >> (http://udev.sourcearchive.com/documentation/161-1/input__id_8c-source.html) >> >> are used to determine if the device is a touch screen device or not a >> >> pen. With both pen and touch on the same logical port (serial touch >> >> screen with pen and touch enabled, refer to wacom_w8001.c), BTN_TOUCH >> >> and !BTN_TOOL_PEN will always be false, which indicates a >> >> non-touchscreen device. That is wrong. >> >> >> >> Unless we have other means to tell the user land a device is a >> >> touchscreen, BTN_TOUCH with !BTN_TOOL_PEN won't do the job for us. >> >> >> >> I've already had a value for the new type: >> >> >> >> +#define BTN_TOOL_TOUCH 0x149 >> >> >> >> This new type resolves the confusion we had for the existing serial >> >> pen and touch enabled touchscreen devices. Considering we are merging >> >> the two logical ports for USB devices, the new type is required for >> >> the future USB touchscreen support as well. >> > >> > How is BTN_TOOL_TOUCH is different from BTN_TOOL_FINGER? >> >> Good question. >> >> BTN_TOOL_FINGER is used for touchpad or trackpad, or whichever term >> that works for you. It indicates a relative cursor movement. The touch >> screen needs to translate the (x,y) events into absolute movement. >> That's why none of those touchscreen drivers use BTN_TOOL_FINGER so >> far. >> > > BTN_TOOL_FINGER and the new BTN_TOOL_TOUCH convey the same data to the > userspace, namely that there is a finger on the owrking surface, as > oopsed to pen, mouse, lens or something else. It does not dictate how > exactly the data should be used, although right now we have heuristic to > decide the class of the device we are dealing with. I've a small clarification for readers that might not be aware. For BTN_TOOL_FINGER, its still used to mean a kinda of "in proximity of surface" and BTN_TOUCH is used when actually touching touchpad. For touchpad, those two things probably should follow each other... but as an example the synaptics driver only sets BTN_TOOL_FINGER immediately but BTN_TOUCH when pressure is over some threshold. So there is a time period when they do not match. Touchscreens today can only send BTN_TOUCH event... which is a little odd but works. > > It looks like that we getting into fuzzy area where it is hard to > classify the device solely by its capabilities. Maybe it is time we > revisited the topic of adding "flags" or "hint" to the device to > describe it's main purpose(s). > I think the proposed BTN_TOOL_TOUCH is in the same spirit of most other BTN_TOOL_*'s. We seem comfortable that userland wants to know difference between pen and eraser tools. The only thing unique they bring to table is a type of resolution (fine tip vs. blunt tip) as well as an indication of tool switching. I'm not sure we needed 8 tools to express resolution concepts or tool switching concepts but we do have them. To me, the BTN_TOOL_TOUCH fits in just fine with this. It says its low resolution like both BTN_TOOL_ERASER and BTN_TOOL_FINGER say to different degrees. But it also says that, unlike BTN_TOOL_FINGER, it has touchscreen visibility going for it to replace missing in-proximity concept and effectively increase its resolution... and so you do not need to revert to relative emulation. As the udev input-id shows, I think we have pretty firm class of devices and it seems touchscreens are only ones not cleanly defined. It does show something is clearly missing from kernel side. Mice - BTN_TOOL_MOUSE or anything that only has REL_* events. Touchpads - BTN_TOOL_FINGER Tablets - BTN_TOOL_PEN Touchscreens - fall threw case if you don't find above. it seems BTN_TOOL_TOUCH(screen) is probably only needed/missing value. Are there other major classes that are not just combo devices? I guess my point is it looks like we will not need to keep extending BTN_TOOL_ for device classes over time. Adding a new BTN_TOOL_TOUCH sure is less disrupted to userland as we start to expand to support combo pen+touch devices. If we took the flags/hint approach then BTN_TOOL_FINGER becomes pretty meaningless for both touchpads and touchscreens. I do also want to discuss if its OK to send BTN_TOOL_FINGER=1 and BTN_TOOL_DOUBLETAP/TRIPLETAP=1 at same time and also proper way to send DOUBLETAP/TRIPLETAP on touchscreens since they can't use BTN_TOOL_FINGER today... but I'll save that for a new thread. :-) Chris -- 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
