LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 08-17-2015, 03:48 AM   #1
GammaPaladin
LQ Newbie
 
Registered: Aug 2015
Posts: 3

Rep: Reputation: Disabled
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.
 
Old 08-21-2015, 04:39 PM   #2
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
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:
Quote:
You're NUTS! Just use X!
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.

Last edited by rtmistler; 08-21-2015 at 04:41 PM.
 
Old 08-23-2015, 01:43 PM   #3
GammaPaladin
LQ Newbie
 
Registered: Aug 2015
Posts: 3

Original Poster
Rep: Reputation: Disabled
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.
 
Old 08-25-2015, 09:12 AM   #4
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,876
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
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.
 
Old 08-25-2015, 01:59 PM   #5
GammaPaladin
LQ Newbie
 
Registered: Aug 2015
Posts: 3

Original Poster
Rep: Reputation: Disabled
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: NetBSD 7.0 RC1 Adds Support for Raspberry Pi 2, Ports Linux DRM/KMS LXer Syndicated Linux News 0 06-22-2015 08:01 PM
Linux frame buffer nagarjunas Linux - Newbie 1 11-14-2012 05:19 AM
Linux Frame buffer nagarjunas Linux - Newbie 0 11-14-2012 05:16 AM
Accessing Frame buffer in linux desktop moutusi Programming 1 12-03-2009 10:04 PM
Linux frame buffer console help needed ssenuta Linux - Hardware 0 09-20-2007 10:55 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 01:39 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration