Hi Jason, [Adding Peter to the discussion as well]
Jason Gerecke said the following on 07/19/2012 07:08 PM: > I've been going over the possible ways to deal with button mapping, > and I've come to the conclusion that driver and libwacom need to be > modified in tandem. I can work around most of the problems in the > driver (see > https://github.com/jigpu/xf86-input-wacom/tree/fix/sane-button-numbering > for my work-in-progress), but there are two that can't be handled by > the driver alone: button ordering and ambiguous physical location. > > Button ordering is the problem that buttons aren't necessarily in the > order you expect them to be in. An obvious example of this is the > Intuos4: button 'A' is the modeswitch button and physically located > between buttons 'E' and 'F'. This is exactly the problem I have for the OSD window. > We could try to change the kernel driver > to work around this, but the change wouldn't be backwards-compatible > -- buttons would suddenly become renumbered without apparent reason. Yes, agreed. > I think it'd be better if libwacom provided a way for clients to get the > tablet geometry and use that to discover the A-Z identifier associated > with specific buttons. Blindly using the A-Z identifier without first > querying geometry is asking for trouble given the many different ways > we layout our buttons. By tablet geometry you mean the "xkb_layout" (or similar) description approach we discussed before? I thought we would list the button A-Z as we do now (we still need to name those and we need to remain compatible with what we have now), and add to libwacom the API and data per device to get the extra info about the actual geometry so that a client can tell where the button are located (thus making the actual order less relevant, at least for a graphical representation of the device). Otherwise, if we want to list the button in any meaningful order, being from top to bottom, left to right, or any other order agreed on, we either need the driver to list them in expected order or expose the order they're listed in libwacom database so taht if listed as B,C,D,E,A,F,G,HI we can get that list in this order. But I agree that would necessarily be a simplified view of the actual geometry (would be like using 1 coordinate - a list- to represent a 2D image) and the actual geometry is what we should be aiming at. > Ambiguous physical location is the problem that we have a few tablets > (e.g. Graphire4, Bamboo Fun) for which the driver doesn't have enough > information to accurately deduce which BTN_* events should be > associated with the pad. This occurs when the tablet has both pad and > puck tools, but no "generic" buttons. In this case its known that some > of the "mouse" buttons must be associated with the pad, but unknown > which ones in particular. Again, this might be fixable in the kernel > driver, but would break the button's semantics. I think a better idea > might be to link the Xorg driver against libwacom and then teach > libwacom about the difference between "generic" and "mouse" buttons. > The driver could then get a definitive list of mouse buttons that > belong on the pad device, allowing it to build an appropriate table. Not sure what you mean by linking the X11 driver to the libwacom database, I don't think the X11 driver should rely on libwacom, imho, but maybe I am mistaken. Cheers, Olivier ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
