Questions about KMS/DRM and linux frame buffer devices.
 

Questions about KMS and linux /dev/fb* devices...

Postby GammaPaladin » 2015-08-17 00:34
Basically, what I want to do is to allow most standard framebuffer graphics apps (At least, any that support being told which /dev/fb* device to use, or can deduce that from the framebuffer the VT they're launched from is using) to operate on a specific monitor in a multi-monitor system. This is actually trivial with fbcon assuming you've got a system with multiple graphics cards... But I want to make it work with zaphod headed cards, which is not currently possible (At least as far as about 3 days of research can tell me) without custom code. I mean, it might be possible for nvidia cards, I wouldn't know, but radeondrmfb definitely only creates one linux framebuffer for the entire card, with all three monitors showing the same output.

So, the theoretical solution I've come to is this: I use code similar to what's found here: http://betteros.org/tut/graphics1.php#dumb polished up a bunch, since that's just demo code to show you how to use kms/drm in a manner akin to a framebuffer, and create a buffer corresponding to each connector which reports as active and connected, based on each one's screen dimensions (Possibly twice the size, to allow for y-pan double buffering), and then register with the kernel as a device driver, creating a /dev/fb{n} file descriptor for each buffer.

Then implement code that allows the driver application to present itself to the kernel as though it were a framebuffer device (Effectively it is at this point, and I suspect this is actually how radeondrmfb operates, but I haven't completely parsed radeon_fb.c from the kernel source just yet, so I'm guessing), while implementing all the standard functions expected of the linux framebuffer through kms/drm.

At that point the standard grub/syslinux kernel arg fbcon=map:<pattern> should work to place framebuffer consoles for specific VT numbers on specific consoles (For example, if my driver manages to allocate /dev/fb1, /dev/fb2, and /dev/fb3, then fbcon=map:123 should cause tty1 to show up on the monitor associated with /dev/fb1, tty2 on /dev/fb2, and so on). At that point launching most well-written framebuffer applications like fbi should launch them attached to the framebuffer the fbcon instance that called them is in.

No guarantees, and poorly written framebuffer applications are likely to just grab /dev/fb0 and ruin your day (And I suspect anything using directfb will cause horrible, horrible things to happen), but in theory this should give me the ability to view 3 ttys simultaneously without X, or operate 3 graphical framebuffer applications simultaneously, on my 3 monitors all going through my single triple-headed card.

Now I'm totally out of my depth here, and I'm diving into the deep end, effectively writing a device driver here... So anyone with experience with this sort of thing able to tell me if my hypothesis is sound, and/or give me some advice? Aside from: "You're nuts, just use X!" of course.

All I can say is that EVERYTIME I've tried to write directly to the framebuffer, it has ONLY ever worked on 386 processor devices where the graphics are entirely normal.

I say this because I live in the programming world of embedded Linux where we use Intel ATOM, ARM, and MIPS processors and the same intentions are to "write graphics directly to the frame buffer --- what could be simpler?" And it never is, in fact it was determined to be impossible for 3/4 or a higher percentage of the platforms of which I speak.

As you say, "being out of your depth" well, the sole solution here is to learn more than enough to basically become a graphics driver expert so that you can accomplish this. And then you'll likely stand to have additional work getting it to work with various processors beyond the normal i386 architecture.

Oh and:I long ago submitted, but I only ever entertained the subject enough to learn that I was beyond my scope and conceded in the first round. However I'm also exquisitely talented at configuring the XServer with no XDM, and managing rotation of the screen.

Hmm, I've never had much trouble with actually drawing to a framebuffer as long as the logistical issues of actually getting it in place are done. I mean it's literally just a bitmap... a character stream of width*height*bpp... And 8 and 32 bit color are both quite intuitive (8 because each character is a pixel, and 32 because each character is a color or alpha value. 16 is a little funky).

I find that super easy to conceptualize and work with.

I understand how to write to the frame buffer and I've not had problems writing to it and seeing the results either, when the driver is working properly. My point was that it is difficult for proper support of the frame buffer to be correctly taken care of by the driver.

Ah, gotcha. Luckily the i86 platform is all I'm really concerned with for this project, but yeah, even there getting the driver to do what I want is not trivial :)

Also luckily, I quite enjoy low-level coding :D