# \[PATCH\] i.MX23/28 framebuffer driver - List: linux-fbdev - 3 messages, 3 authors - Page: https://ratatoskr.run/linux-fbdev/2011/02/8568928/t ## \[PATCH\] i.MX23/28 framebuffer driver - From: Clark, Rob \ - Date: 2011-02-17 01:08:48 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8568928.md ```text 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. BR, -R On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker [ref] wrote: > Speaking for the Linaro graphics working group, I think it's great.  And, I > think you're right, that if enough of the KMS support in xf86-video-* is > similar enough (I was only aware of intel and nouveau supporting it properly > at current), pulling it out into a common layer would make it easier to > support in new drivers (including fbdev). > > cheers, > Jesse > > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann [ref] wrote: >> >> On Tuesday 15 February 2011, Clark, Rob wrote: >> > I'd been experimenting a bit on the side w/ the DRM driver framework ( >> > >> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu >> > ), but had to add a good chunk of mostly boilerplate code to our xorg >> > driver in order just to test it.  Maybe some generic support for KMS >> > in xf86-video-fbdev would have made this easier to develop the kernel >> > part without in parallel having to implement the userspace part.  I'm >> > not sure if this is the sort of thing the linaro-wg has in mind? >> >> I'm not sure what the the linaro multimedia wg thinks of this, but the >> kernel code you linked looks like it's doing exactly the right thing. >> >>        Arnd >> >> _______________________________________________ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > ``` ## \[PATCH\] i.MX23/28 framebuffer driver - From: James Simmons \ - Date: 2011-02-17 16:14:43 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8569039.md ```text > 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. ``` ## \[PATCH\] i.MX23/28 framebuffer driver - From: Dave Airlie \ - Date: 2011-02-21 03:12:32 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8569309.md ```text On Fri, Feb 18, 2011 at 2:14 AM, James Simmons [ref] 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..  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. the problem with that is libkms relies on libdrm, so you'd have a circular dependency. With the addition of the dumb ioctl to the kernel we can certainly avoid some of that dependency, but you guys are missing one important point about libkms, its meant to be a fallback. Why? well because most GPUs in reality have non-generic memory layouts, they prefer having tiled buffers for different things and different types of tiling. There is simply no nice way to abstract that out, since it depends on the userspace libraries that use this. Starting off with an untiled allocation for the frontbuffer can pretty much leave you messed up when you plug anything like acceleration in afterwards. I have been looking at this from the USB driver pov as well, and we can probably resurrect the old xf86-video-modesetting driver along with some code in the X server maybe, mesa also has a libkms fallback X driver that works quite well if just a bit messy to build (since its in mesa). Dave. ```