Since the changes touch the general DRM code I would say hold off on making the changes. I think it might be a good idea to push the 4.3.0 out the door and let the vendors pick up that for release since quite a few improvements already exist in the code base. At that point we can focus on a release that has some of the improvements that have been working their way into the DRI CVS tree, but haven't been accepted in the main XFree86 tree since they were too drastic for the 4.3.0 release.
Just my thoughts ... On Fri, 14 Feb 2003, David Dawes wrote: > Egbert and I have been looking into the issues that are preventing a second > X server to be started for i810/830M platforms when DRI is enabled. Several > issues were found: > > 1. The i810 support doesn't unbind/release the agpgart module when VT > switching away, and this prevents a second X server from acquiring > it. Since the i810 driver requires agpgart access even for 2D > operation, this is prevents a second X server from running. A fix > for this is to add the unbind/release calls at LeaveVT, and > acquire/rebind at EnterVT. The attached patch does this. It also > makes a small change to the unbind code in the DRM kernel modules > to handle this. > > 2. The 830M support does unbind/release the agpgart module, but code > in DRM(release) called when closing a /dev/dri/* device blocks > until it can obtain the lock. Since the first server holds the > lock while switched away, the second one can never get it, so it > ends up blocking in close(). The second server opens/closes the > devices to find out whether DRI can be enabled. DRI can't be > enabled on the second server (which isn't a problem), but this > blocking behaviour is preventing it from starting up at all. I've > found that this can be solved by keeping track of whether the opener > has ever tried to acquire the lock, and not try to acquire it at > close/release when it had never previously been acquired. The patch > below implements this. > > 3. The drm module AGP support code keeps track of a "handle" for > allocated AGP regions. It uses the memory address returned from > the allocation for this purpose. This would normally be unique, > but for the i810 driver case where "DCACHE" memory is "allocated". > In the DCACHE case, the allocated memory is freed immediately (since > DCACHE doesn't come from the system memory pool), and the next > allocation often ends up getting the same memory address, and thus > the same "handle". This showed up as a problem when the unbind/rebind > code was added. > > The user-level agpgart interfaces use a "key" value to uniquely > identify allocated AGP regions. I don't know why the DRM module > doesn't do the same, since the key is guaranteed to be unique. > The patch below changes the handle to be the "key" value. > > I'm wary of making changes like this so close to the 4.3 release, but > I would like to see this problem fixed in 4.3. Does anyone see any > potential problems with the attached patch? > > David > -- //========================================================\\ || D. Hageman <[EMAIL PROTECTED]> || \\========================================================// ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
