Kevin: That puts structure onto the technical side of things, but not any structure onto the social problem.Ījax: The problem with merging things together is that it doesn't address the modularization problem. It's a social problem, but this technical change would help. Jesse: The only thing that makes sense to merge back together is the server and drivers. It would be great for tagging releases, but not so nice for "build master".Ījax: It's great to be able to build the server without having to build xedit. Instead, it has to have exact sha1 sums for each point. We don't get a master supermodule that points to all the "master" branches of the submodules. So if we did put everything together, we'd need lots of separate trees, (input, etc.).Ījax: Do git submodules help us address the issue?Įric: Zack's done more work with the submodule thing, but I don't think it gives us what we want. But if we had the big blob, and someone tried to bisect, then it would all just be "Oh my God, my keyboard doesn't work". People can bisect an independent driver and find Jesse's driver bug. If we had done pciaccess correctly, then it wouldn't have been any work-just a sed script.ĭaniel: Bisectability is really nice. John: Is the big problem lack of resources for driver development?Ījax: I don't think it's lack of resources. Wouldn't it be better if driver hackers had a vested interest in getting the "big blob of server and drivers" into a releasable state together. That never came to consensus, but wouldn't it help? Right now, nobody cares about the "server" and the distribution maintainers end up taking on all the pain. Jesse Barnes: We had a big flamewar about putting the drivers back "in tree" in one git module or whatever. But we could have done the whole pciaccess change in-pace with a compatibility layer so that nothing would have ever broken. The problem is that we don't have anyone signing up for that janitorial work-or a commitment to "don't break the drivers". Fortunately, someone stepped in to save things after the fact. Finaly, we sat down and forced it in, but found that only the "top 3" drivers had been ported to it, and everything else broke. Then, several months later someone, (lately, Ajax), looks at the list and sees which ones are actually coming together, (about 50%), and decides those are the ones that actually go in.Įxample of the picaccess change that was on the "desired" list for several releases, but never went in. Releases are cheap guys! I don't have a solution for that except shaming people-maybe this is how I get a start.Įvery 6 months or so we have a session where we say "what do we want in our next release?" and we write them on the whiteboard. We see lots of churn in the drivers, but not releases. Things change and break, but nobody takes responsibility for things.Įven the drivers that are "well maintained" have problems. There are huge swaths of the code that nobody cares about. One fixed.Ījax: I don't feel like I'm scaling that well. Nobody else is looking at this stuff? Daniels: I just closed a blocker. And Glucose isn't happening at all.Ījax: I'm feeling kind of alone here. Some of the breakage is avoidable with XAANoOffscreenPixmaps.Ĭan we drop XAA altogether? Not for this release. But it'sīug 13795: With Mozilla and cairo now using Render, we're using lots of parts of the server/drivers that have never really been used before. There were lots of good talks at XDS in the fall about new stuff that was coming, (Gallium, etc.). We do have a list of (70) bugs blocking the release (10101):īut nobody other than Adam has ever looked at that. Part of it should be in any future 3.1 release after having been tested outside of 3.1.6.Adam Jackson on X release status and process. We will probably merge the two remaining ones to reduce the amount of code to be maintained and the scope for bugs. Yes, but that was done independently to simplify maintanance.I used a slightly unclean hack, but which works well (we update when the mouse cursor is changed, and VBoxClient changes it briefly to a "waiting" cursor when new modes are available), while VMWare uses a cleaner but more heavy-weight approach. What the older servers do lack is a way to "jig" the server to update the mode list. In fact the amount of code required is smaller than when using the new extensions. It turned out that the older version of the RandR extension introduced in XFree86 was also designed to support adding new modes at runtime (this was intended for future extensions, as in fact happened with RandR 1.2, but is enough to provide usable support for the older distributions). Most of the work involved was in studying the rather intractable X Server source code and the VMWare driver to work out how this could be done.In fact, I took a closer look at the VMWare X.Org driver to see what they were doing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |