Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing to the Framebuffer

seenaburns.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Writing to the Framebuffer

#11

Post by Jasper_ »

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 chain of strange events that are hard to describe. This explains why you can't write to a /dev/fb during an active X11 session and have it show up: it's a fake buffer that only shows up when KMS isn't in use.

[0] https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

Re: Writing to the Framebuffer

#12

Post by Jasper_ »

pjc50 wrote: post #6

Is /dev/fb writing directly to the framebuffer or is there translation going on kernel side? Is the card in VESA / BIOS mode when on a virtual console without X?

VESA / EFI FBs can be used, but usually only as a last resort. On devices with native KMS drivers, there is a compatibility path for /dev/fb. This is why your kernel console is in a resolution bigger than 800x600.

Re: Writing to the Framebuffer

#13

Post by derefr »

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 master GPU then interleaves the two framebuffers together (pulling data from the slave GPU's framebuffer over the SLI link) when outputting a field.

Re: Writing to the Framebuffer

#14

Post by digi_owl »

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.

Re: Writing to the Framebuffer

#15

Post by mnemotronic »

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?

Re: Writing to the Framebuffer

#16

Post by mjg59 »

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?

In the absence of an IOMMU configured to block GPU accesses to non-GPU memory regions, yes - however, drivers should block any request to do so.

Re: Writing to the Framebuffer

#17

Post by vardump »

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?

Well, if you're root... and configure IOMMU in such a way, etc.

Otherwise, it simply depends on system hardware architecture and drivers.

If the GPU is in a position to read and write physical memory (bus master DMA), and there's no hardware level protection like IOMMU or it's not properly configured, operating system has very little say in the matter, be it Linux or anything else.

Re: Writing to the Framebuffer

#18

Post by therein »

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

[0] https://gfycat.com/CornyHugeIndianRhinoceros

Post reply on HN