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

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Danny Milosavljevic <dannym <at> scratchpost.org>, 54654 <at> debbugs.gnu.org
Subject: bug#54654: libx11 libxcursor handling - Problems with big cursors not working in Java and xterm
Date: Fri, 01 Apr 2022 08:16:29 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.