Kev,

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

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

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

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 ?

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

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

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.

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

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

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

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.

> Using the Linux Framebuffer but still wanting some hardware
> acceleration might be such a case.

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

R.Wieser <address@is.invalid> wrote:
>Computer Nerd Kev <not@telling.you.invalid> wrote:
>> 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.
[snip]
> 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.

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.

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

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

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.

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

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

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

Regards,
Rudy Wieser

On Fri, 30 Jun 2023 16:21:31 +0200, "R.Wieser" <address@is.invalid>
declaimed the following:

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

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

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

R.Wieser <address@is.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) wrote:
>> Maybe someone would ask back 100 yes/no questions
>
> 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".

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

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

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.

> And isn't including a GCC (or alike) into an OS package quite common ?

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.

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

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,

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

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

> [you don't have to answer these questions - they're an example
> for how you could make your future first posts less ambiguous]

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.

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

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

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

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

> I should have asked whether software compatibility with other
> non-RPi platforms mattered as well.

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.

> 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 suggest you (re)read my initial posts "tl;dr" part.

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

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.

> 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

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

> _before_ you realised that it wasn't properly documented and didn't
> "just work" for hardware mouse acceleration.

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.

> 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

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

> 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

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

--
Bill Findlay
Free software contributor since 1976. Incompetent googler and "Usenet leech"
(c.s.r-pi dixit).

On Sat, 1 Jul 2023 09:32:33 +0200, "R.Wieser" <address@is.invalid>
declaimed the following:

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

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

On Sun, 25 Jun 2023 19:27:59 +0200
"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.

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>

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Bill,

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

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,

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

Yep, that is as far as got too.

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

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,

> 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

On 02/07/2023 08:36, R.Wieser wrote:
> 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.
>
And a little Rust now creeping in.
And the dreaded C++ shite
> Regards,
> Rudy Wieser
>
>
>

--
If I had all the money I've spent on drink...
...I'd spend it on drink.

Sir Henry (at Rawlinson's End)

On a sunny day (Tue, 27 Jun 2023 17:40:28 +0200) it happened "R.Wieser"
<address@is.invalid> wrote in <u7evtp$1eabv$1@dont-email.me>:

>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,
I use things like this:
https://panteltje.nl/panteltje/xgpspc/index.html
runs on the oldest Pi I have,
uses libX11
compiles on raspi:

See X11.c
You can gate mouse position see
get_pointer()
do_mouse()
And draw anything anywhere you like
Basically write stuff to xbuffer.
Same code also runs on X86 back to before year 2000.

simpler:
https://panteltje.nl/panteltje/mcamip/index.html
look at the Makefiles
LIBRARY = -L/usr/lib/arm-linux-gnueabihf -lXaw -lXext -lX11 -lXt -ljpeg -lm

Hope this helps.

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

On a sunny day (Thu, 6 Jul 2023 14:36:30 +0200) it happened "R.Wieser"
<address@is.invalid> wrote in <u86cgt$u6s7$1@dont-email.me>:

>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

OK, I have used OpenGL myself for some thing, used code from here:
https://www.codemiles.com/c-opengl-examples/

You could perhaps look at the source of libxt:
https://gitlab.freedesktop.org/xorg/lib/libxt
or source of xlib

I did something long ago writing directly to a graphics card hardware,
then modified the routines for xlib, for xvtx-p:
https://panteltje.nl/panteltje/satellite/xvtx-p-0.1.1.tgz
is that wat you want:
screenshot:
https://panteltje.nl/pub/xvtx-p-nl_now.gif

From the code:
Display *mydisplay;

void s3plot(int x, int y, int color)/*plot 1 dot*/
{ static int previouscolor;
/* avoid 're appearing' at left and top */
if(x >= HSIZE)return;
if(y >= VSIZE)return;
if(color != previouscolor)
{
XSetForeground(mydisplay, xptestgc, color);
previouscolor = color;
}
/* XSetBackground(mydisplay, xptestgc, WHITE);*/
XDrawPoint(mydisplay, topwindow, xptestgc, x, y);
https://tronche.com/gui/x/xlib/graphics/drawing/XDrawPoint.html
? https://www.x.org/releases/current/doc/libX11/libX11/libX11.html

OK have fun!
Found it fun to program all that stuff in the late nineties.

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.

xvtx-p has a nice hand like cursor..

Jan,

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

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

R.Wieser <address@is.invalid> wrote:
> 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 when you
use that term in your posts. What irked me before was that you
didn't do so even after the problems with understanding had arisen.

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

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

On 07/07/2023 09:02, R.Wieser wrote:
> 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.
>
That depends on if it is you that wants help...

> Regards,
> Rudy Wieser
>
>

--
The New Left are the people they warned you about.

On 07/07/2023 09:48, The Natural Philosopher wrote:
> On 07/07/2023 09:02, R.Wieser wrote:
>> 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.
>>
> That depends on if it is you that wants help...
>
>> Regards,
>> Rudy Wieser
>>
>>
>

Typical Rudy behaviour.

He doesn't want help he wants a argument.