Messages in this thread | | | Subject | Re: [Linux-fbdev-devel] fbdv/fbcon pending problems | From | Benjamin Herrenschmidt <> | Date | Thu, 26 Feb 2004 11:33:01 +1100 |
| |
> 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/
| |