On Saturday 03 June 2006 05:55, Jon Smirl wrote:
> On 6/2/06, D. Hazelton <[email protected]> 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.
Actually, Jon, Dave is thinking like I am in that the DRI drivers needs to be
loaded for use. Rather than forcing applications to include all that code the
userspace daemon can be configured to load the DRI driver and provides the
userspace interface to the system. Using a daemon for a simple task, like
modesetting, is idiotic - but using the daemon to provide userspace with full
access to acceleration (the Kernel drivers only provide the backend for the
acceleration. The userspace side actually provides the code that manages it
all) without needing to have to worry about loading and initializing the dri
drivers provides a method for anything from a scripting language to a full
compiled application easy access to the acceleration.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
