[PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
If you need something really fancy you should be writing a real X.org driver. --- drivers/gpu/drm/drm_ioctl.c | 12 ++++++++++++ drivers/gpu/drm/i915/intel_display.c | 5 +++++ drivers/gpu/drm/radeon/radeon_display.c | 5 +++++ include/drm/drm.h | 4 ++++ include/drm/drm_crtc.h | 4 ++++ 5 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 904d7e9..37d2ce7 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -283,6 +283,18 @@ int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_priv) case DRM_CAP_VBLANK_HIGH_CRTC: req->value = 1; break; + case DRM_CAP_DUMB_ARGB_CURSOR_WIDTH: + req->value = dev->mode_config.max_cursor_width; + break; + case DRM_CAP_DUMB_ARGB_CURSOR_HEIGHT: + req->value = dev->mode_config.max_cursor_height; + break; + case DRM_CAP_DUMB_PREFERRED_DEPTH: + req->value = dev->mode_config.preferred_depth; + break; + case DRM_CAP_DUMB_PREFER_SHADOW: + req->value = dev->mode_config.prefer_shadow; + break; default: return -EINVAL; } diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 56a8554..cd169a5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8387,6 +8387,11 @@ void intel_modeset_init(struct drm_device *dev) dev->mode_config.min_width = 0; dev->mode_config.min_height = 0;
+ dev->mode_config.max_cursor_width = 64; + dev->mode_config.max_cursor_height = 64; + dev->mode_config.preferred_depth = 24; + dev->mode_config.prefer_shadow = 1; + dev->mode_config.funcs = (void *)&intel_mode_funcs;
intel_init_quirks(dev); diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 6adb3e5..35bd467 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1310,6 +1310,11 @@ int radeon_modeset_init(struct radeon_device *rdev) rdev->ddev->mode_config.max_height = 4096; }
+ rdev->ddev->mode_config.max_cursor_width = 64; + rdev->ddev->mode_config.max_cursor_height = 64; + rdev->ddev->mode_config.preferred_depth = 24; + rdev->ddev->mode_config.prefer_shadow = 1; + rdev->ddev->mode_config.fb_base = rdev->mc.aper_base;
ret = radeon_modeset_create_props(rdev); diff --git a/include/drm/drm.h b/include/drm/drm.h index 4be33b4..adc8174 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -757,6 +757,10 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_BUFFER 0x1 #define DRM_CAP_VBLANK_HIGH_CRTC 0x2 +#define DRM_CAP_DUMB_ARGB_CURSOR_WIDTH 0x3 +#define DRM_CAP_DUMB_ARGB_CURSOR_HEIGHT 0x4 +#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x5 +#define DRM_CAP_DUMB_PREFER_SHADOW 0x6
/* typedef area */ #ifndef __KERNEL__ diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 44335e5..ed6f8dc 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -623,6 +623,10 @@ struct drm_mode_config { struct drm_property *scaling_mode_property; struct drm_property *dithering_mode_property; struct drm_property *dirty_info_property; + + /* dumb ioctl parameters */ + uint32_t max_cursor_width, max_cursor_height; + uint32_t preferred_depth, prefer_shadow; };
#define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
If you need something really fancy you should be writing a real X.org driver.
Would prefer_shadow ever be 0?
Isn't preferred_depth just a static (non-driver-specific) preference list like "24, 30, 16, 15, 8" or something? Do we not expose the list of supported depths somewhere else?
Would prefer_shadow ever be 0?
Yes thats for the USB and vmware type users, where the buffer is just a main RAM buffer not in VRAM or uncached memory.
Isn't preferred_depth just a static (non-driver-specific) preference list like "24, 30, 16, 15, 8" or something? Do we not expose the list of supported depths somewhere else?
No we don't as we have userspace drivers that know as much as our kernel drivers about the hw, I was tempted to go for a list, but it gets a bit messy to enumerate, and really the generic driver doesn't care, it just wants to pick one value for autoconfiguration, if someone sets a value in xorg.conf and it blows up well thats their issue and they can pick another value.
Dave.
On Thu, 29 Sep 2011 09:43:12 -0700 Eric Anholt eric@anholt.net wrote:
On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
If you need something really fancy you should be writing a real X.org driver.
Would prefer_shadow ever be 0?
Devices which are fully cache coherent with the CPU are probably a good example. No point running back buffers then. Also any device with a generally slow CPU/GPU interface rather than one where write is fast but read is not.
Alan
On Thu, 29 Sep 2011 16:26:32 +0100 Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
Actually there is probably one other thing to report - which is whether the buffers are cached. That general piece of info "front/back buffer cached/uncached" allows you to both make intelligent decisions about using back buffers and also about which copy algorithms to use.
I guess X could work it out by timing algorithms at start up.
Also you call this max cursor width - in some devices isn't it actually a fixed cursor width ?
On Thu, Sep 29, 2011 at 7:41 PM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
On Thu, 29 Sep 2011 16:26:32 +0100 Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
Actually there is probably one other thing to report - which is whether the buffers are cached. That general piece of info "front/back buffer cached/uncached" allows you to both make intelligent decisions about using back buffers and also about which copy algorithms to use.
I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter.
The shadow flag is just to let X know back/front is preferred by default, I don't see a need for anymore info beyond that.
Also you call this max cursor width - in some devices isn't it actually a fixed cursor width ?
Yeah thats a good question, its probably is more of a fixed size pixmap w/h alright.
Dave.
I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter.
It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be best if the X server simply does some timings.
Alan
On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter.
It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be best if the X server simply does some timings.
probably makes sense to just rename the shadow preferred attribute to dumb_bos_are_cached or something.
Dave.
From: Dave Airlie airlied@redhat.com
For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor.
If you need something really fancy you should be writing a real X.org driver.
drivers/gpu/drm/drm_ioctl.c | 12 ++++++++++++ drivers/gpu/drm/i915/intel_display.c | 5 +++++ drivers/gpu/drm/radeon/radeon_display.c | 5 +++++ include/drm/drm.h | 4 ++++ include/drm/drm_crtc.h | 4 ++++ 5 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 904d7e9..37d2ce7 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -283,6 +283,18 @@ int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_priv) case DRM_CAP_VBLANK_HIGH_CRTC: req->value = 1; break;
- case DRM_CAP_DUMB_ARGB_CURSOR_WIDTH:
req->value = dev->mode_config.max_cursor_width;break;- case DRM_CAP_DUMB_ARGB_CURSOR_HEIGHT:
req->value = dev->mode_config.max_cursor_height;break;- case DRM_CAP_DUMB_PREFERRED_DEPTH:
req->value = dev->mode_config.preferred_depth;break;- case DRM_CAP_DUMB_PREFER_SHADOW:
req->value = dev->mode_config.prefer_shadow;break;
Could it be possible to make it a per drm_crtc. I have run into the issue of the case of a system with 2 CRTC but the hardware cursor is supported on only one CRTC. The other is that the cursor dimensions might actually vary on each CRTC.
dri-devel@lists.freedesktop.org
-
Alan Cox -
Dave Airlie -
Eric Anholt -
James Simmons