Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-04-03 Thread Peter Hutterer
On Fri, Apr 01, 2011 at 12:02:12PM -0700, Jason Gerecke wrote:
 On Thu, Mar 31, 2011 at 9:28 PM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  On Thu, Mar 31, 2011 at 12:07:32AM -0700, Jason Gerecke wrote:
  On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer
  peter.hutte...@who-t.net wrote:
   On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
   Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
   in get_map, this total hackjob of a patch fixes the problem with
   us having no way of knowing the driver's defaults for wheels and
   strips.
  
   Thankfully, the defaults aren't changing anytime soon so its
   not likely to break. Additionally, once the raw button path is
   removed from the driver, the entire 'get_map' function can go
   the way of the dodo.
  
   This seems to solve the wrong problem. How about we decide that xsetwacom
   controls the physical buttons on the device? That way, anyone wanting to
   configure logical mapping can use the X tools and xsetwacom is
   driver-specific and stays (documented so!) driver-specific. which of 
   course
   also means we need to check that the Button xorg.conf option does the 
   right
   thing.
  
  That would make a number of things easier, but also comes with its own
  drawbacks. I think we should probably figure out where hassle,
  correctness, and compatibility collide first.
 
  just checked the man page again:
 
  Option ButtonM AC
    reports  an  action  AC when button M is pressed,  where M is one of the
    device supported  button numbers,  it can be 1 to 32. Wacom uses a
    driver-internal button mapping, where any physical button appears to the
    X server as  the button specified by the ButtonM mapping. Hence, if two
    physical buttons have the same ButtonM mapping, the server will think
    they are the same physical button.  The default action reported to the X
    server is mouse button M click. Because X uses buttons 4, 5, 6, and 7 as
    the four scrolling directions, physical buttons 4 and higher are mapped
    to 8 and higher by default.  To ignore the button click, i.e.,  to  not
    report  any  button click event to the X server,  use 0 or button 0.
 
  so at least for the xorg.conf option, we already say that this is the
  _physical_ button mapping. I guess it makes sense then to have xsetwacom do
  the same on the physical buttons and leave the X specific stuff up to the X
  tools.
 
  Cheers,
   Peter
 
 And xsetwacom's man page is wholly silent on just what its version 'M'
 is, so deferring to the existing docs would make sense.
 
 Of course, despite the lack of official documentation, its expected
 by users familiar with xsetwacom that it use the X button number.
 Don't get me wrong -- I'd love to see the change. I just hate breaking
 things for our users/customers without good cause. :) Then again, we
 already broke compatibility in the last release, so...

when things are broken, it's better to fix them as soon as possible than
dragging them out. I'm not sure how many users we have that rely on a
specific behaviour of xsetwacom but I've stated repeatedly that it's not to
be relied upon, especially not until we've called the driver stable.

Cheers,
  Peter

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-04-01 Thread Jason Gerecke
On Thu, Mar 31, 2011 at 9:28 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Thu, Mar 31, 2011 at 12:07:32AM -0700, Jason Gerecke wrote:
 On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
  Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
  in get_map, this total hackjob of a patch fixes the problem with
  us having no way of knowing the driver's defaults for wheels and
  strips.
 
  Thankfully, the defaults aren't changing anytime soon so its
  not likely to break. Additionally, once the raw button path is
  removed from the driver, the entire 'get_map' function can go
  the way of the dodo.
 
  This seems to solve the wrong problem. How about we decide that xsetwacom
  controls the physical buttons on the device? That way, anyone wanting to
  configure logical mapping can use the X tools and xsetwacom is
  driver-specific and stays (documented so!) driver-specific. which of course
  also means we need to check that the Button xorg.conf option does the right
  thing.
 
 That would make a number of things easier, but also comes with its own
 drawbacks. I think we should probably figure out where hassle,
 correctness, and compatibility collide first.

 just checked the man page again:

 Option ButtonM AC
   reports  an  action  AC when button M is pressed,  where M is one of the
   device supported  button numbers,  it can be 1 to 32. Wacom uses a
   driver-internal button mapping, where any physical button appears to the
   X server as  the button specified by the ButtonM mapping. Hence, if two
   physical buttons have the same ButtonM mapping, the server will think
   they are the same physical button.  The default action reported to the X
   server is mouse button M click. Because X uses buttons 4, 5, 6, and 7 as
   the four scrolling directions, physical buttons 4 and higher are mapped
   to 8 and higher by default.  To ignore the button click, i.e.,  to  not
   report  any  button click event to the X server,  use 0 or button 0.

 so at least for the xorg.conf option, we already say that this is the
 _physical_ button mapping. I guess it makes sense then to have xsetwacom do
 the same on the physical buttons and leave the X specific stuff up to the X
 tools.

 Cheers,
  Peter

