i've experienced the same thing on an eMac 700Mhz with an nVidia GeForce2 MX as
well, but only on the built-in monitor (CrtcNumber 1).  when i use the external
monitor (CrtcNumber 0), the mouse cursor displays just fine whether i use
HWCursor "on" or "off".

(see also bug 3714)

I'm seeing the same on a Athlon X2 system with FC5T3:

00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge
(rev a2)

xorg-x11-drv-nv-1.0.1.5-3.1

Same here, on integrated nVidia in an Acer Athlon box running FC5T3.

00:05.0 0300: 10de:0242 (rev a2)

Same here with Gigabyte GA-K8N51GMf-9 with IGP GeForce 6100 on FC5

Same invisible cursor problem:
 - FC5 Release
 - ASUS K8N-VM nVidia GeForce 6100 Motherboard
 - nVidia C51 PCI Express Bridge rev 162
 - AMD Athlog 64 3000+ Venice Core 800 MHZ HT 754 E6
 - Gateway 15" (driver 800 x 600 generic CRT display)

Fixed by disabling HWCursor

This problem has been reported in Red Hat bugzilla by numerous people over
the last 4 months or so, and is present on x86, x86_64, and ppc builds, so
it is presumed to be a general problem not constrained to any particular
architecture.

In all cases reported so far, using Option "swcursor" or one of its many
synonyms, works around the issue.

Recently, a user has reported that disabling rhgb (Red Hat graphical boot),
allows the X server to start up and the hardware cursor works fine.  Another
user worked around the problem by booting into runlevel 3, and then logging
in as root and typing "init 5".  After that, the nv driver worked fine
and did not have hardware cursor problems.

Anyone experiencing this problem on any distribution, should attempt one
of these workarounds as well to see if it works.

Both of these workarounds essentially causes rhgb to be bypassed, so rhgb
appears to be the catalyst which makes this bug appear.  For those who
are not familiar with rhgb, it is essentially a graphical shell around
boot time init startup, which is essentially eye-candy init.  rhgb starts
up an X server with DRI disabled as soon as possible in the init sequence,
so that the remainder of the init can proceed graphically inside X.  The
X server that is started, is started in a minimal environment where the
hard disk is read-only, etc.

Once the system has started up, rhgb starts a second X server, which is
the real X server the user will be using, and then kills the minimal X
server it was running with.

As such, there is a small window of time, in which 2 X servers can actually
be running at the same time on different VCs, and this may bring video
driver bugs or X server bugs to the surface which would not ever happen
if only a single X server were running.

It would appear that the "nv" video driver in this case, does not start up
correctly if another X server has been started already, however it is not
clear what exactly the problem is yet.



- This particular bug is reported by a Yellowdog user, indicating that it is
  a clone of Fedora Core 2.  Does Yellowdog also use rhgb, and if so, if you
  disable rhgb, does the problem go away?

- Are any other users out there of other distributions able to reproduce this
  problem?

- Using another OS, or having removed rhgb in a Red Hat system, can any user
  using "nv" reproduce this problem manually, by starting an X server, then
  switching VTs and starting a second X server on :1?

Hopefully this information will be useful in tracking down the cause of the
problem in the nv driver.  In the mean time, until a solution is found and
committed to CVS, users experiencing the problem are recommended to only use
a single X server at a time, and to disable rhgb or any similar software
until a solution can be found - or alternatively to continue using swcursor
to avoid the issue.

Hope this helps.

Adding Nvidia to CC.

There have been more updates on the Red Hat bugzilla tracking the same issue:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182517

It appears that the problem occurs after a VT switch, the mouse cursor
disappears.  This happens when Red Hat graphical boot is active, because
it starts one X server to do its thing, then starts a second one for
the user when it's done and switches to the other server.  This is done
in order to avoid excessive screen flicker when switching from one X
server to another.

Of course that causes a VT switch to occur, which uncovers this driver
bug.  Users who are not using rhgb, and have uninstalled it, sometimes
experience this issue as well, when doing VT switches normally, however
it does not happen for all users, so it may be restricted to a subset
of hardware.

While it's mostly reported by rhgb users, as it affects a lot of them,
lots of people are hitting this problem on VTswitch nonetheless wether
they're using rhgb or not.

Hope this helps diagnose/resolve the issue.

Thanks guys..
TTYL

Having same problem,  Red Hat 5, Nvidia GeForce 6150LE.

Would anyone be willing to post an example file for the xorg.conf SWCursor edit?
 I'm still a little unsure which section it goes it.  How serious are the
consequences if I guess wrong and restart the X server? How likely is X to fail
to start altogether if there's a typo in xorg.conf? 

Tried editing rhgb out of my grub file.  I get a cursor on the first log in, but
it disappears when I log out.  I don't see any obvious cursor commands in the
post session file.  I had thought that it wasn't supposed to restart rhbg on
logout, but haven't gone through the process table to check this yet.
  

