On Wed, Mar 24, 2010 at 11:59:14AM -0700, Ping Cheng wrote: > This patch still has the cursor jumps to (0,0) issue when pressing an > expresskey. I think the root cause is not solely the SetScreen call. > It is the PostMotionEvent call.
correct, this was just the first part of it and it is based on the assumption that the pad is an absolute device. If it isn't, that makes things a lot easier. > I tested expresskeys with linuxwacom. It works. I looked into both > xf86-input-wacom and linuxwacom driver code. The basic difference that > related to this feature is the mode. xf86-input-wacom always sets pad > to absolute mode (refer to wcmDevSwitchModeCall) while linuxwacom sets > pad to relative/absolute according to if it is a core/non-core device. > The rationale behind linuxwacom's choice was not to move the cursor > no matter pad is a core device or not. ok, now it makes sense. I tried to fix this by leaving the abs mode for the pad but this turned out to be a really nasty problem. I'll switch the pad to relative by default because these days all devices are 'core' if not specified otherwise (the notion of core and non-core device as such doesn't really exist anymore in the server). That should simply fix the issue with the cursor jump. > I am not sure what would be a proper fix for an absolute core pad. > Looks like we could remove SetScreen. But, the problem stays. How do > we get the approriate (x,y) for pad when we don't have values for > them? Or, maybe we can use another xf86PostSomething call to report > valutors 4,5,6 without moving the cursor? You might have a solution > for us. Otherwise I would have to serach through the X.Org docs. it is an inherent issue in the server and I'm not even sure it can be fixed - at least not easily. because core events always require x/y coordinates to be filled in, the server fills in the non-existing coordinates from the cached values. if they never exist, then the server has to use 0/0. Because of scaling issues, we can't just take the screen coordinates either - the pad has a different resolution. There's no other xf86Foo API that lets you do that, the issue is not in the API (which works correctly) but rather in the server code (dix/getevents.c to be precise). Cheers, Peter > On Tue, Mar 23, 2010 at 11:05 PM, Peter Hutterer > <[email protected]> wrote: > > I don't know how that could have worked since 38482b322d3b "Added support > > for Intuos4". x/y is hardcoded to 0, hence the SetScreen call would always > > reset to whatever screen is there. > > > > Either way, it's one of the contributors to the Intuos3's strip buttons > > being broken. > > > > Signed-off-by: Peter Hutterer <[email protected]> > > --- > > src/wcmCommon.c | 2 -- > > 1 files changed, 0 insertions(+), 2 deletions(-) > > > > diff --git a/src/wcmCommon.c b/src/wcmCommon.c > > index b9385af..560fd91 100644 > > --- a/src/wcmCommon.c > > +++ b/src/wcmCommon.c > > @@ -941,8 +941,6 @@ void wcmSendEvents(LocalDevicePtr local, const > > WacomDeviceState* ds) > > { > > x = 0; > > y = 0; > > - if ( v3 || v4 || v5 ) > > - wcmSetScreen(local, x, y); > > > > /* don't emit proximity events if device does not > > support proximity */ > > if ((local->dev->proximity && !priv->oldProximity)) > > -- > > 1.6.6.1 > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
