On Wed, Jun 6, 2012 at 6:00 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > 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 I actually made patches to rework the exposed mapping which apply on top of my "Remove raw button code from xf86-input-wacom", but withheld them because of the shuffle pains. Tweaking them to add a new property instead of remapping the existing one is an interesting idea.
First though, I need to find somebody with the time to test that patch set under the latest GNOME. Its a little too invasive for me to feel comfortable merging with just my own poking and prodding. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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
