Re: [Linuxwacom-devel] building 0.17.0 fails

2012-09-21 Thread Peter Hutterer
On Thu, Sep 06, 2012 at 09:54:01AM -0700, Jason Gerecke wrote:
> From 1e1d26f088ff65749c748439d749703cc5dcdaf2 Mon Sep 17 00:00:00 2001
> From: Jason Gerecke 
> Date: Thu, 6 Sep 2012 09:41:26 -0700
> Subject: [PATCH] Add LogMessageVerbSigSafe to fake-symbols
> 
> Somehow overlooked this while adding 'xf86MsgVerb' to fake-symbols.
> Oops.
> 
> Signed-off-by: Jason Gerecke 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  test/fake-symbols.c | 5 +
>  test/fake-symbols.h | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/test/fake-symbols.c b/test/fake-symbols.c
> index 800c619..9ed632b 100644
> --- a/test/fake-symbols.c
> +++ b/test/fake-symbols.c
> @@ -325,6 +325,11 @@ InitProximityClassDeviceStruct(DeviceIntPtr dev)
>  return 0;
>  }
>  
> +_X_EXPORT void
> +LogMessageVerbSigSafe(MessageType type, int verb, const char *format, ...)
> +{
> + return;
> +}
>  
>  _X_EXPORT void
>  xf86MsgVerb(MessageType type, int verb, const char *format, ...)
> diff --git a/test/fake-symbols.h b/test/fake-symbols.h
> index f180085..4b28745 100644
> --- a/test/fake-symbols.h
> +++ b/test/fake-symbols.h
> @@ -121,6 +121,7 @@ XIRegisterPropertyHandler(DeviceIntPtr dev,
>int (*DeleteProperty) (DeviceIntPtr dev,
>   Atom property));
>  extern int InitProximityClassDeviceStruct(DeviceIntPtr dev);
> +extern void LogMessageVerbSigSafe(MessageType type, int verb, const char 
> *format, ...);
>  extern void xf86MsgVerb(MessageType type, int verb, const char *format, ...);
>  extern void xf86Msg(MessageType type, const char *format, ...);
>  
> -- 
> 1.7.12
> 


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] fdo bugs copied to this list?

2012-09-21 Thread Peter Hutterer
On Thu, Sep 13, 2012 at 09:39:41AM -0700, Jason Gerecke wrote:
> On Thu, Sep 13, 2012 at 6:00 AM, Bastien Nocera  wrote:
> > Em Thu, 2012-09-13 às 15:39 +0300, Timo Aaltonen escreveu:
> >>   Hi
> >>
> >>   I'd suggest to modify fdo bugzilla so that input/wacom bugmail would
> >> be copied here, so that bugs would get a wider audience.
> >
> I'd like to see this as well, honestly. Having to monitor several
> places for bugs is really annoying. Between -devel, -discuss, SF, and
> FDO, there's a lot of places for bugs to be missed.

tbh, I think we should retire the SF bug tool and move to FDO exclusively.
I've talked about this in the past, but never pulled it off. Given that some
bugs are also server bugs, a reassignment keeps it nicely in the same
bugzilla.

> > No point, you can subscribe to the bugs through bugzilla directly. I
> > already don't like seeing patches fly here when they could be handled
> > through bugzilla as well (though I know Peter has a different opinion of
> > this).
> >
> I can't seem to find any good way to auto-subscribe to bugs of
> interest. The only mechanism I've found so far is the 'user watching'
> mechanism, but it would require the default  assignee to be changed
> for the wacom component (which is pretty much what Timo is looking
> for). Aside from that, I can add myself to the CC list on a per-bug
> basis, but that doesn't change anything -- I still have to check both
> my inbox and FDO for new bugs.

I think the easiest is to subscribe to the xorg-team list and filter based
on X-Bugzilla-Component.
http://lists.x.org/mailman/listinfo/xorg-team

I don't think subscribing one list to another is the right thing to do here,
bugzilla has a lot of noise that you're forcing on everyone here then.

Cheers,
   Peter

> Ideally I could subscribe to my saved search for terms like "intuos",
> "cintiq", "21UX", etc. to keep on top of bugs that are outside of our
> component but still affect our users.

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH] Ignore out-of-prox events from unknown devices already out-of-prox

