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] Add LED0 and LED1 options for led-controlling buttons
On Wed, Jun 6, 2012 at 8:53 AM, Bastien Nocera wrote: > On Tue, 2012-05-29 at 17:09 -0700, Ping Cheng wrote: >> On Wed, May 23, 2012 at 7:17 PM, Peter Hutterer >> wrote: >> > These two button options specify which button controls which LED bank >> > exposed by the kernel. >> > >> > Signed-off-by: Peter Hutterer >> > --- >> > Notably on the Cintiq, the layout of the banks is inverse to what one >> > expects (0 is right, 1 is left). That can be fixed in the kernel but >> > long-term it's better to rely on a specific flag to tell us. >> >> We may not want to fix it in the kernel. People should not assume 0 is >> for left. All Cintiqs have 0 for right, so far ;). You may mention >> Intuos4. But I4 only has one set of LEDs. >> >> > Not sure about the 24HD here - three buttons that control the leds? is this >> > correct? >> >> Every LED has its own button. > > I would really rather have this fixed in the kernel. We already know > which devices have LEDs, and how many, having them correctly numbered > (or at least in a way that makes sense) in there is what we should do. Well, kernel driver has already reported them. We just need to map those BTN_s to UI properly. linux-input does not distinguish buttons with LEDs from without LEDs. Button events are reported independently from LED changes in kernel. This is true for all LED enabled tablets, no matter LEDs are around a button (I4, I5, and C21UX2), or are embedded in buttons (C24HD). My suggestion to link button and LED together in xf86-input-wacom was rejected last year. That pushed LED control outside of drivers. The benefit for clients is they get the freedom to control LEDs the way they like. However, practically, I think we should provide a set of features in UI that offer users default options to link button(s) to its relevant LEDs even though, in theory, they are independent. Ping -- 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] Add LED0 and LED1 options for led-controlling buttons
On Tue, 2012-05-29 at 17:09 -0700, Ping Cheng wrote: > On Wed, May 23, 2012 at 7:17 PM, Peter Hutterer > wrote: > > These two button options specify which button controls which LED bank > > exposed by the kernel. > > > > Signed-off-by: Peter Hutterer > > --- > > Notably on the Cintiq, the layout of the banks is inverse to what one > > expects (0 is right, 1 is left). That can be fixed in the kernel but > > long-term it's better to rely on a specific flag to tell us. > > We may not want to fix it in the kernel. People should not assume 0 is > for left. All Cintiqs have 0 for right, so far ;). You may mention > Intuos4. But I4 only has one set of LEDs. > > > Not sure about the 24HD here - three buttons that control the leds? is this > > correct? > > Every LED has its own button. I would really rather have this fixed in the kernel. We already know which devices have LEDs, and how many, having them correctly numbered (or at least in a way that makes sense) in there is what we should do. Cheers -- 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: Add button order to libwacom
Bastien Nocera said the following on 06/06/2012 03:02 PM: > On Tue, 2012-06-05 at 15:09 +0200, Olivier Fourdan wrote: >> The libwacom API does not provide any way for client applications to >> get the buttons order as this may differ from the actual button >> definition. >> >> For example, the Bamboo Fun Pen&Touch tablet maps buttons from top to >> bottom (with pad on the left) as A, D, C, B instead of A, B, C, D as >> expected, thus breaking the logic used to number the buttons in client >> apps such as GNOME Wacom settings panel. > Not only does this require system level applications like > gnome-settings-daemon and gnome-control-center to have code to > specifically handle it, it will also break enumeration for the users > (shouldn't button A be before button B which would be before button C?). That's precisely the goal, enumeration does not work now for all devices. As for gnome-settings-daemon and gnome-control-center, well yes, they would need some code to take advantage of the possible different order, that's the purpose, but they would work without needing changing as well. > This should be fixed in the driver. libwacom is a place to define things > that drivers cannot, not to work around hardware differences like this. > > Big NAK. It's not just to work around an issue with the Bamboo tablet. Let's say you want to create some sort of a graphical representation of all the buttons (to show what button does what, in an OSD window for example). Let's take for example a Intuos 5 M. It has, from top to bottom 4 buttons, then the touch ring with its modeswitch, then 4 more buttons. Definition gives: [Buttons] Left=A;B;C;D;E;F;G;H;I Ring=A RingNumModes=4 If button A is before button B, then that means that touchring button is first, while it's not, it's in the middle With the proposed patch, the definition would then be: [Buttons] Left=B;C;D;E;A;F;G;H;I Ring=A RingNumModes=4 That would allow a program to list the buttons in their actual physical order. The tablet definition for the Cintiq 21UX2 already has something like this: Left=B;C;D;E;A;F;G;H;I But this cannot be used unless we give access to the order, somehow (granted, this might be an accident, as most definition do not care about orders, but knowing how buttons are ordered on the device would be a plus). 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
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: Add button order to libwacom
On Tue, 2012-06-05 at 15:09 +0200, Olivier Fourdan wrote: > The libwacom API does not provide any way for client applications to > get the buttons order as this may differ from the actual button > definition. > > For example, the Bamboo Fun Pen&Touch tablet maps buttons from top to > bottom (with pad on the left) as A, D, C, B instead of A, B, C, D as > expected, thus breaking the logic used to number the buttons in client > apps such as GNOME Wacom settings panel. Not only does this require system level applications like gnome-settings-daemon and gnome-control-center to have code to specifically handle it, it will also break enumeration for the users (shouldn't button A be before button B which would be before button C?). This should be fixed in the driver. libwacom is a place to define things that drivers cannot, not to work around hardware differences like this. Big NAK. -- 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
