lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-fbdev-devel] fbdv/fbcon pending problems

> > I think this is a bad idea. This has been tried before. In the
> > opensource community there is no such a thing as a standard library.
>
> On the other hand, things like dbus are low-level and slowly getting
> used by everyone... we also have the libc :)

Well now that we have one input api that can happen. Of course with
graphics its much more diverse with what you can do. That is one of the
reasons for so many graphics libraries. It would be really hard to write
a one size fits all library when it comes to graphics.

> > The kernel really needs to be the only state machine for the hardware.
> > Library developers will usually use the kernel standard interfaces.
>
> I don't fully agree. The kernel will do the actual HW banging, but
> we want things like EDID overrides per monitor models, persistent
> configuration saved to storage etc... all of that beeing pretty
> nasty to do in the kernel.

By state machine I mean the physical hardware state. If it's hardware
access then it should be in the kernel. Note I'm refering to mode setting
not acceleration. Now EDID overrides per monitor model and saving the
state to disk is different. That should be userland.

> I have mixed feeling on that. Keith Packard seem to prefer the library
> approach. I don't know for sure what Linus prefers here. Currently, I
> feel we are trying to do too much in the kernel, and that will become
> increasingly painful to manage as we get multiple head & geometry stuff
> getting in the picture.

I think we are fine for whats in the kernel. As for multiple head and
geometry stuff its not that hard if done right. I have been using
multi-head systems for years. I have multip desktop systems for years!!!



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

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:1.529 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site