On Tue, Nov 23, 2010 at 10:55:56PM -0600, Chris Bagwell wrote: > 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 BTN_TOUCH means something (we do not specify what) touches working surface. > 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. In Synaptics BTN_TOUCH was used for legacy clients not understanding BTN_TOOL_FINGER/ABS_PRESSURE (read: mousedev) and had arbitrary pressure thresholds. > > 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. And the expected action when you actually using the tool. > > 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. Huh? I want to reiterate that I do not see any difference between proposed BTN_TOOL_TOUCH and existing BTN_TOOL_FINGER - both indicate that a finger either touches or is in proximity of the working surface. The only difference between tablet, touchcsreen and touchpad is how we react to the same data (i.e. relative/absolute movement; pointer tracking or not, etc). > > 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 -- 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
