xf86-input-mouse signed/unsigned issue with Microsoft protocol
Peter Hutterer
peter.hutterer at who-t.net
Mon Aug 31 16:32:39 PDT 2009
On Mon, Aug 31, 2009 at 09:00:11AM +0200, Michel Dänzer wrote:
> On Mon, 2009-08-31 at 09:03 +1000, Peter Hutterer wrote:
> > On Fri, Aug 28, 2009 at 09:17:37AM -0500, Donald Kayser wrote:
> > > I am developing under a PPC embedded system running 2.6.30.2 Linux,
> > > xserver from debian distribution of 7.3+19, xf86-input-mouse 1.3.0. I
> > > have a custom board that I am sending Microsoft mouse 3 byte protocol
> > > through a pipe to the input of xserver via the mouse driver. I was able
> > > to make small movements, all positive, but if I moved negative, the mouse
> > > would jump a large amount in the positive direction. I checked out from
> > > git and built the mouse driver and turned on debug to find out and it is
> > > not accepting negative numbers correctly in the case of PROT_MS. By
> > > changing the cast on lines 1304/1305 in mouse.c from (char) to (signed
> > > char), I fixed the problem. I don't know if this exists on other (non
> > > PPC) platforms. I also noticed the potential for the same problem in a
> > > few more places. I am using gcc-4.3.
> > >
> > > The source I have is from:
> > > xf86-input-mouse-1.4.0-13-gf292f23
> > >
> > > diff --git a/src/mouse.c b/src/mouse.c
> > > index aff2512..b59a138 100644
> > > --- a/src/mouse.c
> > > +++ b/src/mouse.c
> > > @@ -1301,8 +1301,8 @@ MouseReadInput(InputInfoPtr pInfo)
> > > buttons = (pMse->lastButtons & 2)
> > > | ((int)(pBuf[0] & 0x20) >> 3)
> > > | ((int)(pBuf[0] & 0x10) >> 4);
> > > - dx = (char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F));
> > > - dy = (char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F));
> > > + dx = (signed char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] &
> > > 0x3F));
> > > + dy = (signed char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] &
> > > 0x3F));
> > > break;
> > > case PROT_GLIDE: /* ALPS GlidePoint */
> >
> > this seems to be a problem on your particular architecture
>
> I'd say the problem is that x86 people tend to assume char is signed by
> default, when that's what C defines. (Or that C doesn't define it one
> way or the other, but we have to live with that)
>
> > and while this may be the only point where it is obvious there are
> > more places where char is assumed to be signed (as you mentioned). try
> > passing -fsigned-char to gcc.
>
> Surely we should continue fixing those bugs as we've always done so far.
> I've never needed to resort to -fsigned-char.
Sure. The interesting thing is though that this code hasn't been changed
since at least 2003 (the original import). If this issue just came up
recently, somethings else must have influenced it.
Or that code had just zero exposure on PPC which may also be the case.
Anyway, Donald, I'd appreciate it if you could send a git-formatted patch to
address this issue. See
http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches
A quick peek at this section shows that there's some other protocols that
may be affected by that as well.
Cheers,
Peter
More information about the xorg-devel
mailing list