On Mon, Jul 23, 2012 at 12:02 AM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Fri, Jul 20, 2012 at 09:53:10AM -0700, Jason Gerecke wrote: >> On Fri, Jul 20, 2012 at 9:04 AM, Olivier Fourdan <ofour...@redhat.com> wrote: >> > >> > 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 see two halves to this: equipping the libwacom database with >> geometry information and passing that information along through the >> libwacom API. The xkb_layout approach sounds like a good fit for the >> former, but I don't understand the problem space well enough to say if >> it'd be a good fit for the latter. You're in a better position to make >> that decision than I am :) My main point is just that clients can't >> rely on a list representation if they care about where buttons are >> physically. > >> >> > 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). >> > >> Exactly what I was thinking as well. >> >> > 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. >> > >> As much as I like the idea of out-of-order lists (as its stands now, >> the lists are useless since they don't tell you anything 'nbuttons' >> doesn't) > > IMO what the list should tell you is the buttons available. see the Bamboos > - we have 4 buttons, but those buttons aren't ABCD but ABEF (i.e. with holes > in between). other than that, I think we agree on everything else anyway? > That's another possibility, and the one that would take the least work to implement (libwacom letter = 'A' + default X11 button number - 1). Bastien was against the idea (as am I to a degree) since those holes are just artifacts of the X11 numbering scheme and don't really have anything to do with the underlying hardware. Getting rid of the holes isn't terribly hard (its already working in the branch I mentioned earlier) so I don't see much use in having them around.
Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. >> I don't know how much value they add to the API. There are a >> number of tablets that have linear button layouts which could be >> reasonably used without ever needing to look at the actual geometry, >> but there are just as many which have non-linear layouts for which >> checking the geometry is almost a requirement. If you want to add that >> functionality in I have no problems with it, but users of that >> function should understand that it may not capture the subtleties of >> the tablet's actual 2D layout. >> >> > >> >> 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 >> I was referring to having the driver link against libwacom.so and call >> (to-be-written) functions that would let us find out which "mouse" >> buttons are on the tablet. I'm on the fence about this myself, but is >> the only really reasonable solution I see other than hardcoding quirks >> in the driver. > > I'd love to have the driver use libwacom for model detection as well. I had > a go at this on a plane in the early stages of libwacom but it proved > complicated. ideally, we'll only have one* location for model numbers, etc > only. > > Cheers, > Peter > > * well, two, the kernel won't be using libwacom anytime soon :) ------------------------------------------------------------------------------ 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