It goes in the Device section:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        VendorName  "Videocard vendor"
        BoardName   "nVidia Corporation C51 PCI Express Bridge"
        Option      "HWCursor" "off"
EndSection

Yes, binary nvidia drivers on this machine, but the same thing works on a
machine running the free nv driver.

HWCursor off fix works for me.  Thank you for the example.

Disabling rhgb works for me, on FC6, with a GeForce 6150, I am using hwcursor now.

BTW - before coming across this bug and the no-rhgb workaround, I had come up
with the swcursor workaround myself.  However, swcursor seems to leave screen
corruption (a wake of blocky painting around the mouse pointer) when certain
types of operation were occurring.  When I was still on FC5, I only noticed this
when doing video editing, but when I upgraded to FC6 and turned on the compiz
desktop effects, this screen corruption impinged more onto regular use (e.g.
when mousing over menus, dragging title bars etc).  Thus:

1) With increased compiz-type use, fixing this bug (3009) becomes more important.

2) Should a separate bug be filed for the corruption problem with swcursor? (I
am using the nvidia drivers, and do not know if the swcursor problem occurs with nv)

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Hi!
I had the same problem on Debian Etch running on a Sempron system with nGeoForce 6100.
The problem occurred after the installation of all libraries needed for running vmware server on a 64-bit environments. Until that moment I had no problem at all.
In detail I tried to install the following packages (some of them was already in my system, but I do not remember which. In any case I worked on a fresh install):

libx11-6 libx11-dev libxtst6 xinetd wget binutils-doc make manpages-dev autoconf automake1.9 libtool flex bison gdbgcc-2.95-doc

After the installation I had to reboot. Then, I installed
ia32-libs, vmware with a patch.

After a new reboot, the mouse pointer was not visible.

Disabling HWCursor fixed the problem.

Just adding my piece of contribution.

I have experienced the same problem in different distros: SUSE 10.2 i386 and an LFS 6.2 based with Xorg 7.1 installed.

In both systems disabling HWCursor has worked.

Just to correct myself,
on Debian etch 64-bit running on a Sempron system with nGeoForce 6100 disabling HWCursor has only partially solved the problem: when I logout the pointer vanishes in gdm and it is not visible anymore.

Complete Linux noob. New box Dell E521. nv 6150LE. First install, first problem. Fixed with HWCursor [off].

Excuse me if this sounds completely ridicules. I did a stint at Apple as a QA manager and sometimes a noob will get lucky because they "don't know any better".

While trying to work around this I found...

In Gnome 2.0 docs >configuring the mouse it says the default pointer is a "the default black pointer"...yet in System/preferences/hardware/mouse/pointers... the default pointer APPEARS to be no pointer.

Could the code be selecting this default "no pointer" and causing this problem?

I'm seeing similar isues on an hp tx1000z laptop.  It has a nVidia C51 (Geforce 6150 Go).

I installed F7 and the laptop would load the rhgb fine.. When it switched to normal X server it would often hang up.  I found the following two things fixed that solution.  Add either "noapic" or "vga=0x317" to boot options.

If I use "noapic" then I eventually had an invisible cursor.  This happened after upgrading my sound drivers (nVidia chipset again using snd-hda-intel drivers) to ALSA snapshot drivers.  After rebooting the cursor was invisible.

I didn't try disabling HWCursor but I'm assuming that would have fixed it as ewll.


For some unknown reason, when I switched from "noapic" to "vga=0x317" then the cursor became visible again.

HWCursof still does not work in F8:
xorg-x11-drv-nv-2.1.5-2.fc8
xorg-x11-drivers-7.2-9.fc8
xorg-x11-apps-7.3-1.fc8

*** Bug 12314 has been marked as a duplicate of this bug. ***

*** Bug 9341 has been marked as a duplicate of this bug. ***

Still present with xorg-x11-drv-nv-2.1.6-7.fc9.i386

I have an nVidia GeForce 2 MX 200 and NEVER experienced this problem. I used various Fedora versions and other Linuxes, Solaris, various BSDs, Xorg and XFree86, free nv and binary nvidia driver, rhgb or no rhgb: hardware cursor always worked, even after numerous vt switches or with multiple X servers running in parallel.

Appeared for me with:

xorg-x11-drv-nv-2.1.12-6.fc10.i386
nVidia Corporation C51 [GeForce 6150 LE] (rev a2)

after I started a second X server to run system-config-display on another VT.  After that server exited, the cursor on the other X server disappeared.  I ended up disabling HWcursor to get it to come back.

Also happening with xorg-x11-drv-nv-2.1.13-1.fc11.x86_64

xf86-video-nv has been officially unmaintained for a bit now, and we are closing all -nv bugs. If your problem was not addressed, and -nv is still broken, please try xf86-video-nouveau. Thank you.