On Tue, Jun 21, 2011 at 11:19 AM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Tue, 21 Jun 2011 06:21:11 -0500 Rob Clark robdclark@gmail.com wrote:
On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it.
I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream.
I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from).
Cool, thanks for this
I'm just thinking through how I'd implement the driver part in omap drm driver.. so please bear with me if I'm misunderstanding..
In particular I'm thinking about being able to use a given video pipe (basically like a dma channel) as either framebuffer layer or overlay at various points in time, depending on how many displays are attached. Is the idea to use drm_plane *only* for overlay layer, and still use crtc->fb for the normal framebuffer layer?
Given the structure of the current KMS API, a CRTC implies a plane of some sort, but I don't think the driver is restricted to using the same plane for a given CRTC forever; it could allocate and switch them around depending on usage, with planes beyond what's currently associated with the CRTC exposed through this interface.
The awkward thing is how do you express to userspace that if it isn't using some CRTC(s) that it has an extra plane(s) available, if each crtc even though it is not enabled, is assumed to consume a plane (video pipe)..
That said if OMAP is the only hw like this, one possible solution is that you just need to have userspace know.. ie. the main one taking advantage of this feature would be the xorg driver, and it already knows what DRM driver it is talking to. Generic things like splash screen won't need to be using all the video planes.
But I'm at least under the impression that some of the other SoC's have similar flexibility to use video planes as either primary or overlay layers. So I figure it is at least worth trying to handle this in a more generic way if it doesn't cause too much ugliness to KMS core.
I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC pass in -1 for fb_id, followed by one or more DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we know it is the old way, and driver automatically picks a drm_plane.
Yeah that might work; we'd probably want a new GETPARAM flag to indicate support for this... The tough part is doing it in such a way that we don't break existing userspace.
fwiw, Daniel and I discussed a bit on IRC earlier today, and he had an interesting idea about having a simple drm_plane shim+helpers to keep things similar for existing drivers. I think it should be possible to support both old and new userspace semantics this way without too much if(driver_features & SUPPORTS_PLANES) sort of stuff.
BR, -R