34

Is there anyone who can explain how hardware cursor works precisely? How does it relate to the graphics I'm drawing on the screen? I'm using OpenGL to draw, how does hardware cursor relate to OpenGL graphics?

EDIT: For those who may be interested in this in the future I just implemented what is needed to show the cursor with the hardware. The implementation was in the kernel and to use it simple ioctl's were sufficient. Works perfectly.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Luca Carlon
  • 9,546
  • 13
  • 59
  • 91
  • 1
    hi Luca, I'm interested to see your code with the ioctls for hardware cursor without X11! Can you link your code or a page / manpage describing how to do it? Thanks. – Sam Watkins May 02 '13 at 05:19
  • Proprietary code, sorry. I could only add information about how I implemented it. – Luca Carlon May 02 '13 at 06:15
  • I would appreciate to see any such information! i.e please answer your own question with reference to Linux, and I will vote for you :) (or send me a message sam@nipl.net) – Sam Watkins May 03 '13 at 06:58
  • I already added the relevant information in the question years ago. I used the system calls to move the pointer on the screen and set data related to the image to display as a cursor. I implemented this in the cursor driver of my environment which, at the time, was Qt for Embedded Linux. I don't think there is much more to say, it was very simple. – Luca Carlon May 03 '13 at 12:53
  • 2
    [`drm-kms(7)`, "Cursors"](https://gitlab.freedesktop.org/mesa/drm/-/blob/libdrm-2.4.109/man/drm-kms.7.rst#cursors), [`drmModeSetCursor()`/`drmModeMoveCursor()`](https://gitlab.freedesktop.org/mesa/drm/-/blob/libdrm-2.4.109/xf86drmMode.h#L344-353) – genpfault Dec 23 '21 at 04:35

3 Answers3

45

Hardware Cursor means, that the GPU provides to draw a (small) overlay picture over the screen framebuffer, which position can be changed by two registers (or so) on the GPU. So moving around the pointer doesn't require to redraw the portions of the framebuffer that were previously obstructed.

Relation to OpenGL: None!

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • No relation to OpenGL means that it is not important what is writing to the framebuffer, I can use OpenGL, X11 or whatever and the pointer would be placed the same way at the end of the chain. Is this right? Thanks for your answer! – Luca Carlon Aug 05 '11 at 21:59
  • 1
    @Luca: Indeed. OpenGL is just one way to draw to the screen framebuffer. But either way, the hardware cursor works independent from this. – datenwolf Aug 06 '11 at 02:12
  • Would you say this is the best way to provide cursor to devices that needs high performance graphics? Or maybe simply rendering a cursor with accelerated OpenGL implementation is better? Thanks! – Luca Carlon Aug 06 '11 at 09:09
  • 1
    @Luca: Clearly a hardware accelerated cursor is the best solution. HW accelerated or not, changing one bit in a OpenGL scene requires to rerender the whole thing (or work with cache textures). HW cursors just work, and they are easy to use; Just use the graphics system's standard cursor image setting functions (SetCursor in Windows, XCursor in X11, MacOS X I don't know, but the manual knows it ;) – with properly installed graphics drivers you'll get HW accelerated cursors automatically. – datenwolf Aug 06 '11 at 10:04
  • 1
    Unfortunately I'm not working with either Windows, X11 or MacOS X :-) That is why the details of this subject are relevant for me. Thanks! – Luca Carlon Aug 06 '11 at 10:18
  • It is a Linux built from scratch. For graphics I use a combination of custom EGL implementation and QWS (the Qt Window System). For implementing hardware cursor I think it is necessary to know if there is a library implementing it and writing a driver for it to work with QWS. Is this right? I suppose that is how this is implemented with the classic Window Systems. – Luca Carlon Aug 06 '11 at 12:12
  • @Luca: Hardware cursors are implemented by the graphics driver. In the case of Xorg this is done by the Xorg driver. EGL and QWS build upon Mesa, which again uses DRI/DRM if there are open source drivers (so not for NVidia). There should be HW cursor support somewhere in there, but don't ask me where exactly. There's no all purpose HW cursor library, though, as this is highly hardware specific. – datenwolf Aug 06 '11 at 22:37
  • Given *hardware cursor* is implemented by the hardware. But isn't OpenGL (or DirectX) your window (door, gateway, method of communication) with that hardware? i guess i'm asking: How do you tell the brand of video card installed in the computer to "draw a cursor *here*"? – Ian Boyd Nov 11 '11 at 15:22
  • @IanBoyd: Technically you don't (tell it to draw something). It's really just an area of memory and two registers and the GPU will overlay for every frame sent to the display (it's not drawn, it's overlayed onto the data going out to the monitor). So there's not acutal cursor "drawing". Putting the cursor image into graphics memory and setting the registers is done by the driver. This is very different from using a API like OpenGL which makes the GPU generating a image. – datenwolf Nov 11 '11 at 19:56
  • @datenwolf But how do you talk to the driver? Surely i don't have to write code tailored for every revision of every piece of hardware ever created, with every revision of every driver ever created. Surely there's some API (e.g. OpenGL) that abstracts the details of a particular vendor's hardware sprites. – Ian Boyd Nov 11 '11 at 21:39
  • @IanBoyd I already explained that in another comment, answering Luca: The operating system graphics layer provides mid-level API calls. On Windows it's SetCursor, on X11 you use the XCursor protocol, and MacOS X provides the NSCursor class. Those APIs then do the talking to the driver. – datenwolf Nov 12 '11 at 01:03
  • i understand now. A hardware cursor is what happens naturally, and people have to go to lengths to *hide* the normal cursor in order to draw their own. i thought "hardware cursor" was something you have to program; in reality "not hardware cursor" is something you have to program. – Ian Boyd Nov 12 '11 at 01:08
  • @IanBoyd: Hardware cursor only refers to the graphics hardware's capability to overly a cursor image in a way that doesn't require a full redraw update everytime the cursor position or image changes. If a graphics hardware doesn't support hardware cursor overlays (unlikely those days), then the graphics system must implement the cursor by drawing directly to the screen framebuffer. Which implies that the parts exposed by a cursor move must be redrawn by the affected programs; if a program didn't update its windows contents inbetween you can use a double XOR drawing for efficient updates. – datenwolf Nov 12 '11 at 01:21
  • @datenwolf But from a Stackoverflow/Programmer programming in OpenGL on an operating system: i don't *do* anything to "create" a hardware cursor. The operating system does that. As a programmer the only thing i could do (on modern operating systems) is jump through hoops to *avoid* using the hardware cursor. As a programmer, writing an OpenGL-based program: i don't have to do anything. – Ian Boyd Nov 14 '11 at 15:56
  • @IanBoyd: Exactly, only that the HW cursor is actually something provided by the hardware, not the OS. The OS just provides a unified API to set it. – datenwolf Nov 14 '11 at 16:13
15

The hardware cursor is not rendered or supported by OpenGL. Some small piece of hardware overlays it on whatever image is going out the display connector - it's inserted directly into the bitstream at scan-out of each frame. Because of that, it can be moved around by changing a pair of hardware registers containing its coordinates. In the old days, these were called sprites and various numbers of them were supported on different systems.

phkahler
  • 5,687
  • 1
  • 23
  • 31
  • Would you say this is the common or best way to show the cursor for high performance graphic interfaces? Thanks! – Luca Carlon Aug 06 '11 at 09:11
12

Hardware cursors have less latency, and thus provide a better experience, because they are not tied to your game or engine frame rate but to the screen refresh rate.

Software cursors, rendered by you as a screen-space sprite during your render loop, however, must run at the rate of your game engine. Thus, if your game experiences lag or otherwise drops below target fps, the cursor latency will get worse. A minor drop in game fps is usually acceptable, but a minor drop in cursor latency is very noticeable as a "sluggish cursor".

You can test this easily by rendering a software cursor while leaving the hardware cursor on. (FYI, in Windows API the hw cursor function is ShowCursor). You'll find that the software cursor trails behind the hardware cursor.

Rama Hoetzlein
  • 129
  • 1
  • 3