>Moving mode setting from the Xsever does not necessarily mean it has >to go into the kernel.
I agree. The thing I am worried about (just speaking about the mode setting part here) is that we end up with 2 defined APIs. One for the mode setting, done as a user library, and another for the kernel part that is really tiny. That assumes a split that will be hard to agree on. As long as we only define one entry point, everyone can be happy. i.e. define a pretty small library API in user space and let the driver writer decide where to split the unprivileged library code from the privileged (kernel in most cases) part. But that means that there is no guarantee what the actual kernel API looks like, it becomes driver dependent. In my mind you have 3 modules. 1: Privileged code that can access hardware directly 2: Unprivileged code that provides a minimal known mode API and any number of unknown APIs specific to hardware. 3: DD code that is part of the higher level library. XFree driver or Mesa driver etc. The API between 1 and 2 is undefined. Any kernel/user split could be used. The goal for the driver writer is to get as much in module #2 but you could put all the code kernel-side and just make module #2 a function wrapper for your ioctls if you wanted. The API between 2 and 3 has only a tiny definition. Small mode setting, maybe some tiny 2d drawing just to be nice and nothing else. The rest is driver dependent and only gets used by module 3. Module 3 is just the DD layer or XFree, or the DD layer of Mesa. Doesn't matter what high level design ends up winning in the end. >People seem to advocate to utilize OpenGL for 2D rendering on modern >chipsets. It remains to be seem how feasable this alternative is. >However a solution for this already exists. >If we are talking about 3D rendering a solution for this already >in the making with standalone MESA. >For 2D rendering X has a rather smart infrastructure to map X drawing >requests onto those 2D primitives that are commonly provided by chipsets. >The driver part there is rather lightweight as most of the work is >done by this abstraction layer. >It would be great if this interface could be kept for chipsets that >need 2D acceleration. I agree. The high level stuff will probably need several code paths depending on chip capabilities. You are talking about APIs used above module 3 which should all be possible given the correct 1 and 2. >> >> 1) A small, device-independent, API that can be used to set modes and >> do some very simple rendering. I would suggest get, set, put, copy. > >Do you suggest to accelerate these and put the acceleration for them into >the kernel? This would mean a longer path from user space. Since the >these operations typically don't deal with huge areas this may mean a >signifficant performance penalty. Not making any claim as to where they would be (module 1 or 2). Just indicating that there would be a small "defined" API and everything else is undefined. Having a defined way to do some primitives would allow a completely device independent X server written today to limp along on hardware of tomorrow. Some minimal mode setting is a must have part of that defined API. Get, set, put, copy seems a safe set of helpers. Just a way to get some minimal performance until you can get an actual DD driver created or installed. >Experience has shown that there is almost no way to desing an API so >generic that it can effectively deal with new features that come along >in the future in an effective way. I agree. I think we are on the same page. A minimal set of features is all that would be part of the defined mode setting API. It is just a question of if some of the multi-head concepts are generic enough to be part of that defined set. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
