Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number
On Fri, Apr 01, 2011 at 12:02:12PM -0700, Jason Gerecke wrote: > On Thu, Mar 31, 2011 at 9:28 PM, Peter Hutterer > 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 > >> 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
On Thu, Mar 31, 2011 at 9:28 PM, Peter Hutterer 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 >> 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
On Thu, Mar 31, 2011 at 12:07:32AM -0700, Jason Gerecke wrote: > On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer > 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
Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number
On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer 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
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