On Sun, Mar 22, 2026 at 01:32:00AM -0400, Onana Onana Xavier Manuel wrote: > > To help you find the best solution, it would be help to have some more > > details > > about exactly what you are trying to do: > > > > What sort of program is this? > > It is true I forgot to add some details about what I'm trying to do. I am > trying > to make a non-accelerated windowing system as a personnal project which is the > reason why I am not using Xlib nor libdrm.
OK, that makes sense. > > Is it intended as a programming exercise, or to solve a particular local > > problem, or is it being developed for public release and intended to be > > portable to other systems? > > > > What hardware are you developing this on? > > I am not trying to make this portable, just working on my machine which is a > 64-bit amd CPU. I was able to get efifb configured after disabling amdgpu and > set > the display mode to dumbfb but the problem is when switching ttys the > framebuffer > that was received through mmap is still displayed. There is only one actual framebuffer which is shared between all of the textmode VTs. The contents of the screen and the scroll-back buffer is stored as textual data. This is basically an array of UCS codepoints and attributes such as colours and underline for each character. When you switch between text-mode VTs, the content of the new VT is drawn to the underlying framebuffer. If you've plotted data directly to the framebuffer, this is not known to the wscons subsystem, and it will just draw the glyphs for text characters on top of it. You basicaly have a few options: 1. Ignore the problem. If this is just a proof of concept or personal project then the easiest thing to do is just to accept that switching VTs causes graphical disruption. 2. Detect when you switch back to the VT that your graphical program is running on, and re-draw the screen. This would be similar to how Xlib programs need to respond to 'expose' events. Personally, I would not do this even for a personal hobby project, as it's adding a lot of complexity in an area that you shouldn't need, either storing a copy of the whole framebuffer in case you need to re-paint it, or otherwise storing the underlying vectors and glyphs for everything on-screen so that you can re-render it on each VT switch. 3. Use kernel mode setting. This is the most 'correct' way, and also by far the most difficult to get started on. It's basically what X11 does, and it gives you the maximum flexibility to set up your own framebuffer which is completely separate from the one used for the text mode VTs. It also has the big advantage that you could use amdgpu instead of efifb. But do not underestimate the difficulty of this task, it's way more complicated than dumbfb. 4. Implement some pixel-plotting and graphics primitives functionality directly in the rasops subsystem, then call those new functions from your usermode program. The key here is to make sure that it's implemented per VT, in a similar way to the text rendering system in wscons, maintaining a backing store so that the graphical content can be re-drawn along with the text glyphs when you change VTs. This is basically the approach I took for some internal programs I am developing here. Just bear in mind that none of this will ever be of interest to the wider OpenBSD project so you'll have to port your kernel code forward to each new release. I'm already responsible for doing this for a tonne of other code we use internally here, so it's no big deal. But it's probably a major hassle that you don't want for your own project. The most realistic options for you are probably 1 or 3. If you have the time and patience, definitely go for 3, because it's the only one that paves the way for sharing the code at a later date if you ever wanted to.
