Mouse drawing directly to fb0

Wed Feb 19 22:28:14 UTC 2025

On Wed, 19 Feb 2025 13:16:40 -0500 Zinful <zinfulpersonal at gmail.com> said:

> Thank you all for your help and suggestions I really I appreciate it. So
> the project is sorta weird cause the whole idea is to have a working, fast,
> and smooth GUI-like environment on a raspi-0. I wanted to do it that way to
> force myself to work low-level and manage resources carefully (like drawing
> the mouse directly instead of an icon or sprite).

Well i suggested a "soft sprite". not a hardware one (e.g. a hw cursor or
hardware plane). you'll learn something in the process, but the way you do
sprites is really just compositing (with alpha channel and/or mask or bitmap
mask) on top of another set of pixels that represent the screen content below.
i could go into all the wonders of many hardware layers and compositing engines
or for that matter entire scene graph engines (i've written a relatively big
one that runs entire toolkits and compositors and is essentially a sprite
engine on a few boatloads of steroids). I'm trying to keep it simpler for you
so you can learn some of the core concepts and then be able to build on top or
recycle later.

> I'm going to have to use Carsten's idea though since dealing with different
> endians and getting the mouse to draw/replace its previous position with
> the correct color seems like an almost impossible task. It works perfectly
> with a 1 pixel size mouse but anything above that it fails to replace with
> the proper color
> 
> The resource constraint is also why I'm not using xorg-dev or other high
> level libraries. But I like the sprite idea, I just have to render it first
> and find a convenient way to move it around. Going with a double buffer
> approach (I don't know much yet I'm assuming) I'm pretty sure I can update
> sections of the screen instead of replacing the entire screen every
> mouse-position movement

correct. i am assuming at this stage you'd have 1 offscreen memory buffer for
the screen. you'd then copy a small regio of that to a temporary composition
buffer where the mouse pointer goes. you'd now composite the pointer on top
(using alpha channel or mask) then copy this small region to the screen.

it won't be perfect. you will see tearing at times, but this is easily then
extended to double buffering and zero-copy swaps later when you figure that
out. you can in future replace this composition of the pointer with controlling
as hardware cursor overlay instead. but you'll now know what overlays do for
you as you've had to do it yourself.

if something updates the off-screen "screen buffer" you copy the updated
region to the real screen. if the pointer intersects that region you copy those
intersected regions as above to temporary buffers, composite the pointer into
that then copy this to the real screen.

you'll have a smooth experience with a pointer that doesn't flicker and can be
any image you provide.

> I'll have to find out once I dig into it though. I know the main issue with
> the current mouse is that I'm essentially just manipulating memory so
> getting the previous byte, at the right time, and especially in the right
> order, might be too complex math-wise to be worth it overall

see above. separate buffers for different layers of content. combine them then
copy to screen. you can always remove the "copy to screen" with double buffered
(or triple) zero-copy swaps later. using kms and atomic mode switching you will
be able to do tear-free, flicker-free and zero copy display then. the good
thing is this technique works just about anywhere. it can work in a window in
x, wayland or any other OS. it doesn't rely on a real framebuffer with atomic
swaps. to speed up development you can abstract these parts of the pipeline and
develop everything else "in a window" on your current desktop ... then when on
the target platform you simply use a different buffer present path.

> Essentially I'm stubborn and am doing things the hard way cause I don't
> know any better yet lol :)

Well as Enrico was beginning to point out - there will have been plenty of
people who have solved this problem many times over well ahead of you and
created libraries and/or compositors and so on that do this for you. That is
what the venerable Xorg actually does for you. It's what wayland compositors do
for you. It's what libraries like EFL can just hide and do for you. But you
won't learn if you just take the existing solution... it's amazing what you
learn when you re-invent the wheel. Also you will just not have the sense of
accomplishment unless you do it the hard way yourself. I encourage you to stick
to it and learn. Make mistakes. Ask for some pointers/advice. In the end you'll
be a better developer.

> On Wed, Feb 19, 2025, 3:59 AM Carsten Haitzler <raster at rasterman.com> wrote:
> 
> > On Wed, 19 Feb 2025 09:20:45 +0100 "Enrico Weigelt, metux IT consult"
> > <info at metux.net> said:
> >
> > > On 18.02.25 08:12, Carsten Haitzler wrote:
> > >
> > > > Advice - don't try and just bolt on a mouse with a hack. reality is to
> > do a
> > > > mouse, you're doing sprites/overlays and/or compositing (to do it
> > right) so
> > > > instead of bolting it on with a hack, bite the bullet and work out how
> > to do
> > > > some proper compositing of images (sprites) off-screen with also
> > retained
> > > > off-screen content of the screen then transfer any changes on to the
> > screen
> > > > when done.
> > >
> > > Actually, raw fbdev isn't the right choice for such things - unless one
> > > really hasn't any other choice.
> > >
> > > DRM has support for such things, easy to use via libdrm:
> > > https://github.com/metux/twtk/blob/master/src/platform/drm.c
> >
> > why i mentioned going to swaps (i was implying you'd end up with kms etc.)
> > but
> > fbdev is a simple way to learn the basics of what a framebuffer is and how
> > to
> > possibly fill it with content. moving to a nice multi-buffer swapping
> > mechanism
> > is another stage in the learning... :)
> >
> > > I'd also recommend using some existing library for drawing (eg. cairo).
> >
> > i actually suspect that learning something about drawing/rendering and so
> > on is
> > part of the task... so as a college project ... it's better to DIY with
> > some
> > cpu compositing to learn it all.. :) what you do to learn and what you do
> > to
> > get a quick result will be different :)
> >
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > >
> > > Indeed ;-)
> > >
> > >
> > > --mtx
> > >
> > > --
> > > ---
> > > Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> > > werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> > > GPG/PGP-Schlüssel zu.
> > > ---
> > > Enrico Weigelt, metux IT consult
> > > Free software and Linux embedded engineering
> > > info at metux.net -- +49-151-27565287
> > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster at rasterman.com
> >
> >

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com