From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Clark, Rob" Date: Fri, 18 Feb 2011 04:32:24 +0000 Subject: Re: [PATCH] i.MX23/28 framebuffer driver Message-Id: List-Id: References: <1297257651-8002-1-git-send-email-s.hauer@pengutronix.de> <201102091731.07794.arnd@arndb.de> <201102161322.08126.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Jammy Zhou Cc: Linux Fbdev development list , linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, Arnd Bergmann , Sascha Hauer , DRI development list , James Simmons , Jakob Bornecrantz , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org 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 wrote: > To accommodate the fact of independent display controller and GPU compone= nts > in ARM SOC, it will be better if we can separate KMS from DRM both in ker= nel > 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). Th= en > we can build xrandr1.2+ support based on KMS for ARM platforms, even if D= RM > 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 > wrote: >> >> > 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.. =A0I 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 o= ne >> 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 > >