drm: add some caps for userspace to discover more info for dumb KMS driver
Subsystems (4)
Dave Airlie
maintainerRFC PATCH 1/1 drm: add some caps for userspace to discover more info for dumb KMS driver
From: Dave Airlie <[email protected]>
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(-)
drivers/gpu/drm/drm_ioctl.c +12 -0
@@ -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 ; }
drivers/gpu/drm/i915/intel_display.c +5 -0
@@ -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);
drivers/gpu/drm/radeon/radeon_display.c +5 -0
@@ -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);
include/drm/drm.h +4 -0
@@ -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__
include/drm/drm_crtc.h +4 -0
@@ -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)
Signature · 1 line
1.7.6
Quoted 11 lines · Dave Airlie
From: Dave Airlie <[email protected]>
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?
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie
maintainerQuoted 2 lines
Would
prefer_shadowever 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.
Quoted 3 lines
Isn't
preferred_depthjust 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.
Quoted 6 lines · On Thu, 29 Sep 2011 09:43:12 -0700 Eric Anholt <[email protected]> wrote:
Quoted 5 lines · Dave Airlie
From: Dave Airlie <[email protected]>
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.
Quoted 8 lines
Quoted 6 lines
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_shadowever 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
Quoted 9 lines · On Thu, 29 Sep 2011 16:26:32 +0100 Dave Airlie <[email protected]> wrote:
From: Dave Airlie <[email protected]>
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 ?
Dave Airlie
maintainerQuoted 10 lines · Alan Cox
Quoted 7 lines · On Thu, 29 Sep 2011 16:26:32 +0100 Dave Airlie <[email protected]> wrote:
From: Dave Airlie <[email protected]>
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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
Dave Airlie
maintainerQuoted 8 lines · Alan Cox
Quoted 3 lines
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.
Quoted 33 lines
From: Dave Airlie <[email protected]>
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(-)drivers/gpu/drm/drm_ioctl.c +5
-0@@ -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;
drivers/gpu/drm/drm_ioctl.c int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_priv) · line 300
Quoted 10 lines
drivers/gpu/drm/drm_ioctl.c +7
-0+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 ; }
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.