Mouse drawing directly to fb0

[Zinful]

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

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

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

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

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20250219/e0e10801/attachment.htm>