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. 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. 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. . > >> 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. >> >> Your point about only the "how to react" being different between >> touchpad and touchscreen is also true for all tools above. I'm not >> sure why your limiting comment and not including tablet and mice >> tools. We could switch to BTN_TOOL_1/2/3/4 and some sort of per tool >> hint (BTN_TOOL_CAPABILITIES sent with tool events perhaps?) but I'm >> not real excited about work involved in userland for that. >> >> If your still not convinced on BTN_TOOL_TOUCH (I've not really >> mentioned much new info) then can you give rough ideas of what flags >> interface should look like? >> >> For example, should it be sent as BTN_TOOL_CAPABILITIES event for each >> tool change? Or should it be an ioctl() per BTN_TOOL_*? The former >> is good if we think BTN_TOOL_*'s will use tool ID's and two tools may >> have different capabilities. > > No, the hint or flags or type is per device. So you'd do: > > ioctl(fd, EVIOCGDEVTYPE, &type); > > when you notified about a new device and it would return a bitmap of all > that it could be, like INPUT_TYPE_TOUCHSCREEN or INPUT_TYPE_TABLET. And > then you'd know how to deal with that device. Thanks for example. That cleared up some things in my mind on how you see it. Chris > >> >> Once solved for ST, it also needs solution for MT. For slot based MT, >> it may need to be sent as events if we allow tools to float between >> slots. >> > > I do not see how that involves ST vs MT at all. > > -- > 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
