Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Wed, Jun 06, 2012 at 06:48:02PM -0700, Jason Gerecke wrote: > On Wed, Jun 6, 2012 at 6:00 PM, Peter Hutterer > 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 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 > >> > >> > >> > >> 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. the problem here is that property aliasing is not that simple and could get quite messy. this property is both easier and harder because you can re-use the properties that contain the actual actions. but making sure they're set correctly is a bit of a pain. plus, there's the chance of sending a client into a loop when it updates property 1, gets a notify for property 2, then updates that back, etc. not realistic in this case, but something to be aware of. > 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. fwiw, the gnome code doesn't actually fill in the property, it grabs the button and then sends the event through XTest. so changing the properties shouldn't affect gnome at all. 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Wed, Jun 6, 2012 at 6:00 PM, Peter Hutterer 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 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 >> > >> >> > >> 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
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 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 > > >> > > >> 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Wed, Jun 6, 2012 at 11:30 AM, Jason Gerecke wrote: > On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera 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 >>> >>> 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Wed, 2012-06-06 at 09:30 -0700, Jason Gerecke wrote: > On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera 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 > >> > >> 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 ;) -- 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera 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 >> >> 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. 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
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 > > 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? -- 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
Hey Peter, Peter Hutterer said the following on 06/05/2012 08:03 AM: > [...] > does gnome take the buttons in order? does it work if you redefine > it as Left=A;E;D;C No, unfortunately not, it doesn't and I am not sure it could, as I don't see any API in libwacom to retrieve the list of buttons in any particular order. So what GNOME tablet settings applet does is to loop through all the possible buttons < libwacom_get_num_buttons() and for each one check if libwacom_get_button_flag() & WACOM_BUTTON_DIRECTION and use it if true. So the actual order specified in the tablet definition is not used. I believe libwacom API should give access to such information because not only that would help with this particular issue with Bamboo devices, but that would also help with something else I have in mind for the GNOME tablet settings. Right now, the UI lists all the buttons but there is no easy way for the user to match that with the actual buttons on the tablet so that's not very convenient. To help with this, I was considering some sort of an OSD help screen, which would map a fullscreen window and show the buttons and their current assigned function (or shortcut, for now). But for this to work, GNOME tablet settings would need to have a reliable way to match the buttons and their location on the device and thus the actual order is needed. I'll take a look at this in libwacom, I believe what I am missing is just a way to retrieve a copy of device->buttons[] Cheers, Olviier. -- əɔıʌəp əɯos ɥʇıʍ əɹəɥʍəɯos ɯoɹɟ ʇuəs -- 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Mon, Jun 04, 2012 at 02:29:05PM +0200, Olivier Fourdan wrote: > > Hey Peter, > > Peter Hutterer said the following on 05/29/2012 07:28 AM: > > On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote: > >> Signed-off-by: Peter Hutterer > > 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? > > Indeed, testing with a Wacom Bamboo Fun Pen&Touch 2011 (CTH-470S, aka > "Wacom Bamboo 16FG 4x5", id 056a:00de), the following works for me: > > [Features] > Buttons=5 my first thought was that we should rename this to MaxButtons or similar. but given that the [Buttons] section must define the location of all buttons anyway, this setting is superflous. we can easily calculate this number. > ... > [Buttons] > Left=A;C;D;E > > and GNOME tablet settings "see" all 4 buttons and allow for mapping > them to different key presses. > > However, pressing buttons 1, 2, 3, 4 (as assigned in GNOME wacom > settings in this order) will actually do 1, 4, 3, 2, and if we ever > change (fix) this in the future it may change button assignment in > client apps such as GNOME tablet settings which could confuse users. does gnome take the buttons in order? does it work if you redefine it as Left=A;E;D;C 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
Hey Peter, Peter Hutterer said the following on 05/29/2012 07:28 AM: > On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote: >> Signed-off-by: Peter Hutterer > 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? Indeed, testing with a Wacom Bamboo Fun Pen&Touch 2011 (CTH-470S, aka "Wacom Bamboo 16FG 4x5", id 056a:00de), the following works for me: [Features] Buttons=5 ... [Buttons] Left=A;C;D;E and GNOME tablet settings "see" all 4 buttons and allow for mapping them to different key presses. However, pressing buttons 1, 2, 3, 4 (as assigned in GNOME wacom settings in this order) will actually do 1, 4, 3, 2, and if we ever change (fix) this in the future it may change button assignment in client apps such as GNOME tablet settings which could confuse users. Cheers, Olivier. -- əɔıʌəp əɯos ɥʇıʍ əɹəɥʍəɯos ɯoɹɟ ʇuəs -- 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
Right. Since the 3.6.38 kernel or so the BambooPT button situation has been: physical Button 1BTN_RIGHT X Button 3 physical Button 2BTN_BACK X Button 8 physical Button 3BTN_FORWARDX Button 9 physical Button 4BTN_LEFTX Button 1 -- 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
Re: [Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer 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? Cheers, Peter > --- > data/bamboo-2fg-4x5.tablet | 15 +++ > data/bamboo-2fg-6x8.tablet | 15 +++ > data/bamboo-2fg.tablet | 15 +++ > data/bamboo-craft.tablet | 15 +++ > 4 files changed, 60 insertions(+) > > diff --git a/data/bamboo-2fg-4x5.tablet b/data/bamboo-2fg-4x5.tablet > index 96804bd..249d5a6 100644 > --- a/data/bamboo-2fg-4x5.tablet > +++ b/data/bamboo-2fg-4x5.tablet > @@ -7,6 +7,18 @@ > # stylus with two buttons and eraser; 2FG touch > # Pen active area: 5.8 x 3.62in > # Touch active area: 4.92 x 3.35in > +# > +# Button Map: > +# (A=1, B=2, C=3, ...) > +# > +#*---* > +#| | > +# A | | > +# B |TABLET | > +# C | | > +# D | | > +#| | > +#*---* > > [Device] > Name=Wacom Bamboo 2FG 4x5 > @@ -21,3 +33,6 @@ Reversible=true > Touch=true > Buttons=4 > BuiltIn=false > + > +[Buttons] > +Left=A;B;C;D > diff --git a/data/bamboo-2fg-6x8.tablet b/data/bamboo-2fg-6x8.tablet > index 0f204ea..ee50723 100644 > --- a/data/bamboo-2fg-6x8.tablet > +++ b/data/bamboo-2fg-6x8.tablet > @@ -7,6 +7,18 @@ > # stylus with two buttons and eraser; 2FG touch > # Pen active area: 8.53 x 5.40 in > # Touch active area: 7.48 x 5.12 in > +# > +# Button Map: > +# (A=1, B=2, C=3, ...) > +# > +#*---* > +#| | > +# A | | > +# B |TABLET | > +# C | | > +# D | | > +#| | > +#*---* > > [Device] > Name=Wacom Bamboo 2FG 6x8 > @@ -21,3 +33,6 @@ Reversible=true > Touch=true > Buttons=4 > BuiltIn=false > + > +[Buttons] > +Left=A;B;C;D > diff --git a/data/bamboo-2fg.tablet b/data/bamboo-2fg.tablet > index 6037775..db405e4 100644 > --- a/data/bamboo-2fg.tablet > +++ b/data/bamboo-2fg.tablet > @@ -6,6 +6,18 @@ > # > # no stylus; 2FG touch > # Touch active area: 4.92 x 3.35in > +# > +# Button Map: > +# (A=1, B=2, C=3, ...) > +# > +#*---* > +#| | > +# A | | > +# B |TABLET | > +# C | | > +# D | | > +#| | > +#*---* > > [Device] > Name=Wacom Bamboo 2FG > @@ -20,3 +32,6 @@ Reversible=true > Touch=true > Buttons=4 > BuiltIn=false > + > +[Buttons] > +Left=A;B;C;D > diff --git a/data/bamboo-craft.tablet b/data/bamboo-craft.tablet > index 8dba88c..65b3e45 100644 > --- a/data/bamboo-craft.tablet > +++ b/data/bamboo-craft.tablet > @@ -7,6 +7,18 @@ > # stylus with two buttons and eraser; 2FG touch > # Pen active area: 5.8 x 3.62in > # Touch active area: 4.92 x 3.35in > +# > +# Button Map: > +# (A=1, B=2, C=3, ...) > +# > +#*---* > +#| | > +# A | | > +# B |TABLET | > +# C | | > +# D | | > +#| | > +#*---* > > [Device] > Name=Wacom Bamboo Craft > @@ -21,3 +33,6 @@ Reversible=true > Touch=true > Buttons=4 > BuiltIn=false > + > +[Buttons] > +Left=A;B;C;D > -- > 1.7.10.1 > -- 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
[Linuxwacom-devel] [PATCH libwacom 1/3] data: define button positions for Bamboos
Signed-off-by: Peter Hutterer --- data/bamboo-2fg-4x5.tablet | 15 +++ data/bamboo-2fg-6x8.tablet | 15 +++ data/bamboo-2fg.tablet | 15 +++ data/bamboo-craft.tablet | 15 +++ 4 files changed, 60 insertions(+) diff --git a/data/bamboo-2fg-4x5.tablet b/data/bamboo-2fg-4x5.tablet index 96804bd..249d5a6 100644 --- a/data/bamboo-2fg-4x5.tablet +++ b/data/bamboo-2fg-4x5.tablet @@ -7,6 +7,18 @@ # stylus with two buttons and eraser; 2FG touch # Pen active area: 5.8 x 3.62in # Touch active area: 4.92 x 3.35in +# +# Button Map: +# (A=1, B=2, C=3, ...) +# +#*---* +#| | +# A | | +# B |TABLET | +# C | | +# D | | +#| | +#*---* [Device] Name=Wacom Bamboo 2FG 4x5 @@ -21,3 +33,6 @@ Reversible=true Touch=true Buttons=4 BuiltIn=false + +[Buttons] +Left=A;B;C;D diff --git a/data/bamboo-2fg-6x8.tablet b/data/bamboo-2fg-6x8.tablet index 0f204ea..ee50723 100644 --- a/data/bamboo-2fg-6x8.tablet +++ b/data/bamboo-2fg-6x8.tablet @@ -7,6 +7,18 @@ # stylus with two buttons and eraser; 2FG touch # Pen active area: 8.53 x 5.40 in # Touch active area: 7.48 x 5.12 in +# +# Button Map: +# (A=1, B=2, C=3, ...) +# +#*---* +#| | +# A | | +# B |TABLET | +# C | | +# D | | +#| | +#*---* [Device] Name=Wacom Bamboo 2FG 6x8 @@ -21,3 +33,6 @@ Reversible=true Touch=true Buttons=4 BuiltIn=false + +[Buttons] +Left=A;B;C;D diff --git a/data/bamboo-2fg.tablet b/data/bamboo-2fg.tablet index 6037775..db405e4 100644 --- a/data/bamboo-2fg.tablet +++ b/data/bamboo-2fg.tablet @@ -6,6 +6,18 @@ # # no stylus; 2FG touch # Touch active area: 4.92 x 3.35in +# +# Button Map: +# (A=1, B=2, C=3, ...) +# +#*---* +#| | +# A | | +# B |TABLET | +# C | | +# D | | +#| | +#*---* [Device] Name=Wacom Bamboo 2FG @@ -20,3 +32,6 @@ Reversible=true Touch=true Buttons=4 BuiltIn=false + +[Buttons] +Left=A;B;C;D diff --git a/data/bamboo-craft.tablet b/data/bamboo-craft.tablet index 8dba88c..65b3e45 100644 --- a/data/bamboo-craft.tablet +++ b/data/bamboo-craft.tablet @@ -7,6 +7,18 @@ # stylus with two buttons and eraser; 2FG touch # Pen active area: 5.8 x 3.62in # Touch active area: 4.92 x 3.35in +# +# Button Map: +# (A=1, B=2, C=3, ...) +# +#*---* +#| | +# A | | +# B |TABLET | +# C | | +# D | | +#| | +#*---* [Device] Name=Wacom Bamboo Craft @@ -21,3 +33,6 @@ Reversible=true Touch=true Buttons=4 BuiltIn=false + +[Buttons] +Left=A;B;C;D -- 1.7.10.1 -- 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
