Hello all,

I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
no GUI of any kind.

I ofcourse wanted to see if I could draw some graphics on it. :-)

I've found that it supports a "Frame Buffer" onto which pixels can be
plotted.

I also found the "fb.h" include file, and was able to get FBIOCOPYAREA to
work.

Alas, thats as far as I got. Even though the file mentions hardware
support for a mouse cursor I've not been able to get that to work. :-(

The file also contains "fb_fillrect" structure, but doesn't show anything
about how / where its used.

tl;dr:
I could use an example which shows how to use "_iowr()" to get the build-in
mouse cursor to work, and would not mind at all if someone knows how to draw
a simple rectangle using the same "_iowr()" method.

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
> Hello all,
>
> I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
> no GUI of any kind.
>
> I ofcourse wanted to see if I could draw some graphics on it. :-)
>
> I've found that it supports a "Frame Buffer" onto which pixels can be
> plotted.
>
> I also found the "fb.h" include file, and was able to get FBIOCOPYAREA to
> work.
>
> Alas, thats as far as I got. Even though the file mentions hardware
> support for a mouse cursor I've not been able to get that to work. :-(
>
> The file also contains "fb_fillrect" structure, but doesn't show anything
> about how / where its used.

RISC OS uses the GPU to draw its hardware pointer. Here's the code:
https://gitlab.riscosopen.org/RiscOS/Sources/Video/HWSupport/BCMVideo/-/blob/master/s/HWPointer

That appears to be using VCHIQ which is the service to send messages to the
GPU:
https://ultibo.org/wiki/Unit_VC4VCHIQ
https://elinux.org/Raspberry_Pi_VideoCore_APIs

RISC OS appears to be using the vc_dispman API to ask the GPU to draw the
pointer.

> tl;dr:
> I could use an example which shows how to use "_iowr()" to get the build-in
> mouse cursor to work, and would not mind at all if someone knows how to draw
> a simple rectangle using the same "_iowr()" method.

_iowr() is a basic 32-bit I/O write (ie write 32 bits to I/O address
0x....).

The GPU is several levels above this in the stack: you need to craft a
message to ask the GPU to do it, using the appropriate API, and then ask
something (/dev/vchiq on Linux) to deliver the message.

There may be some support for this stuff in the RPi userland libraries:
https://github.com/raspberrypi/userland/tree/master/interface
but it's not immediately clear where it might be.

Having said all this, you're on Linux not baremetal so I think a better way
would be to use some existing library. I'd have a look at SDL as that might
be easier to deal with (SDL 2 is '3D', SDL 1.2 is older and more 2D focused.
You might be better starting with SDL 2 to begin with, even if you only want
2D stuff). SDL is designed to be run either in a window or on a bare
framebuffer style display.

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> R.Wieser <address@is.invalid> wrote:
>> tl;dr:
>> I could use an example which shows how to use "_iowr()" to get the build-in
>> mouse cursor to work, and would not mind at all if someone knows how to draw
>> a simple rectangle using the same "_iowr()" method.
>
> _iowr() is a basic 32-bit I/O write (ie write 32 bits to I/O address
> 0x....).
>
> The GPU is several levels above this in the stack: you need to craft a
> message to ask the GPU to do it, using the appropriate API, and then ask
> something (/dev/vchiq on Linux) to deliver the message.

If the aim is to go the lowest-level route, then it is possible to
send "mailbox" messages to the GPU's proprietary driver directly
via /dev/mem, rather than via a driver. Broadcom's routines for
this are here:
https://github.com/raspberrypi/firmware/blob/master/opt/vc/src/hello_pi/hello_fft/mailbox.c

The documentation for Broadcom's GPU firmware isn't public
though, so you'd need to look at the code of an existing graphics
driver to figure out how to use (some of?) it anyway.

> There may be some support for this stuff in the RPi userland libraries:
> https://github.com/raspberrypi/userland/tree/master/interface
> but it's not immediately clear where it might be.

This is the best index that I'm aware of for the various GPU API
options:
https://forums.raspberrypi.com/viewtopic.php?f=67&p=1901014

> Having said all this, you're on Linux not baremetal so I think a better way
> would be to use some existing library. I'd have a look at SDL as that might
> be easier to deal with (SDL 2 is '3D', SDL 1.2 is older and more 2D focused.
> You might be better starting with SDL 2 to begin with, even if you only want
> 2D stuff). SDL is designed to be run either in a window or on a bare
> framebuffer style display.

SDL 2 also has a "kmsdrm" driver which in theory might be faster
than than the "directfb" framebuffer driver for SDL 1.2 and SDL 2.
It uses the kernel's vc4 driver (note that there's a Mesa driver
that's also called vc4), which presumably has some way of moving
the mouse pointer with the GPU if that acceleration is normally
used.

--
__ __
#_ < |\| |< _#

Theo,

> Having said all this, you're on Linux not baremetal so I think
> a better way would be to use some existing library.

Which is why I mentioned the "fb.h" file and its mentioning of having a
"_iowr()" function to set up such a cursor. I just can't seem to find
enough info to be able to either get it to work or figure out if its
unsupported. :-(

Regards,
Rudy Wieser

Kev,

> If the aim is to go the lowest-level route,

Not really. Currently I just want to get it to work thru the available
"frame buffer" methods.

The problem is that that "fb.h" file /looks/ to be saying such support is
available, but I can't get it to work. As such at this point in time I
would just like to know if its supported or not.

I have no problem throwing another number of hours googeling at it trying to
figure out what I did wrong and what I need to do instead, but would like to
forgo the possibility that its simply not supported (and as such would just
be wasting my time, getting more and more frustrated :-( ).

Regards,
Rudy Wieser

On 2023-06-25 19:27, R.Wieser wrote:
> Hello all,
>
> I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
> no GUI of any kind.
>
> I ofcourse wanted to see if I could draw some graphics on it. :-)
>
> I've found that it supports a "Frame Buffer" onto which pixels can be
> plotted.
>

I got one of these
pi@raspberrypi:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2835
Revision : 000e
Serial : 000000000304c6ef
Model : Raspberry Pi Model B Rev 2
pi@raspberrypi:~ $

running

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@raspberrypi:~ $

which uses the frambuffer - via SDL- via pygame

I have this in the header - migth be valid urls still
""
Pygame base template for opening a window

Sample Python/Pygame Programs
Simpson College Computer Science
http://programarcadegames.com/
http://simpson.edu/computer-science/

Explanation video: http://youtu.be/vRB_983kUMc
"""

I think the relevant part is ( edited and untested)

import os
import pygame

def puts(what,size,x,y):
font = pygame.font.SysFont("freserif", size)
color = WHITE
text = font.render(what, True, color)
screen.blit(text, (x - text.get_width() // 2, \
y - text.get_height() // 2))

os.environ["SDL_FBDEV"] = "/dev/fb1"
pygame.init()
# Set the width and height of the screen [width, height]
size = (320, 240)
screen = pygame.display.set_mode(size)
pygame.mouse.set_visible(0)
done = False
# -------- Main Program Loop -----------
while not done:
try:
for event in pygame.event.get():
if event.type == pygame.QUIT:
done = True
elif event.type == pygame.KEYDOWN \
and event.key == pygame.K_ESCAPE:
done = True

# --- Game logic should go here

# --- Screen-clearing code goes here

screen.fill(BLACK)

#get data to draw

# --- Drawing code should go here
puts(str(int(today['total'])), 150, 160, 60)
puts(str(int(this_week['total'])), 75, 80, 140)
puts(str(int(last_week['total'])), 75, 80, 200)
puts(str(int(this_month['total'])), 75, 240, 140)
puts(str(int(last_month['total'])), 75, 240, 200)
# --- Go ahead and update the screen with what we've drawn.
pygame.display.flip()

pygame.quit()
exit()

--
/Björn

Bj�rn,

> I think the relevant part is ( edited and untested)
>
[snip]

Thank you for that code. But I'm looking for something a bit more low-level
than that.

I've already written most of what you have there in plain C, but would like
to replace some of my own solutions with whats already available as part of
the "frame buffer" support.

Hardware instead of a software mouse pointer. Makes the drawing other stuff
much easier. The mentioned _iowr() call to draw a (filled) rectangle
instead of iterating over all the pixels myself. Perhaps other drawing
stuff if available (lines ? (filled) circles ? Anything goes).

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
> Computer Nerd Kev wrote:
>> If the aim is to go the lowest-level route,
>
> Not really. Currently I just want to get it to work thru the available
> "frame buffer" methods.
>
> The problem is that that "fb.h" file /looks/ to be saying such support is
> available, but I can't get it to work. As such at this point in time I
> would just like to know if its supported or not.

OK right, you're talking about the Linux framebuffer rather than
the GPU framebuffer, which the Linux framebuffer writes to. I see
now that this is the fb.h file that you mean:
https://github.com/torvalds/linux/blob/master/include/linux/fb.h

I guess this is what you're interested in:
/* Draws cursor */
int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);

I guess that _might_ be supported on the Pi via the KMS/DRM driver,
but this suggests that it's at least possible for it not to use
hardware acceleration:
https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c

Maybe one of the results here is a good example of using the
framebuffer cursor?
https://codesearch.debian.net/search?q=fb_cursor

--
__ __
#_ < |\| |< _#

Kev,

> I see now that this is the fb.h file that you mean:
> https://github.com/torvalds/linux/blob/master/include/linux/fb.h

Not quite the same one. Mine seems to be a bit simpler, and starts with :

- - - - - - - - - - - - - - - - - - - -
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _LINUX_FB_H
#define _LINUX_FB_H

#include <linux/types.h>
#include <linux/i2c.h>

/* Definitions of frame buffers */

#define FB_MAX 32 /* sufficient for now */

/* ioctls
0x46 is 'F' */
#define FBIOGET_VSCREENINFO 0x4600
#define FBIOPUT_VSCREENINFO 0x4601
- - - - - - - - - - - - - - - - - - - -

> I guess this is what you're interested in:
> /* Draws cursor */
> int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);

Something like it :
- - - - - - - - - - - - - - - - - - - -
#define FBIO_CURSOR _IOWR('F', 0x08, struct fb_cursor)
- - - - - - - - - - - - - - - - - - - -

IOW, I've got the call and the struct(s) (a bit lower in the file), but am
struggeling with filling the struct(s) with the correct data. Or maybe I
have done that, but my Rpi simply doesn't support it. And I've got no idea
how to check for the latter. Frustrating to say the least.

> I guess that _might_ be supported on the Pi via the KMS/DRM
> driver, but this suggests that it's at least possible for it
> not to use hardware acceleration:
> https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c

I found that one too, but as the name already suggests, that seems to be for
an emulated mouse cursor. That one I already wrote myself. :-)

And although I thought I could at least extract the method with which it
draws stuff on the canvas, the part ending with
"info->fbops->fb_imageblit(info, image);" has way to much stuf in there that
I have no idea what exactly it is doing (using GCC here). :-|

> Maybe one of the results here is a good example of using the
> framebuffer cursor?
> https://codesearch.debian.net/search?q=fb_cursor

Whoa, 26 pages of it ... That will take me quite some time to get thru it
all, even when I skip the C++ snippets.

Thanks for that, I don't think I've ever used that "codesearch" engine.

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
> Kev,
>
>> I see now that this is the fb.h file that you mean:
>> https://github.com/torvalds/linux/blob/master/include/linux/fb.h
>
> Not quite the same one. Mine seems to be a bit simpler, and starts with :

OK, this must be it:
https://github.com/torvalds/linux/blob/master/include/uapi/linux/fb.h

>> I guess this is what you're interested in:
>> /* Draws cursor */
>> int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);
>
> Something like it :
> - - - - - - - - - - - - - - - - - - - -
> #define FBIO_CURSOR _IOWR('F', 0x08, struct fb_cursor)
> - - - - - - - - - - - - - - - - - - - -
>
> IOW, I've got the call and the struct(s) (a bit lower in the file), but am
> struggeling with filling the struct(s) with the correct data. Or maybe I
> have done that, but my Rpi simply doesn't support it. And I've got no idea
> how to check for the latter. Frustrating to say the least.

Yes, and not having programmed for the Linux framebuffer I can't
help much myself. But the key thing is that this is the _Linux_
framebuffer, not the hardware framebuffer. So it's hardware
independent and there isn't a question over whether your RPi
supports it. The same code writing to the Linux framebuffer should
display on RPi, PC, or even on a custom display panel that
someone's written a framebuffer driver for.

>> I guess that _might_ be supported on the Pi via the KMS/DRM
>> driver, but this suggests that it's at least possible for it
>> not to use hardware acceleration:
>> https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/core/softcursor.c
>
> I found that one too, but as the name already suggests, that seems to be for
> an emulated mouse cursor. That one I already wrote myself. :-)

You missed my point. That's in the framebuffer driver code, so when
you do all this to move the cursor via the Linux framebuffer, the
Linux kernel probably just runs that code to "emulate" a hardware
mouse cursor in software. The framebuffer driver on the RPi isn't
necessarily good enough to have implemented the hardware
acceleration so you might be better off just using your own
software mouse cursor code.

I don't know how to rule in/out there being RPi hardware cursor
support in the Linux source code. If it's there then it isn't
obvious, but these things often aren't. Apparantly in 2014 it
wasn't there, because this RPi software engineer published a
modified version of the slightly-RPi-accelerated "fbturbo"
framebuffer driver which added hardware mouse cursor support:
https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

Note that the thread ends before the matching GPU firmware binary
was released. Did it get included in a later GPU firmware version,
or was it abandoned? If the firmware wasn't released then the
thread makes it clear that the hardware cursor didn't work without
it.

Or maybe it was released and supported somewhere in the main Linux
framebuffer driver that's used now on the RPi. These mysteries are
all too hard to figure out, so you'll have to do that yourself.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> I don't know how to rule in/out there being RPi hardware cursor
> support in the Linux source code. If it's there then it isn't
> obvious, but these things often aren't. Apparantly in 2014 it
> wasn't there, because this RPi software engineer published a
> modified version of the slightly-RPi-accelerated "fbturbo"
> framebuffer driver which added hardware mouse cursor support:
> https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490
>
> Note that the thread ends before the matching GPU firmware binary
> was released. Did it get included in a later GPU firmware version,
> or was it abandoned? If the firmware wasn't released then the
> thread makes it clear that the hardware cursor didn't work without
> it.
>
> Or maybe it was released and supported somewhere in the main Linux
> framebuffer driver that's used now on the RPi. These mysteries are
> all too hard to figure out, so you'll have to do that yourself.

Gah, I mixed up the kernel framebuffer driver and the X framebuffer
driver (both called fbdev). fbturbo is the accelerated X
framebuffer driver, and indeed the version with the accelerated
cursor support was released and working with the GPU firmware in
2014:
https://forums.raspberrypi.com/viewtopic.php?t=69926

So you can't use that fbturbo driver, but _if_ similar code is in
the Linux kernel's RPi framebuffer driver somewhere then it might
be used. If not, then you might as well draw the cursor with your
own code (or use X if you really need the hardware acceleration).

--
__ __
#_ < |\| |< _#

Kev,

> But the key thing is that this is the _Linux_
> framebuffer, not the hardware framebuffer. So it's hardware
> independent and there isn't a question over whether your RPi
> supports it. The same code writing to the Linux framebuffer
> should display on RPi, PC, or even on a custom display panel
> that someone's written a framebuffer driver for.

Don't be too sure about that. I've seen quite a number of implementations
which only code is returning a constant value.

> You missed my point.
....
> The framebuffer driver on the RPi isn't necessarily good enough
> to have implemented the hardware acceleration so you might be
> better off just using your own software mouse cursor code.

Thats the RPi doesn't have hardware support is quite possible, though the
"fb.h" file seems to hit at it being present. As such the absense of any
way to check (directly or indirectly) for supported features is ... not
funny.

Heck, I can't even seem to find any documentation on what the returned value
means. And that /really/ bugs me.

> because this RPi software engineer published a modified version
> of the slightly-RPi-accelerated "fbturbo" framebuffer driver which
> added hardware mouse cursor support:
> https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

I think I've come across that name too, but as with the other
bits-and-pieces I found there does not seem to be any testing code around
that shows its usage.

I followed the link to james "hwcursor.c" code, and noticed its from 2014.
In Rpi time thats pretty-much the stone age era (I'm using bullseye, which
is rather recent).

> Or maybe it was released and supported somewhere in the main
> Linux framebuffer driver that's used now on the RPi. These
> mysteries are all too hard to figure out, so you'll have to
> do that yourself.

:-) I /know/ its too hard to figure out for me, which is why I posted my
question here.

I think I'm going to throw the towel, and just assume that the only support
my framebuffer has is copying something from one place on the screen to
another, and that everything else - even if I've seen some of them marked as
required - needs to be written yourself.

Oh well. Thanks for the help.

Regards,
Rudy Wieser

Computer Nerd Kev <not@telling.you.invalid> wrote:
> R.Wieser <address@is.invalid> wrote:
> > Kev,
> >
> >> I see now that this is the fb.h file that you mean:
> >> https://github.com/torvalds/linux/blob/master/include/linux/fb.h
> >
> > Not quite the same one. Mine seems to be a bit simpler, and starts with :
>
> OK, this must be it:
> https://github.com/torvalds/linux/blob/master/include/uapi/linux/fb.h

The Pi kernel is a separate tree:
https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/linux/fb.h
that one looks quite different to the fb.h in mainline Linux.

> Yes, and not having programmed for the Linux framebuffer I can't
> help much myself. But the key thing is that this is the _Linux_
> framebuffer, not the hardware framebuffer. So it's hardware
> independent and there isn't a question over whether your RPi
> supports it. The same code writing to the Linux framebuffer should
> display on RPi, PC, or even on a custom display panel that
> someone's written a framebuffer driver for.

The mainline fb.h looks full of 90s-era VGA-related stuff. There's some
mention of ARM chips, but they're all 15+ years old.

In general terms, many framebuffers don't support a hardware pointer -
they're just dumb framebuffers after all. It looks like support has been
added to the Pi version for that.

The Pi hardware doesn't support a hardware pointer either, but AIUI the GPU
handles drawing it for you. So it's effectively a fake hardware pointer,
it's just drawn by something that isn't the OS.

(traditionally, hardware pointers are drawn on top of the raster scanout.
Here the GPU is doing a full image composite instead, so that's not really a
'hardware' pointer, it's just an API call to the GPU)

> You missed my point. That's in the framebuffer driver code, so when
> you do all this to move the cursor via the Linux framebuffer, the
> Linux kernel probably just runs that code to "emulate" a hardware
> mouse cursor in software. The framebuffer driver on the RPi isn't
> necessarily good enough to have implemented the hardware
> acceleration so you might be better off just using your own
> software mouse cursor code.
>
> I don't know how to rule in/out there being RPi hardware cursor
> support in the Linux source code. If it's there then it isn't
> obvious, but these things often aren't. Apparantly in 2014 it
> wasn't there, because this RPi software engineer published a
> modified version of the slightly-RPi-accelerated "fbturbo"
> framebuffer driver which added hardware mouse cursor support:
> https://forums.raspberrypi.com/viewtopic.php?t=65037&start=25#p490490

SFAIK the RPi folks added the 'hardware cursor' support as GPU-side
software, to support operating systems like RISC OS which are designed
around a hardware pointer. For that (on bare metal) you use the GPU
mailboxes to send a VCHIQ message to the GPU.

I think FBIO_CURSOR in that fb.h file is a red herring: it's been there
since 29 July 2004, which means the _IOWR is an I/O write that's nothing to
do with the Pi, most likely related to some of the VGA-compatible hardware
that was in use at the time.
https://github.com/tbodt/linux-history/commit/53699287a25ea8c6d3a3f1b3404d8ebbcba6b580

I think if you want to use this from modern Linux (not via this legacy
framebuffer stuff) you need to interact with the DRM (direct rendering
manager) kernel subsystem via the KMS (kernel mode setting) interface:
https://en.wikipedia.org/wiki/Direct_Rendering_Manager

Theo

Theo,

> The Pi hardware doesn't support a hardware pointer either, but AIUI
> the GPU handles drawing it for you.

Do you have any (example) code which tells the GPU to do that ? 'Cause I
can't seem to find any (might be because I don't recognise it though :-| ).

And if that is so, how does it work with frame buffer (memory) writes ? How
does the {whatever} know when it should remove the fake cursor so the image
beneath it can be altered ?

Curently I have to disable (remove) my fake cursor before, and than enable
(draw) it again after each action which changes the frame buffer memory.

> I think FBIO_CURSOR in that fb.h file is a red herring:

I've gotten that feeling too.

By the way, if you know any other frame buffer manipulation calls (draw
(filled) rectangles and circles, draw an image, draw lines(?) ) I would like
to hear about them. Even better if you happen to have a link to a Raspberry
Pi specific documentation of it. :-)

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
> Theo,
>
> > The Pi hardware doesn't support a hardware pointer either, but AIUI
> > the GPU handles drawing it for you.
>
> Do you have any (example) code which tells the GPU to do that ? 'Cause I
> can't seem to find any (might be because I don't recognise it though :-| ).

I think it would be somewhere in the vc_dispmanx APIs, but I'm not seeing it
here:
https://github.com/raspberrypi/userland/tree/master/interface/vmcs_host

I pointed upthread to the RISC OS code which uses it, but that's not Linux.

> And if that is so, how does it work with frame buffer (memory) writes ?
> How does the {whatever} know when it should remove the fake cursor so the
> image beneath it can be altered ?

It's composited on top by the GPU, ie the framebuffer has no cursor, the
GPU draws the cursor on top of the framebuffer when the screen is
composited. You just give the GPU a pointer to the cursor bitmap and the
X/Y coordinates.

> By the way, if you know any other frame buffer manipulation calls (draw
> (filled) rectangles and circles, draw an image, draw lines(?) ) I would like
> to hear about them. Even better if you happen to have a link to a Raspberry
> Pi specific documentation of it. :-)

Look at OpenVG which offers 2D graphics operations:
https://en.wikipedia.org/wiki/OpenVG
https://github.com/cboyer/openvg-rpi

Supposedly OpenVG has been dropped from the Pi 4 (which uses a different GPU
to 0/1/2/3). These days it's better to use 3D operations (eg OpenGL) for 2D
drawing. There are some implementations of OpenVG on top of OpenGL:
https://forums.raspberrypi.com/viewtopic.php?t=245380

Theo

R.Wieser <address@is.invalid> wrote:
>> The Pi hardware doesn't support a hardware pointer either, but AIUI
>> the GPU handles drawing it for you.
>
> Do you have any (example) code which tells the GPU to do that ? 'Cause I
> can't seem to find any (might be because I don't recognise it though :-| ).

Well you said you already saw the fbturbo implementation:
https://github.com/JamesH65/xf86-video-fbturbo/blob/master/src/raspi_hwcursor.c

OK it's from 2014, but I doubt they would have changed the commands
used by the GPU, and they're what matter.

--
__ __
#_ < |\| |< _#

Theo,

> I think it would be somewhere in the vc_dispmanx APIs, but I'm not seeing
> it here:
> https://github.com/raspberrypi/userland/tree/master/interface/vmcs_host
>
> I pointed upthread to the RISC OS code which uses it, but that's not
> Linux.

I guess I could take a look and see if I can find any "frame buffer" calls
in there ... Hmm, a quick look in all the .C files doesn't show any frame
buffer related includes.

> It's composited on top by the GPU, ie the framebuffer has no cursor,
> the GPU draws the cursor on top of the framebuffer when the screen is
> composited.

That suspiciously sounds like mouse pointer hardware support. :-)

> Look at OpenVG which offers 2D graphics operations:

Thank you for the link. Though my current objective is to try to find out
as much as I can about what "frame buffer" supports.

At some point in the future I might just install OpenGL or alike and bin my
own attempts to create something usefull, but today isn't the day.

Hobbyists are weird : they can spend untold hours upon recreating what
already exists (even in a better form) and see nothing wrong with it. I'm a
hobby programmer. :-)

Regards,
Rudy Wieser

Kev,

> Well you said you already saw the fbturbo implementation:

I did.

> OK it's from 2014, but I doubt they would have changed the
> commands used by the GPU, and they're what matter.

The thing is that that is, AFAIK, what "frame buffer" support is build ontop
of. With it doing some of the abstractions which would enable a program
written using it to run on different hardware configurations.

Going down a level from "frame buffer" support to using the "mailbox" way of
sending commands is something I've not yet tried.

Though I might try to rewrite all the "frame buffer" stuff I've currently
got using that "mailbox" method. Who knows. Currently my focus is "frame
buffer", trying to find out what exactly it offers me and how to use it.

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
> Though I might try to rewrite all the "frame buffer" stuff I've currently
> got using that "mailbox" method. Who knows. Currently my focus is "frame
> buffer", trying to find out what exactly it offers me and how to use it.

Traditionally, framebuffer is exactly that. A pointer to an W x H sized
block of pixels, which is displayed on the screen. That's it. Nothing
else. If you want to draw stuff on it, it's up to you to manipulate the
pixels. If you want to double buffer, change the pointer to a different WxH
block of pixels.

Some graphics cards (eg VGA) have 'extra stuff' which know about things like
fonts or pointers, but that's not the framebuffer, it's down to the VGA or
other driver. In the Pi's case that's the VideoCore and the VCHIQ APIs, but
they're not standard.

So if you're looking for these things inside the framebuffer code you won't
find them. If you do want more stuff you need to explore DRM/KMS (as a
generic Linux kernel API) or VCHIQ (for Pi specific things).

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> R.Wieser <address@is.invalid> wrote:
>> Though I might try to rewrite all the "frame buffer" stuff I've currently
>> got using that "mailbox" method. Who knows. Currently my focus is "frame
>> buffer", trying to find out what exactly it offers me and how to use it.
>
> Traditionally, framebuffer is exactly that. A pointer to an W x H sized
> block of pixels, which is displayed on the screen. That's it. Nothing
> else. If you want to draw stuff on it, it's up to you to manipulate the
> pixels. If you want to double buffer, change the pointer to a different WxH
> block of pixels.

Exactly, and "traditionally" it's actually a hardware address for
unaccelerated display of bitmaps via the graphics card. Accelerated
things like the mouse cursor are done on top of this. The _Linux_
framebuffer is a pretend version of that, so if any acceleration
features did exist, they'd be sort-of a bonus, becuase they're not
really the intention, which is a hardware-independent version on
the physical framebuffer.

Of course a look at the Framebuffer page on Wikipedia explains all
this already.

This is why I originally assumed that R.Wieser _was_ talking about
the Pi's hardware framebuffer, instead of the Linux one. He still
insists on not specifying which one he's talking about when talking
about "the frame buffer stuff" in his posts. Somewhat frustrating.

--
__ __
#_ < |\| |< _#

Theo,

> Traditionally, framebuffer is exactly that. A pointer to an W x H
> sized block of pixels, which is displayed on the screen.

That part I've got down. Drawing lines, (filled) rectangles, (filled)
circles, clipping and a software mouse cursor. Still working at filled
polygons. Convex works, concave takes some more work.

The whole thing is that the "fb.h" file on my machine hints at support for a
few things, like a hardware mouse cursor, drawing a (filled?) rectangle,
drawing an image, panning the screen, copying one part of the screen to
another part and a few others.

IOW, the same include file which contains the declarations that are needed
to be able to create access to such a user-land pixel memory also contains
hints to support for other stuff. And the usage of that other stuff is
what I'm currently trying to figure out.

> So if you're looking for these things inside the framebuffer code you
> won't find them.

I already found them. In many implementations. Though some of them just
contain "return -EINVAL;" for a number of the calls. :-|

Currently all I'm doing is looking at the API - and only at a number of
implementations to figure out how to use it.

And thats also part of the problem : I have no idea which of those
implementations is the one used by bullseye or even if its actually among
them. If I had the code it would be rather easy to figure out what, and
what isn't supported.

Regards,
Rudy Wieser

Kev,

> This is why I originally assumed that R.Wieser _was_ talking
> about the Pi's hardware framebuffer, instead of the Linux one.
> He still insists on not specifying which one he's talking about
> when talking about "the frame buffer stuff" in his posts.

I had hoped that all the info I included in my first post would have cleared
that up. You know, "fb.h", "_iowr()", "FBIOCOPYAREA" and "fb_copyarea".

And thats besides the several times I tried to explain at what level I'm
working at. Including the "With it doing some of the abstractions which
would enable a program written using it to run on different hardware
configurations." and "Though I might try to rewrite all the "frame buffer"
stuff I've currently got using that "mailbox" method." that I wrote in my
previous message.

But to clear that confusion up, I am talking about the (what I /assume/ you
mean with) "the linux one".

A question tough : "the Pi's hardware framebuffer" ? As in the same thing
with the same API/hardware adresses for *all* the different RPi versions ?
In that case it could be worth some time to take a peek at it.

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
>> This is why I originally assumed that R.Wieser _was_ talking
>> about the Pi's hardware framebuffer, instead of the Linux one.
>> He still insists on not specifying which one he's talking about
>> when talking about "the frame buffer stuff" in his posts.
>
> I had hoped that all the info I included in my first post would have cleared
> that up. You know, "fb.h", "_iowr()", "FBIOCOPYAREA" and "fb_copyarea".

There's many a fb.h file out there, just do a web search and you'll
see. Code found by searching for "fb.h raspberry pi" is mostly
working with the hardware framebuffer, rather than the Linux one.
Either way I wasn't going to read every fb.h that I could find just
to see whether the contents matched all the symbols you happened to
mention.

If you'd provided a link, or the full path where it was installed
by a RPi OS package, in the first post, then there needn't have
been any guessing.

> A question tough : "the Pi's hardware framebuffer" ? As in the same thing
> with the same API/hardware adresses for *all* the different RPi versions ?
> In that case it could be worth some time to take a peek at it.

Like the GPIO and other peripherals, different versions have
different physical addresses for the different Pis. RPi 1 and Zero
uses a base address of 0x20000000. RPI 2, 3, and Zero 2 is
0x3F000000. That changes the addresses for the mailbox registers as
shown in register maps.

For the framebuffer itself, the GPU will actually allocate an area
of memory for it upon request and tell you the starting address
that it's chosen. As such you have to assume that the address might
be different every time you initialise it, and use the pointer it
gives you via the mailbox interface (but you need to convert it
from a bus address (0x7E000000) to a physical address (as above)).

https://elinux.org/RPi_Framebuffer

The RPi 4 GPU is VideoCore VI, rather than VideoCore IV for the
other Pis. I don't know much about it. Most docs don't seem to have
been updated to cover it yet.

--
__ __
#_ < |\| |< _#

Kev,

> There's many a fb.h file out there,

And you never thought of trying to match it up with the device this
newsgroup is for ? <surprised face>

> If you'd provided a link,

You mean as I pretty-much did at Tue, 27 Jun 2023 08:46:40 +0200 in message
<u7e0l1$1auoe$1@dont-email.me> ?

> or the full path where it was installed by a RPi OS package, in
> the first post, then there needn't have been any guessing.

you mean the first line in my initial post where I said :

[quote]
I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
no GUI of any kind.
[/quote]

As for the path ? Why would you need that ? I provided the name "fb.h"
there too, and with it should be easy to find. On my system there is only
one.

>> A question tough : "the Pi's hardware framebuffer" ? As in the same
>> thing with the same API/hardware adresses for *all* the different RPi
>> versions ?
>> In that case it could be worth some time to take a peek at it.
>
> Like the GPIO and other peripherals, different versions have
> different physical addresses for the different Pis.

My apologies, I see I could have been a bit more precise : AFAIK I have to
*ask* the RPi for a/the (hardware) framebuffer, and than map it into user
space. After it is mapped you have to use the address returned by that
mapping function - just as for the 'linux" framebuffer. Am I wrong there ?

My question was aimed at if the place to send such requests to and the
format of those requests is the same for all RPi versions.

In fact, that is the problem I tried to evade by limiting myself (for the
moment) to the "linux" framebuffer. I took it that if differences would be
there than that API would handle them.

Full disclosure : I've been programming direct (basic) hardware since
forever, and only got taken that outof my hands by Windows (where I wasn't
permitted direct access to it anymore). :-|

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
>> There's many a fb.h file out there,
>
> And you never thought of trying to match it up with the device this
> newsgroup is for ? <surprised face>

Now this is getting silly, but I'll repeat the bit you snipped
from my last post:

Code found by searching for "fb.h raspberry pi" is mostly
working with the hardware framebuffer, rather than the Linux one.

>> If you'd provided a link,
>
> You mean as I pretty-much did at Tue, 27 Jun 2023 08:46:40 +0200 in message
> <u7e0l1$1auoe$1@dont-email.me> ?

No, not provide an extract, a link/path. It happened to be that I
could do a web search on a bit of that and found out that you were
using a "fb.h" header file provided by Linux. There was no
indication of that earlier in the thread, so I assumed that fb.h
was from one of the hardware framebuffer libraries seeing as you
were talking about hardware acceleration.

>> or the full path where it was installed by a RPi OS package, in
>> the first post, then there needn't have been any guessing.
>
> you mean the first line in my initial post where I said :
>
> [quote]
> I've got a RPi 1B rev1, onto which I've installed "bullseye lite", meaning
> no GUI of any kind.
> [/quote]
>
> As for the path ? Why would you need that ? I provided the name "fb.h"
> there too, and with it should be easy to find. On my system there is only
> one.

How do I know your system? It may be "bullseye lite", but I assume
you've installed and downloaded other things onto it, and you never
said you were using fb.h from Linux so it could easily be from
some library or other that you've installed via a package or source
code download. The path would have answered that.

Anyway I've seen others have similar arguments with you about being
unclear in your questions on Usenet, so I guess it's pointless.

>>> A question tough : "the Pi's hardware framebuffer" ? As in the same
>>> thing with the same API/hardware adresses for *all* the different RPi
>>> versions ?
>>> In that case it could be worth some time to take a peek at it.
>>
>> Like the GPIO and other peripherals, different versions have
>> different physical addresses for the different Pis.
>
> My apologies, I see I could have been a bit more precise : AFAIK I have to
> *ask* the RPi for a/the (hardware) framebuffer, and than map it into user
> space. After it is mapped you have to use the address returned by that
> mapping function - just as for the 'linux" framebuffer. Am I wrong there ?

That's correct.

> My question was aimed at if the place to send such requests to and the
> format of those requests is the same for all RPi versions.

"The place to send such requests" is the mailbox peripheral, and
the format is the same for the all the VideoCore IV Pis, which
currently means all the models except maybe those based on the Pi
4, which uses VideoCore VI (different GPU hardware, so many things
changed, maybe including how the framebuffer works).

> In fact, that is the problem I tried to evade by limiting myself (for the
> moment) to the "linux" framebuffer. I took it that if differences would be
> there than that API would handle them.

Sometimes you try to avoid a hassle only to create another one.
Using the Linux Framebuffer but still wanting some hardware
acceleration might be such a case.

--
__ __
#_ < |\| |< _#