On Tue, Sep 29, 2015 at 10:04:40PM -0700, Keith Packard wrote: > Jonas Ådahl <jad...@gmail.com> writes: > > > On Tue, Sep 29, 2015 at 09:49:46AM -0700, Keith Packard wrote: > >> Jonas Ådahl <jad...@gmail.com> writes: > >> > >> > As mentioned, a different approach would be to work-around the issue in > >> > xwayland, but I consider such a solution more hacky than this. Please let > >> > me know what you think. > >> > >> All you need do in xwayland is smash pSpriteCursor to some other value, > >> like ((CursorPtr) (intptr_t) 1). That'll make the existing checks fail > >> and force the driver to be called with the new cursor. > >> > >> No mipointer changes ABI/API needed, which means we could merge this for > >> 1.18 (given the DIX patch which I've already reviewed). > > > > The added field is in the end of the struct, and for what I can > > understand from Adam running abidiff, the only remaining ABI issue was > > the fact that SpriteRec was put in the middle of another public struct > > making it impossible to extend; this new patch does not modify > > SpriteRec. It feels less hacky than adding a "fake" pointer > > ((intptr_t) 1)and the necessary checks all over mipointer.c. > > There wouldn't be any changes to mipointer.c.
Yes, otherwise we'd crash in miPointerUpdateSprite when trying to access pCursor->bits. After fixing that, we'd have to patch up the sprite callbacks in xwayland to deal with the not-a-cursor cursor. It feels hacky, but anyway, I'll make such a patch anyway if thats what you prefer. Jonas > > -- > -keith _______________________________________________ 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