# \[PATCH\] i.MX23/28 framebuffer driver - List: linux-fbdev - 4 messages, 3 authors - Page: https://ratatoskr.run/linux-fbdev/2011/02/8568140/t ## \[PATCH\] i.MX23/28 framebuffer driver - From: Arnd Bergmann \ - Date: 2011-02-09 16:31:07 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8568140.md ```text On Wednesday 09 February 2011, Sascha Hauer wrote: > The driver patch itself is Cced to linux-fbdev, only the introductory > mail is not. Ok, I see. > > Did you consider making the driver a KMS driver instead of > > a frame buffer? I think the recommendation these days is > > to start out with KMS for new drivers, which will be somewhat > > simpler and give you a frame buffer device as well. I don't > > think that there is a need to change over any drivers from > > fb to kms though, since you've already done the work. > > I tried doing so for the i.MX51 which supports multiple displays on dvi > and vga outputs and thus could make good use of KMS and friends. Anyway, > I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI > and needs many many callbacks to implement. Additionally the userspace > tools expect a nvidia/amd/intel driver and do not have a generic > fallback. I think this stuff is good for implementing a full blown > graphics driver, but is lacking support for simple framebuffer grapics. > I'd love to go this way but it still requires a lot of work. Ok. This sounds like a lot of upfront work indeed, to make KMS more generic, though I think a number of driver would benefit from it eventually. It could be something for the Linaro graphics working group to look at in the following 11.11 release, depending on how many other people are interested in getting there. Arnd ``` ## \[PATCH\] i.MX23/28 framebuffer driver - From: Robert Schwebel \ - Date: 2011-02-10 17:09:36 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8568236.md ```text On Wed, Feb 09, 2011 at 05:31:07PM +0100, Arnd Bergmann wrote: > Ok. This sounds like a lot of upfront work indeed, to make KMS more > generic, though I think a number of driver would benefit from it > eventually. It could be something for the Linaro graphics working > group to look at in the following 11.11 release, depending on how > many other people are interested in getting there. There is already a blueprint at linaro: https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-dri-1105 We have recently tested the state of Qt acceleration on the MX51, in order to find out which is the best way to make use of the possibilities. However, at least at the moment this requires highly experimental Qt sceenegraph git branches, and even then it results in lower perfomance than with software rendering ... But for the long term, the linaro blueprint looks like the way to go. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ``` ## \[PATCH\] i.MX23/28 framebuffer driver - From: Clark, Rob \ - Date: 2011-02-15 14:13:27 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8568719.md ```text On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann [ref] wrote: > On Wednesday 09 February 2011, Sascha Hauer wrote: > >> The driver patch itself is Cced to linux-fbdev, only the introductory >> mail is not. > > Ok, I see. > >> > Did you consider making the driver a KMS driver instead of >> > a frame buffer? I think the recommendation these days is >> > to start out with KMS for new drivers, which will be somewhat >> > simpler and give you a frame buffer device as well. I don't >> > think that there is a need to change over any drivers from >> > fb to kms though, since you've already done the work. >> >> I tried doing so for the i.MX51 which supports multiple displays on dvi >> and vga outputs and thus could make good use of KMS and friends. Anyway, >> I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI >> and needs many many callbacks to implement. Additionally the userspace >> tools expect a nvidia/amd/intel driver and do not have a generic >> fallback. I think this stuff is good for implementing a full blown >> graphics driver, but is lacking support for simple framebuffer grapics. >> I'd love to go this way but it still requires a lot of work. > > Ok. This sounds like a lot of upfront work indeed, to make KMS more > generic, though I think a number of driver would benefit from it > eventually. It could be something for the Linaro graphics working > group to look at in the following 11.11 release, depending on how > many other people are interested in getting there. > fwiw, it seems to me like xorg could have some more common code to deal with the KMS part of DRM.. the various userspace xorg drivers end up having a lot of very similar code to deal with enumerating CRTCs/outputs and modes, handle hotplug, etc. 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? BR, -R ``` ## \[PATCH\] i.MX23/28 framebuffer driver - From: Arnd Bergmann \ - Date: 2011-02-16 12:22:07 - Message: https://ratatoskr.run/linux-fbdev/2011/02/8568860.md ```text 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 ```