In DOS, in real mode, the framebuffer was just mapped directly into memory. If you wanted to put something on the screen, you wrote to that memory address (often segment A000). For text modes, you would write ASCII characters straight into the buffer. For bitmap modes, your bytes would be interpreted as colors (or shades of gray, depending on the mode.) It was very exciting when I figured out how to use extended memory to draw high-resolution (640x480) graphics.
Writing to the Framebuffer
41–49 of 49 posts
Re: Writing to the Framebuffer
#42Earlier quoted context omitted.
Thanks. It is the Remarkable Tablet but the API is entirely undocumented. Took a fair bit of analysis to get it to this state but now it is actually ready for people to build their own applications upon it. The GitHub project: https://www.github.com/canselcik/libremarkable
This is cool, you should post it as a “Shown HN”. And don’t get discouraged if it doesn’t immediately garner attention. Post it again later if you only get an insignificant amount of upvotes. Your project is front page worthy and if it doesn’t get there the first time then it’s just bad timing / bad luck (or poorly worded title, that’s a possibility as well of course). Post it until it gets to the front page, waiting…
Thanks, I am very glad to hear that. I will be posting it with a more detailed write-up soon, detailing the reversing process as well. That should make it an even more interesting read.
Re: Writing to the Framebuffer
#43Earlier quoted context omitted.
This is cool, you should post it as a “Shown HN”. And don’t get discouraged if it doesn’t immediately garner attention. Post it again later if you only get an insignificant amount of upvotes. Your project is front page worthy and if it doesn’t get there the first time then it’s just bad timing / bad luck (or poorly worded title, that’s a possibility as well of course). Post it until it gets to the front page, waiting…
I agree, this is super cool and deserves attention.
Thank you. :)
Re: Writing to the Framebuffer
#44I wonder if there's a way to take over another VT so you don't have the console text over your images.
You need to read Unix and Linux Stack Exchange.
Re: Writing to the Framebuffer
#45Millenial discovers the framebuffer ... welcome to the planet.
Would you please read https://news.ycombinator.com/newsguidelines.html and follow the rules when commenting here?
Re: Writing to the Framebuffer
#46I have a feeling that framebuffer must be something very slow. When I used both Windows and Linux without proprietary drivers for a video card (so they use some generic VGA or VESA driver), GUI would be slower. For example, scrolling in a window was laggy. Or dragging a window around the screen. Why it could be so? Do video card vendors intentionally slow down video memory access or is VGA or VESA some poorly designed standard?
I was not using Compiz or something like this so it cannot be explained with the lack of 3D acceleration.
Also, with generic VGA driver you cannot have 100Hz frame rate on high resolutions.
Re: Writing to the Framebuffer
#47There may be more than just one simultaneous framebuffer per display on the hardware level. GPUs can actually scan to a display from multiple overlapping framebuffers in different resolutions and color formats in the same time . Alpha blending and rotations are often supported as well. A bit like a very large mouse cursor. In a way, mouse cursors are also framebuffers. Or like hardware video layers in the nineties.
Windows used a separate buffer for mouse cursor and video overlay. Seems like a good idea that helps to achieve smooth GUI performance even on a slow machine. You don't have to calculate what part of video frame is covered by other windows and you don't have to update pixels when moving a mouse cursor.
Re: Writing to the Framebuffer
#48Earlier quoted context omitted.
> GPUs can actually scan to a display from multiple framebuffers in different resolutions and color formats in the same time. This is also how early SLI worked: each GPU has a framebuffer, one holding the "even" scanlines and one holding the "odd" scanlines. Each GPU does its own rendering work to its own framebuffer, each rendering a vertically-squashed scene, with one scene offset by one pixel vertically. The maste…
To add to that, "early SLI" stands for Scan-Line Interleave, not Scalable Link Interface like it is now. CRT was some crazy shit to deal with. I'm glad I never had to deal with it. If you ever wondered why some old Youtube video looked like crap and has lines that don't match up, interleaving was why.
Usually artifacts are not the result of using interleaved source but the result of recoding done wrong. I remember reading mencoder manual about "pulldown" and other recoding options.
Re: Writing to the Framebuffer
#49Earlier quoted context omitted.
My first thought was to use the sh -c method.
Or, just use 'su' to become root, then write to the device file.
su isn't an option that's available to "regular" users. In particular in an environment where sudo has been set up correctly then it may be for the reason that you want regular users to be able to perform "some" powerful functions without giving them the keys to the system.