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

> 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.

Note that I am NOT talking about a graphics library. This has NO
BUSINESS doing any kind of rendering. It's only the userland interface
to the underlying kernel drivers as far as mode switching & geometry
is concerned. That's _ALL_. In the same was as libGL is the userland
interface to DRI, or iptables the userlnad interface to netfilter,
etc...

> 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 agree. The HW access is done in kernel space. That's even true for
acceleration actually. You are mixing things. What I'm taking about
is exactly that: The userland library gets the various EDID & other
probing informations coming from the kernel drivers. It does the various
policy decisions on mode setting, it provides the API for userland to
deal with mode setting & monitor placement (what I call geometry)
and saving/restoring of configurations. The actual banging of the mode
to the HW is done by the kernel driver though. (The card specific back
end of the library probably builds either a mode description or a
register list and pass that to the kernel driver).

> 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!!!

I have been using multi head systems for years and I've seen how good
it can be, but also a bunch of the pitfalls when trying to design a
driver for it. If it was that easy, we would have had the right support
in fbdev for ages. We don't.

Ben.

-
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:2.975 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site