Re: [Linux-fbdev-devel] fbdv/fbcon pending problems

[Benjamin Herrenschmidt]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/