Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

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

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
GammaPaladin
Posts: 3
Joined: 2015-08-14 05:53

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

#1 Post by GammaPaladin »

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.

Post Reply