Does the RPi 1B rev1 Framebuffer have hardware support for a mouse cursor ?

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.

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

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)).

Kev,

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

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

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.

My apologies, I see I could have been a bit more precise : AFAIK I have to

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

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.

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.

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.

That's correct.

"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

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.

Kev,

I noticed the same. I also noticed that most of the returned results had little, if anything, to do with an RPi. In short : for someone like me who's searching for something *relevant to the RPi* its next to worthless, as info pertaining to the RPi is seldom-if-ever marked as such, and thus drowns in a series of codesamples all allmost, but not exactly the same. :-(

... and thats while already having ignored "results" like "the nearest baker to you" and similar crap.

Or, in other words: I have not been able to find "linux frame buffer" code relevant to the RPi. If I would have I could rather likely have spotted if the hardware cursor would be supported or not, and which other basic graphic actions (rectangle, image, etc) would be available - and by inspecting how the implementation of them handles their arguments be able to figure out how to invoke them.

... and I would never have posted here ...

Ah, you wanted me to find the same file on the internet and so that way you could look at it yourself. It would have been a good idea to tell me that.

As for that "you were using a "fb.h" header file provided by Linux." ? Even with just the info I supplied in my initial post (or just looking at the subjectline of this thread!) /what else/ would I have been using than Linux ?

It would have been a good idea to verify that with me, 'cause no, I haven't. As such your assumption just made your task more difficult for you than need be, and as a result more difficult for me.

I had no idea why you would ask me for that path when you do not seem to run an RPi (with bullseye), and as such would be unable to inspect that file.

... Which is why I posted the first few lines of it, so you could see that your and my files where not equal.

And I've seen you being unclear in what you needed from me, so I guess we are on an equal footing there.

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.

Thank you. As said, that is enough for me to make it worth while to spend time writing "mailbox" stuff for it.

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 ...

But as we cannot that ofcourse works the other way around as well - trying to avoid a (non existing?) hassle and by it find yourself in (an even bigger) one. IOW, you do not have a point here.

And I do not want to be blunt here, but the /only/ "hassle" I have is the absense of basic documentation.

And I could have known that the "linux framebuffer" does not have any such support (even though it strongly hints to it) before this thread ... how exactly ?

Also, I suggest you (re?)read the subjectline and/or my initial post. In it I made it quite clear that I was inquiring about *if* such support is available for the RPi, and *if* it is how to use it.

And this is your next "hassle" you have assumed yourself into : what makes you think that I would like to mix up the linux framebufer with something else (mailbox), just to get a hardware mouse pointer ? To me that was at the moment of writing, a strict or-or situation.

... But now you've suggested it I might just see if it 1) can be done 2) is a workable solution. Why ? Why not.

Regards, Rudy Wieser

In my opinion your questions are often too hard to interpret correctly.

Maybe someone would ask back 100 yes/no questions including "have you ever installed a package on your "bullseye lite" RPi 1B rev1?", and somehow receive the answer "no", before attempting an actual answer, but not me.

Especially because I doubt you're understanding me either - you must have installed a compiler in your "bullseye lite" at least.

Sorry, "you" wasn't supposed to be personal. I meant we all do that, myself frequently included. I'm just making the point that the "easy way" with the Linux framebuffer might actually be harder if you want hardware acceleration. Or maybe there is h/w mouse acceleration hiding somewhere in the kernel's framebuffer driver? As I've said, I don't know for sure.

Kev,

Than you are very welcome to ask for clarification.

But be honest, look at the subjectline and tell me that that is a difficult question.

A single question to start with would have been enough : "did you install any packages".

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 know. But as you posted it to me ...

If you want you can replace the "I"s I used with "we"s. It doesnt make any difference.

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.

Regards, Rudy Wieser

On Fri, 30 Jun 2023 16:21:31 +0200, "R.Wieser" snipped-for-privacy@is.invalid declaimed the following:

It is if one does not know /which/ flavor of framebuffer is in play. A minimal software buffer where all drawing is done by setting bits using user-level software and which periodically gets blitted to the display hardware; one that is "owned" by a GPU that responds to drawing commands specific to the GPU (and in the case of the R-Pi, Broadcom releases very little documentation on its GPU -- one probably has to pay a small fortune and sign NDAs to get those details)?

Dennis,

For which I posted additional information in my initial post, which combination of name and usage I presumed /should/ have allowed anyone to figure it out. You know, OS version, name of include file, way of calling, argument names.

