Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a better idea with some card
Michel Dnzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a better idea with some card
Keith Whitwell wrote:
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback
(both on the idea and the implementation) before I build anything
upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a
Stephane Marchesin wrote:
Keith Whitwell wrote:
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback
(both on the idea and the implementation) before I build anything
upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
--- Stephane Marchesin [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
Stephane Marchesin wrote:
Michel Dnzer wrote:
+DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user
*)data,
+ sizeof(memfree) );
+
+dev_priv-surfaces= (~(1memfree.surface));
It should definitely ensure that only the owner can free a surface
though. It would
Hi,
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
The reason to add a new ioctl is the following : since there are only 8
surfaces someone has to arbitrate between allocations by the ddx (color
buffers) and from the dri (depth buffers).
On Wed, 2004-12-08 at 02:54 +0100, Stephane Marchesin wrote:
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
[...]
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback (both on the idea and the implementation)
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a better idea with some card specific hooks..
10 matches
Mail list logo