Writing to the Framebuffer • Hacker News Board

Re: Writing to the Framebuffer

#21

Post by jimmies » Thu, Apr 05, 2018, 12:31 AM UTC

derefr wrote: post #13

vardump wrote: post #5

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

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

Re: Writing to the Framebuffer

#22

Post by Relys » Thu, Apr 05, 2018, 12:52 AM UTC

mnemotronic wrote: post #15

note: I don't know linux... Is it possible to get the GPU to copy kernel / system memory to the framebuffer, then read that back with user space app? I.e. can we convince the GPU or framebuffer to give us the contents of protected system memory?

On the Nintendo Wii U we were able to do this. Check out "GX2 unchecked memory read/write": http://wiiubrew.org/wiki/Wii_U_System_Flaws. Same issue with "gspwn" on the Nintendo 3DS: https://www.3dbrew.org/wiki/3DS_System_Flaws

Re: Writing to the Framebuffer

#23

Post by Jasper_ » Thu, Apr 05, 2018, 1:02 AM UTC

voltagex_ wrote: post #10

I wonder if there's a way to take over another VT so you don't have the console text over your images.

You can do this without taking over another VT by using ioctl(KDSETMODE, KD_GRAPHICS). This tells fbcon in the kernel to stop drawing console text to /dev/fb.

Re: Writing to the Framebuffer

#24

Post by pwg » Thu, Apr 05, 2018, 1:22 AM UTC

digi_owl wrote: post #14

tbirdz wrote: post #2

The reason why sudo wasn't working is that it runs the command with root privileges, but redirecting to a file with > is done through the shell, which is running under your normal user level privileges. If you want to redirect to a file that only root can write to, you can use the tee command. That command will write anything passed to it via stdin to the file given as an arg. For example, echo "foo" | sudo tee /path…

My first thought was to use the sh -c method.

Or, just use 'su' to become root, then write to the device file.

Re: Writing to the Framebuffer

#25

Post by gandreani » Thu, Apr 05, 2018, 1:25 AM UTC

therein wrote: post #18

Jasper_ wrote: post #11

Keep in mind that /dev/fb, on a modern system, isn't an actual framebuffer on your GPU. It's a land of make-believe, mostly supported to get the kernel console ("fbcon") working. Going back for at least 10 years, the kernel mode-setting API (KMS) is used to display buffers, and there's compatibility code which sets up a user-space buffer in the KMS subsystem [0] which is swapped to when fbcon happens through a large…

That is correct. One exception perhaps is embedded devices with displays, including EInk tablets. For instance one thing I have been working on is a library that allows writing to and partially refreshing an EInk display with low latency enabling this[0]. I am curious what would happen if I got xorg working on this and used an additional application to call the `refresh` ioctl so that the changes get displayed on the…

That's very awesome! What tablet and project is that?

Re: Writing to the Framebuffer

#26

Post by therein » Thu, Apr 05, 2018, 1:30 AM UTC

gandreani wrote: post #25

therein wrote: post #18

Earlier quoted context omitted.

That is correct. One exception perhaps is embedded devices with displays, including EInk tablets. For instance one thing I have been working on is a library that allows writing to and partially refreshing an EInk display with low latency enabling this[0]. I am curious what would happen if I got xorg working on this and used an additional application to call the `refresh` ioctl so that the changes get displayed on the…

That's very awesome! What tablet and project is that?

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

Re: Writing to the Framebuffer

#27

Post by gandreani » Thu, Apr 05, 2018, 2:26 AM UTC

therein wrote: post #26

gandreani wrote: post #25

Earlier quoted context omitted.

That's very awesome! What tablet and project is that?

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

Thank you very much! I will check out both very soon. I'm interested in a lightweight portable ssh terminal eink device and this combination might just work for me

Re: Writing to the Framebuffer

#28

Post by BenjiWiebe » Thu, Apr 05, 2018, 3:33 AM UTC

voltagex_ wrote: post #10

I wonder if there's a way to take over another VT so you don't have the console text over your images.

I do it with tput civis, and redirecting the output to null.

Re: Writing to the Framebuffer

#29

Post by vvanders » Thu, Apr 05, 2018, 4:44 AM UTC

vardump wrote: post #5

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

Yup, on Android this is handled by a service called SurfaceFlinger which you can easily inspect from the shell(adb shell dumpsys SurfaceFlinger).

Not sure if it's still the case but back in the ICS days your status bar, wallpaper and launcher/app were all separate surfaces that were scanned out from different frame buffers.

Re: Writing to the Framebuffer

#30

Post by jonny789 » Thu, Apr 05, 2018, 4:45 AM UTC

I am trying to run as root user :: cat /dev/graphics/fb0 in my android (oreo) phone. But showing 'No such device' error. Could anyone guide me on how to make it work so that I could take screenshot directly and do some graphics stuff on my phone directly.