Re: [patch 2/3] vmwgfx: depends on FB
On 11 mar 2010, at 22.01, a...@linux-foundation.org wrote: From: Randy Dunlap randy.dun...@oracle.com vmwfgx uses framebuffer interfaces, so it should depend on FB. Otherwise it has these build errors (e.g., when CONFIG_FB=m): drivers/built-in.o: In function `vmw_fb_close': (.text+0x97713): undefined reference to `unregister_framebuffer' drivers/built-in.o: In function `vmw_fb_close': (.text+0x97754): undefined reference to `framebuffer_release' drivers/built-in.o: In function `vmw_fb_init': (.text+0x97e1c): undefined reference to `framebuffer_alloc' drivers/built-in.o: In function `vmw_fb_init': (.text+0x9838d): undefined reference to `register_framebuffer' drivers/built-in.o: In function `vmw_fb_init': (.text+0x9842a): undefined reference to `framebuffer_release' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: David Airlie airl...@linux.ie Signed-off-by: Andrew Morton a...@linux-foundation.org Thanks and Acked-by: Jakob Bornecrantz ja...@vmware.com Cheers Jakob. --- drivers/gpu/drm/vmwgfx/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb drivers/gpu/drm/vmwgfx/Kconfig --- a/drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb +++ a/drivers/gpu/drm/vmwgfx/Kconfig @@ -1,6 +1,6 @@ config DRM_VMWGFX tristate DRM driver for VMware Virtual GPU - depends on DRM PCI + depends on DRM PCI FB select FB_DEFERRED_IO select FB_CFB_FILLRECT select FB_CFB_COPYAREA _ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vmwgfx + VMWare 7.0 - libdrm modetest.c
On 9 feb 2010, at 13.05, Peter Hanzel wrote:
Hello.
I have a question about libdrm/libkms and test/modetest/modetest.c.
I am now working with vmwgfx + VMWare 7.0, where vmwgfx had correctly
initialized framebuffer and also now using fbcon.
Now I want to test it woth modetest.c
This program is only for intel so i recoded it to use libkms
functions.
I had to add:
struct kms_bo
{
struct kms_driver *kms;
void *ptr;
size_t size;
size_t offset;
size_t pitch;
unsigned handle;
};
to modetest.c to compile it.
Now the test can set mode. I have tested 800x600 and also 1024x768.
But my problem is that screen is always black. If you take a look into
modetest.c it is making that nice one tilled colour screen.
The problem lines are in:
libkms/vmwgfx.c
static int
vmwgfx_bo_create(struct kms_driver *kms,
const unsigned width, const unsigned height,
const enum kms_bo_type type, const unsigned *attr,
struct kms_bo **out)
{
do {
ret = drmCommandWriteRead(bo-base.kms-fd,
DRM_VMW_ALLOC_DMABUF,
arg, sizeof(arg));
} while (ret == -ERESTART);
if (ret)
goto err_free;
bo-base.handle = rep-handle;
bo-map_handle = rep-map_handle;
bo-base.handle = rep-cur_gmr_id;
bo-base.offset = rep-cur_gmr_offset;
As you can see, there is:
bo-base.handle = rep-handle;
bo-base.handle = rep-cur_gmr_id;
So it is overwiting the same base.handle.
This handle I am using in modetest.c - drmModeAddFB(). maybe
here is
error,
bo-base.handle is not the correct one for use in drmModeAddFB(
bo-handle)
So my question is:
1) The need of define for strcut kms_bo (is is located in
libkms/internal.h)
struct kms_bo is a internal resource to the libkms interface, it
should be opaque to the user but to the internal code. All the buffer
exposes pretty much the same set of information to the user but might
need extra information attached. Defining a base kms_bo object that
backends can use as a baseclass allows code to be shared.
2) Why the screen is still black?
You need to use the drmModeDirtyFB ioctl/function to tell the Kernel
to update the screen. Just call it like so drmModeDirtyFB(fd, fb,
NULL, 0); and it should update the whole screen.
Cheers Jakob.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/vmwgfx: Fix a circular locking dependency bug.
From: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 17 +
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 13 +++--
3 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 0eaf682..9c89868 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -113,6 +113,7 @@ struct vmw_fifo_state {
unsigned long static_buffer_size;
bool using_bounce_buffer;
uint32_t capabilities;
+ struct mutex fifo_mutex;
struct rw_semaphore rwsem;
};
@@ -213,7 +214,7 @@ struct vmw_private {
* Fencing and IRQs.
*/
- uint32_t fence_seq;
+ atomic_t fence_seq;
wait_queue_head_t fence_queue;
wait_queue_head_t fifo_queue;
atomic_t fence_queue_waiters;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 4157547..39d43a0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -74,6 +74,7 @@ int vmw_fifo_init(struct vmw_private *dev_priv, struct
vmw_fifo_state *fifo)
fifo-reserved_size = 0;
fifo-using_bounce_buffer = false;
+ mutex_init(fifo-fifo_mutex);
init_rwsem(fifo-rwsem);
/*
@@ -117,7 +118,7 @@ int vmw_fifo_init(struct vmw_private *dev_priv, struct
vmw_fifo_state *fifo)
(unsigned int) min,
(unsigned int) fifo-capabilities);
- dev_priv-fence_seq = dev_priv-last_read_sequence;
+ atomic_set(dev_priv-fence_seq, dev_priv-last_read_sequence);
iowrite32(dev_priv-last_read_sequence, fifo_mem + SVGA_FIFO_FENCE);
return vmw_fifo_send_fence(dev_priv, dummy);
@@ -283,7 +284,7 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv,
uint32_t bytes)
uint32_t reserveable = fifo_state-capabilities SVGA_FIFO_CAP_RESERVE;
int ret;
- down_write(fifo_state-rwsem);
+ mutex_lock(fifo_state-fifo_mutex);
max = ioread32(fifo_mem + SVGA_FIFO_MAX);
min = ioread32(fifo_mem + SVGA_FIFO_MIN);
next_cmd = ioread32(fifo_mem + SVGA_FIFO_NEXT_CMD);
@@ -351,7 +352,7 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv,
uint32_t bytes)
}
out_err:
fifo_state-reserved_size = 0;
- up_write(fifo_state-rwsem);
+ mutex_unlock(fifo_state-fifo_mutex);
return NULL;
}
@@ -426,6 +427,7 @@ void vmw_fifo_commit(struct vmw_private *dev_priv, uint32_t
bytes)
}
+ down_write(fifo_state-rwsem);
if (fifo_state-using_bounce_buffer || reserveable) {
next_cmd += bytes;
if (next_cmd = max)
@@ -437,8 +439,9 @@ void vmw_fifo_commit(struct vmw_private *dev_priv, uint32_t
bytes)
if (reserveable)
iowrite32(0, fifo_mem + SVGA_FIFO_RESERVED);
mb();
- vmw_fifo_ping_host(dev_priv, SVGA_SYNC_GENERIC);
up_write(fifo_state-rwsem);
+ vmw_fifo_ping_host(dev_priv, SVGA_SYNC_GENERIC);
+ mutex_unlock(fifo_state-fifo_mutex);
}
int vmw_fifo_send_fence(struct vmw_private *dev_priv, uint32_t *sequence)
@@ -451,9 +454,7 @@ int vmw_fifo_send_fence(struct vmw_private *dev_priv,
uint32_t *sequence)
fm = vmw_fifo_reserve(dev_priv, bytes);
if (unlikely(fm == NULL)) {
- down_write(fifo_state-rwsem);
- *sequence = dev_priv-fence_seq;
- up_write(fifo_state-rwsem);
+ *sequence = atomic_read(dev_priv-fence_seq);
ret = -ENOMEM;
(void)vmw_fallback_wait(dev_priv, false, true, *sequence,
false, 3*HZ);
@@ -461,7 +462,7 @@ int vmw_fifo_send_fence(struct vmw_private *dev_priv,
uint32_t *sequence)
}
do {
- *sequence = dev_priv-fence_seq++;
+ *sequence = atomic_add_return(1, dev_priv-fence_seq);
} while (*sequence == 0);
if (!(fifo_state-capabilities SVGA_FIFO_CAP_FENCE)) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
index d40086f..4d7cb53 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_irq.c
@@ -85,19 +85,12 @@ bool vmw_fence_signaled(struct vmw_private *dev_priv,
return true;
/**
-* Below is to signal stale fences that have wrapped.
-* First, block fence submission.
-*/
-
- down_read(fifo_state-rwsem);
-
- /**
* Then check if the sequence is higher than what we've actually
* emitted. Then the fence is stale and signaled.
*/
- ret = ((dev_priv-fence_seq - sequence) VMW_FENCE_WRAP);
- up_read(fifo_state-rwsem
[PATCH] drm/vmwgfx: Update the user-space interface.
From: Thomas Hellstrom thellst...@vmware.com
When time-based throttling is implemented, we need to bump minor.
When the old way of detecting scanout is removed, we need to bump major.
In the meantime, this change should not break existing user-space.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |5 +++--
include/drm/vmwgfx_drm.h | 12 +---
4 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 135be96..0eaf682 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -39,10 +39,10 @@
#include ttm/ttm_execbuf_util.h
#include ttm/ttm_module.h
-#define VMWGFX_DRIVER_DATE 20090724
+#define VMWGFX_DRIVER_DATE 20100118
#define VMWGFX_DRIVER_MAJOR 0
-#define VMWGFX_DRIVER_MINOR 1
-#define VMWGFX_DRIVER_PATCHLEVEL 2
+#define VMWGFX_DRIVER_MINOR 9
+#define VMWGFX_DRIVER_PATCHLEVEL 0
#define VMWGFX_FILE_PAGE_OFFSET 0x0010
#define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
#define VMWGFX_MAX_RELOCATIONS 2048
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 778851f..1c7a316 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -48,6 +48,12 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
case DRM_VMW_PARAM_FIFO_OFFSET:
param-value = dev_priv-mmio_start;
break;
+ case DRM_VMW_PARAM_HW_CAPS:
+ param-value = dev_priv-capabilities;
+ break;
+ case DRM_VMW_PARAM_FIFO_CAPS:
+ param-value = dev_priv-fifo.capabilities;
+ break;
default:
DRM_ERROR(Illegal vmwgfx get param request: %d\n,
param-param);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index c7efbd4..933e90d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -610,9 +610,10 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
*/
srf-flags = ~SVGA3D_SURFACE_HINT_SCANOUT;
srf-scanout = true;
- } else {
+ } else if (req-scanout)
+ srf-scanout = true;
+ else
srf-scanout = false;
- }
if (srf-scanout
srf-num_sizes == 1
diff --git a/include/drm/vmwgfx_drm.h b/include/drm/vmwgfx_drm.h
index 2be7e12..dfaf3c2 100644
--- a/include/drm/vmwgfx_drm.h
+++ b/include/drm/vmwgfx_drm.h
@@ -68,7 +68,8 @@
#define DRM_VMW_PARAM_NUM_FREE_STREAMS 1
#define DRM_VMW_PARAM_3D 2
#define DRM_VMW_PARAM_FIFO_OFFSET 3
-
+#define DRM_VMW_PARAM_HW_CAPS 4
+#define DRM_VMW_PARAM_FIFO_CAPS5
/**
* struct drm_vmw_getparam_arg
@@ -181,6 +182,8 @@ struct drm_vmw_context_arg {
* The size of the array should equal the total number of mipmap levels.
* @shareable: Boolean whether other clients (as identified by file
descriptors)
* may reference this surface.
+ * @scanout: Boolean whether the surface is intended to be used as a
+ * scanout.
*
* Input data to the DRM_VMW_CREATE_SURFACE Ioctl.
* Output data from the DRM_VMW_REF_SURFACE Ioctl.
@@ -192,7 +195,7 @@ struct drm_vmw_surface_create_req {
uint32_t mip_levels[DRM_VMW_MAX_SURFACE_FACES];
uint64_t size_addr;
int32_t shareable;
- uint32_t pad64;
+ int32_t scanout;
};
/**
@@ -295,6 +298,9 @@ union drm_vmw_surface_reference_arg {
*
* @commands: User-space address of a command buffer cast to an uint64_t.
* @command-size: Size in bytes of the command buffer.
+ * @throttle-us: Sleep until software is less than @throttle_us
+ * microseconds ahead of hardware. The driver may round this value
+ * to the nearest kernel tick.
* @fence_rep: User-space address of a struct drm_vmw_fence_rep cast to an
* uint64_t.
*
@@ -304,7 +310,7 @@ union drm_vmw_surface_reference_arg {
struct drm_vmw_execbuf_arg {
uint64_t commands;
uint32_t command_size;
- uint32_t pad64;
+ uint32_t throttle_us;
uint64_t fence_rep;
};
--
1.6.0.4
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/vmwgfx: Support old hardware
Also included are overall modesetting improvements
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |5 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 81 --
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 18
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 68 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 70 -
6 files changed, 144 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index a6e8f68..5268af2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -318,6 +318,15 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
goto out_err3;
}
+ /* need mmio memory to check for fifo pitchlock cap */
+ if (!(dev_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY)
+ !(dev_priv-capabilities SVGA_CAP_PITCHLOCK)
+ !vmw_fifo_have_pitchlock(dev_priv)) {
+ ret = -ENOSYS;
+ DRM_ERROR(Hardware has no pitchlock\n);
+ goto out_err4;
+ }
+
dev_priv-tdev = ttm_object_device_init
(dev_priv-mem_global_ref.object, 12);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 356dc93..fdcc1d6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -179,6 +179,7 @@ struct vmw_private {
uint32_t vga_red_mask;
uint32_t vga_blue_mask;
uint32_t vga_green_mask;
+ uint32_t vga_pitchlock;
/*
* Framebuffer info.
@@ -393,6 +394,7 @@ extern int vmw_fifo_send_fence(struct vmw_private *dev_priv,
extern void vmw_fifo_ping_host(struct vmw_private *dev_priv, uint32_t reason);
extern int vmw_fifo_mmap(struct file *filp, struct vm_area_struct *vma);
extern bool vmw_fifo_have_3d(struct vmw_private *dev_priv);
+extern bool vmw_fifo_have_pitchlock(struct vmw_private *dev_priv);
/**
* TTM glue - vmwgfx_ttm_glue.c
@@ -466,6 +468,9 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
struct ttm_object_file *tfile,
struct ttm_buffer_object *bo,
SVGA3dCmdHeader *header);
+void vmw_kms_write_svga(struct vmw_private *vmw_priv,
+ unsigned width, unsigned height, unsigned pitch,
+ unsigned bbp, unsigned depth);
/**
* Overlay control - vmwgfx_overlay.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 9822ee6..c1eae30 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -135,16 +135,14 @@ static int vmw_fb_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
- /* without multimon its hard to resize */
- if (!(vmw_priv-capabilities SVGA_CAP_MULTIMON)
- (var-xres != par-max_width ||
-var-yres != par-max_height)) {
- DRM_ERROR(Tried to resize, but we don't have multimon\n);
+ if (!(vmw_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY)
+ (var-xoffset != 0 || var-yoffset != 0)) {
+ DRM_ERROR(Can not handle panning without display topology\n);
return -EINVAL;
}
- if (var-xres par-max_width ||
- var-yres par-max_height) {
+ if ((var-xoffset + var-xres) par-max_width ||
+ (var-yoffset + var-yres) par-max_height) {
DRM_ERROR(Requested geom can not fit in framebuffer\n);
return -EINVAL;
}
@@ -157,8 +155,8 @@ static int vmw_fb_set_par(struct fb_info *info)
struct vmw_fb_par *par = info-par;
struct vmw_private *vmw_priv = par-vmw_priv;
- if (vmw_priv-capabilities SVGA_CAP_MULTIMON) {
- vmw_write(vmw_priv, SVGA_REG_NUM_GUEST_DISPLAYS, 1);
+ if (vmw_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY) {
+ vmw_write(vmw_priv, SVGA_REG_ENABLE, 0);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, 0);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_IS_PRIMARY, true);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_X, 0);
@@ -167,18 +165,11 @@ static int vmw_fb_set_par(struct fb_info *info)
vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, 0);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
- vmw_write(vmw_priv, SVGA_REG_ENABLE, 1);
- vmw_write(vmw_priv, SVGA_REG_WIDTH, par-max_width);
- vmw_write(vmw_priv, SVGA_REG_HEIGHT, par-max_height);
- vmw_write(vmw_priv, SVGA_REG_BITS_PER_PIXEL, par-bpp);
- vmw_write(vmw_priv, SVGA_REG_DEPTH, par-depth);
- vmw_write(vmw_priv, SVGA_REG_RED_MASK, 0x00ff
[PATCH] drm/vmwgfx: Bump major and drop scanout flag compat
Even if this bumps the version to 1 it does not mean the driver is
out of staging. From what we know this is the last backwards
incompatible change to the driver.
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 +
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 9c89868..356dc93 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -39,9 +39,9 @@
#include ttm/ttm_execbuf_util.h
#include ttm/ttm_module.h
-#define VMWGFX_DRIVER_DATE 20100118
-#define VMWGFX_DRIVER_MAJOR 0
-#define VMWGFX_DRIVER_MINOR 9
+#define VMWGFX_DRIVER_DATE 20100209
+#define VMWGFX_DRIVER_MAJOR 1
+#define VMWGFX_DRIVER_MINOR 0
#define VMWGFX_DRIVER_PATCHLEVEL 0
#define VMWGFX_FILE_PAGE_OFFSET 0x0010
#define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 933e90d..f8fbbc6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -35,11 +35,6 @@
#define VMW_RES_SURFACE ttm_driver_type1
#define VMW_RES_STREAM ttm_driver_type2
-/* XXX: This isn't a real hardware flag, but just a hack for kernel to
- * know about primary surfaces. Find a better way to accomplish this.
- */
-#define SVGA3D_SURFACE_HINT_SCANOUT (1 9)
-
struct vmw_user_context {
struct ttm_base_object base;
struct vmw_resource res;
@@ -579,6 +574,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
srf-flags = req-flags;
srf-format = req-format;
+ srf-scanout = req-scanout;
memcpy(srf-mip_levels, req-mip_levels, sizeof(srf-mip_levels));
srf-num_sizes = 0;
for (i = 0; i DRM_VMW_MAX_SURFACE_FACES; ++i)
@@ -604,17 +600,6 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
if (unlikely(ret != 0))
goto out_err1;
- if (srf-flags SVGA3D_SURFACE_HINT_SCANOUT) {
- /* we should not send this flag down to hardware since
-* its not a official one
-*/
- srf-flags = ~SVGA3D_SURFACE_HINT_SCANOUT;
- srf-scanout = true;
- } else if (req-scanout)
- srf-scanout = true;
- else
- srf-scanout = false;
-
if (srf-scanout
srf-num_sizes == 1
srf-sizes[0].width == 64
--
1.6.0.4
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 4/4] drm/vmwgfx: Handle old hardware
On 30 jan 2010, at 03.38, Jakob Bornecrantz wrote: This allows both fbdev and kms to work on older hardware that does not have the display topology cap. There are also some other misc improvments related to handling older hardware version of SVGA. The current cut of is if the pitchlock cap is not set. Signed-off-by: Jakob Bornecrantz ja...@vmware.com NACK: Turns out that this patch has problems reboots and fails to set a mode. I'm working on something more proper. Cheers Jakob. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/vmwgfx: Request SVGA version 2
On 29 jan 2010, at 07.57, Michel Dänzer wrote:
On Thu, 2010-01-28 at 18:59 +, Jakob Bornecrantz wrote:
From: Peter Hanzel hanzelpe...@gmail.com
This fixes the driver not loading on older versions of VMware.
Signed-off-by: Peter Hanzel hanzelpe...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/
vmwgfx/vmwgfx_drv.c
index f47ff2c..8e68333 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -209,6 +209,7 @@ static int vmw_driver_load(struct drm_device
*dev, unsigned long chipset)
{
struct vmw_private *dev_priv;
int ret;
+long svga_id;
This should be uint32_t rather than long.
Ah right.
@@ -239,6 +240,13 @@ static int vmw_driver_load(struct drm_device
*dev, unsigned long chipset)
dev_priv-mmio_start = pci_resource_start(dev-pdev, 2);
mutex_lock(dev_priv-hw_mutex);
+
+vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
+svga_id = vmw_read(dev_priv, SVGA_REG_ID);
+if (svga_id == SVGA_ID_2) {
+DRM_INFO(We have SVGA ID 2\n);
+}
+
dev_priv-capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);
if (dev_priv-capabilities SVGA_CAP_GMR) {
Shouldn't this be something like:
vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
svga_id = vmw_read(dev_priv, SVGA_REG_ID);
if (svga_id != SVGA_ID_2) {
DRM_ERROR(Unsupported SVGA ID 0x%lx\n, svga_id);
/* Bail */
}
I guess its better to bail on old hardware that we haven't tested on.
I'll respin this patch.
Cheers Jakob.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/4] drm/vmwgfx: Fixes and more support for old hardware
This a slightly updated patch series to the ones already sent out earlier. Not much to say about them except that I would like to get some more eyes or maybe even at tested-by on the last patch. Its quite intrusive. I wanted it to go out early so more people had access to it, release early and often and all that. Peter patch 0004 should fix the problems you where having with getting kms working on VMware Workstation 5.5.2. It would be awesome if you could test it and give me a tested by on it. Cheers Jakob. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] drm/vmwgfx: Handle old hardware
This allows both fbdev and kms to work on older hardware
that does not have the display topology cap.
There are also some other misc improvments related to handling
older hardware version of SVGA. The current cut of is if the
pitchlock cap is not set.
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 45 +--
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 18 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 64 +++---
6 files changed, 119 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index a6e8f68..5268af2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -318,6 +318,15 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
goto out_err3;
}
+ /* need mmio memory to check for fifo pitchlock cap */
+ if (!(dev_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY)
+ !(dev_priv-capabilities SVGA_CAP_PITCHLOCK)
+ !vmw_fifo_have_pitchlock(dev_priv)) {
+ ret = -ENOSYS;
+ DRM_ERROR(Hardware has no pitchlock\n);
+ goto out_err4;
+ }
+
dev_priv-tdev = ttm_object_device_init
(dev_priv-mem_global_ref.object, 12);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 135be96..3e03cb7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -178,6 +178,7 @@ struct vmw_private {
uint32_t vga_red_mask;
uint32_t vga_blue_mask;
uint32_t vga_green_mask;
+ uint32_t vga_pitchlock;
/*
* Framebuffer info.
@@ -392,6 +393,7 @@ extern int vmw_fifo_send_fence(struct vmw_private *dev_priv,
extern void vmw_fifo_ping_host(struct vmw_private *dev_priv, uint32_t reason);
extern int vmw_fifo_mmap(struct file *filp, struct vm_area_struct *vma);
extern bool vmw_fifo_have_3d(struct vmw_private *dev_priv);
+extern bool vmw_fifo_have_pitchlock(struct vmw_private *dev_priv);
/**
* TTM glue - vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 9822ee6..994ad2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -135,16 +135,14 @@ static int vmw_fb_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
- /* without multimon its hard to resize */
- if (!(vmw_priv-capabilities SVGA_CAP_MULTIMON)
- (var-xres != par-max_width ||
-var-yres != par-max_height)) {
- DRM_ERROR(Tried to resize, but we don't have multimon\n);
+ if (!(vmw_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY)
+ (var-xoffset != 0 || var-yoffset != 0)) {
+ DRM_ERROR(Can not handle panning without display topology\n);
return -EINVAL;
}
- if (var-xres par-max_width ||
- var-yres par-max_height) {
+ if ((var-xoffset + var-xres) par-max_width ||
+ (var-yoffset + var-yres) par-max_height) {
DRM_ERROR(Requested geom can not fit in framebuffer\n);
return -EINVAL;
}
@@ -157,8 +155,7 @@ static int vmw_fb_set_par(struct fb_info *info)
struct vmw_fb_par *par = info-par;
struct vmw_private *vmw_priv = par-vmw_priv;
- if (vmw_priv-capabilities SVGA_CAP_MULTIMON) {
- vmw_write(vmw_priv, SVGA_REG_NUM_GUEST_DISPLAYS, 1);
+ if (vmw_priv-capabilities SVGA_CAP_DISPLAY_TOPOLOGY) {
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, 0);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_IS_PRIMARY, true);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_X, 0);
@@ -177,8 +174,6 @@ static int vmw_fb_set_par(struct fb_info *info)
vmw_write(vmw_priv, SVGA_REG_BLUE_MASK, 0x00ff);
/* TODO check if pitch and offset changes */
-
- vmw_write(vmw_priv, SVGA_REG_NUM_GUEST_DISPLAYS, 1);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, 0);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_IS_PRIMARY, true);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_X,
info-var.xoffset);
@@ -187,12 +182,27 @@ static int vmw_fb_set_par(struct fb_info *info)
vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, info-var.yres);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
} else {
+ vmw_write(vmw_priv, SVGA_REG_ENABLE, 0);
+ if (vmw_fifo_have_pitchlock(vmw_priv))
+ iowrite32(info-fix.line_length, vmw_priv-mmio_virt +
SVGA_FIFO_PITCHLOCK
[PATCH 3/4] drm/vmwgfx: Don't send bad flags to the host
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
3 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 59acc51..135be96 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -96,6 +96,8 @@ struct vmw_surface {
struct drm_vmw_size *sizes;
uint32_t num_sizes;
+ bool scanout;
+
/* TODO so far just a extra pointer */
struct vmw_cursor_snooper snooper;
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 686692d..eeba6d1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -707,6 +707,9 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
if (ret)
goto try_dmabuf;
+ if (!surface-scanout)
+ goto err_not_scanout;
+
ret = vmw_kms_new_framebuffer_surface(dev_priv, surface, vfb,
mode_cmd-width,
mode_cmd-height);
@@ -740,6 +743,13 @@ try_dmabuf:
}
return vfb-base;
+
+err_not_scanout:
+ DRM_ERROR(surface not marked as scanout\n);
+ /* vmw_user_surface_lookup takes one ref */
+ vmw_surface_unreference(surface);
+
+ return NULL;
}
static int vmw_kms_fb_changed(struct drm_device *dev)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index e01db12..c7efbd4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -35,6 +35,11 @@
#define VMW_RES_SURFACE ttm_driver_type1
#define VMW_RES_STREAM ttm_driver_type2
+/* XXX: This isn't a real hardware flag, but just a hack for kernel to
+ * know about primary surfaces. Find a better way to accomplish this.
+ */
+#define SVGA3D_SURFACE_HINT_SCANOUT (1 9)
+
struct vmw_user_context {
struct ttm_base_object base;
struct vmw_resource res;
@@ -599,8 +604,17 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
if (unlikely(ret != 0))
goto out_err1;
+ if (srf-flags SVGA3D_SURFACE_HINT_SCANOUT) {
+ /* we should not send this flag down to hardware since
+* its not a official one
+*/
+ srf-flags = ~SVGA3D_SURFACE_HINT_SCANOUT;
+ srf-scanout = true;
+ } else {
+ srf-scanout = false;
+ }
- if (srf-flags (1 9)
+ if (srf-scanout
srf-num_sizes == 1
srf-sizes[0].width == 64
srf-sizes[0].height == 64
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] drm/vmwgfx: Request SVGA version 2 and bail if not found
From: Peter Hanzel hanzelpe...@gmail.com
This fixes the driver not loading on older versions of VMware.
Signed-off-by: Peter Hanzel hanzelpe...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f47ff2c..a6e8f68 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -209,6 +209,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
{
struct vmw_private *dev_priv;
int ret;
+ uint32_t svga_id;
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (unlikely(dev_priv == NULL)) {
@@ -239,6 +240,16 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev_priv-mmio_start = pci_resource_start(dev-pdev, 2);
mutex_lock(dev_priv-hw_mutex);
+
+ vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
+ svga_id = vmw_read(dev_priv, SVGA_REG_ID);
+ if (svga_id != SVGA_ID_2) {
+ ret = -ENOSYS;
+ DRM_ERROR(Unsuported SVGA ID 0x%x\n, svga_id);
+ mutex_unlock(dev_priv-hw_mutex);
+ goto out_err0;
+ }
+
dev_priv-capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);
if (dev_priv-capabilities SVGA_CAP_GMR) {
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] drm/vmwgfx: Correctly detect 3D
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |2 +-
4 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index dedd121..f47ff2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -357,6 +357,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
dev_priv-pm_nb.notifier_call = vmwgfx_pm_notifier;
register_pm_notifier(dev_priv-pm_nb);
+ DRM_INFO(%s, vmw_fifo_have_3d(dev_priv) ? Have 3D\n : No 3D\n);
+
return 0;
out_no_device:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 50529a7..59acc51 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -389,6 +389,7 @@ extern int vmw_fifo_send_fence(struct vmw_private *dev_priv,
uint32_t *sequence);
extern void vmw_fifo_ping_host(struct vmw_private *dev_priv, uint32_t reason);
extern int vmw_fifo_mmap(struct file *filp, struct vm_area_struct *vma);
+extern bool vmw_fifo_have_3d(struct vmw_private *dev_priv);
/**
* TTM glue - vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index f7d5f70..4157547 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -29,6 +29,25 @@
#include drmP.h
#include ttm/ttm_placement.h
+bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
+{
+ __le32 __iomem *fifo_mem = dev_priv-mmio_virt;
+ uint32_t fifo_min, hwversion;
+
+ fifo_min = ioread32(fifo_mem + SVGA_FIFO_MIN);
+ if (fifo_min = SVGA_FIFO_3D_HWVERSION * sizeof(unsigned int))
+ return false;
+
+ hwversion = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
+ if (hwversion == 0)
+ return false;
+
+ if (hwversion SVGA3D_HWVERSION_WS65_B1)
+ return false;
+
+ return true;
+}
+
int vmw_fifo_init(struct vmw_private *dev_priv, struct vmw_fifo_state *fifo)
{
__le32 __iomem *fifo_mem = dev_priv-mmio_virt;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 5fa6a4e..778851f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -43,7 +43,7 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
param-value = vmw_overlay_num_free_overlays(dev_priv);
break;
case DRM_VMW_PARAM_3D:
- param-value = dev_priv-capabilities SVGA_CAP_3D ? 1 : 0;
+ param-value = vmw_fifo_have_3d(dev_priv) ? 1 : 0;
break;
case DRM_VMW_PARAM_FIFO_OFFSET:
param-value = dev_priv-mmio_start;
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Don't send bad flags to the host
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
3 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 59acc51..135be96 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -96,6 +96,8 @@ struct vmw_surface {
struct drm_vmw_size *sizes;
uint32_t num_sizes;
+ bool scanout;
+
/* TODO so far just a extra pointer */
struct vmw_cursor_snooper snooper;
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 686692d..eeba6d1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -707,6 +707,9 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
if (ret)
goto try_dmabuf;
+ if (!surface-scanout)
+ goto err_not_scanout;
+
ret = vmw_kms_new_framebuffer_surface(dev_priv, surface, vfb,
mode_cmd-width,
mode_cmd-height);
@@ -740,6 +743,13 @@ try_dmabuf:
}
return vfb-base;
+
+err_not_scanout:
+ DRM_ERROR(surface not marked as scanout\n);
+ /* vmw_user_surface_lookup takes one ref */
+ vmw_surface_unreference(surface);
+
+ return NULL;
}
static int vmw_kms_fb_changed(struct drm_device *dev)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index e01db12..c7efbd4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -35,6 +35,11 @@
#define VMW_RES_SURFACE ttm_driver_type1
#define VMW_RES_STREAM ttm_driver_type2
+/* XXX: This isn't a real hardware flag, but just a hack for kernel to
+ * know about primary surfaces. Find a better way to accomplish this.
+ */
+#define SVGA3D_SURFACE_HINT_SCANOUT (1 9)
+
struct vmw_user_context {
struct ttm_base_object base;
struct vmw_resource res;
@@ -599,8 +604,17 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
if (unlikely(ret != 0))
goto out_err1;
+ if (srf-flags SVGA3D_SURFACE_HINT_SCANOUT) {
+ /* we should not send this flag down to hardware since
+* its not a official one
+*/
+ srf-flags = ~SVGA3D_SURFACE_HINT_SCANOUT;
+ srf-scanout = true;
+ } else {
+ srf-scanout = false;
+ }
- if (srf-flags (1 9)
+ if (srf-scanout
srf-num_sizes == 1
srf-sizes[0].width == 64
srf-sizes[0].height == 64
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/vmwgfx: Request SVGA version 2
From: Peter Hanzel hanzelpe...@gmail.com
This fixes the driver not loading on older versions of VMware.
Signed-off-by: Peter Hanzel hanzelpe...@gmail.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f47ff2c..8e68333 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -209,6 +209,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
{
struct vmw_private *dev_priv;
int ret;
+ long svga_id;
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (unlikely(dev_priv == NULL)) {
@@ -239,6 +240,13 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev_priv-mmio_start = pci_resource_start(dev-pdev, 2);
mutex_lock(dev_priv-hw_mutex);
+
+ vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
+ svga_id = vmw_read(dev_priv, SVGA_REG_ID);
+ if (svga_id == SVGA_ID_2) {
+ DRM_INFO(We have SVGA ID 2\n);
+ }
+
dev_priv-capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);
if (dev_priv-capabilities SVGA_CAP_GMR) {
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/vmwgfx: Correctly detect 3D
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |2 +-
4 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index dedd121..f47ff2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -357,6 +357,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
dev_priv-pm_nb.notifier_call = vmwgfx_pm_notifier;
register_pm_notifier(dev_priv-pm_nb);
+ DRM_INFO(%s, vmw_fifo_have_3d(dev_priv) ? Have 3D\n : No 3D\n);
+
return 0;
out_no_device:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 50529a7..59acc51 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -389,6 +389,7 @@ extern int vmw_fifo_send_fence(struct vmw_private *dev_priv,
uint32_t *sequence);
extern void vmw_fifo_ping_host(struct vmw_private *dev_priv, uint32_t reason);
extern int vmw_fifo_mmap(struct file *filp, struct vm_area_struct *vma);
+extern bool vmw_fifo_have_3d(struct vmw_private *dev_priv);
/**
* TTM glue - vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index f7d5f70..4157547 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -29,6 +29,25 @@
#include drmP.h
#include ttm/ttm_placement.h
+bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
+{
+ __le32 __iomem *fifo_mem = dev_priv-mmio_virt;
+ uint32_t fifo_min, hwversion;
+
+ fifo_min = ioread32(fifo_mem + SVGA_FIFO_MIN);
+ if (fifo_min = SVGA_FIFO_3D_HWVERSION * sizeof(unsigned int))
+ return false;
+
+ hwversion = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
+ if (hwversion == 0)
+ return false;
+
+ if (hwversion SVGA3D_HWVERSION_WS65_B1)
+ return false;
+
+ return true;
+}
+
int vmw_fifo_init(struct vmw_private *dev_priv, struct vmw_fifo_state *fifo)
{
__le32 __iomem *fifo_mem = dev_priv-mmio_virt;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 5fa6a4e..778851f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -43,7 +43,7 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
param-value = vmw_overlay_num_free_overlays(dev_priv);
break;
case DRM_VMW_PARAM_3D:
- param-value = dev_priv-capabilities SVGA_CAP_3D ? 1 : 0;
+ param-value = vmw_fifo_have_3d(dev_priv) ? 1 : 0;
break;
case DRM_VMW_PARAM_FIFO_OFFSET:
param-value = dev_priv-mmio_start;
--
1.6.0.4
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] Fixes for ERESTARTSYS and unlocked ioctl
As the subject says.
Cheers Jakob.
From 7063217d9aa887dac4df75e4152e1d5b8a6a248b Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom thellst...@vmware.com
Date: Tue, 8 Dec 2009 12:57:51 +0100
Subject: [PATCH] drm/vmwgfx: Fix unlocked ioctl and add propper access control
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 47 ++
1 files changed, 19 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 7b48bb3..1db1ef3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -103,37 +103,39 @@
*/
static struct drm_ioctl_desc vmw_ioctls[] = {
- VMW_IOCTL_DEF(DRM_IOCTL_VMW_GET_PARAM, vmw_getparam_ioctl, 0),
+ VMW_IOCTL_DEF(DRM_IOCTL_VMW_GET_PARAM, vmw_getparam_ioctl,
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_DMABUF, vmw_dmabuf_unref_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CURSOR_BYPASS,
- vmw_kms_cursor_bypass_ioctl, 0),
+ vmw_kms_cursor_bypass_ioctl,
+ DRM_MASTER | DRM_CONTROL_ALLOW | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CONTROL_STREAM, vmw_overlay_ioctl,
- 0),
+ DRM_MASTER | DRM_CONTROL_ALLOW | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CLAIM_STREAM, vmw_stream_claim_ioctl,
- 0),
+ DRM_MASTER | DRM_CONTROL_ALLOW | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_STREAM, vmw_stream_unref_ioctl,
- 0),
+ DRM_MASTER | DRM_CONTROL_ALLOW | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CREATE_CONTEXT, vmw_context_define_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_CONTEXT, vmw_context_destroy_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CREATE_SURFACE, vmw_surface_define_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_SURFACE, vmw_surface_destroy_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_REF_SURFACE, vmw_surface_reference_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_EXECBUF, vmw_execbuf_ioctl,
- 0),
+ DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_FIFO_DEBUG, vmw_fifo_debug_ioctl,
- 0),
+ DRM_AUTH | DRM_ROOT_ONLY | DRM_MASTER | DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_FENCE_WAIT, vmw_fence_wait_ioctl,
- 0)
+ DRM_AUTH | DRM_UNLOCKED)
};
static struct pci_device_id vmw_pci_id_list[] = {
@@ -460,11 +462,9 @@ static long vmw_unlocked_ioctl(struct file *filp, unsigned int cmd,
struct drm_file *file_priv = filp-private_data;
struct drm_device *dev = file_priv-minor-dev;
unsigned int nr = DRM_IOCTL_NR(cmd);
- long ret;
/*
- * The driver private ioctls and TTM ioctls should be
- * thread-safe.
+ * Do extra checking on driver private ioctls.
*/
if ((nr = DRM_COMMAND_BASE) (nr DRM_COMMAND_END)
@@ -477,18 +477,9 @@ static long vmw_unlocked_ioctl(struct file *filp, unsigned int cmd,
nr - DRM_COMMAND_BASE);
return -EINVAL;
}
- return drm_ioctl(filp-f_path.dentry-d_inode,
- filp, cmd, arg);
}
- /*
- * Not all old drm ioctls are thread-safe.
- */
-
- lock_kernel();
- ret = drm_ioctl(filp-f_path.dentry-d_inode, filp, cmd, arg);
- unlock_kernel();
- return ret;
+ return drm_ioctl(filp, cmd, arg);
}
static int vmw_firstopen(struct drm_device *dev)
--
1.6.0.4
From f57c0da83ed052f0a5c7c6bb07fffb091edfc986 Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom thellst...@vmware.com
Date: Tue, 8 Dec 2009 12:59:34 +0100
Subject: [PATCH] drm/vmwgfx: Return -ERESTARTSYS when interrupted by a signal.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c |6 ++
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 7a39f3e..7e73cf5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -386,7 +386,7 @@ static int vmw_validate_single_buffer(struct vmw_private *dev_priv,
return 0;
ret = vmw_gmr_bind(dev_priv, bo);
- if (likely(ret == 0 || ret == -ERESTART))
+ if (likely(ret == 0 || ret == -ERESTARTSYS))
return ret;
@@ -429,7 +429,7 @@ int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
ret = mutex_lock_interruptible(dev_priv-cmdbuf_mutex);
if (unlikely(ret != 0)) {
- ret = -ERESTART;
+ ret = -ERESTARTSYS;
goto out_no_cmd_mutex;
}
diff --git a/drivers
[PATCH 0/2] Slightly updated version of the vmwgfx driver
Hi again here is a slightly updated version of the vmwgfx driver. Its the same driver plus what ever changes has been made inside the vmwgfx repo. So not really anything interesting. The driver compiles and run on drm-core-next. Comments please? Hopefully this time the mails wont get stuck somewhere. Cheers Jakob. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] RFC: Upstreaming the vmwgfx driver
This patch series add the vmwgfx driver to the kernel tree inside the staging tree. I split the patch in two parts as the svga headers fail checkpatch quite hard. The svga* headers are shared between a lot of different components but I can understand if they get rejected due to thier uglyness. So I will clean them up before the final patch series. There are some checkpatch warnings in the second patch but only width 80. If I have the time I will also change the fbdev code to use the drm_fb_helper code. Comments please? Cheers Jakob. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Add dirty ioctl and property
This commit adds a ioctl and property to allow userspace
to notify the kernel that a framebuffer has changed. Instead
of snooping the command stream this allows finer grained
tracking of which areas have changed.
The primary user for this functionality is virtual hardware
like the vmware svga device, but also Xen hardware likes to
be notify. There is also real hardware like DisplayLink and
DisplayPort that might take advantage of this ioctl.
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/drm_crtc.c | 104
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |1 +
include/drm/drm_crtc.h | 19
include/drm/drm_mode.h | 44 ++
5 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 32756e6..4fe321d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -125,6 +125,15 @@ static struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
+static struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
+ { DRM_MODE_DIRTY_OFF, Off },
+ { DRM_MODE_DIRTY_ON, On },
+ { DRM_MODE_DIRTY_ANNOTATE, Annotate },
+};
+
+DRM_ENUM_NAME_FN(drm_get_dirty_info_name,
+drm_dirty_info_enum_list)
+
struct drm_conn_prop_enum_list {
int type;
char *name;
@@ -802,6 +811,36 @@ int drm_mode_create_dithering_property(struct drm_device
*dev)
EXPORT_SYMBOL(drm_mode_create_dithering_property);
/**
+ * drm_mode_create_dirty_property - create dirty property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_dirty_info_property(struct drm_device *dev)
+{
+ struct drm_property *dirty_info;
+ int i;
+
+ if (dev-mode_config.dirty_info_property)
+ return 0;
+
+ dirty_info =
+ drm_property_create(dev, DRM_MODE_PROP_ENUM |
+ DRM_MODE_PROP_IMMUTABLE,
+ dirty,
+ ARRAY_SIZE(drm_dirty_info_enum_list));
+ for (i = 0; i ARRAY_SIZE(drm_dirty_info_enum_list); i++)
+ drm_property_add_enum(dirty_info, i,
+ drm_dirty_info_enum_list[i].type,
+ drm_dirty_info_enum_list[i].name);
+ dev-mode_config.dirty_info_property = dirty_info;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
+
+/**
* drm_mode_config_init - initialize DRM mode_configuration structure
* @dev: DRM device
*
@@ -1753,6 +1792,71 @@ out:
return ret;
}
+int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_clip_rect __user *clips_ptr;
+ struct drm_clip_rect *clips = NULL;
+ struct drm_mode_fb_dirty_cmd *r = data;
+ struct drm_mode_object *obj;
+ struct drm_framebuffer *fb;
+ unsigned flags;
+ int num_clips;
+ int ret = 0;
+
+ mutex_lock(dev-mode_config.mutex);
+ obj = drm_mode_object_find(dev, r-fb_id, DRM_MODE_OBJECT_FB);
+ if (!obj) {
+ DRM_ERROR(invalid framebuffer id\n);
+ ret = -EINVAL;
+ goto out_err1;
+ }
+ fb = obj_to_fb(obj);
+
+ num_clips = r-num_clips;
+ clips_ptr = (struct drm_clip_rect *)(unsigned long)r-clips_ptr;
+
+ if (!num_clips != !clips_ptr) {
+ ret = -EINVAL;
+ goto out_err1;
+ }
+
+ flags = DRM_MODE_FB_DIRTY_FLAGS r-flags;
+
+ /* If userspace annotates copy, clips must come in pairs */
+ if (flags DRM_MODE_FB_DIRTY_ANNOTATE_COPY (num_clips % 2)) {
+ ret = -EINVAL;
+ goto out_err1;
+ }
+
+ if (num_clips clips_ptr) {
+ clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
+ if (!clips) {
+ ret = -ENOMEM;
+ goto out_err1;
+ }
+
+ ret = copy_from_user(clips, clips_ptr,
+num_clips * sizeof(*clips));
+ if (ret)
+ goto out_err2;
+ }
+
+ if (fb-funcs-dirty) {
+ ret = fb-funcs-dirty(fb, flags, r-color, clips, num_clips);
+ } else {
+ ret = -ENOSYS;
+ goto out_err2;
+ }
+
+out_err2:
+ kfree(clips);
+out_err1:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
+
+
/**
* drm_fb_release - remove and free the FBs on this file
* @filp: file * from the ioctl
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index bfaf59b..ff2f104 100644
[PATCH 0/2] Core drm changes for vmwgfx driver
Hi everybody Here is a small patch series that adds functionality needed by the vmwgfx driver to core drm. The first patch gives the driver hooks for the drm_[set|drop]_master ioctls. The second adds the framebuffer dirty ioctl. Checkpatch gives 1 error and 2 warnings for the second patch but in those places I have done exactly what the code is doing around it. Cheers Jakob. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm: Add support for drm master_[set|drop] callbacks.
From: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/drm_fops.c | 14 ++
drivers/gpu/drm/drm_stub.c | 11 +++
include/drm/drmP.h |9 +
3 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 251bc0e..d632f3c 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -297,6 +297,18 @@ static int drm_open_helper(struct inode *inode, struct
file *filp,
goto out_free;
}
}
+ mutex_lock(dev-struct_mutex);
+ if (dev-driver-master_set) {
+ ret = dev-driver-master_set(dev, priv, true);
+ if (ret) {
+ /* drop both references if this fails */
+ drm_master_put(priv-minor-master);
+ drm_master_put(priv-master);
+ mutex_unlock(dev-struct_mutex);
+ goto out_free;
+ }
+ }
+ mutex_unlock(dev-struct_mutex);
} else {
/* get a reference to the master */
priv-master = drm_master_get(priv-minor-master);
@@ -504,6 +516,8 @@ int drm_release(struct inode *inode, struct file *filp)
if (file_priv-minor-master == file_priv-master) {
/* drop the reference held my the minor */
+ if (dev-driver-master_drop)
+ dev-driver-master_drop(dev, file_priv, true);
drm_master_put(file_priv-minor-master);
}
}
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 55bb8a8..066b0aa 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -174,6 +174,8 @@ void drm_master_put(struct drm_master **master)
int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
+ int ret = 0;
+
if (file_priv-is_master)
return 0;
@@ -188,6 +190,13 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
mutex_lock(dev-struct_mutex);
file_priv-minor-master = drm_master_get(file_priv-master);
file_priv-is_master = 1;
+ if (dev-driver-master_set) {
+ ret = dev-driver-master_set(dev, file_priv, false);
+ if (unlikely(ret != 0)) {
+ file_priv-is_master = 0;
+ drm_master_put(file_priv-minor-master);
+ }
+ }
mutex_unlock(dev-struct_mutex);
}
@@ -204,6 +213,8 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
mutex_lock(dev-struct_mutex);
+ if (dev-driver-master_drop)
+ dev-driver-master_drop(dev, file_priv, false);
drm_master_put(file_priv-minor-master);
file_priv-is_master = 0;
mutex_unlock(dev-struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c8e64bb..bf7df3f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -795,6 +795,15 @@ struct drm_driver {
/* Master routines */
int (*master_create)(struct drm_device *dev, struct drm_master *master);
void (*master_destroy)(struct drm_device *dev, struct drm_master
*master);
+ /**
+* master_set is called whenever the minor master is set.
+* master_drop is called whenever the minor master is dropped.
+*/
+
+ int (*master_set)(struct drm_device *dev, struct drm_file *file_priv,
+ bool from_open);
+ void (*master_drop)(struct drm_device *dev, struct drm_file *file_priv,
+ bool from_release);
int (*proc_init)(struct drm_minor *minor);
void (*proc_cleanup)(struct drm_minor *minor);
--
1.6.0.4
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm: Add dirty ioctl and property
This commit adds a ioctl and property to allow userspace
to notify the kernel that a framebuffer has changed. Instead
of snooping the command stream this allows finer grained
tracking of which areas have changed.
The primary user for this functionality is virtual hardware
like the vmware svga device, but also Xen hardware likes to
be notify. There is also real hardware like DisplayLink and
DisplayPort that might take advantage of this ioctl.
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/drm_crtc.c | 105
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |1 +
include/drm/drm_crtc.h | 19
include/drm/drm_mode.h | 44 ++
5 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5cae0b3..4beb439 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -125,6 +125,16 @@ static struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
+static struct drm_prop_enum_list drm_dirty_info_enum_list[] =
+{
+ { DRM_MODE_DIRTY_OFF, Off },
+ { DRM_MODE_DIRTY_ON, On },
+ { DRM_MODE_DIRTY_ANNOTATE, Annotate },
+};
+
+DRM_ENUM_NAME_FN(drm_get_dirty_info_name,
+drm_dirty_info_enum_list)
+
struct drm_conn_prop_enum_list {
int type;
char *name;
@@ -802,6 +812,36 @@ int drm_mode_create_dithering_property(struct drm_device
*dev)
EXPORT_SYMBOL(drm_mode_create_dithering_property);
/**
+ * drm_mode_create_dirty_property - create dirty property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_dirty_info_property(struct drm_device *dev)
+{
+ struct drm_property *dirty_info;
+ int i;
+
+ if (dev-mode_config.dirty_info_property)
+ return 0;
+
+ dirty_info =
+ drm_property_create(dev, DRM_MODE_PROP_ENUM |
+ DRM_MODE_PROP_IMMUTABLE,
+ dirty,
+ ARRAY_SIZE(drm_dirty_info_enum_list));
+ for (i = 0; i ARRAY_SIZE(drm_dirty_info_enum_list); i++)
+ drm_property_add_enum(dirty_info, i,
+ drm_dirty_info_enum_list[i].type,
+ drm_dirty_info_enum_list[i].name);
+ dev-mode_config.dirty_info_property = dirty_info;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
+
+/**
* drm_mode_config_init - initialize DRM mode_configuration structure
* @dev: DRM device
*
@@ -1753,6 +1793,71 @@ out:
return ret;
}
+int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_clip_rect __user *clips_ptr;
+ struct drm_clip_rect *clips = NULL;
+ struct drm_mode_fb_dirty_cmd *r = data;
+ struct drm_mode_object *obj;
+ struct drm_framebuffer *fb;
+ unsigned flags;
+ int num_clips;
+ int ret = 0;
+
+ mutex_lock(dev-mode_config.mutex);
+ obj = drm_mode_object_find(dev, r-fb_id, DRM_MODE_OBJECT_FB);
+ if (!obj) {
+ DRM_ERROR(invalid framebuffer id\n);
+ ret = -EINVAL;
+ goto out_err1;
+ }
+ fb = obj_to_fb(obj);
+
+ num_clips = r-num_clips;
+ clips_ptr = (struct drm_clip_rect *)(unsigned long)r-clips_ptr;
+
+ if (!num_clips != !clips_ptr) {
+ ret = -EINVAL;
+ goto out_err1;
+ }
+
+ flags = DRM_MODE_FB_DIRTY_FLAGS r-flags;
+
+ /* If userspace annotates copy, clips must come in pairs */
+ if (flags DRM_MODE_FB_DIRTY_ANNOTATE_COPY (num_clips % 2)) {
+ ret = -EINVAL;
+ goto out_err1;
+ }
+
+ if (num_clips clips_ptr) {
+ clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
+ if (!clips) {
+ ret = -ENOMEM;
+ goto out_err1;
+ }
+
+ ret = copy_from_user(clips, clips_ptr,
+num_clips * sizeof(*clips));
+ if (ret)
+ goto out_err2;
+ }
+
+ if (fb-funcs-dirty) {
+ ret = fb-funcs-dirty(fb, flags, r-color, clips, num_clips);
+ } else {
+ ret = -ENOSYS;
+ goto out_err2;
+ }
+
+out_err2:
+ kfree(clips);
+out_err1:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
+
+
/**
* drm_fb_release - remove and free the FBs on this file
* @filp: file * from the ioctl
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a75ca63..18fdc21 100644
Re: [PATCH] drm/i915: Add page flipping ioctl
On 12 nov 2009, at 17.44, Kristian Høgsberg wrote:
This adds a page flipping ioctl to the KMS API. The ioctl takes an
fb ID
and a ctrc ID and flips the crtc to the given fb at the next vblank.
The ioctl returns immediately but the flip doesn't happen until after
any rendering that's currently queued up against the new framebuffer
is done. After submitting a page flip, any execbuffer involving the
old front buffer will block until the flip is completed.
Optionally, a vblank event can be generated when the swap eventually
happens.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
Okay, here we go again. Page flip ioctl, this time, with blocking in
the kernel and optional events to userspace. Blocking in the kernel
doesn't hold any locks and lets other processes use the GPU while
we're
waiting for the flip to finish.
cheers,
Kristian
Cool stuff! You have my
Acked-by: Jakob Bornecrantz ja...@vmware.com
if you fix a couple of things in the patch (mostly docu).
Can you describes what happens if userspace continues to submit
command to the pending buffer? Does it block, does the flip get
delayed, or will it complete as soon as the commands that where
pending at page_flip ioctl time?
What happens if I try to use the old framebuffer as a source? What
happens if I submit a new page_flip before the old one completes?
Twenty questions I know but I just want what happens to be well
documented, not just in this email thread but in actually source as
well. So we can say use the source Luke with good conscience.
Cheers Jakob.
drivers/gpu/drm/drm_crtc.c | 69 ++
drivers/gpu/drm/drm_drv.c|1 +
drivers/gpu/drm/i915/i915_drv.h | 11 ++
drivers/gpu/drm/i915/i915_gem.c | 63 +-
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 232 +
-
drivers/gpu/drm/i915/intel_drv.h |3 +
include/drm/drm.h|1 +
include/drm/drm_crtc.h |8 ++
include/drm/drm_mode.h | 11 ++
11 files changed, 378 insertions(+), 33 deletions(-)
[SNIP]
/**
* Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfcc60d..7df8af2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -290,6 +290,7 @@ struct drm_property {
struct drm_crtc;
struct drm_connector;
struct drm_encoder;
+struct drm_pending_vblank_event;
/**
* drm_crtc_funcs - control CRTCs for a given device
@@ -333,6 +334,11 @@ struct drm_crtc_funcs {
void (*destroy)(struct drm_crtc *crtc);
int (*set_config)(struct drm_mode_set *set);
+
+ /* Flip to the given framebuffer on next vblank */
+ int (*page_flip)(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+struct drm_pending_vblank_event *event);
};
The documentation here doesn't describe the stuff that is hard to get
about the page_flip behavior. Like the blocking draw commands on the
old framebuffer until the flip completes, that it should return
immediate and so on. Please add that.
/**
@@ -757,6 +763,8 @@ extern int drm_mode_gamma_get_ioctl(struct
drm_device *dev,
extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file
*file_priv);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
+extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
+ void *data, struct drm_file
*file_priv);
extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
int hdisplay, int vdisplay, int
vrefresh,
bool reduced, bool interlaced, bool
margins);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 1f90841..bcabc17 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -268,4 +268,15 @@ struct drm_mode_crtc_lut {
__u64 blue;
};
Same here, can you please describe the side effects are of the ioctl?
I know that none of the other ioctl's have this kind of docu, but my
feeling is that we are in the get_resources does probe boat because of
that, and I hate to see it again.
Something like:
/*
* KMS page flip ioctl, providing cool tearfree flipping since 2009.
*
* Flips between to a new framebuffer at vblank time, the ioctl will
* only schedule a flip and returns immediate. An event will be
* generated if the PAGE_FLIP_EVENT flag is set, see ??.
*
* Submitting a new page flip before the next one completes
causes ??.
*
* Side effects:
* Page flip event generated if flag is provided.
* Rendering to the old framebuffer is block untill completion
Re: [PATCH] libdrm: add KMS page flip interface
2009/5/8 Kristian Høgsberg k...@bitplanet.net:
From: Jesse Barnes jbar...@virtuousgeek.org
Sits on top of KMS page flipping ioctl.
Cool stuff.
[SNIP]
extern int drmModeCrtcSetGamma(int fd, uint32_t crtc_id, uint32_t size,
uint16_t *red, uint16_t *green, uint16_t *blue);
extern int drmModeCrtcGetGamma(int fd, uint32_t crtc_id, uint32_t size,
uint16_t *red, uint16_t *green, uint16_t *blue);
+extern int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t fb_id, void
*user_data);
I'm thinking that there are use cases where we actually want to send a
real uint64_t to the kernel and not just a wrapped pointer. So maybe
we should let the user convert the pointer instead of us doing it for
him.
diff --git a/shared-core/drm.h b/shared-core/drm.h
index b97ba09..b01fc43 100644
--- a/shared-core/drm.h
+++ b/shared-core/drm.h
@@ -1107,7 +1107,7 @@ struct drm_gem_open {
#define DRM_IOCTL_MODE_GETFB DRM_IOWR(0xAD, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_ADDFB DRM_IOWR(0xAE, struct drm_mode_fb_cmd)
#define DRM_IOCTL_MODE_RMFB DRM_IOWR(0xAF, uint32_t)
-#define DRM_IOCTL_MODE_REPLACEFB DRM_IOWR(0xB0, struct drm_mode_fb_cmd)
+#define DRM_IOCTL_MODE_PAGE_FLIP DRM_IOW( 0xB0, struct
drm_mode_page_flip)
/*...@}*/
@@ -1122,6 +1122,30 @@ struct drm_gem_open {
#define DRM_COMMAND_BASE 0x40
#define DRM_COMMAND_END 0xA0
+/**
+ * Header for events written back to userspace on the drm fd. The
+ * type defines the type of event, the length specifies the total
+ * length of the event (including the header), and user_data is
+ * typically a 64 bit value passed with the ioctl that triggered the
+ * event. A read on the drm fd will always only return complete
+ * events, that is, if for example the read buffer is 100 bytes, and
+ * there are two 64 byte events pending, only one will be returned.
+ */
+struct drm_event {
+ uint32_t type;
+ uint32_t length;
+ uint64_t user_data;
+};
Jesse and me where talking about routing hotplug events via this new
drm_event. And from that I'm not so certain if we want to have the
user_data as a generic item, I'm thinking its better to put it on the
events that actually want to use it.
[SNIP]
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event
2009/5/8 Kristian Høgsberg k...@bitplanet.net: From: Kristian Høgsberg k...@redhat.com This patch adds a vblank synced pageflip ioctl for to the modesetting family of ioctls. The ioctl takes a crtc and an fb and schedules a pageflip to the new fb at the next coming vertical blank event. This feature lets userspace implement tear-free updating of the screen contents with hw-guaranteed low latency page flipping. The ioctl is asynchronous in that it returns immediately and then later notifies the client by making an event available for reading on the drm fd. This lets applications add the drm fd to their main loop and handle other tasks while waiting for the flip to happen. The event includes the time of the flip, the frame counter and a 64 bit opaque token provided by user space in the ioctl. Great idea with the poll/read stuff. I think you have the userspace - kernel part pretty much all figured out now. [SNIP] + +/** + * drm_mode_page_flip - page flip ioctl + * @dev: DRM device + * @data: ioctl args + * @file_priv: file private data + * + * The page flip ioctl replaces the current front buffer with a new one, + * using the CRTC's mode_set_base function, which should just update + * the front buffer base pointer. It's up to mode_set_base to make + * sure the update doesn't result in tearing (on some hardware the base + * register is double buffered, so this is easy). + * + * Note that this covers just the simple case of flipping the front + * buffer immediately. Interval handling and interlaced modes have to + * be handled by userspace, or with new ioctls. + */ +int drm_mode_page_flip(struct drm_device *dev, void *data, + struct drm_file *file_priv) This function should have _ioctl appended to it. It should also go into the drm_crtc.c file. And should not use drm_crtc_helper functions and structs since those are not apart of the core kms implementation. Also I rather see as much as possible of the code below be put in the generic part and not just wrap this functions in a small function. [SNIP] + /* + * The mode_set_base call will change the domain on the new + * fb, which will force the rendering to finish and block the + * ioctl. We need to do this last part from a work queue, to + * avoid blocking userspace here. + */ + crtc-fb = obj_to_fb(fb_obj); + ret = crtc_funcs-mode_set_base(crtc, 0, 0, NULL); We should not block on rendering in the ioctl but do the call from a worker thread. And you probably need one thread per crtc. Also holding the struct_mutex while waiting for rendering might blow up in your face big time if the rendering command takes a long while to complete. [SNIP] + + /* + * Unpin the old fb after setting a mode. Must be called + * after the old framebuffer is no longer visible, ie, after + * the next vblank, typically. + */ + void (*mode_unpin_fb)(struct drm_crtc *crtc, struct drm_framebuffer *fb); I was going to say that should probably go on the framebuffer functions but the framebuffer doesn't have any helper functions. Cheers Jakob. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)
On Fri, May 1, 2009 at 10:19 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 29 Apr 2009 18:02:59 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 29 Apr 2009 15:09:33 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: I'm still working through mutlihead issues on the kernel side; the flip waits should wait for *both* vblank events before completing the flip. But other than that, I'm pretty happy with things. This incremental set fixes up the multihead handling and adds swap interval support as a bonus. It's nice to see flipping no tearing on two heads at once! Here's an update that makes all the code generic. Jakob suggested that we do the mode_set_base call out of the caller's context so we don't block the caller waiting for the GTT domain transition (effectively waiting until rendering finishes). I definitely want to do this, but I'll have to add a way to communicate the necessary flip data from the ioctl to the new work function. Cool stuff Jesse. I'm starting to agree with what Kristian said on irc, that we should only support one pending flip per crtc in the begining and then move onto supporting more later on if needed. I do think that the user space parts of libdrm looks fine with the exception of some comments. +#define DRM_IOCTL_GEM_PAGE_FLIPDRM_IOW( 0xB0, struct drm_gem_page_flip) Don't you mean DRM_IOCTL_MODE_PAGE_FLIP? +#define DRM_PAGE_FLIP_WAIT (10) /* block on previous page flip */ Isn't the comment wrong here? And if we go with the idea that we only support on pending flip, should we have some sort of flag to control if we should return -EBUSY or block until the pending flip has cleared and the flip and the calling flip has been added? Cheers Jakob. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel KMS + fbcon + Mplayer
On 29 apr 2009, at 12.04, Peter Hanzel wrote: Hello. I have tried Intel KMS in kernel 2.6.91.1 with fbcon. I am using only framebuffer console. Most fb apps works, but I have problem with mplayer. The init works but the video is badly displayed. I have investigated the problem and found, that for my laptop mode 1280x800-32. The ioctl on /dev/fb0 FBIOGET_VSCREENINFO returns. var.bits_per_pixel=32 var.transp.length = 0. So the mplayer thinks we are in 24 bit mode (maybe this is bug in mplayer, because bits_per_pixel is 32). But next I have checked it with kernel vesafb and for same mode (1280x800-32, vga=0x362 ) The fb ioctl returns var.bits_per_pixel=32 var.transp.length = 8. So is this intentionally made so. Because I think this mode use only red, green,blue and no transp. But for one pixel you must write 4 bytes. (so transp is not used). Hmm, if I remember correctly from running mplayer in the early days of kms mplayer has two fbdev drivers and I think that only #2 worked. It did worked back then but it was a long time ago. Heck it was one of the first things we demoed kms with. Cheers Jakob. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm: speed up connector mode fetching
2009/3/31 Kristian Høgsberg k...@bitplanet.net: 2009/3/31 Eric Anholt e...@anholt.net: On Fri, 2009-03-27 at 15:48 -0700, Jesse Barnes wrote: On Fri, 27 Mar 2009 22:53:00 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Fri, Mar 27, 2009 at 8:58 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: This patch speeds up drmModeGetConnector by pre-allocating mode property info space before calling into the kernel. In many cases this pre-allocation will be sufficient to hold the returned values (it's easy enough to tweak if the common case becomes larger), which means we don't have to make the second call, which saves a lot of time. Any comments or problems with the patch? Looks good, I do wonder how much time do we save on doing pre allocation, just curious? Anyways the patch is Acked-by: Jakob Bornecrantz wallbra...@gmail.com Cheers Jakob. Some of my testing showed it took about .3s for a drmModeGetConnector call and my testing showed this decrease a lot with the pre-allocation (conveniently lost the test results though). Theoretically it should be about half the cost with pre-allocation, which adds up if you multiply by the number of outputs. Seems like the ioctl needs a flag for did the user want me to go reprobe things? like we did in the X Server. Yes, please, I've been pushing for that too. Hmm I'm thinking that should be done on get resource and never done on get connector. So we can also reprobe for things like hotpluggable connectors, yet keep the change to one function. I wonder if any code expects things to be reprobed on get connector? Cheers Jakob. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm: speed up connector mode fetching
On Fri, Mar 27, 2009 at 8:58 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
This patch speeds up drmModeGetConnector by pre-allocating mode
property info space before calling into the kernel. In many cases this
pre-allocation will be sufficient to hold the returned values (it's
easy enough to tweak if the common case becomes larger), which means we
don't have to make the second call, which saves a lot of time.
Any comments or problems with the patch?
Looks good, I do wonder how much time do we save on doing pre
allocation, just curious? Anyways the patch is
Acked-by: Jakob Bornecrantz wallbra...@gmail.com
Cheers Jakob.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index 872604f..e2aba81 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -357,21 +357,45 @@ drmModeConnectorPtr drmModeGetConnector(int fd,
uint32_t connector_id)
{
struct drm_mode_get_connector conn;
drmModeConnectorPtr r = NULL;
+ int pre_props = 8, pre_modes = 16, pre_encoders = 4;
conn.connector_id = connector_id;
conn.connector_type_id = 0;
conn.connector_type = 0;
- conn.count_modes = 0;
- conn.modes_ptr = 0;
- conn.count_props = 0;
- conn.props_ptr = 0;
- conn.prop_values_ptr = 0;
- conn.count_encoders = 0;
- conn.encoders_ptr = 0;
+ conn.count_modes = pre_modes;
+ conn.count_props = pre_props;
+ conn.count_encoders = pre_encoders;
+
+ /*
+ * Pre-allocate space for some modes, properties, and encoders. If
+ * we're lucky we won't need to call into the kernel twice.
+ */
+ conn.props_ptr = VOID2U64(drmMalloc(pre_props * sizeof(uint32_t)));
+ conn.prop_values_ptr = VOID2U64(drmMalloc(pre_props *
+ sizeof(uint64_t)));
+ conn.modes_ptr = VOID2U64(drmMalloc(pre_modes *
+ sizeof(struct
drm_mode_modeinfo)));
+ conn.encoders_ptr = VOID2U64(drmMalloc(pre_encoders *
+ sizeof(uint32_t)));
if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, conn))
return 0;
+ if (conn.count_props = pre_props
+ conn.count_modes = pre_modes
+ conn.count_encoders = pre_encoders)
+ goto done;
+
+ /* Oh well, free reallocate everything and ask again... */
+ drmFree(U642VOID(conn.prop_values_ptr));
+ drmFree(U642VOID(conn.props_ptr));
+ drmFree(U642VOID(conn.modes_ptr));
+ drmFree(U642VOID(conn.encoders_ptr));
+ conn.prop_values_ptr = 0;
+ conn.props_ptr = 0;
+ conn.modes_ptr = 0;
+ conn.encoders_ptr = 0;
+
if (conn.count_props) {
conn.props_ptr =
VOID2U64(drmMalloc(conn.count_props*sizeof(uint32_t)));
conn.prop_values_ptr =
VOID2U64(drmMalloc(conn.count_props*sizeof(uint64_t)));
@@ -386,6 +410,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t
connector_id)
if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, conn))
goto err_allocs;
+done:
if(!(r = drmMalloc(sizeof(*r {
goto err_allocs;
}
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: register the LVDS before the CRT
On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven ar...@infradead.org wrote:
From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:34:46 -0700
Subject: [PATCH] KMS: register the LVDS before the CRT
for the cases where the user only really cares about lighting up one output,
or only one output at first, lighting up the LVDS (which only gets detected
with lid-up) rather than the CRT is the right answer.
This patch flips their order of registration so that this becomes possible.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
Not-acked-by: Jakob Bornecrantz wallbra...@gmail.com
I'm going to nack this patch out of principle, getting the correct
behavior from userspace depending on the order of connectors is bad.
The interface gives you enough information to find the LVDS and turn
that on only that on. Is there some other reason that the getting of
output name is slow? If so I would be happy to see patches that fixes
that.
You also have a comment change in there that isn't related to this change.
Cheers Jakob.
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a283427..c0ab079 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1466,12 +1466,12 @@ static void intel_setup_outputs(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_connector *connector;
- intel_crt_init(dev);
-
- /* Set up integrated LVDS */
+ /* Set up integrated LVDS -- will skip if the lid is closed */
if (IS_MOBILE(dev) !IS_I830(dev))
intel_lvds_init(dev);
+ intel_crt_init(dev);
+
if (IS_I9XX(dev)) {
int found;
--
1.6.0.6
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: register the LVDS before the CRT
On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven ar...@infradead.org wrote: On Thu, 26 Mar 2009 11:59:13 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven ar...@infradead.org wrote: From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:34:46 -0700 Subject: [PATCH] KMS: register the LVDS before the CRT for the cases where the user only really cares about lighting up one output, or only one output at first, lighting up the LVDS (which only gets detected with lid-up) rather than the CRT is the right answer. This patch flips their order of registration so that this becomes possible. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Not-acked-by: Jakob Bornecrantz wallbra...@gmail.com I'm going to nack this patch out of principle, getting the correct behavior from userspace depending on the order of connectors is bad. this has nothing to do with userspace though, but all about user choice. Hard coding a specific order is not giving the user choice. Please tell me how doing crt-before-lvds fails with something that isn't userspace, currently I don't see how the order is important? Last time I checked there where only one kernel side consumer of the kms, the legacy fbdev stuff. Which if I remember correctly tried to clone one fb to all connectors. If you want to do some sort of no clone setup with fbdev you should let the user define the binding on the command line. Something like i915 fb0=lvds0 fb1=crt0. There might be some issues with this naming and hotplugable connectors. And all the other users that I know of is userspace. The interface gives you enough information to find the LVDS and turn that on only that on. Is there some other reason that the getting of output name is slow? If so I would be happy to see patches that fixes that. This patch has nothing to do with speed; it is only about registration order. LVDS-before-CRT makes total sense (as long as the lid of the laptop is not closed, which is why I added the comment); while CRT-before-LVDS does not. It makes totally sense for you, for somebody else not, which is why policy in the kernel is a bad idea. What happens if the lid is closed? Is no lvds connector created? The comment you added make it sounds so, at least that was my first impression. Cheers Jakob. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: register the LVDS before the CRT
On Thu, Mar 26, 2009 at 4:25 PM, Arjan van de Ven ar...@infradead.org wrote: On Thu, 26 Mar 2009 15:59:12 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven ar...@infradead.org wrote: On Thu, 26 Mar 2009 11:59:13 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven ar...@infradead.org wrote: From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:34:46 -0700 Subject: [PATCH] KMS: register the LVDS before the CRT for the cases where the user only really cares about lighting up one output, or only one output at first, lighting up the LVDS (which only gets detected with lid-up) rather than the CRT is the right answer. This patch flips their order of registration so that this becomes possible. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Not-acked-by: Jakob Bornecrantz wallbra...@gmail.com I'm going to nack this patch out of principle, getting the correct behavior from userspace depending on the order of connectors is bad. this has nothing to do with userspace though, but all about user choice. Hard coding a specific order is not giving the user choice. Please tell me how doing crt-before-lvds fails with something that isn't userspace, currently I don't see how the order is important? Last time I checked there where only one kernel side consumer of the kms, the legacy fbdev stuff. Which if I remember correctly tried to clone one fb to all connectors. If you want to do some sort of no clone setup with fbdev you should let the user define the binding on the command line. Something like i915 fb0=lvds0 fb1=crt0. There might be some issues with this naming and hotplugable connectors. so the other patches in this patch series added a consumer that basically lights up the first one and then continues booting the kernel, while the all but first get detected asynchronously. The concern from various people was that if there was an oops, around that time, it should be on the primary display, where the driver decided what was primary. Now we are talking. Having a primary screen does make sense, but I do not think that the order in which they where discovered on the device should decide that. Couldn't there be some sort of primary field on the dev struct that get turned on? And that could be selected by a command line option like i915.primary=hdmi0 and the default being lvds, if it is present. Giving choice to the user and the default being something which I have to agree does make sense. Does this sounds okay with you? Also a primary option for drm would be smart of multi gpu systems like drm.primary=i915 maybe? This patch has nothing to do with speed; it is only about registration order. LVDS-before-CRT makes total sense (as long as the lid of the laptop is not closed, which is why I added the comment); while CRT-before-LVDS does not. It makes totally sense for you, for somebody else not, which is why policy in the kernel is a bad idea. complaining about a change in policy by saying there should be no policy is not very useful; the policy is there today. What happens if the lid is closed? Is no lvds connector created? The comment you added make it sounds so, at least that was my first impression. that is what the rest of the code says yes. I just wanted to add the comment to show that. That sounds like a bug, I don't want to have to reload my i915 driver because I had the laptop lid closed when I booted it. Or is there some code in there that adds the connector later on? Cheers Jakob. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
Jesse Barnes wrote: On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote: Here's a work in progress VGA hotplug patch that I've been testing on my GM45. I've only tested VGA interrupts so far, but other ports may work or should be easy to enable. When a hotplug interrupt is received, the i915 interrupt handler kicks off a work queue which ends up sending a uevent. I've deliberately done nothing else; I figure userspace should decide what to do with the event (ignore it, probe outputs, set up a cloned or extended configuration, etc.). Thoughts or comments? The passing of the DRM device struct to the work function is pretty ugly at this point, and could be improved, and whether hotplug detection is enabled should probably be configurable since it depends on the outputs being powered enough to detect events. Here's a slightly less revolting version. I removed all the global variables, and moved to using the system wide work queue rather than an i915 specific one, so things are much cleaner clearer. Comments? Userspace will still need to call getresources after receiving a hotplug event, but I think that's better than trying to do something by default in the kernel. When we only run fbcon we might not be blessed with a clever userspace that can add a new monitor to the fb config. Maybe we should run some sort of detection code in the intel fb code. That is my only comment and it is a minor one, so the patch is Acked-By: Jakob Bornecrantz ja...@vmware.com Cheers Jakob. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove drmModeReplaceFb after it was removed from the kernel.
Owain Ainsworth wrote: Probably should bump major after this, since it made it to a release. From 14558d90eb615c729f88ea54cae636df2ee90dfa Mon Sep 17 00:00:00 2001 From: Owain G. Ainsworth o...@openbsd.org Date: Sun, 11 Jan 2009 19:02:07 + Subject: [PATCH] Remove drmModeReplaceFb after it was removed from the kernel. It is impossible to replace the original semantics of this call purely in userland, since the fb_id would change. after discussion with Dr_Jakob Signed-Off-By: Owain Ainsworth o...@openbsd.org The patch looks good and is Acked-By: Jakob Bornecrantz ja...@vmware.com Cheers Jakob. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Drop DRM_IOCTL_MODE_REPLACEFB, add+remove works just as well.
On Thu, Dec 18, 2008 at 4:14 AM, Kristian Høgsberg k...@redhat.com wrote: The replace fb ioctl replaces the backing buffer object for a modesetting framebuffer object. This can be acheived by just creating a new framebuffer backed by the new buffer object, setting that for the crtcs in question and then removing the old framebuffer object. Signed-off-by: Kristian Høgsberg k...@redhat.com You beat me to it, so here is a Acked-by: Jakob Bornecrantz ja...@vmware.com Cheers Jakob. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RFC: DRI2 add support for different types of contexts
Hi all
So at XDS we had a quick bof about adding support in dri2 for different
types of contexts. Like VG, GLES, exa and so on. This is a first quick draft
which does that. I have updated the dri interface the glx code and the
shared dri_util code imported by dri drivers. It compiles but I haven't
tested the code.
Cheers Jakob.
From ae8bb84c220308ce3ce7c70b4ad5cb215319f3ab Mon Sep 17 00:00:00 2001
From: Jakob Bornecrantz [EMAIL PROTECTED]
Date: Thu, 4 Sep 2008 17:12:20 +0200
Subject: [PATCH] dri2: Add different types of contexts to create
---
include/GL/internal/dri_interface.h| 69 +++-
src/glx/x11/dri2_glx.c | 19 +++--
src/glx/x11/glxclient.h|5 ++
src/mesa/drivers/dri/common/dri_util.c |9 +++-
4 files changed, 95 insertions(+), 7 deletions(-)
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index e4cc16b..3a2c1fe 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -78,6 +78,10 @@ typedef struct __DRIswrastExtensionRec __DRIswrastExtension;
typedef struct __DRIbufferRec __DRIbuffer;
typedef struct __DRIdri2ExtensionRec __DRIdri2Extension;
typedef struct __DRIdri2LoaderExtensionRec __DRIdri2LoaderExtension;
+typedef struct __DRIdri2GL2ExtensionRec __DRIdri2GL2Extension;
+typedef struct __DRIdri2VGExtensionRec __DRIdri2VGExtension;
+typedef struct __DRIdri2GLESv1ExtensionRec __DRIdri2GLESv1Extension;
+typedef struct __DRIdri2GLESv2ExtensionRec __DRIdri2GLESv2Extension;
/[EMAIL PROTECTED]/
@@ -663,7 +667,70 @@ struct __DRIdri2ExtensionRec {
const __DRIconfig *config,
void *loaderPrivate);
-__DRIcontext *(*createNewContext)(__DRIscreen *screen,
+};
+
+/**
+ * This extension provides GL1/GL2 compatible context
+ * constructors for DRI2.
+ */
+#define __DRI_DRI2_GL2 DRI_DRI2_GL2
+#define __DRI_DRI2_GL2_VERSION 1
+
+struct __DRIdri2GL2ExtensionRec {
+__DRIextension base;
+
+__DRIcontext *(*createNewGL2Context)(__DRIscreen *screen,
+ const __DRIconfig *config,
+ __DRIcontext *shared,
+ void *loaderPrivate);
+
+};
+
+/**
+ * This extension provides a VG context
+ * constructor for DRI2.
+ */
+#define __DRI_DRI2_VG DRI_DRI2_VG
+#define __DRI_DRI2_VG_VERSION 1
+
+struct __DRIdri2VGExtensionRec {
+__DRIextension base;
+
+__DRIcontext *(*createNewVGContext)(__DRIscreen *screen,
+ const __DRIconfig *config,
+ __DRIcontext *shared,
+ void *loaderPrivate);
+
+};
+
+/**
+ * This extension provides a GLESv1 context
+ * constructor for DRI2.
+ */
+#define __DRI_DRI2_GLESv1 DRI_DRI2_GLESv1
+#define __DRI_DRI2_GLESv1_VERSION 1
+
+struct __DRIdri2GLESv1ExtensionRec {
+__DRIextension base;
+
+__DRIcontext *(*createNewGLESv1Context)(__DRIscreen *screen,
+ const __DRIconfig *config,
+ __DRIcontext *shared,
+ void *loaderPrivate);
+
+};
+
+/**
+ * This extension provides a GLESv2 context
+ * constructor for DRI2.
+ */
+#define __DRI_DRI2_GLESv2 DRI_DRI2_GLESv2
+#define __DRI_DRI2_GLESv2_VERSION 1
+
+struct __DRIdri2GLESv2ExtensionRec {
+__DRIextension base;
+
+__DRIcontext *(*createNewGLESv2Context)(__DRIscreen *screen,
const __DRIconfig *config,
__DRIcontext *shared,
void *loaderPrivate);
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index c56adfa..5c80c89 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -105,7 +105,7 @@ static void dri2UnbindContext(__GLXDRIcontext *context)
(*core-unbindContext)(pcp-driContext);
}
-static __GLXDRIcontext *dri2CreateContext(__GLXscreenConfigs *psc,
+static __GLXDRIcontext *dri2CreateGL2Context(__GLXscreenConfigs *psc,
const __GLcontextModes *mode,
GLXContext gc,
GLXContext shareList, int renderType)
@@ -119,13 +119,16 @@ static __GLXDRIcontext *dri2CreateContext(__GLXscreenConfigs *psc,
shared = pcp_shared-driContext;
}
+if (psc-GL2)
+ return NULL;
+
pcp = Xmalloc(sizeof *pcp);
if (pcp == NULL)
return NULL;
pcp-psc = psc;
pcp-driContext =
- (*psc-dri2-createNewContext)(psc-__driScreen,
+ (*psc-GL2-createNewGL2Context)(psc-__driScreen,
config-driConfig, shared, pcp);
gc-__driContext = pcp-driContext;
@@ -276,9 +279,17 @@ static __GLXDRIscreen *dri2CreateScreen(__GLXscreenConfigs *psc, int screen,
psc-core = (__DRIcoreExtension *) extensions[i];
if (strcmp(extensions[i]-name, __DRI_DRI2) == 0)
psc-dri2 = (__DRIdri2Extension *) extensions[i];
+ if (strcmp(extensions[i]-name, __DRI_DRI2_GL2) == 0)
+ psc-GL2 = (__DRIdri2GL2Extension *) extensions[i];
+ if (strcmp(extensions[i]-name, __DRI_DRI2_VG) == 0)
+ psc-VG = (__DRIdri2VGExtension *) extensions[i];
+ if (strcmp(extensions[i]-name, __DRI_DRI2_GLESv1) == 0)
+ psc-GLESv1 = (__DRIdri2GLESv1Extension *) extensions[i];
+ if (strcmp(extensions[i]-name
Re: Aperture mapping under GEM
On Fri, Aug 1, 2008 at 8:13 PM, Keith Packard [EMAIL PROTECTED] wrote: On Fri, 2008-08-01 at 18:48 +0200, Jakob Bornecrantz wrote: The basic fault here is that you have added a driver specific flag to a generic ioctl/syscall. Which the last time I checked we didn't want. For example on PCIE Radeon there is no GTT to map, so bit 31 makes no sense there. The GEM MMAP ioctl is driver-specific, not generic for precisely this reason. If you want a none generic ioctl for that function go ahead, but IHMO it should then be some sort of flag field on the request. Fiddling with bits on the address feels a bit icky at best. But, the last time I check the only reason you could even hope to get a mmap ioctl into mainline was under the provision that you later moved it to the mmap syscall, which is however generic. Cheers Jakob. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium HW winsys
On Thu, Jul 10, 2008 at 6:22 PM, Younes Manton [EMAIL PROTECTED] wrote: I'm trying to get the HW winsys stuff set up for XvMC and have some questions. Is there any problem with dlopen()ing the DRI driver (in this case nouveau_dri.so) and instead of writing my own winsys? Stephane suggested I look into this, even though the winsys is supposed to be tied to the API. For Softpipe I looked at what Mesa's winsys was doing and implemented the stuff I needed and ignored any GL-specific things, but I realize now I may have been able to load egl_softpipe.so and reused their winsys. Is this acceptable for nouveau if I can live with some possibly minor GL dependencies?. I'm looking at dri_glx.c and glxext.c to see how this might be done. As things currently are you need to make sure that libGL.so linked to the application. I think it just enough to dlopen() it GLOBAL and then dlopen *_dri.so you want. You then need some hocks and things to get the pipe_winsys and context creation out of the winsys or write code on your own side. I think you might be better of just writing your own winsys. But yes that is a lot of code duplication. If you look at the gallium i915 driver it has one dri winsys and one EGL winsys. Both these share a lot of backend code in a common directory, this part only talks to the DRM. Now I know this is beyond the scope of your gsoc but you could try to talk to the nouveau guys about it. dri: gallium/winsys/dri/intel EGL: gallium/winsys/egl_drm/intel backend: gallium/winsys/common/intel_drm Cheers Jakob. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Thu, Jul 10, 2008 at 2:55 PM, Tiago Vignatti [EMAIL PROTECTED] wrote: Daniel Stone escreveu: On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? Yes, Daniel. This was my first thought. Now I'm trying to discuss with you how we can distribute this things between X, drm and kernel. The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Cheers Jakob. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Eliminating pipe_texture-cpp and pipe_surface-cpp in gallium
On Fri, Jun 27, 2008 at 12:57 PM, José Fonseca
[EMAIL PROTECTED] wrote:
In order to properly represent the compressed textures and (yuv formats
to some extent) it is necessary to abandon the chars-per-pixels concept
in gallium, and use instead the concept of pixel blocks (in p_format.h):
/**
* Describe accurately the pixel format.
*
* The chars-per-pixel concept falls apart with compressed and yuv images,
where
* more than one pixel are coded in a single data block. This structure
* describes that block.
*
* Simple pixel formats are effectively a 1x1xcpp block.
*/
struct pipe_format_block
{
/** Block size in bytes */
unsigned size;
/** Block width in pixels */
unsigned width;
/** Block height in pixels */
unsigned height;
};
/**
* Describe pixel format's block.
*
* @sa http://msdn2.microsoft.com/en-us/library/ms796147.aspx
*/
static INLINE void
pf_get_block(enum pipe_format format, struct pipe_format_block *block)
{
switch(format) {
case PIPE_FORMAT_DXT1_RGBA:
case PIPE_FORMAT_DXT1_RGB:
block-size = 8;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_DXT3_RGBA:
case PIPE_FORMAT_DXT5_RGBA:
block-size = 16;
block-width = 4;
block-height = 4;
break;
case PIPE_FORMAT_YCBCR:
case PIPE_FORMAT_YCBCR_REV:
block-size = 4; /* 2*cpp */
block-width = 2;
block-height = 1;
break;
default:
block-size = pf_get_size(format);
block-width = 1;
block-height = 1;
break;
}
}
static INLINE unsigned
pf_get_nblocksx(const struct pipe_format_block *block, unsigned x)
{
return (x + block-width - 1)/block-width;
}
static INLINE unsigned
pf_get_nblocksy(const struct pipe_format_block *block, unsigned y)
{
return (y + block-height - 1)/block-height;
}
Pipe texture will become:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -303,7 +303,10 @@ struct pipe_texture
unsigned height[PIPE_MAX_TEXTURE_LEVELS];
unsigned depth[PIPE_MAX_TEXTURE_LEVELS];
- unsigned cpp:8;
+ struct pipe_format_block block;
+ unsigned nblocksx[PIPE_MAX_TEXTURE_LEVELS];
+ unsigned nblocksy[PIPE_MAX_TEXTURE_LEVELS];
+
unsigned last_level:8;/** Index of last mipmap level present/defined
*/
unsigned compressed:1;
Also, with chars per pixel gone, pitch is better be specified in bytes,
rather than pixels. To make sure that nothing gets forgotten I'm going
to rename all pipe_texture and pipe_surface pitch members to stride,
so that if somewhere is forgotten one gets a compiler error:
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -267,10 +267,12 @@ struct pipe_surface
enum pipe_format format; /** PIPE_FORMAT_x */
unsigned status; /** PIPE_SURFACE_STATUS_x */
unsigned clear_value; /** XXX may be temporary */
- unsigned cpp; /** bytes per pixel */
unsigned width;
unsigned height;
- unsigned pitch; /** in pixels */
+ struct pipe_format_block block;
+ unsigned nblocksx;
+ unsigned nblocksy;
+ unsigned stride; /** in bytes */
unsigned layout; /** PIPE_SURFACE_LAYOUT_x */
unsigned offset; /** offset from start of buffer, in bytes */
unsigned refcount;
Looks good.
I have fixed the problems in the i915simple driver and dri/intel
winsys that where remaining. So that works now.
I seem to have lost single buffer windows somewhere along the line. I
donnu if this is related to these changes (probably not), but I don't
have time to debug. Will fix it next week.
Cheers Jakob.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse [EMAIL PROTECTED] wrote: On Mon, 19 May 2008 15:03:50 +0200 Thomas Hellström [EMAIL PROTECTED] wrote: Hi! Parallell to the memory manager discussion, I think we need to revisit the case of what happens when a VRAM driver is suspending to memory. 1) The ideal thing would be for the card contents to be quickly copied to backing-store and suspend is done. However, this requires pinning as much physical pages as there is VRAM. 2) The other approach is to have a backing object of some sort, either a list of swap-entries or perhaps a gem object. The gem object would, at the point of suspend, either be paged out or unpopulated which means (provided that the swap sub-system is up at the suspend point) there will be heavy disk-access and the operation might fail due to a shortage of either swap space or physical memory for the swap system bookkeeping. Just want to know what's the general opinion here. Are the VRAM card developers planning to back all VRAM objects with pinned physical pages, or are we looking at approach 2) which might fail? /Thomas The ideal things, from my POV, is to ask to kernel to reserve swap space each time we allocate a buffer, if we ran out of swap space or whatever backing store the kernel can propose then we should fail buffer allocation even if we still have vram available. Idea being that once we migrate out stuff we know that there won't be failure to give us space to save things. Anothers things is to add a hint from userspace which tell if we can drop buffer content, i think we can use such hint for cmd buffer or others temporary buffer we know of, won't save much but still might help to save somebandwidth. Of course this need that kernel provide us an interface for such things. If i am right shmem is already talking with kernel about swap space. Cheers, Jerome Glisse The biggest question is where we can write or read pages to swap at suspend to RAM and resume from RAM under all occasions. If not we have no other option then to have pages as backing store if we want to support suspend to ram for cards with VRAM that turn the ram of at suspend to RAM. The problem is that no solution is good. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell [EMAIL PROTECTED] wrote: The biggest question is where we can write or read pages to swap at suspend to RAM and resume from RAM under all occasions. If not we have no other option then to have pages as backing store if we want to support suspend to ram for cards with VRAM that turn the ram of at suspend to RAM. It should be possible. The two-phased approach that seems to be ascendent would give all the opportunity you need in the prepare phase, while the full system is still running. http://lwn.net/Articles/274008/ Keith Yes a two step program can work. At prepare we turn on backing storage mode for VRAM, that is all buffers in VRAM gain backing storage and all buffers that are moved to VRAM keep their pages. Then at suspend we copy everything down from VRAM and turn the card off. The problem is that after prepare things must still work as before so clients can still render so we can't copy pages down then. I also don't think we can count on swap being around at the call to suspend. Heck a system might not even have swap. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 5:03 PM, Jakob Bornecrantz [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell [EMAIL PROTECTED] wrote: The biggest question is where we can write or read pages to swap at suspend to RAM and resume from RAM under all occasions. If not we have no other option then to have pages as backing store if we want to support suspend to ram for cards with VRAM that turn the ram of at suspend to RAM. It should be possible. The two-phased approach that seems to be ascendent would give all the opportunity you need in the prepare phase, while the full system is still running. http://lwn.net/Articles/274008/ Keith Yes a two step program can work. At prepare we turn on backing storage mode for VRAM, that is all buffers in VRAM gain backing storage and all buffers that are moved to VRAM keep their pages. Then at suspend we copy everything down from VRAM and turn the card off. The problem is that after prepare things must still work as before so clients can still render so we can't copy pages down then. I also don't think we can count on swap being around at the call to suspend. Heck a system might not even have swap. So the whole idea is that we have a backing store mode that is only used between prepare and suspend to make sure that buffers in VRAM can be saved. Some updates, allocating 1GB plus of memory might not work at prepare, for that matter allocating 64-256mb might not go that well over with the kernel developers for that matter. So the idea is that at prepare we evict all buffers that we can from VRAM and if we feel like it AGP too. If the driver is using a superioctl we can also temporary stop all submissions through it and wait on the last fence to be sure we can move all buffers out. That should only leave the cmdbuffer(s) and scanout buffer(s) left. For the buffers that are in VRAM we now allocate backing stores, this should not fail since we have just unpinned a lot of memory. Should this fail we are out of luck and can not suspend. After that we turn on backing store mode and unlock the superioctl so that clients can use it. Since the card should still work after prepare from what I can understand. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM modesetting sysfs
On Tue, Apr 8, 2008 at 10:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote: I just pushed a few changes updating the DRM modesetting sysfs support, both for debugging and eventual HAL friendliness. So far, the support is limited to describing outputs and generating hotplug events. A typical card0 directory now looks like this: . |-- card0-DAC-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- card0-LVDS-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- dev |-- device - ../../../../../devices/pci:00/:00:02.0 |-- dri_library_name |-- power | `-- wakeup |-- subsystem - ../../../../../class/drm `-- uevent Each output is listed, prefixed with its associated card number to disambiguate it at the top level /sys/class/drm directory (where it also has some symlinks). Currently, only DPMS, EDID, mode list and connection status properties are exported, but we could list more as needed. You can use 'udevmonitor --env' to look for hotplug events; you should see several at load time, and presumably some at connection hotplug time (though I haven't gotten that working yet, any ideas Jakob?). I was going to suggest that you plug it into the hotplug_stage_two function but it looks like you have already done that. Things might be routed differently now then since the last time I looked at the code, are you sure that stage_two is being run? Any thoughts on the interface? Anything in particular people would like to see? Looks good, can you write to dpms, that is turn a monitor on and of, that would be slightly cool but not overly useful. On the whole I think exporting properties are fine, but I don't think setting modes and crtc's are to be done in sysfs. However it is entirely possible. Thanks, Jesse Cheers Jakob. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Updated Gallium3D i915simple
Hello everyone I have updated the i915simple driver to work with drm master. It is currently in a separate branch in the mesa repo on freedesktop called gallium-i915-current. http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-i915-current But there are still problems: 1. There is a bad memory leak somewhere, I think I tracked it down to the state tracker allocating user buffers and not releasing them. 2. It was way slower then i915tex but the new slab allocator (from i915tex) made it faster which is nice (but not faster then i915tex). Moving the region pool (textures and the like) to the slab allocator from a normal drmBO pool made kernel usage drop from ~60% to ~5%, and made glxgears go from 60fps to 400 ~600 [4]. 3. It is not tested at all so I'm sure there are places where it will fall over. It would be nice if more people could try it out. 4. Currently glxgears behaves weird, it starts out fast ~600fps and then slowly drops to about 100fps. Covering the window makes it shot up to ~600fps. And uncovering it makes it slow down again. Its not instant but takes a while, and thats just weird. Cheers Jakob. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: kernel modesetting progress report....
On Thu, Feb 28, 2008 at 2:36 PM, Jerome Glisse [EMAIL PROTECTED] wrote: On Thu, 28 Feb 2008 16:53:46 +1000 Dave Airlie [EMAIL PROTECTED] wrote: So just to let people know where kernel modesetting is getting to and what I'm up to with it.. So I really want to ship something in Fedora 9 with kernel modesetting in it, whether this is a default or a special boot option for the user I won't decide for a while. But with this in mind I've checked in bunch of changes to the modesetting drm to make modesetting optional for i915, you now load the i915 module with modeset=1 to enable it. I've also created an intel-kernelmode branch which is based on the intel-batchbuffer branch, with fairly clean modesetting integration. It still needs work to fixup a few features but I'm going to work my way through the list. (it needs fixes for rotation + video at the moment) The DDX driver can detect whether modesetting is enabled in the drm and does the right thing for each case. I checked a patch into the server to allow the crtc callback to work, I think this breaks ABI with xf86Crtc.c users, need to confirm what the proper action for this is. Dave. Dave there is one things that is needed to be redone: frame buffer creation handling. And i would like we not freeze the API until we had some time to play with it a bit. So i guess my question is does this means modesetting API get freezed or not ? For frame buffer create i believe we need some kind of properties system where userspace can ask for driver specific properties at creation time. Also we need a way to allow to query the actual framebuffer properties (ie one asked at creation might not work and driver can adjust them so userspace have to requery properties to know what have been done). I'm guessing a flag system could be used, sorta like the BO flags. There are some things to consider: should we allow driver dependant flags on it or should those be exposed in a driver specific ioctl. Also do we want a offset property? So we can have two framebuffers in one buffer or just not the start of it. I also would like the BO argument to become optional ie if none is supplied it's up to the driver to allocate a BO which fit with the asked properties. Corollary frame buffer creation can fail if supplied BO ain't big enough for the asked framebuffer properties. It sounds like its just a convenience. If the driver creates it who owns it? There is also the question of reference on the buffer? Does the driver up the reference if it creates it? Finaly i am wondering if we should not provide some way to update get part of the framebuffer this could be especialy usefull in case of dumb userspace which can't understand framebuffer properties and if we ever have hw which can't have linear framebuffer but need to store it in some strange format (maybe embedded device already fall in this category). Dumb userspace shouldn't be able to create tiled or none linear framebuffers, so its not realy a problem. I'm sure there are some crazy hardware which doesn't support linear framebuffers rgb buffers, the GameCube/Wii being one(two) of them. This is the dreaded acceleration api in kernel that nobody wants but everybody does anyways. What I mean by that is that all drivers has a function to speed up clearing memory regions and copy memory between vram and agp, it takes very little work to make those general for fill and copy. Oh and modesetting can refuse to set mode if supplied framebuffer don't fit conditions. I'm pretty sure the code does this now. Cheers, Jerome Glisse Cheers Jakob. PS: Sorry Jerome, silly gmail doesn't reply to all per default. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[rfc] Modesetting Hotplug for i915
Hi there, A month or so ago I added hotplug support to the i915 driver based on the modesetting branch. The patches currently reside in the modesetting-101-hotplug branch in the main fd.o drm repo. http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-101-hotplug So how does it work. First we receive the interrupt from the hardware, the intel HW has pretty good hotplug support. In the interrupt handler I tried to do as little as possible. Which is to tell a waiting worker thread that a hotplug event has happened and which output was affected. The worker thread then does all of the actual probing and EDID parsing, since this takes far to long to be handled in a interrupt. Now I didn't implement a way for userspace to get these events, since it was just me going at it and that interface need some more thought to it. What it does do, is detect the status. On disconnect it turns the output and corresponding crtc off. On connect we turn the output on again along with updating the information in the intel_fb code. A few notes on the branch: I had to change the interrupt handling a bit, because the code treats the interrupt registers as 16bit due to the i8XX legacy. But i9XX interrupt registers are 32bit, but those bits weren't used until now that is. And because I don't have any i8XX I was a bit reluctant to push these patch straight to the modesetting-101 branch. I would now like, after discussion, merge the branch into modesetting-101. Cheers Jakob. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On 02/08/07, Jerome Glisse [EMAIL PROTECTED] wrote: Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This time i do not hijack the thread :) So we just discussed with Jakob and Jesse on this on irc and here is what i believe we agreed on: I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: DRM enhancements document
Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. I just about can't do anything right to day :) Cheers Jakob. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
I'm hijacking this thread a bit for a question. Currently we have a feature with the lvds code that powers my laptop display, which turns off the screen backlight at modeset, resulting in a near black screen. What should the default behavior be? Some suggestions: 1) leave it up to the apps (harder to write small simple apps) 2) restore previous power level (what if the screen doesn't have a previous state, or it was off) 3) always go full power (leave it up to the apps to power save) Cheers Jakob. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/3] Drm kernel side modesetting
Hia I have been talkting with Dave Airlie about kernel side modesetting, and I decided that I would see what I could do to help out in the matter. These patches contains what I have manage to do so far. Currently it is only the userspace library and kernel side functions stubs for the ioctls. I'm sending these patches now because I would like some commonts on them and also let other people know that work is being done on this matter. The the userpsace functions are based (if not a copy of) the Randr1.2 X protocol so that integration with the X server would be easy. Cheers Jakob Bornecrantz. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] Added kernel side ioctls of drm modesettings
Added kernel side ioctls of drm modesettings
From ee2bb161b7cb70b935ab626a7877bde40fedbb96 Mon Sep 17 00:00:00 2001
From: Jakob Bornecrantz [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 20:13:40 +0100
Subject: [PATCH] Added kernel side ioctls of drm modesettings
---
linux-core/Makefile.kernel |2 -
linux-core/drmP.h |1
linux-core/drm_drv.c | 14 +
linux-core/drm_mode.c | 131
linux-core/drm_mode.h | 61
5 files changed, 208 insertions(+), 1 deletions(-)
diff --git a/linux-core/Makefile.kernel b/linux-core/Makefile.kernel
index 81a9433..f42675a 100644
--- a/linux-core/Makefile.kernel
+++ b/linux-core/Makefile.kernel
@@ -13,7 +13,7 @@ drm-objs:= drm_auth.o drm_bufs.o drm
drm_sysfs.o drm_pci.o drm_agpsupport.o drm_scatter.o \
drm_memory_debug.o ati_pcigart.o drm_sman.o \
drm_hashtab.o drm_mm.o drm_object.o drm_compat.o \
- drm_fence.o drm_ttm.o drm_bo.o drm_bo_move.o
+ drm_fence.o drm_ttm.o drm_bo.o drm_bo_move.o drm_mode.o
tdfx-objs := tdfx_drv.o
r128-objs := r128_drv.o r128_cce.o r128_state.o r128_irq.o
mga-objs:= mga_drv.o mga_dma.o mga_state.o mga_warp.o mga_irq.o
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index 648e29b..37ce929 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -82,6 +82,7 @@ #define __OS_HAS_MTRR (defined(CONFIG_MT
#include drm_os_linux.h
#include drm_hashtab.h
+#include drm_mode.h
/* If you want the memory alloc debug functionality, change define below */
/* #define DEBUG_MEMORY */
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index b95f796..2a4a24f 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -123,6 +123,20 @@ #endif
DRM_AUTH },
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW)] = {drm_update_drawable_info,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY},
+
+ /* Drm modesetting */
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_GETRESOURCES)] = {drm_mode_getresources,
0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_GETFRAMEBUFFER)] = {drm_mode_getfb, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_SETFRAMEBUFFER)] = {drm_mode_setfb, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_GETCRTC)] = {drm_mode_getcrtc, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC)] = {drm_mode_setcrtc, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_GETCRTCGAMMA)] = {drm_mode_getcrtcgamma,
0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTCGAMMA)] = {drm_mode_setcrtcgamma,
0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_GETOUTPUT)] = {drm_mode_getcrtc, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_NEWMODE)] = {drm_mode_newmode, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_DESMODE)] = {drm_mode_desmode, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDMODE)] = {drm_mode_addmode, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_DELMODE)] = {drm_mode_delmode, 0},
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/linux-core/drm_mode.c b/linux-core/drm_mode.c
new file mode 100644
index 000..09c3183
--- /dev/null
+++ b/linux-core/drm_mode.c
@@ -0,0 +1,131 @@
+/*
+ * \file drm_mode.c
+ * DRM modesetting interface, kernel side.
+ *
+ * \author Jakob Bornecrantz [EMAIL PROTECTED]
+ *
+ * \par Acknowledgements:
+ * Feb 2007, Dave Airlie [EMAIL PROTECTED]
+ */
+
+/*
+ * Copyright (c) year copyright holders
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include drmP.h
+
+int drm_mode_getresources(struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ // TODO impl
+ return 0;
+}
+
+/*
+ * FrameBuffer
+ */
+int drm_mode_getfb(struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ // TODO impl
+ return 0;
+}
+
+int drm_mode_setfb(struct inode *inode, struct file *flip,
+ unsigned int cmd, unsigned
[PATCH 3/3] Added userspace side library of drm modesettings
Added userspace side library of drm modesettings - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] Added structs and ioctls for modesetting in kernel
Added structs and ioctls for modesetting in kernel
From c34f2024584b3a150bc42a1b9ae532f8246a2e8f Mon Sep 17 00:00:00 2001
From: Jakob Bornecrantz [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 20:11:39 +0100
Subject: [PATCH] Added structs and ioctls for modesetting in kernel
---
shared-core/drm.h | 125 +
1 files changed, 125 insertions(+), 0 deletions(-)
diff --git a/shared-core/drm.h b/shared-core/drm.h
index 3c59cd4..7dc6743 100644
--- a/shared-core/drm.h
+++ b/shared-core/drm.h
@@ -888,6 +888,117 @@ typedef union drm_mm_init_arg{
} rep;
} drm_mm_init_arg_t;
+/*
+ * Drm mode setting
+ */
+
+typedef struct drm_mode_modeinfo {
+
+ unsigned int id;
+
+ unsigned short width, height;
+ unsigned int dotClock;
+ unsigned short hSyncStart, hSyncEnd, hTotal, hSkew;
+ unsigned short vSyncStart, vSyncEnd, vTotal;
+
+ int count_flag;
+ unsigned int __user *modeFlags;
+
+} drm_mode_modeinfo_t;
+
+typedef struct drm_mode_card_res {
+
+ unsigned int frameBufferId;
+
+ int count_crtcs;
+ unsigned int __user *crtcs;
+
+ int count_outputs;
+ unsigned int __user *outputs;
+
+ int count_modes;
+ unsigned int __user *modes;
+
+} drm_mode_card_res_t;
+
+typedef struct drm_mode_get_fb {
+
+ unsigned int minWidth, maxWidth;
+ unsigned int minHeight, maxHeight;
+
+} drm_mode_get_fb_t;
+
+typedef struct drm_mode_set_fb {
+
+ unsigned int bufferId;
+
+ unsigned int width, height;
+
+} drm_mode_set_fb_t;
+
+typedef struct drm_mode_crtc
+{
+ unsigned int crtcId; /** Id */
+ unsigned int bufferId; /** Id of framebuffer */
+
+ int x, y; /** Position on the frameuffer */
+ unsigned int width, height;
+ unsigned int mode; /** Current mode used */
+
+ int count_outputs;
+ unsigned int __user *outputs; /** Outputs that are connected */
+
+ int count_possibles;
+ unsigned int __user *possibles; /** Outputs that can be connected */
+
+ int gamma_size;
+
+} drm_mode_crtc_t;
+
+typedef struct drm_mode_crtc_gamma {
+
+ unsigned int crtc;
+
+ int count_ramp;
+ unsigned short __user *ramps;
+
+} drm_mode_crtc_gamma_t;
+
+typedef struct drm_mode_get_output {
+
+ unsigned int output; /** Id */
+ unsigned int crtc; /** Id of crtc */
+
+ unsigned int connection;
+ unsigned int width, height; /** HxW in millimeters */
+ unsigned int subpixel;
+
+ int count_crtcs;
+ unsigned int __user *crtcs; /** possible crtc to connect to */
+
+ int count_clones;
+ unsigned int __user *clones; /** list of clones */
+
+ int count_modes;
+ unsigned int __user *modes; /** list of modes it supports */
+
+} drm_mode_get_output_t;
+
+typedef struct drm_mode_create_mode {
+
+ unsigned int modeId; /** return id */
+
+ drm_mode_modeinfo_t m;
+
+} drm_mode_create_mode_t;
+
+typedef struct drm_mode_outputmode {
+
+ unsigned int outputId;
+ unsigned int modeId; /** mode to be added/deleted */
+
+} drm_mode_outputmode_t;
+
/**
* \name Ioctls Definitions
*/
@@ -959,6 +1070,20 @@ #define DRM_IOCTL_MM_INIT
#define DRM_IOCTL_UPDATE_DRAW DRM_IOW(0x3f, drm_update_draw_t)
+#define DRM_IOCTL_MODE_GETRESOURCES DRM_IOWR(0xA0, drm_mode_card_res_t)
+#define DRM_IOCTL_MODE_FORCEPROBE DRM_IO( 0xA1)
+#define DRM_IOCTL_MODE_GETFRAMEBUFFER DRM_IOWR(0xA2, drm_mode_get_fb_t)
+#define DRM_IOCTL_MODE_SETFRAMEBUFFER DRM_IOR( 0xA3, drm_mode_set_fb_t)
+#define DRM_IOCTL_MODE_GETCRTC DRM_IOWR(0xA4, drm_mode_crtc_t)
+#define DRM_IOCTL_MODE_SETCRTC DRM_IOWR(0xA5, drm_mode_crtc_t)
+#define DRM_IOCTL_MODE_GETCRTCGAMMA DRM_IOWR(0xA6, drm_mode_crtc_gamma_t)
+#define DRM_IOCTL_MODE_SETCRTCGAMMA DRM_IOWR(0xA7, drm_mode_crtc_gamma_t)
+#define DRM_IOCTL_MODE_GETOUTPUTDRM_IOWR(0xA8, drm_mode_get_output_t)
+#define DRM_IOCTL_MODE_NEWMODE DRM_IOWR(0xA9, drm_mode_create_mode_t)
+#define DRM_IOCTL_MODE_DESMODE DRM_IO( 0xAA)
+#define DRM_IOCTL_MODE_ADDMODE DRM_IOWR(0xAB, drm_mode_outputmode_t)
+#define DRM_IOCTL_MODE_DELMODE DRM_IOWR(0xAC, drm_mode_outputmode_t)
+
/[EMAIL PROTECTED]/
/**
--
1.4.1
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] Added userspace side library of drm modesettings
Added userspace side library of drm modesettings
hmm apperently I forgot to attach a file
From 510bcb9d2f875aa856c96985057667da0774f696 Mon Sep 17 00:00:00 2001
From: Jakob Bornecrantz [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 20:15:47 +0100
Subject: [PATCH] Added userspace side library of drm modesettings
---
libdrm/Makefile.am |4
libdrm/xf86drmMode.c | 404 ++
libdrm/xf86drmMode.h | 297 +
3 files changed, 703 insertions(+), 2 deletions(-)
diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am
index e7e07e4..24c3203 100644
--- a/libdrm/Makefile.am
+++ b/libdrm/Makefile.am
@@ -23,9 +23,9 @@ libdrm_ladir = $(libdir)
libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined
AM_CFLAGS = -I$(top_srcdir)/shared-core
-libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c
+libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c
xf86drmMode.c
libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = xf86drm.h xf86mm.h
+libdrminclude_HEADERS = xf86drm.h xf86mm.h xf86drmMode.h
EXTRA_DIST = ChangeLog TODO
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
new file mode 100644
index 000..4edb247
--- /dev/null
+++ b/libdrm/xf86drmMode.c
@@ -0,0 +1,404 @@
+/*
+ * \file xf86drmMode.c
+ * Header for DRM modesetting interface.
+ *
+ * \author Jakob Bornecrantz [EMAIL PROTECTED]
+ *
+ * \par Acknowledgements:
+ * Feb 2007, Dave Airlie [EMAIL PROTECTED]
+ */
+
+/*
+ * Copyright (c) year copyright holders
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+/*
+ * TODO the types we are after are defined in diffrent headers on diffrent
+ * platforms find which headers to include to get uint32_t
+ */
+#include stdint.h
+
+#include xf86drmMode.h
+#include xf86drm.h
+#include drm.h
+
+/*
+ * Util functions
+ */
+
+static uint32_t* drmAllocCpy(unsigned int *array, int count)
+{
+ uint32_t *r;
+ int i;
+
+ if (!count || !array)
+ return 0;
+
+ if (!(r = drmMalloc(count*sizeof(*r
+ return 0;
+
+ for (i = 0; i count; i++)
+ r[i] = array[i];
+
+ return r;
+}
+
+/*
+ * A couple of free functions.
+ */
+
+void drmModeFreeModeInfo(drmModeInfoPtr ptr)
+{
+ if (!ptr)
+ return;
+
+ drmFree(ptr-modeFlags);
+ drmFree(ptr);
+}
+
+void drmModeFreeResources(drmModeResPtr ptr)
+{
+ if (!ptr)
+ return;
+
+ drmFree(ptr-crtcs);
+ drmFree(ptr-outputs);
+ drmFree(ptr-modes);
+ drmFree(ptr);
+
+}
+
+void drmModeFreeFrameBufferInfo(drmModeFrameBufferInfoPtr ptr)
+{
+ if (!ptr)
+ return;
+
+ /* we might add more frees later. */
+ drmFree(ptr);
+}
+
+void drmModeFreeCrtcInfo(drmModeCrtcInfoPtr ptr)
+{
+ if (!ptr)
+ return;
+
+ drmFree(ptr-outputs);
+ drmFree(ptr-possibles);
+ drmFree(ptr);
+
+}
+
+void drmModeFreeOutputInfo(drmModeOutputInfoPtr ptr)
+{
+ if (!ptr)
+ return;
+
+ drmFree(ptr-crtcs);
+ drmFree(ptr-clones);
+ drmFree(ptr-modes);
+ drmFree(ptr);
+
+}
+
+/*
+ * ModeSetting functions.
+ */
+
+drmModeResPtr drmModeGetResources(int fd)
+{
+ drm_mode_card_res_t res;
+ int i;
+ drmModeResPtr r = 0;
+
+ res.count_crtcs = 0;
+ res.crtcs = 0;
+ res.count_outputs = 0;
+ res.outputs = 0;
+ res.count_modes = 0;
+ res.modes = 0;
+
+ if (ioctl(fd, DRM_IOCTL_MODE_GETRESOURCES, res))
+ return 0;
+
+ if (res.count_crtcs)
+ res.crtcs = drmMalloc(res.count_crtcs*sizeof(*res.crtcs));
+
+ if (res.count_outputs)
+ res.outputs = drmMalloc(res.count_outputs*sizeof(*res.outputs));
+
+ if (res.count_modes)
+ res.modes = drmMalloc(res.count_modes*sizeof(*res.modes
[PATCH] Add support for CN700 chipset in miniglx
After some work and modification i got the CN700 chipset working with miniglx, tho some hacking of drm is required due to ioctl ADD_DRAW being DRM_MASTER. Also I have no idea what the define should be named, so I just took what seemed to used the most. diff --git a/src/mesa/drivers/dri/unichrome/server/via_dri.c b/src/mesa/drivers/dri/unichrome/server/via_dri.c index 2fe61e4..6944bd6 100644 --- a/src/mesa/drivers/dri/unichrome/server/via_dri.c +++ b/src/mesa/drivers/dri/unichrome/server/via_dri.c @@ -1179,6 +1179,7 @@ static int viaInitFBDev(DRIDriverContext pVia-Chipset = VIA_KM400; break; case PCI_CHIP_VT3204: +case PCI_CHIP_VT3344: pVia-Chipset = VIA_K8M800; break; case PCI_CHIP_VT3259: diff --git a/src/mesa/drivers/dri/unichrome/server/via_regs.h b/src/mesa/drivers/dri/unichrome/server/via_regs.h index 5c5eecb..87e1e9d 100644 --- a/src/mesa/drivers/dri/unichrome/server/via_regs.h +++ b/src/mesa/drivers/dri/unichrome/server/via_regs.h @@ -44,6 +44,7 @@ #define PCI_CHIP_VT3205 0x3205 #define PCI_CHIP_VT7205 0x7205 #define PCI_CHIP_VT3204 0x3108 #define PCI_CHIP_VT3259 0x3118 +#define PCI_CHIP_VT3344 0x3344 #define BIOS_BSIZE 1024 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
