Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 179044 - Mouse pointer theme not activating correctly
Summary: Mouse pointer theme not activating correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: libX11
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2006-01-26 20:32 UTC by Garry Harthill
Modified: 2013-01-10 03:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-23 21:58:42 UTC

Attachments (Terms of Use)
strace (deleted)
2006-01-26 21:54 UTC, Jesse Keating
no flags Details

Description Garry Harthill 2006-01-26 20:32:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5

Description of problem:
It seems if i change the to bluecurve cursor theme using System -> Prefs -> Mouse it seems to change the settings in the current active window only. All others are the same old cursors. Although the cursors work in the active window only the hour glass cursor is still not showing. If I swap to another active window the theme doesn't follow. It only works in the active window the theme was activated in.

If i change the cursor theme with all active windows closed the theme doesn't change the cursors at all.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Load into Gnome. Mine is in initlevel 5 so it goes straigt in.
2. Change theme using System -> Prefs -> Mouse to Bluecurve

Actual Results:  I can see the animated cursor just before GDM runs. It then changes to the unanimated cursor when GDM actually starts.
When logged into Gnome theme is not the bluecurve theme which it should be. When the theme is changed note that change only works in active window. Mouse over the panel at top or bottom or over another program and the mouse changes to the default theme

Expected Results:  Theme should be active when GDM is run and when Gnome loads. It should also be active in all aspects of the running of Gnome and not just in the active window.

Additional info:

Comment 1 Matthias Clasen 2006-01-26 20:47:40 UTC
I can't reproduce.

It would be wrong for gdm to pick up your cursor theme anyway, because gdm is
not running in your session.

Is gnome-settings-daemon running ?

Is this a stock gnome session, or do you something like a .Xclients or .xinitrc ?

Comment 2 Garry Harthill 2006-01-26 21:42:38 UTC
Yes. gnome-setting-daemon is running.

This is a stock gnome session. I originally posted on the fedora-devel list. Two
other people also experience the same problem.

Comment 3 Jesse Keating 2006-01-26 21:51:39 UTC
attached is a strace requrested for gnome-calculator which will not show the
cursor arrow set as the gheme.

Comment 4 Jesse Keating 2006-01-26 21:54:25 UTC
Created attachment 123748 [details]

All I can see about cursors is the inability to find  I have
libXcursor installed, but it doesn't seem to provide a .so, just a .so.1.0.2
and so.1

Comment 5 Garry Harthill 2006-01-26 23:12:34 UTC
Do you need any more information from me? I have installed on another machine
here with the same issue. It must be a bug - this other machine had the problem
from a fresh fc5t2 installation.

Comment 6 Matthias Clasen 2006-01-27 14:13:33 UTC
Jesse, thats fine. The .so is in the -devel package. It is a problem if the
library is not found, of course.

Jakub claims that glibc won't go looking for the .so (without .1) unless
somebody is dlopening it. Can you break on dlopen and see if thats the case ?

Comment 7 Matthias Clasen 2006-01-27 14:35:22 UTC
Jesse, just to make sure that we are looking at the source of the problem, can
you see if installing libXcursor-devel fixes it ?

Comment 8 Garry Harthill 2006-01-27 18:58:06 UTC
Installing libXcursor-devel has fixed the problem for me. This ideally needs to
be included in the gnome group because it wasn't installed when I did a standard

Comment 9 Matthias Clasen 2006-01-27 19:14:48 UTC
No, thats not a fix, just a workaround. 

We still need to get to the bottom of why something needs the .so instead of the

Comment 10 Sammy 2006-01-27 22:24:45 UTC
I have a similar problem: 

If you run a i386 application on a x86_64 system, none of the cursor themes
work for them, while they are working fine for all x86_64 applications.
Of course the reason for running i386 applications are for plugins and codecs.

Anyway, I wonder if the missing /usr/lib/ (since on x86_64 we
only install the 64 bit devel package, while the I have both versions of the
libXcursor package). I am at home for the weekend so don't have access to my
x86_64 system to test.

Comment 11 Clint Chapman 2006-02-02 03:53:53 UTC
libXcursor-devel fixed this for me also.

Comment 12 Mike A. Harris 2006-02-02 04:03:11 UTC
(In reply to comment #8)
> Installing libXcursor-devel has fixed the problem for me. This ideally needs to
> be included in the gnome group because it wasn't installed when I did a standard
> installation.

That is a development package only, and should not ever be required on any
system, except for the purpose of compiling software that links to libXcursor.

If installing libXcursor-devel has the effect of making the described problem
go away, that helps in diagnosing the problem, but it is definitely not
a solution to the problem.

The next step, is to determine _why_ the problem goes away when this happens.
It appears that something has linked to libXcursor, and has a DT_NEEDED
on, or is dlopening it or some other case which results in
a direct dependency on the .so.

The real solution, is fixing whatever is causing this problem, to properly
link/load* instead of, in which case the
-devel package should no longer be needed to work around the underlying

I'm going to investigate the libXcursor package now, to see if the bug
is actually in* itself, which is theoretically possible,
as there was a problem of a similar but slightly different nature in* during X11R7 beta testing which was resolved in the final

I'll update the report once I've analyzed the libXcursor runtime.

Comment 13 Ralph Loader 2006-02-02 06:32:01 UTC
Grepping the X sources appears to show the culprit:

./X11/src/CrGlCur.c-55-#ifndef LIBXCURSOR
./X11/src/CrGlCur.c:56:#define LIBXCURSOR ""
./Xcursor/include/X11/Xcursor/Xcursor.h-432- * This is the function called by
Xlib when attempting to
./Xcursor/include/X11/Xcursor/Xcursor.h-433- * load cursors from
XCreateGlyphCursor.  The interface must
./Xcursor/include/X11/Xcursor/Xcursor.h:434: * not change as Xlib loads
'' instead of
./Xcursor/include/X11/Xcursor/Xcursor.h-435- * a specific major version
./Xcursor/include/X11/Xcursor/Xcursor.h-436- */

Comment 14 Mike A. Harris 2006-02-02 09:18:51 UTC
Thanks for the info, I'll reassign it to libXcursor for now.

Comment 15 Sammy 2006-02-02 13:24:38 UTC
I can also confirm that the problem mentioned in comment #10, running i386
applications on x86_64, is also solved if I install the i386 devel package,
which should not be installed!

Comment 16 Matthias Clasen 2006-02-10 02:44:27 UTC
Mike, any progress on this ? Can't we just dlopen ? Or even link
against it ?

Comment 17 Christopher Aillon 2006-02-21 21:08:38 UTC
This issue is high visibility and the potential risk here for this fix seems
minimal.  Matthias and I think this should be moved to the FC5Blocker list as
this makes us look silly, and there's no reason a standard install should
require a -devel package.

Comment 18 Mike A. Harris 2006-02-21 21:29:43 UTC
A blocker is something that will block the release of the OS, holding it
back until it is fixed.  This is definitely not a blocker.  Moving to

Comment 19 Christopher Aillon 2006-02-23 21:58:42 UTC
Fixed in libX11-1.0.0-3

Note You need to log in before you can comment on or make changes to this bug.