> > > > 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