> >
> > I would suggest adding more ioctls:
> >
> > 1. Lock the drm driver against future connections from 3d driver(s).
> >
> > 2. Return the number of current connections.
> >
> > 3. Move the aperture - should only succeed when nothing else is connected.
> >
> > Also, when aperture is moved DRM driver can simply refuse connection to
> > older 3d drivers.
>
> Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unless capture is enabled. Also, I suspect that when
one calls Video BIOS with framebuffer position anywhere other than 0 the
BIOS then toggles the hard reset line.
> Our idea would be an ioctl to set the aperture position on startup and
> (possibly another one) for 3D clients to let the DRM know what they
> think the aperture position is. Then the DRM could fix up client
> commands as necessary. This would work with any 3D driver (except
> probably old incompatible ones from GATOS :).
Well, fixing up commands might not be so trivial. With 4.3.0 drivers it
turned out it was a lot easier to fix the 3d client. Of course, I am not
an expert..
best
Vladimir Dergachev
>
>
> --
> Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
> Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
