OSDev.org

Up to now I ignored the GUI completely. But inspired by frantOS, I think about how a GUI is implemented:

Is the GUI's mouse pointer on an (UEFI x64) PC done in software or hardware? Or if both is possible: How did you implement it in your OS?
(If I remember correctly, on Amiga the mouse pointer was done in hardware.)

Greetings
Peter

The mouse cursor you see on the screen is purely software driven.

All items you see on the screen are considered objects. Each item, such as a window, is an object. In fact, a window is made up of objects: Border, title bar, title bar buttons, background, menu, resize button, etc. Each of these objects have a parent, in this case, the window they belong to. That window's parent might be the root object, the desktop object, or another window. A dialog box window has another window as its parent.

The mouse cursor is a single object with its parent as the desktop object. This cursor object keeps track of where it is displayed on the screen.

The only thing you need to do different with the mouse cursor is that it is always on top. No other object should cover the cursor.

With this in mind, the mouse cursor object can be drawn as anything you want, any size, any color. It is simply an object that is drawn to the screen at the current saved coordinates.

Also, keep in mind that there are completely independent items here. The mouse driver is independent of the mouse cursor. The GUI mouse driver calls the hardware mouse driver to see if the coordinates have changed, if so, updates the coordinates of the GUI cursor position. Each item being completely separate of each other. The driver that draws the mouse cursor to the screen is completely separate of the GUI mouse driver. Remember, each item of the GUI is an object with a parent with none or more children. The screen driver simply updates any object that shows dirty.

Ben
- http://www.fysnet.net/the_graphical_user_interface.htm

In my latest GUI code I made the mouse pointer (shaped as an arrow) out of 24 one-pixel-tall windows that are always on top of all other windows.
This solves the problem of having the non-rectangular pointer shape with all the code that handles only rectangular geometry.
There aren't that many pixels (or windows) in the pointer, so, it's OK.
The code should handle typical workloads of hundreds and thousands of windows anyway.

Hi Alex,

I guess that would work just fine. Never thought of it like that, but it should work.

My code uses transparent pixels to get around (pun intended) the square window. Granted, if I have an object that is not square, and click "within" the square, it will select that object.
However, there is already code implemented to bypass this if the pixel is a transparent pixel. I just don't use it at the moment.

Ben

It has nothing to do with the machine being UEFI x64 or not. It's a capability of the display controller. I am aware, that some of (maybe any) ARM SoCs dipslay controllers, have such a capability - to have a cursor as a separate entity (plus some more similar for "sprites") and then combine it with the current buffer content on the fly to the display. it's cool. you don't draw the cursor into "main" buffer, instead you set up a separate one - surely, it's display controller specific, so your graphical subsystem should have an interface with the video driver and resort to drawing the cursor the common way if the driver says no. don't know how is on PCs display controllers, which are a part of GPUs, but wouldn't be surprised if it's the same. you need the GPU documentation. Intel GMA stuff is documented and Korona has experience with it, maybe he knows.

I feel like no one has actually answered the OP's question...

If all you have is a framebuffer, there are many approaches to implementing your mouse cursor in software, and that's all you can do.

If you have drivers for your display adapter / GPU, pretty much all of them have supported hardware cursors since long before they were called "GPUs". The obvious benefit to hardware cursors is that they are automatically overlaid on top of the framebuffer when the final video output is generated, all you need to do is tell the display adapter what the cursor should look like (and they usually support multi-bit alpha channels for transparency) and where it is on screen. As you move the mouse around, you don't need to worry about redrawing parts of the framebuffer just to move the cursor.

Another interesting example of "hardware cursors" is the support in some VMs. VirtualBox, for example, has some useful functionality for integration with the host system. One such piece of functionality is that the VM guest can provide a cursor image that VirtualBox will then provide to the host OS in combination with its support for providing the absolute position of the host cursor. This is doubly useful as you don't even need to tell VirtualBox where the cursor is because it already knows, you just have to tell it what it looks like. It also means your guest cursor can exceed the bounds of the VM window, which is slightly amusing.

As for my personal take on software mouse cursors, I don't implement them as a window but they follow similar rendering rules and are always drawn last so they are on top of everything else.

It is mostly done in software.
AFAIK most of the GPUs support so called "sprite" layers which can be used for drawing a mouse overaly.
There are thousands of GPUs, each with their own quirks and each one of them would require different code.
I wouldn't bother with it, for hobby OS'es software way is the way to go.

That makes sense.

Greetings
Peter