Messages in this thread |  | | Date | Sat, 3 Jun 2006 01:55:46 -0400 | From | "Jon Smirl" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote: > The reason Jon is so hot on having direct access like that is he feels that > modesetting and a few other simple tasks should be handled by helpers and > acceleration itself should be handled by userspace libraries, without the drm > daemon at all.
Jon thinks all of the HW level acceleration should be handled in the DRM device drivers where it already exists. The acceleration code in fbdev and XAA/EXA needs to die. DRM is the only choice since it is possible to eliminate the other two and it is not possible to eliminate DRM. Dave is in agreement with this design.
I think you are mixing up my comments about DRI vs DRM. DRI is the user space acceleration code but it doesn't actually touch the hardware. DRM actually touches it. I have never wanted user space acceleration code for the low level hardware access.
Dave and I are only in disagreement on how to handle mode setting. In his model there is a mode setting daemon that has a socket interface. The libraries implementing xlib/OpenGL then talk to both this socket and to the DRM device.
My desire is to have a single point of interface, DRM. Since mode setting is not done very often I would use call_userhelper from the DRM device driver to invoke it when necessary. To set a mode you IOCTL DRM, which then bounces to a transient user space app.
Neither model forces mode setting exclusively into user space or the kernel, each driver can chose to put it where ever is more efficient. By initially reusing the existing X drivers it will probably all end up in user space but people may rewrite that over time.
Two other things that probably have to go into user space are initial reset and attached device (monitors) discovery.
-- Jon Smirl jonsmirl@gmail.com - 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/
|  |