But if that was the whole problem than where am I asked for that flavor ? I would have tried to figure it out (probably with the askers help) and reported it.

Making the responders life easier gives me a better chance at getting a usable answer. But I have to understand the question as much as you guys need to.

By the way, its impossible for me fully respond to your "question", as I have no idea what you exactly mean by "flavor". The "linux" vs. hardware framebuffer ? Other versions of the linux framebuffer (or even hardware framebuffer!) ? Something else ? I like strawberry myself. :-)

Regards, Rudy Wieser

Nope, you could have downloaded fb.h manually from the web, so I'd need to ask that too.

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".

RPi OS's latest versions are based on Debian Bullseye. But by that logic, to be sure I should also ask that it's the official Raspberry Pi OS Lite, not another distro derrived from it.

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, or that you would have pointed out anything that is uncommon in your first post. Like trying to use hardware acceleration via the Linux framebuffer not the hardware framebuffer (which combined with all the other ambiguities made it seem likely that you were talking about the hardware framebuffer, not the Linux framebuffer).

Oh, OK. I remember needing to install lots of compiling tools before compiling software I wrote in RPi OS Lite, but maybe GCC wasn't one of those after all.

No, in minimal/lite releases of Debian and other popular Linux distros GCC usually needs to be installed manually from the package repo. It's not typically in the installation image/package because only a sub-set of users ever compile software.

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.

Kev,

And what would you need to do after you downloaded it ?

If I would know that they where ambiguous than I would already have tried to dis-ambiguate them.

Otherwise I would just have posted "the cursor doesn't work. Help." (as subjectline and contents) (just imagine the drool coming outof the corner of my mouth) and let you guys have a go at figuring out what the heck I might mean with it.

Answer : this is the RPi newsgroup. Take your "guess" which version I might be referring to. IOW, don't be daft.

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.

But somehow I don't really think that the used programming language dictates what the API is supporting. IOW, don't be daft.

I take it that you have neither read my subjectline or my initial message, as both specify what I was after. Any second-guessing to what I "actually" ment in that regard is your own problem. IOW, don't be daft.

While posting in an RPi forum ? And naming a specific hardware platform ? I would have considered you to be an idiot. IOW, its good that you didn't.

I suggest you (re)read my initial posts "tl;dr" part.

Funny, you expect me to resolve all of *YOUR* points of uncertanty before you have even expressed them, while most all of that uncertainty comes from assuming I've done all kinds of uncomon things and have applied alterations without me even mentioning that I did.

Yes, I expect you, when no modifier is supplied, to assume the default - unless you get a strong hint to that I might be using something else. If we (and I stress that "we") cannot do that than any kind of conversation becomes effectivily inpossible.

Really ? When I've mentioned a few times now that my whole goal was to learn how to use that API ?

I already knew it wasn't properly documented. If it would have been my multi-hour (days) "googeling" would have found it, or someone actually using it. I found neither.

Hence my posting here.

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

On 1 Jul 2023, R.Wieser wrote (in article <u7op6j$2shgi$ snipped-for-privacy@dont-email.me):

Rudy, you have discovered how helpful this newsgroup is and how welcoming to newcomers looking for guidance!

On Sat, 1 Jul 2023 09:32:33 +0200, "R.Wieser" snipped-for-privacy@is.invalid declaimed the following:

As a learning device for embedded computers, the "default programming language" pushed by the R-Pi foundation is... PYTHON

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.

Bill,

Well, they /did/ try to respond. I have to give them that.

But as I often get it, somewhere along the road the question and its supporting information gets forgotten and the responses veer off into chaos. A veering off Which than later, for some reason, becomes my fault. :-(

It also doesn't help that I've got a number of years of experience with usenet, computers and programming, which means that I'm not much of a push-over anymore (as you might have noticed :-) ).

Regards, Rudy Wieser

P.s. Sadly enough, nonwithstanding the length of this thread, I literally do not know anything more about the frame buffer API than when I posted the question.

Ahem,

Yep, that is as far as got too.

Thank you.

I had a quick peek at it (first few pages) and it looks promising. Lets hope I can find some example/test code in there, answering the "does or doesn't it" question conclusively.

Regards, Rudy Wieser

Dennis,

:-) 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

And a little Rust now creeping in. And the dreaded C++ s**te

Jan,

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

Jan,

The thing is that drawing on the canvas is simpler (and faster) if the mousepointer doesn't need to be removed every time I want to change a pixel under it.

But don't worry, I wrote a (minimal, basic) software solution even before posting here.

Regards, Rudy Wieser