Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 1, 2006, at 22:18:07, Jon Smirl wrote:
On 6/1/06, Dave Airlie <[email protected]> wrote:
of course, but that doesn't mean it can't re-use X's code, they are the best drivers we have. you forget everytime that the kernel fbdev drivers aren't even close, I mean not by a long long way apart from maybe radeon.
I am aware that X has the best mode setting code and it would be  
foolish to ignore it.
You're kidding, right?  I've never been able to get X to get the  
modes right on my damn flatpanel.  Hell, it can't even match DDC  
channels to VGA ports without hand-holding in the config file.  To  
contrast, the fbdev layer gets it right every time on the whole  
variety of hardware that I've got.  Likewise the only way that I've  
ever gotten X to even set a vaguely functional mode on another card  
is by loading the framebuffer module first and specifying Option  
"UseFBDev" "true".  Anything else and the monitor goes off mode and  
there's no getting it back.
9) there needs to be a way to control the mode on each head, merged fb should also work. Monitor hotplug should work. Video card hot plug should work. These should all work for console and the display servers.
Of course, have you got drivers for these written? this is mostly  
in the realms of the driver developer, the modesetting API is  
going to have to deal with all these concepts.
This needs to be considered in the design stage. For example, if  
both heads are mapped through a single device node they can't be  
independently controlled by two different user IDs. We need to make  
sure we leave the path open to building this.
I kind of agree, but on the other hand there needs to be a way to  
specify multiple viewports in a single framebuffer like MergedFB on  
my radeon.  I would be quite happy to tinker with my little C-based  
framebuffer graphics apps in the console except that I can't  
manipulate the second display's view in the same framebuffer with fbset.
I meant support for Korean, Chinese, etc. You can't draw some of the complex scripts without using something like Pango. Do we want to build a system where people can use console in their native language? You can use these languages from xterm but not console today. I have no strong opinion on this point other that I believe it should be discussed and input from non-English speakers should be considered. No one on this list has a problem with this area since we all speak English.
IMHO the best way to do this is leave basic 7-bit or 8-bit fonts in  
the kernel where they are now and do the rest from a little userspace  
framebuffer console.  With a secure-attention-key to revert to the  
native console for emergency debugging and such, set up so it can  
display panics, I think the rest would be much better handled with  
the flexibility and locale support of userspace.
14) backwards compatible, an old X server should still run on a new kernel. I will allow for new options to be enabled at run-time so that this isn't possible, but just booting a kernel and starting X should work.
I'm not sure we want to continue supporting every X server released  
in the last 25 years. But we should definitely support any X server  
released in a 2.6 based kernel distribution. What are reasonable  
limits?
IMHO X is currently broken enough on much of my hardware that I'd be  
completely happy to be forced to upgrade.  My LCD has diagonal red  
scrolling when in X (works fine on the kernel console though) and X  
can't seem to hardware accelerate at all, even on this RV200 chip.
16) secure - no direct IO or MMIO access, modesetting is slow anyways having the kernel checking the mmio access won't make it much slower.
This needs some expansion. Secure is good, but it's not clear what  
you are requiring with this point.
For me security means reducing the privileged code to an absolute  
minimum and then inspecting it closely to make sure there are no  
holes. Everything that is passed in needs to be checked and  
regarded with suspicion. But you can go too far with the reduction,  
if you provide a generic IOCTL to poke an IO port with an arbitrary  
value you now have to verify that it is safe to pass in every  
possible value. Instead if the IOCTL implements a specific function  
that pokes the port with a single fixed value it is easier to say  
that it is secure.
I'd personally rather not see any IOCTLs for poking of ports, I kinda  
like being able to script framebuffer drawing with a little bit of  
Perl or some hastily written C.  Calling FBIOGET_VSCREENINFO is fine,  
calling FBIO_POKE_OBSCURE_PORT is kinda iffy.  I realize there's no  
black and white but it would be nice to maintain some clarity of  
interface; make simple things simple and hard things possible.
Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux