On Fri, Nov 26, 2010 at 04:48:32PM -0600, Chris Bagwell wrote: > On Wed, Nov 24, 2010 at 7:31 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > On Wed, Nov 24, 2010 at 04:55:32PM -0600, Chris Bagwell wrote: > >> > > >> >> > >> >> 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. > >> > >> Agree. Its important point that happens to be in line with why I like > >> BTN_TOOL_TOUCH concept. More below. > >> > >> > > >> >> > >> >> 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). > >> > > >> > >> Let me give an example of drawing program and worst case where all > >> major device classes are merged in single input device. The input has > >> pen/eraser/touchscreen/touchpad/mouse and user expected behavior. > > > > This is a faulty assumption as I do not see how you could come across > > such a beast. Touchscreens, tablets and touchpads are different devices > > and require different handling: > > > > - touchpads require conversion from absolute to relative movement, and > > movement causes on-screen pointer movement; > > > > - tablets (unless we are talking about wacom mouse tool which is > > special) operate in absolute coordinates but still require on-screen > > pointer movement; > > > > - touchscreens work in absolute coordinates and do not require pointer > > tracking as your tool (finger, stylus) serves as a pointer. > > > > While I can see manufacturers packaging let's say touchscreen and a > > touchpad into a single chip solution we should not try to jam them all > > together into single logical input device but rather split them > > accordingly (based on work surface for example). > > > > Given that you won't ever have to deal with something that is > > touchscreen, tabled and touchpad at once the rest of your example is not > > interesting. > > Hmmm. Let me start of easy part. Having touchpad+touchscreen on > single input doesn't make sense even though it was in my example. I > agree with that. The rest are valid examples that exist today. > > touchscreen/wacom_w8001.c is example of serial device (1 input device > to user) that has tablet features (BTN_TOOL_PEN and BTN_TOOL_FINGER) > and touchscreen touch. Today its playing some games and not sending > BTN_TOOL_FINGER events to prevent device from being directed to > xf86-input-synaptics. This can be fixed after thread is finalized. *nod* > > We have Wacom Bamboo's (tablet/wacom_wac.c) that have tablet features > (BTN_TOOL_PEN and BTN_TOOL_ERASER) on 1 input device and touchpad > feature (BTN_TOOL_FINGER) on another input device. On another thread, > we talked about merging these into 1 logical input device because it > eases filtering those BTN_TOOL_FINGER events while user is using > stylus and resting hand on tablet. Is the Bamboo intended to be used as a big touchpad? Or is it still the tablet that is touch-sensitive? I'd say the 2nd so we should not say that it has "touchpad feature on the 2nd device". While userspace (and parts of kernel space) use BTN_TOOL_FINGER to decide that the device should be treated as touchpad is is simply heuristic. > Also, Wacom Tablet PC's (tablet/wacom_wac.c) and hid-ntrig.c have > tablet (BTN_TOOL_PEN and BTN_TOOL_ERASER) and touchscreen (BTN_TOUCH). > These could be combined and the Wacom Tablet PC's events should be > modified to look closer to hid-ntrig.c... although hid-ntrig.c also > isn't sending BTN_TOOL_FINGER for xf86-input-synaptics reasons. I see... > . > > > >> All tools except mouse share ABS_X/Y/PRESSURE and BTN_TOUCH. Mouse > >> uses REL_* events. > >> > >> * BTN_TOOL_PEN - Small point pen with black ink. Draws upon BTN_TOUCH > >> or ABS_PRESSURE. > >> * BTN_TOOL_ERASER - Large point pen with white ink (simple erase > >> concept). Draws upon BTN_TOUCH or ABS_PRESSURE. > >> * BTN_TOOL_TOUCH - Large point pen with black ink. Draws upon > >> BTN_TOUCH or ABS_PRESSURE. > >> * BTN_TOOL_FINGER - Small (maybe) point pen with black ink. Only > >> moves cursor with BTN_TOUCH or ABS_PRESSURE. No drawing unless > >> BTN_RIGHT clicked. > >> * BTN_TOOL_MOUSE - Small (maybe) point pen with black ink. Only moves > >> cursor on REL_ events. No drawing unless BTN_RIGHT clicked. <-- this > >> is existing wacom example. If reports ABS_* then it would probably > >> use BTN_TOOL_FINGER tool even though a mouse puck. > >> > >> Notice how expected behavior of touchscreen is so close to tablet > >> tools. TOUCH is just a complement tablet tool in same way ERASER is > >> complement to PEN. Touchpads are so unique in how they behave that I > >> think they deserve their own tool type. > > > > No, they deserve to be handled differently (as I outlined above) but the > > tool is still the same. It is your finger. If it was a different tool > > that would mean that there could be a device that supports both > > BTN_TOOL_FINGER and BTN_TOOL_TOUCH. Now how would you differentiate > > between them? When use one and when the other (given that it is > > physically the same object touching the device)? > > > > I now see I had flawed outlook because I was stuck on udev and > xf86-input-evdev logic to much. I wanted to send something along with > each tool that said how to treat in terms of historical device > classes. As example, I wanted to say "Use BTN_TOOL_PEN with logic you > used to use for Tablets." and "Use BTN_TOOL_FINGER with logic you used > to use for touchscreens". BTN_TOOL_TOUCH was just way of encoding > that extra info without new interface. > > Thats why I mentioned per-tool a few times. Your examples show its > better to say "use this BTN_TOOL_* in whatever way makes sense with > Touchscreen (or whatever physical attribute of HW is)." > > Both viewpoints come to same answer in the end but yours is best. Its > basically 1 value per input device; as you show below. > > It doesn't quite work if we have combined touchscreen+touchpad but I > agree that case is probably best to break into 2 input devices. I am glad I'm winning you over ;) -- 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
