write pixel graphics directly to linux console framebuffer

[dankamongmen]

w3m appears capable of rendering pixel images in the linux console sans fbterm. i didn't know this was possible -- i thought you had to use fbterm or something similar to get sub-cell (maybe it's actually bringing the console into framebuffer mode?). figure out what's going on, and use it for our NCBLIT_PIXEL implementation on TERM=linux.

[dankamongmen]

looks like oyu just need permissions to open the appropriate framebuffer device, and then you can mmap() it and scribble to your heart's content.

[WSLUser]

Hey while you're at this, I just thought about this project supporting IO_URING as well. It has to be enabled in the kernel but it's enabled by default in the latest kernel stable and mainline. Framebuffer support is the same, needs to be enabled but typically it is for linux. This is only not the case for certain devices/situations including WSL2 (where when I enable the framebuffer devices, io_uring, and other perf options (compliments to Clear Linux for making those easy to determine), things speed up a bit.)

[ghost]

Curious: Do you have GPM mouse support when running on the raw console?

[dankamongmen]

Hey while you're at this, I just thought about this project supporting IO_URING as well. It has to be enabled in the kernel but it's enabled by default in the latest kernel stable and mainline. Framebuffer support is the same, needs to be enabled but typically it is for linux. This is only not the case for certain devices/situations including WSL2 (where when I enable the framebuffer devices, io_uring, and other perf options (compliments to Clear Linux for making those easy to determine), things speed up a bit.)

i'm quite familiar with io_uring, and it's great stuff, but i don't quite see how it would apply to Notcurses? i'm unafraid of new, esoteric, linux-only APIs; we use pidfd already in src/lib/fd.c.

[dankamongmen]

Curious: Do you have GPM mouse support when running on the raw console?

I believe so! I claim it, so I assume I tested it at some point =].

[WSLUser]

I wasn't sure how much it might play into this project either hence seeing if it has any viability or if it's just not something that is applicable to this type of project.

[dankamongmen]

it looks like we can detect a raw framebuffer with the FBIOGET_VSCREENINFO ioctl. this will also provide cell-pixel geometry.

[dankamongmen]

it looks like we can detect a raw framebuffer with the FBIOGET_VSCREENINFO ioctl. this will also provide cell-pixel geometry.

but i think this needs be performed using the framebuffer device, not the tty.

[dankamongmen]

i'm not sure how/if DRM Dumb Buffers need play a role https://manpages.debian.org/testing/libdrm-dev/drm-memory.7.en.html

[dankamongmen]

i'm also unsure how one determines which framebuffer is relevant if several are present. CON2FBMAP looks like it might be what we want here, or even just /proc/fb.

[dankamongmen]

there's also /sys/class/vtconsole/*/name:

[schwarzgerat](0) $ cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device
[schwarzgerat](0) $ cat /sys/class/vtconsole/vtcon0/name 
(S) dummy device
[schwarzgerat](0) $ 

[dankamongmen]

i think the thing to do here might be to rerun FBIOGET_VSCREENINFO whenever we run a TIOCGWINSZ (i.e., at startup and on SIGWINCH). this way we always know the number of rows and columns, which we need since the fb ioctl only gives us the screen geometry in pixels (and we need to divide it out), and we also update whenever the video mode is changed. we'll only do this if we're a linux framebuffer, of course. so we probably just keep an fd open if that's the case?

[dankamongmen]

we now open the framebuffer device and apply the ioctl, extracting pixel geometry. the name in the banner is then Linux framebuffer as opposed to Linux console.

[dankamongmen]

so an interesting element here is that our method of drawing is fundamentally different. for everything else, we provide rectangular data, and it's laid out for us, written as a large glyph. here, we need lay down the lines ourselves, and they're done via mmap direct writes.

that latter is a wrinkle -- it changes up the ordering of things. we purposefully do bitmap phase 1, glyph phase 1, bitmap phase 2, glyph phase 2, as that's necessary for wipe/restore logic. if we draw directly from sprixel_draw(), that's functionally going to work like bitmap phase 1, bitmap phase 2, glyph phase 1, glyph phase 2...hrmm.

[dankamongmen]

this is pretty much working now, at the level of iterm anyway -- we can draw, but no wiping/rebuilding yet.