--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
--- Michel Dnzer <[EMAIL PROTECTED]> wrote:
On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
I have something to add to this. Recently I tested gatos drivers going from dri to gatos was painless. However when I went back my computer locked up.
That's because they have made incompatible changes to the DRM but haven't changed its major version number to reflect that.
I think I understand what your saying. I did a full build (make World && make install), overwriting all of DRI, hopefully. Then I did the same to get back. I also updated and rmmod/modprobe the DRM, bothways. I think what is going on here is that there is some state
that
needs to be cleared on init, and deinit also(in gatos and fiergl). Thats why I think there
should
be a merge for the difference in state changes made on init/deinit. I don't think this should
change the API, and would seem to be more of a bug fix.
They use a different memory layout on the card, on which all components (X server, DRM and clients) have to agree, so it's very much an API issue.
We want to move to their memory layout for several reasons, but there has to be a transition which preserves backwards compatibility. That provided, the problems on switching between DRMs may be gone as a bonus with some luck, or it will just be a detail to work out hopefully.
I think I could tackle this. What's needed is a dual memory layout settup for the next minor version. This would payve the way to release the next major version, if minor >= x will be forward compatible to the new major. I would say to have dual memory layout support for the DRM would be a gross wast of kernel resorces. So it will be up to X server and clients to carry the burdon of having the new configuration. I know there is allready a dispatch table for clients, could we have 2 radeon drivers? For the ONE(currently active) Xserver it seams as thought just a select for dispatching would be a temporary solution. How long would we need to maintain the proposed hack? Would all the developers be willing to switch to the new major version once it's working front and back? Is gatos's DRM up to the challenge or dose it need work so it can replace the current?
By dual memory layout I'm saying that the client/X would have 2 drivers one for the old kernel and one for the new.
I doubt you'd need two whole new drivers -- just a couple of things that are constants now would have to be set on the fly. Most addresses get set up by the X server and everyone follows from there.
Maybe the easiest thing would be to hack up a non-backwards-compatible version of X, kernel and client drivers, and post the diff to the list. Then we can see how to trim that down & make it backwards compatible.
Keith
------------------------------------------------------- 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
