On Tue, Jan 18, 2011 at 5:29 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > On Tue, Jan 18, 2011 at 6:16 PM, Ping Cheng <pingli...@gmail.com> wrote: >> On Tue, Jan 18, 2011 at 2:02 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >>> What device are you working with that you want this change? I ask >>> because I suspect its easier to add DOUBLETAP to that driver instead >>> of supporting a multi-touch device without DOUBLETAP inside >>> xf86-input-wacom. >>> >>> if you make use of input_mt_report_pointer_emulation() in 2.6.37 you >>> get this support for free as long as you correctly >>> __set_bit(BTN_TOOL_DOUBLETAP) up front for 2FG devices. >> >> I know that one. I didn't want to report BTN_TOOL_DOUBLETAP since I >> wanted to keep pointer_emulation as a pure single touch backward >> support for MT enabled devices. Plus > > Is there driver your interested in? Its difficult to talk in abstract.
I'm moving the existing _TAP_ based USB TPC to _MT_ based format. That's why I don't want to reuse _TAP_ again. >>> And the plus side is that this device then has 90% change of working >>> out of the box for both touch and pen's with xf86-input-evdev; at >>> least enough to pull up a terminal and get config files set up >>> correctly. >> >> I don't feel we want to rely on another driver for Wacom devices >> unless we plan to merge the two drivers. With the current >> xf86-input-wacom, pointer_emulation is unnecessary. If the user >> happens to use an old xf86-input-wacom and new kernel driver, >> BTN_TOOL_DOUBLETAP would only make things worse. >> > > I don't think thats something we need to worry about. Because of how > much we rely on tablet_id for touch devices, any new MT devices > historically requires a new xf86-input-wacom. So user is used to being > forced to upgrade. We are now generically checking for MT support and > in these same versions we also handle DOUBLETAP just fine. > >> I am thinking to introduce ABS_MT_SLOT to the picture. What do you think? >> > > The problem with ABS_MT_SLOT is it to short sighted. It works for > today's Bamboo and maybe first draft of wacom_w801 but problably it > will break with wacom_w801 shortly there after. ABS_MT_SLOT doesn't > tell you wants in those slots and they are not reserved specifically > to touches. > > Thats why ABS_MT_TOOL_TYPE exists... So slot 0 could be a pen and slot > 1 could be a touch. Or who knows what combination. Its impossible to > know long term whats coming in slots without looking at something > else. With MT_SLOT, we know they are really sending more than one set of data. With _TAP_, there could be only one set of data sending from the kernel. > Today the only way to know is by implying it from BTN_TOOL_*'s. So > BTN_TOOL_DOUBLETAP is only way to truly know two slots are meant for > concurrent touches. Thats a pretty firm kernel definition right now > (but who knows what tomorrow holds). > > If you want to do some short term work arounds and really don't want > your kernel driver to send send DOUBLETAP's, I suggest exploring this. > In usbProbeKeys(), you can check for ABS_MT_SLOT since its already > querying abs[] and then add a fake DOUBLETAP to the keys so that its > treated correctly. That will buy us some time until kernel MT > ioctl()'s and best practices firm up. sigh. I know. _TAP_ has bought me enough time. I don't have time to wait for MT ioctl to be available broadly. Tablet PC is not a touch pad. Abusing _TAP_ again in another way isn't something I like.... At least, I hope we can be as consistent as possible within our driver (don't mention BTN_TOOL_FINGER, please ;). Ping > But really all the current MT touch devices in kernel are sending > DOUBLETAPs as well to give userland the hints on slots so I really > think we should be addressing this at kernel side. There is really > not much reason to not do this. ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
