bug#54654: libx11 libxcursor handling - Problems with big cursors not working in Java and xterm

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Am Donnerstag, dem 31.03.2022 um 15:31 +0200 schrieb Danny
Milosavljevic:
> [...]
> Possible fixes:
> 
> a. Patch openjdk and xterm (and who knows what) such that it also
> does the
>    XcursorTryShapeCursor before it calls XCreateFontCursor.
>    That's a lot of work.
>    Note: There are no libxcursor or XLoadFont bindings in openjdk
> yet,
>    and one is not supposed to access Display->cursor_font from
> outside.
>    Note: xterm use libxcursor--but for something else. So it still
>    doesn't work (because it doesn't call XcursorTryShapeCursor).
This solution works short-term and should probably be done in the
meantime while...

> b. Patch guix such that the libx11 package used by libxcursor is one
> without
>    reference to libxcursor, but a new user-visible libx11 package
> actually
>    would just link libxcursor in. Not sure whether that's such a good
>    idea--it could increase the size of everything and have two libx11
>    libraries loaded in the same user process, no?
this is the proper solution, which we would need to deploy on core-
updates first due to the enormous amount of dependents.  As for the two
libx11s being loaded into the same user process, I think there ought to
be a way of making that just one, which would be the big one containing
all the right paths.  I don't think libxcursor should reload libx11 if
there's already a libx11 dynamically loaded.

Cheers