Jon Smirl <[EMAIL PROTECTED]> wrote:
I think this means you are going to have to rewrite the
drivers/dri/chip and the drivers/dri/chip/server directories.
Yes, it would seem that way.
This is worse than what happed with the original embedded Mesa. In
the original embedded Mesa the Xfree driver code and the code in
embedded Mesa /server got too far apart and we lost the ability to
bring changes from Xfree back into embedded Mesa. I am trying to
rework the server directories starting from the Xfree base and
adding minimal IFDEF's. This will allow me to bring in changes from
Xfree as they happen, and they happen a lot -- way too often to
apply the diffs manually. Hopefully I can get the chip and
chip/server directories to a point where I can check my IFDEF's
back into the XFree tree then embedded Mesa and Xfree will be on
the same driver code. (hmm, at that point I might be able to build
embedded Mesa out of the DRI tree).
Well I have been thinking about this somewhat, and it seems to me that it should be perfectly possible to build an abstraction between the DRM/XFree86 interfaces used by the DRI modules today, such that the same code could be compiled to use the SNAP architecture or the DRI/XFree86 architecture. This could be in the form of macros to abstract this, or function layers for areas where performance is not critical. It would be something done at the compile time level, not runtime level.
You can definitely make this work but now you have to maintain all
of the code in your copy of drivers/dri/chip. That is a lot of
complex code to maintain. Once you start significantly editing it
you will lose the ability to update from the Xfree code base. After
the tex-mem merge the drivers/dri/chip directories diff'ed on 60%
of the code. I ended up just deleting the ones in embedded Mesa,
copied them over from Xfree again, and reapplied my changes.
Implementation of pbuffers is likely to cause this to happen again.
Although I am quite willing to modify the DRI chipset driver code to work with SNAP, I would much prefer to avoid this in the future and find some common ground so this code can be shared. Forking the code completely won't make a lot of sense, but if this is to work the folks on the DRI side of the fence will need to be willing to accept changes to the way DRM is hooked into the drivers to make it more abstract.
Do you think there would be any interested from the DRI side in allowing this to happen?
You'd have to explain exactly what you mean and how it might benefit the DRI project, and make those proposals on the dri-devel list.
One issue that is dear to our collective hearts is backwards compatibility. As a minimum requirement, new versions of the kernel modules must support old versions of the driver. For bonus points, we like to have new clientside drivers work with old kernel modules (eg by disabling some features). This last one is optional but desirable.
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
