Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/2/06, D. Hazelton <dhazelton@xxxxxxxxx> 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@xxxxxxxxx
-
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/