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
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-...
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
On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann arnd@arndb.de 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/oma... ), 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
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/oma... ), 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
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 arnd@arndb.de 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/oma...
), 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
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 jesse.barker@linaro.org 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 arnd@arndb.de 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/oma... ), 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
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it can serve as what we needed.
Regards, Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob rob@ti.com 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.
BR, -R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker jesse.barker@linaro.org 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 arnd@arndb.de 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/oma...
), 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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hmm, I was thinking more on the xf86 side of things.. ie. to provide default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec functions..
BR, -R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it can serve as what we needed.
Regards, Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob rob@ti.com 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.
BR, -R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker jesse.barker@linaro.org 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 arnd@arndb.de 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/oma... ), 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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
I also noticed that default XRandR1.2+ implementation is missing in X side. If we can implement one, it would be beneficial for all ARM platforms. By the way, does X driver of TI support XRandR1.2+?
Regards, Jammy
On Thu, Feb 17, 2011 at 11:25 PM, Clark, Rob rob@ti.com wrote:
Hmm, I was thinking more on the xf86 side of things.. ie. to provide default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec functions..
BR, -R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe
it can serve as what we needed.
Regards, Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob rob@ti.com 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.
BR, -R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker jesse.barker@linaro.org
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 arnd@arndb.de 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/oma...
), 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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
I'm in the process of adding xrandr support to our xorg driver.. definitely more built-in support on the X side would make this easier.
BR, -R
On Thu, Feb 17, 2011 at 8:25 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
I also noticed that default XRandR1.2+ implementation is missing in X side. If we can implement one, it would be beneficial for all ARM platforms. By the way, does X driver of TI support XRandR1.2+?
Regards, Jammy
On Thu, Feb 17, 2011 at 11:25 PM, Clark, Rob rob@ti.com wrote:
Hmm, I was thinking more on the xf86 side of things.. ie. to provide default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec functions..
BR, -R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it can serve as what we needed.
Regards, Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob rob@ti.com 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.
BR, -R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker jesse.barker@linaro.org 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 arnd@arndb.de 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/oma... > ), 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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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.
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 jsimmons@infradead.orgwrote:
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
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 jammy.zhou@linaro.org 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 jsimmons@infradead.org 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.
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Feb 18, 2011 at 2:14 AM, James Simmons jsimmons@infradead.org 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.
-
Arnd Bergmann -
Clark, Rob -
Dave Airlie -
James Simmons -
Jammy Zhou -
Jesse Barker -
Robert Schwebel