[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: OpenGL-based framebuffer concepts
On Jun 1, 2006, at 22:18:07, Jon Smirl wrote:
> On 6/1/06, Dave Airlie <> 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.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-03 05:27    [W:0.221 / U:2.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site