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 :) <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2025, 3:59 AM Carsten Haitzler <<a href="mailto:raster@rasterman.com">raster@rasterman.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 19 Feb 2025 09:20:45 +0100 "Enrico Weigelt, metux IT consult" <<a href="mailto:info@metux.net" target="_blank" rel="noreferrer">info@metux.net</a>> 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: > <a href="https://github.com/metux/twtk/blob/master/src/platform/drm.c" rel="noreferrer noreferrer" target="_blank">https://github.com/metux/twtk/blob/master/src/platform/drm.c</a> 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 > <a href="mailto:info@metux.net" target="_blank" rel="noreferrer">info@metux.net</a> -- +49-151-27565287 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - <a href="mailto:raster@rasterman.com" target="_blank" rel="noreferrer">raster@rasterman.com</a> </blockquote></div>