 in four years since we released the stable modular version of the XORG server. And it's time we start reviewing, or maybe it's time to review a bit what has happened and what hasn't happened very shortly. There is this feeling, it's lingering, it's been felt for quite a while that there is still something missing in this whole thing. Something quite fundamental, and well, lots of things have been moving in XORG that are moving way too fast from time to time. There's things like live PCI access which were years too early non-tested that just went straight away. This is a lot of movement, maybe some of it was partly good but some of it was also partly very bad. So we're feeling that we're not really delivering what we should be delivering yet. We're quite a way away. And in recent years, there have been some changes in how the XORG server commits there or being handled. At the moment there is some way of reviewing patches at least. This has never happened before. So there are some ways we're trying to improve apparently and we are mainly looking at other projects to see how we should manage the XORG project. And maybe this is not really the best idea. We want to take over a few things, but we do want to have a more tuned process for something as the XORG. It's really a stand-nice-stand-blown project. And this is mostly a talk about graphics driver stack and that means all the business first all over your system. So yeah, we will dive in now. What was my year? And four years later we can actually review what was good and what was bad. So what was good about modular? And if many people think that modular is the first time that we were able to build except 86 as I ended up being named. First time we were able to build X-drivers outside of the tree. This was not true. X386, 4.0, the whole build up to 3.9, and 4.0 that took a few years in the late 90s. Already gave us the ability to build drivers outside of the tree and quite easily so. There was an SDK already available. The X386 developers were very forward-looking in this respect even though they tried to design very well for the hardware from that time. But there were things that were coming up like multi-head that only happened slightly later. And now there's a completely, the hardware is so different from ten years ago at the moment. This they could not foresee at the time. And this was an issue in the early 2000s where people, that project was not, 2003 was maybe not moving fast enough, but it wasn't all that bad as it was made up here at the time. An issue with the, when I started developing drivers in 2003, the issue then was that almost no distributions came with this fantastic SDK installed already. The only one that I remember from the time was Arc Linux by Baylor Rosencrancer at the time. Nobody probably even remembers this. It's been seven years ago. That was the only distribution that actually installed the SDK, even though it was perfectly available. So it was actually made out for, because people were not really aware of this, it was made a bit harder to actually install an X graphics library. It was actually a very easy process if you have the SDK. So with monitor, the major change from a driver point of view is that this SDK suddenly was installed everywhere. It was a package that was available everywhere. This was fantastic for driver development. Auto tools is another big thing. As a driver developer, you're doing your thing, you don't want to care about a build system. You want something that everybody knows. There are people here. You can talk ages about how bad LipTool, how bad Autocon, how bad everything is. I don't want to care. I want to develop a graphics driver. I don't want to spend too much time with the build system for it. Autocon, AutoTools is something that everybody knows. It's, as its issues, fine, but there is no real alternative. Not unless you want to change every two years from build system. That's also not fun. Another big change is we had the whole tree split up. And here it says clearer structure, well, the next slide will say something else. It's a clearer structure. Many parts are very easily accessible and very easy to build separately now. This is a good change. So there were many bad things as well that came from this, and not all of them had to do with monitor. XP86 was very, very stable, insanely stable. They even tried to maintain ABI's to invite those companies at the time, this was the thinking, invite those companies that want to do close source drivers to please, please do a close source driver. You have to remember this is more than ten years ago. This is a completely different situation. Nobody was really offering X any support much from the hardware side. Not that nice as today. So they even tried to keep the ABI's stable. These days it's actually a problem to keep the ABI's stable. And there's nothing to do with monitor. It's a developer mindset. So we went from one opposite to the absolute other opposite. This is not helping us at all. One big promise in 2004 when people were doing the work on turning the XP863 into a monitor, early XORC monolithic 3, there was also a lot of work, of course, turning all of this in auto tools. And splitting up things where it wasn't split up yet. This was a lot of work. And Kudos to Daniel and whoever else worked on it then because it was a lot of work, nicely done. But there were lots of changes that are not complete yet like the proto changes that happened by Peter Hutter a year ago. There was a lot of pain we had to go through that if we had seen this 45 years ago it would have saved us a lot of trouble now. This we couldn't foresee then either. We were just too busy or too caught up in other things. But one of the big promises then is that vendors were always patching their trees to get new features in. Today the features are not a problem. We have usually enough features. As a vendor you have enough features in your XORC. It's not stable enough. As a vendor, distribution vendor, you're really not shipping the bear XORC. This is not something that's happening. They're still patching their trees, just like with the stability. Highly stable, highly unstable. We went from patching because there were no features. It wasn't doing what people wanted. It's still not doing what the distribution vendors want. But their features are not that production ready. Again, this is getting better. The recent releases with the point releases, that's a good system. Reviews, good system, go on. So I think part of the problem with the huge monolithic releases is if you put out an RC, people would go, crap, release candidate, I really need to make sure this is meant because I'm going to have to ship the result. We put out the release candidate now, no one cares. Because they assume we'll fix it up in a point release, which hopefully we do. So as long as you never ship a point zero in a stable product, then you should be fine. This is where I used to work, not anymore at the moment. We never ship them. We always ship the latest version. We had trouble enough with the manpower we had that does place at the time. We had trouble not keeping up as it was and developing a driver next to it. This was just an insane task for the people here. Now, nobody builds X anymore. This is a nice little survey I want to have here. Who here has built X since it went model? Put up your hands. Oh, that's actually pretty bad. It's not too bad. What, 25 percent? Let's take it high, 25 percent. Who here has built an X model in the last year? Whoa, more than I expected. Actually, I should have done this in the first one. Can't do this on the second one. I'm not doing the X from scratch and just getting Julie Ankerstahl's excellent jid.divian.org trees and having DeepPake AGE build package on them and then using that. This is a beautiful solution for somebody like me who just wants to drive right drivers. And I cannot claim that I've built modular for the last three years. I haven't built modular at all. I don't know. So the question then becomes, yeah, you're a bad crowd actually. Why are you so many of you building this? Yeah, so who still tests anything today? Yeah, there are a few. Is there anyone doing this from scratch with no operating systems? Okay, who is using the build script from the modular? Who is using that build script? Actually, who tried to use it? Who's using that build script? I'll answer your question in a bit. Who's using that build script in the tree in modular? Who's using that build script in the last year? Nobody. You, Daniel? Yeah, okay. Hey, Egbert also wrote his own. There are quite a few people who wrote their own. That's how it is. The problem with the question is that there are two script there. It's also a GHPL. Oh, GHPL doesn't work, so don't use it. If you're a Devian user, check out Julián Sandelis. He's too busy with his PhD. Check out jit.devian.org. His work there is beautiful. I found this, and I was the happiest. Six months ago, I finally managed to find the time to port my Unicron driver to 1.7. I was so happy when I saw it. So, who only tests anything today? And another big one. It's only X that became modular. Mesa? Lipterum or the DRM Mesa tree at the time? No way. So, the graphics driver problem. Graphics hardware is the most complex thing out there. You have a 200 watt card, two teraflops, six displays, whatever. There's nothing like it. 200 watt, CPU is 125 or something. There's nothing like it. It is really unbelievably complex. It's unbelievably complex. It's very diverse. The three graphics makers that are still alive, they are completely different. There is nothing the same that you can find. There's two lines in there, but that's it. There's a feature that's going on. There's a speed war going on between the vendors, except for Intel, they just played their own game anyway with two others. They're constantly battling on features and on speed. And two others also, all of them actually, six months to a year and you have new hardware out. You have new support that you have to bring in. Now, as I explained yesterday with my flash ROM talk, the software that is close to the hardware mimics the hardware. It's always going to be very much the same in a lot of its properties. It's going to be very similar. It's very complex. It's going to be constantly moving. New devices all the time. It's always going to be buggy and it's never going to be stable. We know that this is true for all software. Always buggy, never stable. But for graphics drivers, it's a few orders of magnitude more. If you look at the different pieces that are there for graphics drivers, let's take a quick example here. Something almost the same as the Radeon. You have microcode. You have the DRM driver. You have libDRM. If you have a graphics or driver, you have the DRI driver. You have a gallium driver. If it existed already, you could even have media acceleration that are seven different pieces scattered all over your system. That's the complexity of the driver. It's very unstable. It stabilizes the rest of your system. Graphics drivers is a difficult problem. I wanted to do a survey a week ago, but this is not practical at all. Survey we had was already difficult enough. I already talked to Michael here from Pronex who is taping this. We will probably do this survey with a lot of funny questions. I like to be slightly sarcastic. There are a lot of funny questions and we will work out a nice survey and we will see what people respond. The answer I will see from this survey is that people will say that most of the bugs they experience in the graphics range, 80 to 90 percent can be blamed on the graphics driver. The extra structure is very, very uncommon. It happens, of course, all the time. But compared to the graphics drivers bugs, it's very, very uncommon. And everybody who is using a graphics driver wants to be able to just grab the latest graphics driver pieces and build them, install them, run them. Everybody wants this very, very easily and today you only have this for the X driver. Only the X driver because the XP86 people did so much work and we now have the SDK installed everywhere. So from a graphics point of view, we can identify four different stakeholders in this whole thing. We have the hardware vendors and the hardware vendors, they want to sell you new hardware in their next release. So if you are using their hardware now, they want you to be happy with their hardware. They want you to be happy with their support. Also, they want you to be able to use new hardware with your existing software. If you want to merge to something else, you move to something else, you want to get new hardware, you want to go faster. You want to remain in your familiar environment, especially in the enterprise. You want to keep most of your software that you trust. You want to keep this and you may usually want to run it faster. So you want to upgrade the hardware. So for hardware vendors, they also want you to be able to replace your drivers all the time and keep your current software. They want you to have a distributor for a bit, too short, but it will. And they're mostly into packaging and support. And if they're a commercial distributor, Linux distributor or whatever, they are being paid for packaging and offering you support. They want to be able to take in new hardware support as well without having to change their long QA cycles, operating system, anything in there. They want to change as little as possible to install a new graph drive for the whole stack. They don't want to bother with anything else because that is a big, big stability issue that they will pay dearly for. If something goes wrong, they will pay dearly and it's going to cost them a lot of money. Users, there are many sorts of users you can identify with. There's a normal your home user, there's the enterprise user and there is the advanced user like the average Quran expisitor. Everybody in here, you're the advanced users. There is no difference from a graphics driver point of view between the three. What benefits the enterprise, and it's always a nasty word, enterprise is always scary, what benefits the enterprise benefits everybody else as well. And then the last one, the developers. What do developers want? As I said before, auto tools, I don't want to care about anything else with my driver. This is the first thing. If there is a bug in there, I'll go and fix it. But I don't want to do this. I want to just work my driver most of the time. If I have to go and fix it, not fun. I want to do the driver. What you also want to do is ship my driver, the latest version, ship it to everybody and get feedback. Get patches in, get it updated easily and quickly. So what everybody wants here is being able, oh, first, first, first, first. What does everybody want? Especially since... what do we think? Adrenaline. So, Linux is not ready for the desktop. At this point, we can't say that we are ready for the desktop at all. We're still several years away from that. And most, many people in the year are thinking, well, many of the graphics driver developers, they're all thinking, oh, gaming, gaming, gaming, gaming. We're years and years and years away from gaming if we're not even on the desktop yet. So performance is not that important. Features, they're nice. They're marketing performance and features. They're for all the stakeholders. They're nice. They're marketing advancements for the hardware vendors and for the distributors. But what everybody really wants is stability and the basic functionality. This is what everybody needs. If you don't provide this, you get very unhappy users. And sadly, as Michael said, it's like this. There are a lot of people in there. They will give you endless crap. But they don't realize that basic functionality is already there and this is already a lot. The basic functionality works great, but we don't usually only hear the very noisy people who have a small bug in their 3D driver, while there are so many other things that should be worked on as well. Now all these three above, they all want the same thing basically. Except for the developers. At this point, there are only a few developers that are already above features and above performance. And this is not that great. So, if you want to switch. It's a very hard slide to render for open office on this dual processing machine. Here is a slightly simplified graphics driver stack. Here's the XORG server and the XYZ. I wanted to do XDRV.so but I thought against this. It's being built separately unlike the other parts here and this is some very simplified dependencies you have here. Yeah, I've measured the array. I'm just showing you the array driver here. Same thing for gallium. At the top it's also mentioned media support, but that would just clutter the place even more. LiveDRM and driver-specific LiveDRM same build system. This was recently, well, recently it was moved. This used to be one part a year and a half or so ago. This part was moved in the kernel and three months or so ago Christian Augsburg finally adjusted the Mesa DRM to actually reflect this which didn't make the BSD people very happy. If you look at the different APIs here, this driver there are about 50 of them. So this arrow here is actually a very, very stable API there. 50 drivers, if you want to change something you have to depending on the features you have to change a lot of drivers so inherently this is very, very stable. Same year there are about 15 DRM drivers, this is quite stable. Gallium there are about 10 or so. This is, yeah, you can see that interface is changing all the time. That interface because it's handled badly. Later, later, later, that all comes. Here people are trying to this is also relatively stable and you have to know that this line here the XORG server depends on LIC DRM 2.3.0 which is from August 2006. That's what the XORG server depends on here. The nice thing about here is because of this thing Mesa DRM is depending on almost the very latest version of LIC DRM. And this is a very unstable mess. The other things this is also relatively stable depending on the features of KMS and memory management is still moving a lot but that will also become better. If you look at this more closely and look at the different graphics parts the things I pointed out already they are very stable but there are a few parts which are very, very unstable because they are very little depending on this. These, they can be as unstable as the driver developers want. This part is well this is also very, very unstable. This is the idea that was brought out a few weeks ago or a few months ago at XDS. Move the drivers back into the XORG. So the one good thing about this whole stack they want to do not a very, very good idea. Why? Because it has no real advantage that a built system that already offers. It doesn't offer you anything more as long as you don't test hardware as long as you don't test the features you're not gaining anything. What it will give us is give people in this block the right, like with Mesa Theorem give them the right to just change the API even more. This is the last thing we need at the moment. We need to clean it up but we need to clean it up in such a way. We know this can only happen so that we're not hurting everybody too much. LipPCI access don't even try to do that again because next time I will also be more vicious. I once got blamed by Edward a few years ago when LipPCI access happens that it was my fault. I had nothing to do with LipPCI access itself but I cleaned up the ATI driver this big ATI driver who probed everything and then ran either Mac64, Mac32 or Rage and Radeon. If I hadn't cleaned that up then this move to PCI access based program would have been a lot harder. So yeah I'm still fizzling. Anyway what will happen here is that the current XF86 API will get outlawed and I would not find it that unreasonable when somebody says hey, it's been 6 years why not change all the symbols in there and change the XF86 in front and change it to XOR. We can do this now. Great idea. So it's a bogus idea we don't want this. Oh, now I get to mine. Oh yeah, my cool animation. So what we do is we want to tie these parts loose from the rest of the tree. We want to tie these loose we want to tie this loose we want to tie that loose until here and look what will happen then. Will it work? It works. This lines thing that they disappeared and came back if I have time for one second at the end I'll show you the slide why. If it's possible we want to get there. What do you see here? This is completely driver internal it just depended upon by these two by Gallium and maybe the media exploration it's completely driver internal and this is the thing that is really realizing the whole system at the moment. Is that what it is? Absolutely not. Every two weeks we get on your version. Every time it's about we make improvements we do point releases and we improve API to improve performance and do point releases. While new software depends on new stuff old software continues running. It continues running because it only depends on this part of the DRM. 2D driver by 3D driver depends on my trip set with DRM. I see this block here being bumped every few weeks because there was only driver changes. This block gets bumped every two and DRM depends fully on the latest. No, for Intel it's two versions back or for Radeon it's the latest. Two versions back is a month. A month for the whole Mesa 3 and this is insane. So this is where we want to go and suddenly inside this driver stack I've done this already on Unicron. There is so much you can clean up. There is these headers here. This header here is installed with libc at the moment. The graphics driver header is installed with libc The development package on their Debian for libDRM is installing actually two headers for R, 3D and 4D out to register information. And the libDRM this is insane stuff. It should not be happening at that time. So yeah, if you move to this then it's up to the driver development to decide how stable all this is in this part. This will be inherently stable anyway. So next slide. How much time do I have left? Over half an hour. Oh yeah, then we can all go home early. Or we can have you pick our unit. So what in the rest of your system depends on anything else? One more. This is where all the dependencies of the rest of your system landed with Lipix 11 and Mesa GL GL sorry. They're all over there. There is nothing that directly depends on these parts here. It's only the graphics driver itself. That's fully that's being wrapped away by these studies too. At the moment because with all the fancy ideas of moving graphics drivers disposing them even further there's no idea where this is going to end. But this... What's the difference to what we have today? In there? Did you not follow the slides or... I actually don't know what to talk about. I'm afraid it's customary because that looks exactly like everything in there. It's horrible over here. You could do that if it's possible. But do you want to try that? You really didn't... Well look up. The slides will be available anyway for you guys if you're not understanding it. So when you... The next one is... The next thing that you try these those, yeah? No. And if the package manager even wants to split this up you want to have one... If it's possible at all and they are moving too much it's up to the driver developer. It's up to the people who are developing these drivers. If they move it out they're free to do in this area whatever they want. If users are not happy with it then they blame this. They don't blame anything else. They blame the driver developers here. And if packages want they can have packages all separately and have their dependencies here all separate. This should all be possible. They may be a very... A very tight dependency here which is okay. This is very... There may be a very tight dependency that doesn't have to be... It's up to the driver developer. So yeah, here nothing depends on this directly. It's all the dependencies are on this side of the tree. If you make these more movable if you care about compatibility in these APIs a bit, you don't have to care much a bit then the whole world becomes a lot, a lot nicer. And it is okay when you need new features when you build this against an older X server an older Mesa, an older Ethereum if you need new features when you say, hey, this new feature sorry, we can't offer you that but we can offer you the basic stuff we can offer you the basic functionality and this is what people want. If you say it's half the speed than it used to be well, people can also switch Shadow with B if it's really not fast enough in the word to do in hardware but this is all okay. People want to have the basic functionality first and the rest can come when the new stuff is making it into the distributions. This can come then. At the moment, if you want to keep it old Rural software we can just update the driver to fix the bugs you have because you will have bugs always. So what am I doing in Unicron? Because I'm not just talking to talk here but to do stuff. I have taken my Unicron and I've done Rageon HD in between the last few years and not that much happened to Unicron. Mesa, the right part also didn't move that much and the channel gear and well it moved a bit but there was mostly driven by the Taiwanese guys and it's not really working out. So there are some versions here that say XORG 1.0 version or the 7.0 XORG released 9.107 we got lazy here but we have to see 2010 is about here 2006 is about here but to make it even more visible let's blend in some distributions this is where Debian Old Stable lives that's Debian X that's Debian Stable Lenny there is Debian Squeeze with Juliank Restore packages from two months ago which is what I was using at the time and it actually opens Suze 11.1 still running on this laptop I usually use as a workstation what I'm doing with my Unicron and I've been doing this for years because I am the thermal of X86 vs XORG I took the Unicron driver outside of it at all and just kept on developing drivers I used to be compatible until 6 months ago until all the way to 4.3 which is a 2003 release of XORG this is how far back my Unicron driver used to build a valid mode with acceleration I threw this out out of IIME builds there is nothing, Ubuntu LTS the oldest Ubuntu LTS is sitting at slightly above 1.0 so this I still can test and still install so everything else is throughout this has been a really really easy way but of course I missed out a lot of patients here doing rating IEC what I'm doing for the method DRI this is how far compatible I am and this tree this git tree is up there it's my Unicron repository there is a unified branch in there this is where it builds now and it runs just as rapidly there as it runs on this side as it runs on the other side it's perfect Linux kernel easy of course I missed one guy I did this week or so Intel has 12 people working more? and we're pushing features at a faster rate as I said features, they're not stable features you can disable and say hey we're not having this feature so use it, it really wants this feature they will do it, they will update the rest but don't force this on anybody at the point where we decided that we weren't going to do this anymore I mean we used to have support from 1.6211 or 1.2 this is all there one tree this is one autocom, this is one make I will prove this now so at the point where we removed all that compatibility we deleted a significant fraction of our bugs because it was all interactions with different versions of interfaces gif depths everywhere and nobody was testing on old servers because you were not even allowing us but that's how I feel I don't like it major developers tell us this distribution three months before they're about to release their enterprise version that their whole business model is wrong this is not what should happen and it wasn't you for everybody that knows who so unified building, X-River ever since we had SDK this is how it works, we have autos we all notice all of them this well at least 25% Linux DRM for my driver if you have kbuild installed if you have headers installed for your Linux version you just run make when you have run configure you run make, you're done you have the DRM, you can just install it kbuild headers they're just Debian packs very easy and you can also do this on a suzer but I think I need a slightly more work here so Mesa DRI is a really ugly one you have to especially prepare your Mesa tree you have to run some figure then send down into this directory and run make and then you just point my driver tree to this Mesa directory and build not that hard of course getting over the interface changes that could be most of that week that was painful so where do we go from here the more people who start doing unified trees the more people who start breaking out these hard connections that are there now the more that people will start to care about APIs this will happen naturally and the APIs will evolve better and in a way that is easier to track tracking API changes is very painful in all these parts it's very painful and the really painful one is Mesa DRI even for a driver that hasn't moved that much that was really painful because nobody cares and I think also these changes could have been avoided for the changes I have seen in my uniform if you want to plug in feature as I said you can disable feature many users will be happy until their next big distribution they will be happy and at the same time you already get everything else tested you get feedback on everything else so kernel DRM it's not that hard, it's repository changes we just went through a big change already but the longer term as a driver developer as one of the guys who actually saw some lines in moat setting in the last few years I do not like how everything is just meshed together or mashed together in the DRM driver it's all just thrown in one piece changes pull this out and some things will start making a lot more sense for tracking features if you change that it just looks a bit more messy but the interfaces can be tracked so much better live DRM this driver specific part move this out go for your own version for your own driver internal it's almost a convenience library move to your own versioning and suddenly the link to Mesa will become a lot more sane it will be very easy up there same thing again check out usr include DRM and find out through your package manager either rpm-qf or dpkg-bigs capital S on the files there and find out which packages all the files in there belong to and also note the two register definition files in there it's not how it should be not for driver specific things same thing about mode setting memory management standard DRM like submitting command buffers those things are actually they can be fairly modular they can be pulled apart they can have nice separate interfaces split there and your life will become slightly easier the life of the driver developer is already hard enough Mesa Mesa is at the moment is about 120 megabytes of source and even the releases that are happening every time there is a major release of Mesa or minor release of Mesa they are already shipping this in three different turbos so there is already a clear line there with three different turbos maybe it's time to start modularizing some of this the interfaces are doable and it's actually when you look into the whole build system there you see a nice little convenient nice little convenience libraries all the way already and you can split there and try to formalize the apis for these libraries if you make these libraries, if you make them shared objects you will probably lose one or two percent or whatever speed because of the lookups because it's the only reason that I've been hearing so far that stuck the only reason why this this is something maybe you should also do check usr slash lib check the size of any of the DRI drivers in there you will be looking on an AMD64 system at 2.6 megabytes 2.6 megabytes and even the most feature-rich driver for a DRI an Intel driver, the source code is what 1.3 megabytes so you should compile some source code 1.3 megabytes and you end up with a binary a strict binary that is 2.5 megabytes but what the Red Hat guys did there it's libmesa.a I'll just make it libmesa.so and provide no API guarantees because it's all part of the same package the .so and the things so the Red Hat guys are doing this it's trivial and it gets you the size win while not requiring that you provide stable APIs for a basic API but if you move the drivers out you become more stable automatically it's always a push and pull it will always be push and pull but if the drivers are out there there is another hurdle that you have to jump over before you make a change and you spend a bit more time thinking about the change and often in such a case you will find a better way of doing it or at least being able to track it better this happens naturally at least it should so yeah make them share the objects and try to formalize these APIs and make it so that you can build against it G config and packaging and try to build against but try to have drivers build outside and then the world will become quite a lot better I hope anything else I was going to say thanks for calling remote I had been a limelight yesterday 20 minutes short so questions and we can have a big discussion in 5 minutes maybe a comment about the Mesa and DRI thing I think looking at the classic Mesa drivers it's really not correct to think of Mesa as a shared library that you use the interface is so broad it's more like a toolbox for building drivers and so I think the splitting out is not really that feasible gallium is a different story but Mesa it's the same argument that the kernel guys have for keeping drivers in the same tree is you really want to be able to change some of these data structures want to make modifications there as I said gallium is already in a state where it might make more sense to go in this direction but for classic how long have you been in the vicinity of X I started 2003 pretty much when I started you all served stories about KGI GGI and how it got treated and how it was very hard to get this even accepted or acknowledged by the kernel people at the time because graphics hardware is unbelievably unstable and there's a lot of when you see all the e-mails from the kernel people at the moment there's a lot of stuff going back and forth between the kernel all the time I would love to be able to have all the radiant stuff in one single git tree and not worry about the internal interfaces but the thing is that the interface to Mesa core for the classic drivers is so big X itself is not that easy either it's gonna be bigger X itself, everything that is currently X driver this interface I think it might actually be bigger not the Mesa classic I don't think so but it's worth a try the XAPI is rubbish and incredibly old upon but Mesa classic but for gallium at least for gallium it will be very useful more or less you can look at all of these like the state that the OpenGL spec describes and it's in Mesa plus some computer state it's big but it has it is a huge advantage for doing extension enablement which we get pushed on on a regular basis of we want new extensions extensions features yeah like so you can you're allowed to disable these and say hey I'm not doing this OpenGL are about extension support yeah and you're you have to build something where you can say they don't have to reflect what it needs to be to get the performance and features like if I have to performance and features this is what I'm saying all the time if you let the people who want to build this or you want to update their current driver you at least give them what they have before you don't give them the new performance or the new features they don't want this, they want to fix their current issue they want to continue working and we do have the Mesa stable branches for that right if you want a small bug fix yeah but then everybody else has to go and pull bug fixes and look into all the changes in app and pull bug fixes back if you have this separate oh I pull the bug fixes back in Mesa for my driver like yeah I run the test suite I got I write tests for failures that we have but you don't even have to do this I verify that my cherry fix if you have your driver external and a bit backward about it back to disabled features or performance that's fine if you have this anyway then people will be using the rest of the code shared there will be no bug fixes you have to back forward you just have to be careful about the stuff you have about the abstraction of the API that you build in order to work across all those different versions of it I tried this experiment in the Intel driver and then we gave up on it I tried it in Unicom just now against these 5 versions all the way to stable, stable is 3 years ago they've been stable that's quite a long way, a long time for Mesa and there's quite a few changes where I think was this really necessary was this change really necessary and I'm just one guy I'm not for Unicom I'm just one guy and I managed easily 12, 15 people I don't know how many people you have you should manage you should be telling that your clients of the next distribution vendors that they're having a wrong business this is something I do not accept so any more questions before we continue the discussion more here from the front Harold I mean more and more policy could be even more important than it is today but if you look at the metrics and changing those also which versions of which also come in if you have to define what's going on in the data running right now it's a real mess we can try to get any version in picture but what about if your drivers because 80% of the bucks are going to be in the drivers anyway if your drivers are backward compatible and can be built pretty much in everything that's current then the package managers there will be package managers who will be doing this for you all the time if they get the latest package of this driver if they have an issue so tracking this tracking this will be done by package managers first but what I'm saying here Harold you're talking about the X server I'm talking about the driver and the driver can be one big package it can be one big blob maybe even broken up in different package he's also talking about it but an auto-account is doing this for me auto-account is detecting all this for me you were also talking about the internet I managed it's just a proof account stuff it was the really easy thing to do and it's something that allows me to move very fast in the future with Unicrome as well it was the really easy thing to do but it still sells where you can do this for that easily but on the other hand Intel there's an enormous amount of manpower there you should manage they support a lot more hardware than you would in France then they support a lot more features of course but I support all the hardware that's out there yeah but it's a lot more Intel hardware than Unicrome hardware making that basically Unicrome is currently at 0.3% of the market and speaking by 20% of the year so I support a lot of hardware but of course in your world it's ruling everything I managed there's codes sitting there and you can do the trick with this it's really hard to do so how does your framebub run?