And xsetwacom's man page is wholly silent on just what its version 'M'
is, so deferring to the existing docs would make sense.

Of course, despite the lack of official documentation, its expected
by users familiar with xsetwacom that it use the X button number.
Don't get me wrong -- I'd love to see the change. I just hate breaking
things for our users/customers without good cause. :) Then again, we
already broke compatibility in the last release, so...

Jason

---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-03-31 Thread Jason Gerecke
On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
 Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
 in get_map, this total hackjob of a patch fixes the problem with
 us having no way of knowing the driver's defaults for wheels and
 strips.

 Thankfully, the defaults aren't changing anytime soon so its
 not likely to break. Additionally, once the raw button path is
 removed from the driver, the entire 'get_map' function can go
 the way of the dodo.

 This seems to solve the wrong problem. How about we decide that xsetwacom
 controls the physical buttons on the device? That way, anyone wanting to
 configure logical mapping can use the X tools and xsetwacom is
 driver-specific and stays (documented so!) driver-specific. which of course
 also means we need to check that the Button xorg.conf option does the right
 thing.

That would make a number of things easier, but also comes with its own
drawbacks. I think we should probably figure out where hassle,
correctness, and compatibility collide first.

 ---
  tools/xsetwacom.c |   36 
  1 files changed, 24 insertions(+), 12 deletions(-)

 diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
 index 38002cb..1c0f43f 100644
 --- a/tools/xsetwacom.c
 +++ b/tools/xsetwacom.c
 @@ -1884,22 +1884,34 @@ static void get_map(Display *dpy, XDevice *dev, 
 param_t *param, int argc, char**
       else if (get_button(dpy, dev, param, offset))
               return;
       else
 -     {
 -             int nmap = 256;
 -             unsigned char map[nmap];
 +     { /* FIXME: Ugly hack because there's no way to get default buttons */
 +             if (strcmp(param-prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
 +             {
 +                     int nmap = 256;
 +                     unsigned char map[nmap];

 -             nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
 +                     nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);

 -             if (offset = nmap)
 -             {
 -                     fprintf(stderr, Button number does not exist on 
 device.\n);
 -                     return;
 -             }
 +                     if (offset = nmap)
 +                     {
 +                             fprintf(stderr, Button number does not exist 
 on device.\n);
 +                             return;
 +                     }

 -             print_value(param, %d, map[offset]);
 +                     print_value(param, %d, map[offset]);

 -             XSetDeviceButtonMapping(dpy, dev, map, nmap);
 -             XFlush(dpy);
 +                     XSetDeviceButtonMapping(dpy, dev, map, nmap);

 I didn't pick this up in 155a4b9 but I don't think the
 XSetDeviceButtonMapping actually does anything here. Not sure why it's
 there, looks like a copy paste error (4d2c3d19dce4).

I remember being confused when I saw it, but didn't want to touch it.
I figured it was some arcane intricacy of X.

 +                     XFlush(dpy);
 +             }
 +             else
 +             {
 +                     switch (offset) {
 +                             case 0: print_value(param, 4); break;
 +                             case 1: print_value(param, 5); break;
 +                             case 2: print_value(param, 4); break;
 +                             case 3: print_value(param, 5); break;
 +                     }
 +             }
       }
  }

 --
 1.7.4.1


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-03-31 Thread Peter Hutterer
On Thu, Mar 31, 2011 at 12:07:32AM -0700, Jason Gerecke wrote:
 On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
  Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
  in get_map, this total hackjob of a patch fixes the problem with
  us having no way of knowing the driver's defaults for wheels and
  strips.
 
  Thankfully, the defaults aren't changing anytime soon so its
  not likely to break. Additionally, once the raw button path is
  removed from the driver, the entire 'get_map' function can go
  the way of the dodo.
 
  This seems to solve the wrong problem. How about we decide that xsetwacom
  controls the physical buttons on the device? That way, anyone wanting to
  configure logical mapping can use the X tools and xsetwacom is
  driver-specific and stays (documented so!) driver-specific. which of course
  also means we need to check that the Button xorg.conf option does the right
  thing.
 
 That would make a number of things easier, but also comes with its own
 drawbacks. I think we should probably figure out where hassle,
 correctness, and compatibility collide first.

just checked the man page again:

Option ButtonM AC
   reports  an  action  AC when button M is pressed,  where M is one of the
   device supported  button numbers,  it can be 1 to 32. Wacom uses a
   driver-internal button mapping, where any physical button appears to the
   X server as  the button specified by the ButtonM mapping. Hence, if two
   physical buttons have the same ButtonM mapping, the server will think
   they are the same physical button.  The default action reported to the X
   server is mouse button M click. Because X uses buttons 4, 5, 6, and 7 as
   the four scrolling directions, physical buttons 4 and higher are mapped
   to 8 and higher by default.  To ignore the button click, i.e.,  to  not
   report  any  button click event to the X server,  use 0 or button 0.

so at least for the xorg.conf option, we already say that this is the
_physical_ button mapping. I guess it makes sense then to have xsetwacom do
the same on the physical buttons and leave the X specific stuff up to the X
tools.

Cheers,
  Peter

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


[Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-03-30 Thread Jason Gerecke
Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
in get_map, this total hackjob of a patch fixes the problem with
us having no way of knowing the driver's defaults for wheels and
strips.

Thankfully, the defaults aren't changing anytime soon so its
not likely to break. Additionally, once the raw button path is
removed from the driver, the entire 'get_map' function can go
the way of the dodo.

Signed-off-by: Jason Gerecke killert...@gmail.com
---
 tools/xsetwacom.c |   36 
 1 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 38002cb..1c0f43f 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1884,22 +1884,34 @@ static void get_map(Display *dpy, XDevice *dev, param_t 
*param, int argc, char**
else if (get_button(dpy, dev, param, offset))
return;
else
-   {
-   int nmap = 256;
-   unsigned char map[nmap];
+   { /* FIXME: Ugly hack because there's no way to get default buttons */
+   if (strcmp(param-prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+   {
+   int nmap = 256;
+   unsigned char map[nmap];
 
-   nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
+   nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
 
-   if (offset = nmap)
-   {
-   fprintf(stderr, Button number does not exist on 
device.\n);
-   return;
-   }
+   if (offset = nmap)
+   {
+   fprintf(stderr, Button number does not exist 
on device.\n);
+   return;
+   }
 
-   print_value(param, %d, map[offset]);
+   print_value(param, %d, map[offset]);
 
-   XSetDeviceButtonMapping(dpy, dev, map, nmap);
-   XFlush(dpy);
+   XSetDeviceButtonMapping(dpy, dev, map, nmap);
+   XFlush(dpy);
+   }
+   else
+   {
+   switch (offset) {
+   case 0: print_value(param, 4); break;
+   case 1: print_value(param, 5); break;
+   case 2: print_value(param, 4); break;
+   case 3: print_value(param, 5); break;
+   }
+   }
}
 }
 
-- 
1.7.4.1


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number

2011-03-30 Thread Peter Hutterer
On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
 Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
 in get_map, this total hackjob of a patch fixes the problem with
 us having no way of knowing the driver's defaults for wheels and
 strips.
 
 Thankfully, the defaults aren't changing anytime soon so its
 not likely to break. Additionally, once the raw button path is
 removed from the driver, the entire 'get_map' function can go
 the way of the dodo.

This seems to solve the wrong problem. How about we decide that xsetwacom
controls the physical buttons on the device? That way, anyone wanting to
configure logical mapping can use the X tools and xsetwacom is
driver-specific and stays (documented so!) driver-specific. which of course
also means we need to check that the Button xorg.conf option does the right
thing.

 ---
  tools/xsetwacom.c |   36 
  1 files changed, 24 insertions(+), 12 deletions(-)
 
 diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
 index 38002cb..1c0f43f 100644
 --- a/tools/xsetwacom.c
 +++ b/tools/xsetwacom.c
 @@ -1884,22 +1884,34 @@ static void get_map(Display *dpy, XDevice *dev, 
 param_t *param, int argc, char**
   else if (get_button(dpy, dev, param, offset))
   return;
   else
 - {
 - int nmap = 256;
 - unsigned char map[nmap];
 + { /* FIXME: Ugly hack because there's no way to get default buttons */
 + if (strcmp(param-prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
 + {
 + int nmap = 256;
 + unsigned char map[nmap];
  
 - nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
 + nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
  
 - if (offset = nmap)
 - {
 - fprintf(stderr, Button number does not exist on 
 device.\n);
 - return;
 - }
 + if (offset = nmap)
 + {
 + fprintf(stderr, Button number does not exist 
 on device.\n);
 + return;
 + }
  
 - print_value(param, %d, map[offset]);
 + print_value(param, %d, map[offset]);
  
 - XSetDeviceButtonMapping(dpy, dev, map, nmap);
 - XFlush(dpy);
 + XSetDeviceButtonMapping(dpy, dev, map, nmap);

I didn't pick this up in 155a4b9 but I don't think the
XSetDeviceButtonMapping actually does anything here. Not sure why it's
there, looks like a copy paste error (4d2c3d19dce4).

Cheers,
  Peter

 + XFlush(dpy);
 + }
 + else
 + {
 + switch (offset) {
 + case 0: print_value(param, 4); break;
 + case 1: print_value(param, 5); break;
 + case 2: print_value(param, 4); break;
 + case 3: print_value(param, 5); break;
 + }
 + }
   }
  }
  
 -- 
 1.7.4.1

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel