Tomas Carnecky wrote: > This was somehow missed when I ported all the DevPrivateKey > variables in the source tree. Maybe because it didn't use the > proper DevPrivateKey but rather hardcoded the type, so grep din't > find it. And I can see why the type was hardcoded: because it's > not possible to include privates.h in the file: privates.h depends > on dix.h which depends on cursor.h which needs the definition from > privates.h. > > This patch is a) ugly and b) breaks API. So beware of that when > you merge it. > --- > > Could you try if this patch helps? Maybe someone can in the meantime > come up with a better idea how to untangle the headers. > > dix/globals.c | 3 ++- > include/cursor.h | 5 ++++- > 2 files changed, 6 insertions(+), 2 deletions(-) > >
The patch is buggy, taking the address of the array in globals.c is not the intent. The intent of CursorScreenKey is to provide an array of integers, one for each screen. I think there's some issue with a CursorBits structure having a bad devPrivates pointer. If I knew what the exact sequence of gimp operations were I could attempt to reproduce the problem. If the problem persists then the "devPrivates" field of CursorBits could be dumped and returned to what it was before, which was an array of pointer sized to MAXSCREENS. -- Eamon Walsh <[email protected]> National Security Agency _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
