Re: [PATCH] i.MX23/28 framebuffer driver

I'm all for a more modular drm, although I think the framework of
CRTCs, encoders, and connectors is a nice fit, at least for our hw.
It would be nice to have a better way to expose overlays.  And I'm
still thinking about how/if GEM fits in with our various video and
2/3d accelerators.

BR,
-R

On Thu, Feb 17, 2011 at 8:19 PM, Jammy Zhou [off-list ref] wrote:

To accommodate the fact of independent display controller and GPU components
in ARM SOC, it will be better if we can separate KMS from DRM both in kernel
space and user space (i.e, create a new drivers/video/kms directory for
kernel side, move KMS related code in libdrm to libkms in user space). Then
we can build xrandr1.2+ support based on KMS for ARM platforms, even if DRM
is still not supported. Besides, for buffer management part (GEM) in DRM, if
possible, we can also make it an independent module leaving DRM just a
wrapper, so that the GEM stuff can be used more flexibly.

Regards,
Jammy

On Fri, Feb 18, 2011 at 12:14 AM, James Simmons [off-list ref]
wrote:

quoted

quoted

I'm still in the learning-as-I-go phase here, so definitely not ready
to propose a solution, but it does seem to me like there is room for
some sort of kms-helper library here to handle more of the boilerplate
xf86-video-* stuff..  I guess I'll have a better picture once I have a
chance to add support for the various multi-monitor configurations.
But certainly would be interested if anyone already has some ideas.

I have been thinking about this as well. One of the short coming for DRM
on embedded platforms is the lack of a small well defined library that one
could use. Right now libkms only handles buffer allocation. The mode
setting is currently tied to the libdrm library. It would be nice to
seperate the two out more. Move the mode setting code to libkms and then
have libdrm be a wrapper around this. This way libdrm can both support
the legacy drm drivers and the new kms drivers at the same time. It also
makes a clear seperation. Jakob if you are willing to take this work I
will gladly seen you patches.

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev