[PATCH libwacom 1/3] data: define button positions for Bamboos

[Peter Hutterer-3]

Signed-off-by: Peter Hutterer <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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Peter Hutterer-3]

On Tue, May 29, 2012 at 02:25:11PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer <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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Favux ...]

Right.  Since the 3.6.38 kernel or so the BambooPT button situation has been:

physical Button 1    BTN_RIGHT          X Button 3
physical Button 2    BTN_BACK           X Button 8
physical Button 3    BTN_FORWARD    X Button 9
physical Button 4    BTN_LEFT            X 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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Olivier Fourdan-5]

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<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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Peter Hutterer-3]

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<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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Olivier Fourdan-5]

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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Bastien Nocera]

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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Jason G.]

On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Bastien Nocera]

On Wed, 2012-06-06 at 09:30 -0700, Jason Gerecke wrote:

> On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Chris Bagwell]

On Wed, Jun 6, 2012 at 11:30 AM, Jason Gerecke <killertofu@...> wrote:

> On Wed, Jun 6, 2012 at 6:04 AM, Bastien Nocera <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Peter Hutterer-3]

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 <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Jason G.]

On Wed, Jun 6, 2012 at 6:00 PM, Peter Hutterer <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 <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Peter Hutterer-3]

On Wed, Jun 06, 2012 at 06:48:02PM -0700, Jason Gerecke wrote:

> On Wed, Jun 6, 2012 at 6:00 PM, Peter Hutterer <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 <hadess@...> 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.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@...
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel