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.
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.
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.
If the aim is to go the lowest-level route,
Having said all this, you're on Linux not baremetal so I think
a better way would be to use some existing library.
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 think the relevant part is ( edited and untested)
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.
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 :
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. :-)
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.
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.
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.
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
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.
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
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.
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
The Pi hardware doesn't support a hardware pointer either, but AIUI
the GPU handles drawing it for you.
I think FBIO_CURSOR in that fb.h file is a red herring:
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 ?
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. :-)
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:
OK it's from 2014, but I doubt they would have changed the
commands used by the GPU, and they're what matter.
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.
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.
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.
Look at OpenVG which offers 2D graphics operations:
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.
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.
Traditionally, framebuffer is exactly that. A pointer to an W x H
sized block of pixels, which is displayed on the screen.
So if you're looking for these things inside the framebuffer code you
won't find them.
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".
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.
There's many a fb.h file out there,
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.
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.
Code found by searching for "fb.h raspberry pi" is mostly
working with the hardware framebuffer, rather than the Linux
one.
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.
How do I know your system? It may be "bullseye lite", but I assume
you've installed and downloaded other things onto it,
Anyway I've seen others have similar arguments with you about being
unclear in your questions on Usenet, so I guess it's pointless.
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).
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.
Computer Nerd Kev <not@telling.you.invalid> wrote:[snip]
How do I know your system? It may be "bullseye lite", but I assume
you've installed and downloaded other things onto it,
It would have been a good idea to verify that with me, 'cause no, I haven't.
As for "Unclear in your question" accusations ? Funny that those only turn up way down in a thread, and never are preceeded by any kind of "I don't quite get the question, can you explain {this} or {that}". IOW, mostly coming from people who didn't understand (for whatever reason) the question, ultimatily getting told of (by me) for it, and than try to make it sound as if its my fault.
Sometimes you try to avoid a hassle only to create another one.
If I could only see into the future, than I would just know when to pursue a certain avenue and when to switch to another ...
In my opinion your questions are often too hard to interpret
correctly.
Maybe someone would ask back 100 yes/no questions
Especially because I doubt you're understanding me either - you must
have installed a compiler in your "bullseye lite" at least.
Sometimes you try to avoid a hassle only to create another one.
If I could only see into the future, than I would just know when to
pursue a
certain avenue and when to switch to another ...
Sorry, "you" wasn't supposed to be personal.
I'm just making the point that the "easy way" with the Linux framebuffer might actually be harder if you want hardware acceleration.
But be honest, look at the subjectline and tell me that that is a difficult >question.
But be honest, look at the subjectline and tell me that that is a
difficult question.
It is if one does not know /which/ flavor of framebuffer is in play.
Maybe someone would ask back 100 yes/no questions
A single question to start with would have been enough : "did you install
any packages".
Especially because I doubt you're understanding me either - you must
have installed a compiler in your "bullseye lite" at least.
Thats another assumption with which you have created a new hassle for yourself. I understood your question quite well. I said I didn't install any packages and I haven't. The GCC compiler came as part of the "bullseye lite" OS package.
And isn't including a GCC (or alike) into an OS package quite common ?
I'm just making the point that the "easy way" with the Linux framebuffer
might actually be harder if you want hardware acceleration.
How, and even /why/ do you think so ?
You've been able to look in that "fb.h" file. In it is the call as well as the arguments definition. It looks quite easy to me.
And no, that its not supported(?) by BullsEye's linux framebuffer has no bearing on that.
Besides, the same goes here : it /might/, but it could as easily be another method (the "mailbox" one?) which could turn out to be harder.
In short, you've succumbed to FUD. Don't. All it does is freezing you, not allowing you to try (and learn!) /anything/.
As an example, I wrote a software mouse cursor before even posting here. Which I'm sure is harder than just activating a hardware one. I still wrote it, if only to find out how complex / much work it actually is. It turns
out its not reallly either.
... But I still wanted to know how the other, hardware method works - so I can compare, learn and have a choice.
A single question to start with would have been enough : "did you
install any packages".
Nope, you could have downloaded fb.h manually from the web, so I'd
need to ask that too.
[you don't have to answer these questions - they're an example
for how you could make your future first posts less ambiguous]
Also to be sure I should have asked the full name/version of the OS
because "bullseye lite" refers to a Debian release - "Bullseye".
Theo assumed that you were talking about Raspberry Pi OS, but
officially its versions are named after dates, eg. the latest would
be "Raspberry Pi OS Lite 2023-05-03".
I should have asked what programming language you were using. It
was a C header, but you could have been using/preferring C++ or
any another language that has bindings to C.
I should have asked if you only wanted your program to run on
the RPi 1B rev1, or whether compatibility with other RPi models
mattered as well.
I should have asked whether software compatibility with other
non-RPi platforms mattered as well.
Maybe I should have asked whether you were running the OS in
a virtual environment, just in case you're actually running
an x86 emulator in QEMU so that you can run x86 Debian Bullseye,
and want to pass the mouse acceleration through all the layers of
Linux/QEMU framebuffer emulation?
I could go on, but the conclusion is obvious: I shouldn't bother
answering your questions if you expect me to resolve every single
point of uncertainty rather than assuming that you use RPis in a
common way,
Good, my concern was only that you would stick at the Linux framebuffer
now and ignore the hardware one simply because the Linux one looked easier
_before_ you realised that it wasn't properly documented and didn't
"just work" for hardware mouse acceleration.
An unfounded concern, perhaps.
Perhaps. Though I must say that my eagerness to also figure that "mailbox" method out has been tampered by knowing that if I need to ask a question about it I will probably experience something similar as what we have now.
Besides, I think that that "mailbox" method /might/ be harder, and you have told me not to bother with such "might be harder" things. Aren't you glad that I, for once, heed your advice ? :-)
Regards,
Rudy Wieser
If you where doubting for any reason I would not be using the default >programming language for an RPI you could surely have asked for it.
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.
As far as I know hardware mouse support is something that may or
may not exist depending on the underlying implementation of the
framebuffer device.
I did come across this presentation with links to a lot of
software using the framebuffer which you may find useful. <https://archive.fosdem.org/2020/schedule/event/fbdev/attachments/slides/3595/export/events/attachments/fbdev/slides/3595/fosdem_2020_nicolas_caramelli_linux_framebuffer.pdf>
Rudy, you have discovered how helpful this newsgroup is
and how welcoming to newcomers looking for guidance!
As a learning device for embedded computers, the "default
programming language" pushed by the R-Pi foundation is... PYTHON
Dennis,
As a learning device for embedded computers, the "default
programming language" pushed by the R-Pi foundation is... PYTHON
:-) I know a series of "learning programming devices" (often
microcontroller based), and they all have their own preferred scripting language. Some even using pictograms instead of words.
However, the default programming language for *Linux* still seems to be C, with most
often GCC as its compiler.
Regards,
Rudy Wieser
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
Not sure where the problem is,
Jan,
Not sure where the problem is,
I just want to know how to use the "linux frame buffer" API myself. The >problem is that somehow some people have a problem understanding that.
After that I can always install another something which will give me even >easier graphics access. But that will than probably be OpenGL. Supports 3D >too.
Regards,
Rudy Wieser
Hardware support .. why bother, frame is updated many times
per second. cursor is just a few pixels...?
delete old pixels draw a new one... in the buffer.
Jan,
Not sure where the problem is,
I just want to know how to use the "linux frame buffer" API myself. The problem is that somehow some people have a problem understanding that.
At least now you're specifying which frame buffer you mean
What irked me before was that you didn't do so even after
the problems with understanding had arisen.
On 07/07/2023 09:02, R.Wieser wrote:
Kev,That depends on if it is you that wants help...
At least now you're specifying which frame buffer you mean
Only after someone told me that that was the one I most likely ment
with all
my initialy given information (I'm still wondering how some, given that
info, could have assumed I would be referring to another one, hardware or
otherwise.).
What irked me before was that you didn't do so even after
the problems with understanding had arisen.
At some point you understood which one I ment, but you still needed me to
call it by its full name instead of the short one ? That sounds like
your
problem, not mine.
Regards,
Rudy Wieser
Kev,
At least now you're specifying which frame buffer you mean
Only after someone told me that that was the one I most likely ment with all my initialy given information (I'm still wondering how some, given that
info, could have assumed I would be referring to another one, hardware or otherwise.).
What irked me before was that you didn't do so even after
the problems with understanding had arisen.
At some point you understood which one I ment, but you still needed me to call it by its full name instead of the short one ? That sounds like your problem, not mine.
Regards,
Rudy Wieser
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 158:58:28 |
| Calls: | 3,036 |
| Calls today: | 4 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 294,083 |
| Posted today: | 0 |
