On Wed, Jun 06, 2012 at 05:36:11PM +0100, Bastien Nocera wrote: > On Wed, 2012-06-06 at 09:30 -0700, Jason Gerecke wrote: > > On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera <had...@hadess.net> wrote: > > > On Tue, 2012-05-29 at 15:28 +1000, Peter Hutterer wrote: > > >> On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote: > > >> > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> > > >> > > >> yikes. after running a few more tests I realised that this isn't actually > > >> enough. the bamboos define buttons 1, 3, 8 and 9 and we cannot currently > > >> handle non-continuous button ranges, neither in libwacom nor the gnome > > >> stack. So button 9 is unknown, as we expect buttons 1, 2, 3 and 8. > > >> > > >> So the below patch only solves the problem partially. > > >> > > >> as for solutions: I think claiming the bamboo has 5 buttons would be a > > >> good > > >> enough hack for now until we add non-continuous button range support. > > >> Opinions? > > > > > > Make the driver fix it? > > > > > Can you expand on that a little more? > > > > The long-term solution that springs first to my mind (because its been > > *on* my mind for months) would be to change how the "Wacom Button > > Actions" property is indexed. Instead of having it be indexed by the > > X11 button number I think it should be indexed by the kernel button > > number (i.e. identically to libwacom). The problem with my grand idea > > is that it breaks anything which reads/writes the properties directly. > > Not breaking users existing configs is pretty high on the priority > > list, so this plan is a non-starter without hashing out some kind of > > migration plan to keep the GNOME and KDE panels working. > > > > If you've got an idea of your own though, I'm all ears. > > We should figure out what the destination is before trying to figure out > how to get there ;)
imo best is to not assume continuos button ranges in libwacom and its users. we already need to specific each button and it's location, so the client should not just assume that there are 5 buttons but instead know that there are buttons A, D, E and F on the tablet. num_buttons becomes max_button, the rest is up to the client. for all we know we may have a future tablet where the large version has buttons A, B, C, D, but the small version only has A and D. we're stuck with continuous button ranges in the X driver and while we can shuffle them around it'll be painful as Jason pointed out. Jason: if you had too much spare time recently, you could add a new property that contains the physically-aligned data and provide transparent mapping inside the driver. it'll be entertaining :) Cheers, Peter ------------------------------------------------------------------------------ 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