Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#327 closed bug (invalid)

Hardware cursor displays incorrectly on nvidia and neomagic

Reported by: genki@… Owned by: rudolfc@…
Priority: normal Milestone: R1
Component: System/Kernel Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


I noticed this error a while ago on my Neomagic 2160 laptop and just now with my Geforce 2 GTS.

What happens is that while using hw cursor you can't really move the mouse cursor to the absolute top left on the screen, the cursor if always offset by 2,2. (x,y) Although the actual mouse operation functions correctly.

Do this: Lower your resolution to 640*480. Lower your mouse speed to absolute minimum. Now put a window to the absolute top left. Move cursor to top left and hold down mouse button and move the mouse slightly to the left and down.

You should now see the window move, but the mouse cursor will actually remain in the same position.

Disabling hardware cursor will not display this error. I have not tested this under Haiku yet. (But Haiku currently only has sw cursor, right?)

Change History (2)

comment:1 Changed 13 years ago by rudolfc@…

Resolution: wontfix

comment:2 Changed 13 years ago by rudolfc@…

Status: newclosed


This is actually a system shortcoming. The drivers are working correctly. If you BTW test the Be Neomagic driver, you'll see the exact same behaviour.

Background: A (BeOS) cursor consists of a 16x16 pixel bitmap, which on most hardware has it's reference point at the left-top. This means that if you set coordinate 0,0 the cursor bitmap will be aligned at the left-top position of your screen (at 0,0).

However, cursor bitmaps tend to have a bitmap that does not extend to the border of this bitmap: i.e. the 'hand' has it's fingertip at position 2,2 inside the bitmap. This is called the hotspot.

So, what you see is that the hotspot is unable to be placed at screen coordinate 0,0: this is because that would mean that the cursor bitmap needs to be at screen position -2, -2: wich is something this hardware cannot do.

A solution would be that the app_server sends a new bitmap to the cursor, in which the hand has it's hotspot at cursor bitmap position 0,0 so the hand appears at the correct position.


From the driver's perspective I added a check for negative coordinates, and if this is detected I force 0,0 (appears to be 2,2 for the user because that's the hand hotspot). Movements are actually done, but the cursor bitmap remains unmoved. If I would not include this check, you'd see the cursor bitmap suddenly disappear alltogether, as the position is unsigned. -2, -2 is actually something like 65533,65533 which means the cursor 'jumps' to way beyond the right-bottom of the screen.

Such behaviour is even less pretty than what we have now, hence the 'negative' check.

I hope this explains enough what's happening here.

Note: See TracTickets for help on using tickets.