[PATCH 09/11] drm: replace drawable ioctl by noops

Daniel Vetter daniel at ffwll.ch
Thu Apr 29 05:02:33 PDT 2010


On Thu, Apr 29, 2010 at 11:32:36AM +0200, Michel Dänzer wrote:
> On Don, 2010-04-29 at 11:14 +0200, Daniel Vetter wrote: 
> > The information supplied by userspace through these ioctls is only
> > accessible by dev->drw_idr. But there's no in-tree user of that.
> > Information might also leak via the RM_DRAW ioctl (in the form of
> > a negative return code in case the drawable doesn't exist). But the
> > only user of these ioctls, mesas' miniglx, does not use the RM_DRAW
> > ioctl.
> 
> FYI, the X server DRI1 code also uses these ioctls, via the libdrm
> functions drmCreate/DestroyDrawable and drmUpdateDrawableInfo().

Thanks, I've overlooked the DRI stuff in the xserver. There,
drmDestroyDrawable is used (but the return code is ignored), so should be
fine. The only place the return value is checked when creating a drawable
for the first time (to free any allocations already made). Should be safe,
too.

> > Therefore it's safe to replace these three ioctls with noops and rip
> > out the implementation.
> 
> That should still true though, as none of the DRM drivers use the
> drawable cliprect information anymore. Might still be worth
> double-checking that this doesn't break DRI without KMS on your RV570.

I've tried to test DRI1, but that seems to be in a hilariously broken
state on my box: Windows are smeared all over the screen (tiling
parameters mismatch?) under certain circumstances. But glxinfo shows the
correct render string, AIGLX seems to load correctly (according to
Xorg.log) and kde's opengl cover switch looks all right. Also, after some
time it hangs with the dmesg complaining that someone is monopolizing the
heavyweight lock (in drm_lock_take). Results without these patches are
similar.

I haven't used ums radeon since months, so I don't think you can count
this as useful testing ;)

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


More information about the dri-devel mailing list