2012-09-21 Thread Peter Hutterer
On Fri, Sep 14, 2012 at 04:22:47PM -0700, Jason Gerecke wrote:
> Fixes an issue with the Intuos5, which sends extra out-of-prox
> notifications when the ExpressKeys are touched. This causes the driver
> to ask the kernel for the tool currently in prox and post an empty event
> for it. The result is a cursor that (only while the pen is in prox)
> sometimes jumps to the top left when touching the buttons.
> 
> We fix this by ignoring events that claim to be leaving prox when the
> tool is already supposedly out of prox.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=54250
> 
> Reported-by: Timo Aaltonen 
> Signed-off-by: Jason Gerecke 
> ---
>  src/wcmUSB.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> index f25116b..4fc186a 100644
> --- a/src/wcmUSB.c
> +++ b/src/wcmUSB.c
> @@ -1657,6 +1657,11 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
>   unsigned long keys[NBITS(KEY_MAX)] = { 0 };
>   int rc;
>  
> + if (!ds->proximity) {
> + DBG(3, common, "Unknown out-of-prox device leaving 
> prox. Ignoring.\n");
> + return;
> + }
> +
>   /* Retrieve the type by asking a resend from the kernel */
>   rc = ioctl(common->fd, EVIOCGKEY(sizeof(keys)), keys);
>   if (rc == -1)
> -- 
> 1.7.12
 
Acked-by: Peter Hutterer 

Cheers,
   Peter


--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH] Device grab should be optional

2012-09-21 Thread Peter Hutterer
On Fri, Sep 14, 2012 at 05:07:05PM -0700, Jason Gerecke wrote:
> On Fri, Sep 14, 2012 at 5:04 PM, Jason Gerecke  wrote:
> > Like in recent versions of xf86-input-evdev, grabbing the input device
> > with EVIOCGRAB should be optional. This would enable for example
> > indicator applets, and would improve dynamic handling of different input
> > devices.
> >
> > Proposed patch extended to document new GrabDevice driver option.
> >
> > https://sourceforge.net/tracker/?func=detail&aid=3509828&group_id=69596&atid=525124
> >
> > Reported-by: H Sundelin
> > ---
> >  man/wacom.man |  6 ++
> >  src/wcmUSB.c  | 17 +
> >  2 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/man/wacom.man b/man/wacom.man
> > index e938cf5..0502860 100644
> > --- a/man/wacom.man
> > +++ b/man/wacom.man
> > @@ -197,6 +197,12 @@ paths on the tablet. There are 12 levels, specified by 
> > the integers between
> >  "number" will be logged into the Xorg log file. This option is only
> >  available if the driver was built with debugging support.
> >  .TP 4
> > +.B Option \fI"GrabDevice"\fP \fI"bool"\fP
> > +sets whether the underlying event device will be grabbed by the driver to
> > +prevent the data from leaking to /dev/input/mice. When enabled, while the
> > +X server is running, no other programs will be able to read the event
> > +stream.  Default: "false".
> > +.TP 4
> >  .B Option \fI"CursorProx"\fP \fI"number"\fP
> >  sets the max distance from tablet to stop reporting movement for cursor in 
> > relative mode.
> >  Default for Intuos series is 10, for Graphire series (including Volitos) is
> > diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> > index f25116b..b970e1c 100644
> > --- a/src/wcmUSB.c
> > +++ b/src/wcmUSB.c
> > @@ -138,16 +138,17 @@ usbStart(InputInfoPtr pInfo)
> >  {
> > int err;
> >
> > -#ifdef EVIOCGRAB
> > -   /* Try to grab the event device so that data don't leak to 
> > /dev/input/mice */
> > -   SYSCALL(err = ioctl(pInfo->fd, EVIOCGRAB, (pointer)1));
> > -
> > -   /* this is called for all tools, so all but the first one fails with
> > -* EBUSY */
> > -   if (err < 0 && errno != EBUSY)
> > +   if (xf86CheckBoolOption(pInfo->options, "GrabDevice", 0))
> > + {
> > +   /* Try to grab the event device so that data don't leak to 
> > /dev/input/mice */
> > +   SYSCALL(err = ioctl(pInfo->fd, EVIOCGRAB, (pointer)1));
> > +
> > +   /* this is called for all tools, so all but the first one fails 
> > with
> > +* EBUSY */
> > +   if (err < 0 && errno != EBUSY)
> > xf86Msg(X_ERROR, "%s: Wacom X driver can't grab event 
> > device (%s)\n",
> > pInfo->name, strerror(errno));
> > -#endif
> > + }
> > return Success;
> >  }
> >
> > --
> > 1.7.12
> >
> 
> Seemed like a reasonable enough request, and I'm getting tired of
> having to drop to a TTY just to run evtest (or disable
> xf86-input-wacom to run mtview). :D

there is a side-effect to this patch. Adding the option is harmless enough
but you also switched the default to false. This can cause some
issues, though wcmIsDuplicate() should take care of that.

The effect of the EVIOCGRAB is that only one user can get data from
the event device. So if a user has hotplugging enabled but a static
configuration on, say, /dev/input/wacom or some other symlink, the same
device gets added twice. with EVIOCGRAB, that won't be an issue, but without
both readers can get events now. As said above wcmIsDuplicate() should take
care of this, but please make sure this is still the case.

Coincidentally, this would be a great test to add to
http://cgit.freedesktop.org/~whot/xorg-integration-tests/

Cheers,
   Peter

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel