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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2010
--- Additional Comments From [EMAIL PROTECTED] 2004-12-08 03:49 ---
The 2047
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=1678
--- Additional Comments From [EMAIL PROTECTED] 2004-12-08 04:05 ---
I am also
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);
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=1501
[EMAIL PROTECTED] changed:
What|Removed |Added
The file radeon_dri.c sets several defaults in the radeon's private
data.
ctx-driverPrivate = (void *)info;
info-gartFastWrite = RADEON_DEFAULT_AGP_FAST_WRITE;
info-gartSize = RADEON_DEFAULT_AGP_SIZE;
info-gartTexSize= RADEON_DEFAULT_AGP_TEX_SIZE;
info-bufSize =
Daniel Sperka wrote:
The file radeon_dri.c sets several defaults in the radeon's private
data.
ctx-driverPrivate = (void *)info;
info-gartFastWrite = RADEON_DEFAULT_AGP_FAST_WRITE;
info-gartSize = RADEON_DEFAULT_AGP_SIZE;
info-gartTexSize= RADEON_DEFAULT_AGP_TEX_SIZE;
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
There seems to be no way to configure my r200 to do page flipping! I've hacked
the last line above to force page_flip_enable=1, and the page flipping seems
to work with my tests, but this begs the question -
Is there some other reason that page flipping is disabled (and cannot be
re-enabled
Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger:
Dieter Nützel wrote:
True for DoomIII, but who can switch the lights ON, finally...?
;-)
That is some weird texcoord problem. (I actually have a one-line
workaround for that, which breaks submitting texgen and non-texgen
Just checked out Mesa from CVS and attempted a build. It fails in
src/mesa/drivers/dri/r200 -- portion of build log below.
It appears that there are two files named 'radeon.h' in the -I dirs for
the build of r200_dri.c. One is the one we need, but the other is in the
drm folders. The drm
command line, hence it is picked up. Its not the right file, though, so the
build fails (but there's no indication of a missing .h file).
I had a CVS checkout from a couple weeks ago and there was a change in the
Makefile in src/mesa/drivers/dri/r200. I tried to replace the 'suspect'
Hardware: Mobility M7 7500 reference board from ATI on a PIII i815.
Software: Mesa solo about 4mths old running on a 2.6.9 with voluntary
preempt
I'm running a single full screen 3D app and every so often my graphics
cards locks up either hard or the CP craps out and locks out, now I'm
thinking
17 matches
Mail list logo
