Hi Peter, > you could make the support compiled in, but not compiled _out_. so even if > you HAVE_SMOOTH_SCROLLING, the old bits are ready to go when enabled. > if no smooth scrolling axis is otherwise present on the device, just post > button events as previously. Well, the proper thing to do would be to add new valuators and report the changed axes via a XIDeviceChangedEvent. But since there's no infrastructure for that yet (or is it?), I'll do it that way.
> REL_DIAL is set up as vertical axis by default anyway. Okay. > > Resend, my E-Mail client ate the patch... Sorry, will have a serious word with my client. > > + xf86IDrvMsg(pInfo, X_ERROR, "rel motion: %f\n", v); > > this should be removed in the final version Thanks. > > #define TestBit(bit, array) ((array[(bit) / LONG_BITS]) & (1L << > > ((bit) %> > > LONG_BITS))) > > +#define evdev_SetBit(bit, array) ((array[(bit) / LONG_BITS]) |= (1L << > > ((bit) > Can we use the server's BitIsOn (inputstr.h), SetBit, etc here instead of > relying on our own macros with name conflicts? That wouldn't be the same on Big-Endian machines, since BitIsOn() from inputstr.h expects an char array, while the evdev bitmasks are kept in longs. I agree that this bit looks bad, maybe we could rename TestBit to evdev_TestBit to match evdev_SetBit? Max _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel