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
