On Wed, Jun 6, 2012 at 11:30 AM, Jason Gerecke <killert...@gmail.com> 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. >
Kernel side for Bamboo driver seems reasonable on this. Its declaring a left button, right button, a forward button, and a back button. Other similar tables are reporting buttons 0,1,2,3 or 1,2,3,4 (especially if they do not have touch support). I think long term all 3 of those choices are going to be valid kernel choices. Also, I think its reasonable X input driver behavior that in all 3 cases it has 2 of the buttons as left and right click by default and 2 are back/forward by default. I'd be scratching my head if by default 2 buttons were for mouse scroll. So I don't think I'd change the default mapping their either. So to me the really on reasonable choice left is to address the indexing issue you point out. I personally think we are safe to do this change at this time. We have been so buggy in this area for xsetwacom button maps, X properties button mappings, and xinput set-button-map that I bet if we review every xf86-input-wacom release (not git) for last 3 years, every single release had a different behavior for button mappings in xsetwacom vs. properties vs xinput. Chris ------------------------------------------------------------------------------ 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
