 Hi, everyone. I am my name is David new snow. Otherwise known as gravity for those of you don't know me I want to give people five minutes to settle in so I guess we've had that time now, so Let's get started before we really get started. I just want to invite you all to interrupt me with questions as I go through Please feel free. I'd really like to make this more of a discussion talk than anything if possible, so Without further ado With that in mind would anybody like to take take on passing around the mic Swap mics Well, that one does that one has a cord on it so What would anybody volunteer, please? Yep. All right. Thanks. So What I'm presenting is at least a partial roadmap for what the extra force more or less has planned for for Lenny It's not a complete roadmap because we have a lot of little problems that I don't really feel or worth talking about right here I'll sort of briefly mention some of them But basically what I'm going to be focusing on is the configuration issue Which has really dogged us for a very long time and I really think it's it's important to focus on it because there's been a lot of People coming to coming to work on this project upstream in the past in the past few months and really years so Here's a basic outline for what I'll be telling you about today Just some basic background of the problem of configuration and things like that that we'll be dealing with Certain basic aspects of configuration problems that we've solved and problems that are ongoing to be solved configuration of output input and then Miscellaneous other problems that we as a team are dealing with and have dealt with over the past several years that I'd like to briefly mention So oh no, okay, so you'll have to imagine that this doesn't extend beyond the screen So this is basically supposed to be a very simple diagram of our current setup for how we handle configuration Many of you are probably familiar with the outer aspect of this which is the fairly familiar deep package reconfigure x server dash xorg Which will eventually which I'll ask you a bunch of questions via debconf and then spit out an xorg.com and The way this works is we basically have a single post install script That calls debconf several times to ask questions or fills in blanks during the regular install process And it relies on several external programs in order to get information to fill in correct values including discover x res probe and laptop detect Discover is basically just a database full of PCI IDs that are matched to various device drivers And for our purposes, it's extra vice drivers obviously if you see a certain PCI ID you it'll spit out and say Intel driver to load. Okay, so it's fairly simple. It's maintained entirely externally to the x to x and it's a flat text file or XML text file depending on which version to discover you're using and That makes it easy to deal with The next one is x res probe, which is a script written by Daniel stone to replace the venerable read EDI D And it's basically a shell script that it queries the monitor or The the display panel task it for the resolutions and modes it can display and then it basically spits all that back out to the Shout to the post install and the post install uses it to fill in correct values for your xorg.com And then finally laptop detects a script that I think is fairly widely used in Debbie And I believe Daniel wrote that as well And it basically just guesses you a laptop or not and we and actually x res probe uses that Rather than the post install directly To determine how to how to fill in the EDI D values Now Once the post install script has run it basically passes it passes a lot of these the control off to dexconf dexconf is it sits in I believe user S bin and it basically is a is a simple shell script written by Brandon Robinson that Pulse the values for that were filled in by the post install script in the debconf database and spits out a xorg.conf in the end That's more or less complete So there's certain good things about this setup and why we've kept it around for so long We inherited this from Brandon and some work done by Daniel in Ubuntu when we forked the pack when we forked their xorg packages two years ago and The nice thing about this is it's fairly easy to maintain in certain aspects of it. It's mostly shell scripting which is you know a rapid rapid language to prototype things in and It's very unixy it relies on several different programs that can be individually maintained dealt with uploaded And we've broken things up so that they work pretty well for the most part But there's several problems with this as well One of them is that it's shell no one on the team really like shell and to be honest The post install script is kind of a monster It's 2,000 lines of not fairly clean shell There's a lot of hacks in there, and it's really not designed to do what it is doing currently. It's it's really It's really hanging together by threads in a lot of ways So it's a little over engineered Additionally discovers a bit of a pain to deal with it. It's it's it's not really a pain It's very easy to update, but there's a lot of duplicate effort there. There's several PC IDs Lists that are out there including the one we store in the X server itself and in the drivers So the X server is aware of a great deal of this information that's in discover so it feels like a waste of effort and In addition to that there's also no one else besides the Debian and Debian derivative community that is using these programs And I think even not picks doesn't bother to use this red hat and red hat derivatives for example use their hardware database called kudzu or kudzu and I believe not picks uses that as well So we're not really leveraging that work in any sort of way to get this to get this We have to duplicate that effort and it's really just kind of irritating The final problem with all this that's that's probably the most important is that it's not dynamic at all If you are to change some aspect of the configuration say swap out a video card swap in a video card Change your monitor. You want to change your monitor resolution You have to either edit this manually or rerun de-package reconfigure X server X org and that's just really irritating So what's a better method to do this? Well, this is the entire diagram the X server what if the X server was simply able to just do everything correctly the first time and Dynamically reconfigure itself either at runtime in as many ways as we can make it do or If it was able to just you're able to reboot it and then it just detects everything properly So this might seem a little fantastic given that we've dealt with xorg.com for a very long or x for 86.com config for a very long time But in reality, this is this is going on right now in the new X server X over 1.3 and I believe some of the shipped in 1.2 certain aspects of this That is an edge at least the improve our config. I think shipped in 1.2 There's been a lot of work done by upstream at X org to to address these sort of problems The the red hat maintainer primarily Adam Jackson has written a great deal of code to improve auto config When you when you completely lack an X org.com When you when you if you were to remove your X org.com right now from your et cetera directory Just get rid of it your server will probably run just as much just as well as you expect it It'll do things pretty well And this is kind of surprising Additionally Keith has been demoing randor 1.2 Which I'll talk about a little bit as I get into the output Stuff which will improve Display output configuration and finally there's been a lot of work going on by Daniel stone primarily upstream on input hop plug-in to Improve the way we handle the input devices and so we don't have to deal with all that So this isn't really so such an outlandish idea where the server just does everything we don't have to have all these custom Debian Scripts like X res probe To just handle all this stuff So how are we gonna actually implement this well this kind of relies on having X org which you see here According to uncyclopedia.org X org was founded by professor Charles Xavier here And but basically what's important about this is that this is completely different from X for 86 in a way It's an open development structure. I have commit access and we can pretty much get commit access If we wanted from anyone on the team if we really need to and that allows us to actually contribute back all these patches We don't have to have a massive patch stack that we keep just customized for Debian to do all this auto configuration We can put it directly into the tree everyone in the looks community will end up using it We can draw from them whatever fedora or or susa decides to do we draw from them as well And it really pays off in a lot of ways It's the kind of thing we expect to have but in reality we didn't have with X for 86 We have this map we used to have this massive patch stack that just no longer is present because of this this this change to the exit organization so Now knowing that that's basically the method that we're going to do we're going to cooperate with upstream and push as much as we can And take as much as we can that's that's available Here's the sort of details of what we're going to do. I'll be leading you through our X org.conf that we wrote for etch If you have an etch install this I'll be leading you through essentially what we did for it and telling you how we're going to get rid of each part So for the basic configuration I'll be talking about modules the module section the font section and the DRI section So the module section first if you look in your X org.conf you probably have this it's It lists a set of modules loaded by the X server for various things probably the most notable of which being DRI but also GLX and things you really don't need to worry about So the way this works in server 1.2 which is what shipped with etch is that if you don't have this section at all it loads a default set of modules If you don't have an X org.conf at all it will load all the modules in that it can find But what we've done what I've done is basically I've said okay this is kind of irritating because the minute you specify a single module that you want to load That's different from the default list you have to write out all the modules you have to load because it overrides the defaults And that's really irritating you should be able to have just a minimal config file in that sense and just specify what you want Additionally there was no way to not load a default if you had if you didn't have a section if you wanted to say I want to load all the defaults except for DRI In order to disable DRI you couldn't do that you would have to traditionally comment out the DRI load DRI line and have all these still listed So that's why we wrote all these out in the past and that's that's a lot of stuff and it's really not worth looking at because you probably don't care about Most of these modules under the normal circumstances So what I've done is I've implemented such in both the X server and unstable and it might have transitioned to testing I don't know And also in git head and upstream is that we I took that default list of modules and it's loaded by default and I've added a disabled directive so that you can just say Disable DRI and that's the only thing you have you can have in there and it will load all that defaults and you can just disable DRI that way So you can have your minimal config file and it won't hurt you in terms of in terms of this module section So this is exist today we no longer write the section by default if you do a D package reconfigure X server dash XOR You'll just lose these 10 or so lines and your your config file be smaller easier just glance at and figure out what's going on with it So moving on to the file section this one is particularly ugly This is where we what we've done it does several things but what we did for Edge was we we specified the various font paths That for the core fonts not all fonts just the core fonts which really you don't want to really be using but the server requires at least one core font What's known as fixed and the reason we have this just massive load of junk is because when we transition to 7.0 in the modular series Of the X server we moved the fonts from user X 11 lib dash you know X 11 fonts to user share fonts X 11 And this caused a lot of problems for people because they had this old config file and they weren't finding the fonts where they should We weren't able to simply link it properly for whatever reason so what we did was we just use said thanks to Steve Langosack Writing this really insane said line and and altered all these and we write all these out basically so we explicitly look for them So this is really hideous and it's it's really not that interesting to look at for most people They don't care about the core fonts to begin with and they don't care that you can modify them you just want your server to work and boot up And that's it you know you care about your your true your true type fonts or whatever so So what we've done what I've done is you get well okay so this is based on work by Eugene Konev who used to be in the team He still is but he's been sort of inactive is that he wrote a patch to always use the compiled in font path You can specify at compile time of font path and we do that for our packages it's in Debian rules and we specify this we specify this font path In in Debian rules so what I did was I've patched the X server both in unstable and upstream at x.org to always look in the default Font path unless you set a new server flag that I added say use default font path that that server flag is always set to true But you can you can disable looking in this if you want if you're crazy and you really just have some insane reasons to not look in this font path You can do that I haven't taken that away from you but for the 99.9% of the people who don't care about this it will automatically do it And you can no longer break it by having another adding on another font path which is what it would traditionally do the menu would add some other font path It would override the compiled in default it no longer does that so you can add in whatever font paths you want and it will no longer break your system And this exists today again if you do package reconfigure X server dash X org and unstable you will not have this you will not have this Gimish written and you will have a much cleaner Xorg.com The last basic thing is this little section about DRI and this isn't really well documented and I really I need to write the man man page entry for this In the Xorg.com man page but what this is is for DRI the direct rendering infrastructure what basically allows your apps to talk directly And send commands directly to the hardware to do OpenGL fast and things like that It does so the way the applications do that is by talking through a specific device file and they basically have to ask the X server for permission And once they get permission from the X server the file gets changed modded specifically for them And what we did in Edge is we just we didn't even give you the choice this is probably what you want under most circumstances And we just wrote this by default what we've done is instead we've patched libdrm to use this mode by default You can override it and set it to whatever you want if you'd like if you have reasons being your assistant administrator you can change this But we've patched it by default so you no longer need these lines anymore So that again will shrink your Xorg.com by a little bit So right there just already sitting in unstable we've gotten rid of three individual sections that you know exist in an Edge And we've shrunk down by about 25 lines or so the default Xorg.com And you can get this today if you do package reconfigure So moving on which is to what's really the next task is output stuff output being video of course And specifically the things I'll be talking about our driver selection and mode selection So driver selection so here's what we get this is what we lean on that program discover the essentially PCI database that I talked about earlier This is this is what we use to select the proper video card to figure out what the video card is and load the right driver And this is the this is the section of your Xorg.com that does it it's the device section We give it a name generic video card it doesn't really matter we can assign it a generic name however we want We asked to discover for the right driver to load and we just fill that in And we don't need a PCI bus necessarily unless you've got multiple video cards it's not even vaguely useful But I'm using it as sort of illustration for the process that by which this has to happen Excuse me you have to you have to scan the PCI bus in order to to find the video card anyway The server actually does this internally if you've ever looked at your Xorg log file you've probably seen it scan the PCI bus Server the server is already doing this every time it starts up no matter what the exact same thing that we do for discover The only difference is by default it won't say spit back out a module for you to load or it won't just automatically load a module So we've got a plan to fix this and there is some auto configuration code that's been written by by Adam Jackson To do this it does it by the vendor ID of the PCI code but it's not really ideal His plan and something I've talked with Keith about a little bit while I've been here is to hopefully just have each driver Keep a list in the symbol table of the PCI IDs that it's responsible for and just have the X server loader query that And figure out okay I found this PCI ID it matches this driver just load it and it should just do the right thing So hopefully that'll be implemented within the coming months and we can just get rid of discover and not worry about it I don't know if anything else in Debian is really using discover the way the X server is But we won't lean on it anymore and the X server should just do the right thing And this would allow you to just swap in and out a video card without changing your Xorg.conf It'll just work. Franz? What about video cards that I support my multiple drivers? Right so something like NVIDIA for example Yeah or the VESA driver which can be used as an alternative for a lot of specific drivers The which? The which drive? The VESA So we probably don't want to auto load VESA unless it's the fallback It would be the fallback under most or FB dev depending on the architecture That's actually how we do things in the in the post install Depending on the architecture we would have FB dev be default but under x86 we would have the VESA driver being the fallback But in most circumstances we expect the driver to just work If it says it can handle this PCI ID we expect it to just do that If you need to override it you should be able to override it in your Xorg.conf manually Hopefully there'll be better front ends and I don't have time to talk about it But hopefully there'll be better front ends for altering drivers and things like that Without having to manually edit your config file in the future Okay so once we figured out the driver we have to basically tell it how to output what it's going to output So we have a lot of ugliness here and basically this is how we do it We've got a monitor section that we give a name to We basically ask the monitor what its name is We specify dpms option which is power management This is enabled by default now in the X server so we can just get rid of this option period And we specify horizontal sync and the vertical refresh rate of the monitor And the way we get these numbers in the post install is we use that program Xrespro And it asks for this information for the monitor That's fine The problem with this is well again you can't dynamically reconfigure it You'd have to change things But the other problem is that the X server is already doing this The X server can actually talk to the monitor and does talk to the monitor and gets all this information anyway And it can handle this by default So if you go further the way this is tied to specific resolutions Is that we've got the screen section and you can actually specify those here too But the way we do it is we give what's called the screen a name And we associate with the device in this case the generic video card that I showed you before Which was loading the i810 driver We associate with a monitor which is this one up here We give it a color depth which we can just specify some default And then what we've done in Edge is we say okay for each We go through these subsections and for each color depth that you might want to use We specify all the various resolutions that are available And those come from Xrespro as well And we do this, this is cut off here But this is actually like, I don't know, 15-20 lines Because it's three lines per item Or I'm sorry four lines per item and we specify like eight color depths Or six color depths or something which is really just absurd So you don't actually need to do this You can just specify this mode in general for the single screen section Say use this for all the different color depths And that's actually what I've done for Unstable recently You can configure Xserver-Xorg Right now all these will instead be put into one line here And you'll get rid of about 20 odd lines here as well And your Xserver.conf will shrink dramatically And you get all the same information Now the problem with that though, that approach Is that this isn't necessarily even that useful Especially in the new world with what is known as RANDER 1.2 Which you've probably seen Keith demoing And actually what I'm demoing for you right here RANDER 1.0, you have XRANDER No matter which version of Debbie you're running right now Given that you're running something vaguely recent And it's basically the resize and rotate extension Allows you to change the resolution of the monitor On the fly And what RANDER 1.2 does is it actually dynamically Allows that for things like laptops And for outputting to external displays And things like that So that improves even this And it really relies on the changes that come with RANDER 1.2 Really rely on having this information Available from the monitor at the runtime So the server is already querying this So we can potentially get rid of it And if you're running a RANDER 1.2 driver Which is currently I810 and NVIDIA Or Intel and NVIDIA in Unstable This is an ATI card, ATI The driver isn't released yet But hopefully it'll be coming soon From upstream But basically all the major drivers will be taken care of And NVIDIA GLX doesn't support it yet either But it's also forthcoming But basically for all the major video cards We should be able to dump this information We may want to store it in a cache In case the monitor for some reason doesn't Actually respond with the EDID information And all these resolutions And some old monitors apparently don't do that So we may want to cache that And that's basically what we're using X-Rez probe for now And all this information So we should be able to get rid of it And hopefully that'll happen soon It's basically... If I can figure out how to cache it properly Or if Adam Jackson does We'll just get rid of it And pretty much all this can just go away At that point So we can just dump it And you don't have to worry about it Unless you have to set your resolution Before you start the X-server Input So Franz? I've monitored that Supports 600 by 1200 But only does so as At a really horrible refresh rate There is an option I think That you can set a target refresh rate That will be used On boot of the X-server So that it will use a lower mode That actually matches the higher refresh rate That you really want Is that correct? I honestly don't know That's a good question Keith's nodding, yes Okay, yes Okay So the other real big thing That X deals with is input obviously Micing keyboards really And one of the problems We traditionally face Is that the server isn't really aware Of input hot plugging It really tries to configure The server at runtime And the way we've hacked around this Is to lean on the kernel very heavily We let the kernel multiplex All information to dev input mice Which is set up by Udev And that works really well It does actually really work People can plug and unplug their mice And it works But we haven't In Debian sort of Really relied on that for pointers So hopefully that will be forthcoming soon But here's what we have done in Edge So this is for the mouse And the pointer And basically what we do Is it's sort of similar We give it an identifier It's sort of similar to the device Or to the output We give it an identifier And we tell it with driver to load In this case mouse I can't imagine anyone Who's not loading the mouse driver these days We tell it it's the core pointer Which is of course The most important pointer The X server needs at least one core pointer It's the required one And you can have that fail If you explicitly specify it But we don't You tell it with device to look in And we by default do dev input mice And we tell it with protocol to use The mice can speak several different protocols Including explore ps2 Which you see here Or imps2 And all these different things So what are we going to do To get rid of this? Well we can just load the mouse by default Especially if it detects If the X server detects a mouse Via HAL Daniel's been working on integrating HAL The ability to speak to HAL Via debus into the X server Upstream and hopefully when he gets The ability to do that It'll arrive for us And we'll put that in We may want to go instead Of through the mouse Through the evdev driver Evdev Which is written by our own Zef and I at HAL I'm not entirely sure how appropriate that is I haven't tested it extensively Some people have had real problems with it It works But it seems to be fairly complicated To have a generic device driver Like evdev So we can just tell it What's the core pointer Especially when there's only one Pointer device detected And we can also by default Just point it at dev input mice Which is actually what the X server Does when you don't have one of these sections And it's really the right thing to do Dev input mice really It handles things properly And most people should be running Udev these days I know some people really don't like it For pretty good reasons But frankly if you're one of those people We're not going to take it away The ability to configure this sort of thing But you're going to have to do the work for us We're not going to do it for you In the most insult script anymore This makes our lives easier It makes the lives of you easier For who don't care about using Udev And it's really the right thing to do So we'll probably stop allowing you by default To do things like point at dev PSAUX In our own scripts Finally for the protocol It turns out that the kernel driver For the mouse is really surprisingly good With the protocol If you point the mouse driver Dev input mice What I have with the kernel driver Is when it multiplexes the mice input To this device It automatically translates The protocol into a super set Of all the different protocols And the mouse driver can handle this So you don't have to specify the protocol It'll just do the right thing So today if you want to delete this And you're pointing at dev input mice You can I haven't done that yet in the post-install script I need to But that's something that can happen today You can get rid of that Keyboard So keyboard is relatively Well it's different to configure So much like all the other sections We give it a name The identifier in this case Generic keyboard We tell it to load the KBD driver That might have broken for some of you recently Who had the old keyboard driver K-E-Y-B-O-A-R-D And we didn't alias it properly To keyboard anymore And that broke for some people That fix is I don't think quite ready yet But I think it's forthcoming We tell it what's the core keyboard And then There's certain unsolved problems here for us I've discussed a little bit with Keith But basically We have to specify X keyboard rules What sort of key map you use What's the layout In this case Because I'm American You use US And then the Xorg layout Or XKB rules It's not entirely clear to me yet How to handle this We might be able to Currently the way the post-install script handles it Is it takes information Spit out by the Debian installer And Fills in these values It sort of guesses the right values for you I'm not sure how exactly To get this working in the server Maybe by guessing from the locale About And hopefully we can get that working at some point So we can just scrap this whole section And it'll work by default for you At runtime every time That's the ultimate goal But I don't have an answer for that yet And if people would like to talk about how to do that I'd really like to hear your input And finally This doesn't fall under input or output This just kind of Ties everything together This is the server layout section And you basically All these different devices Including the mouse The generic keyboard The screen The default layout All get tied together with this section This basically tells the server Okay, use all these things I specified before And that's the configuration you want It allows you to specify a ton of different alternate things And turn them on and off easily But in reality I don't think anyone's using this too much We're not going to take this away But what we'll do is if you don't have one It'll just choose the right values It'll use everything that's available It'll use the first one it finds With certain drivers, things like that And it'll generally do the right thing That code exists today In the x.org head In git head It does not exist yet in Debian Because it's kind of a pain to backport And it's not really worth it But you will get this It is forthcoming I tested it, it works And it will ship with Lenny So this will just go away So that's it for the details on configuration Are there any questions Before I keep going With the basic bugs that we've been doing? Keith So how long will the default Configuration file be now? How many lines? Hopefully very few As far as I know Hopefully it'll be none in the end If we can get rid of that xkb stuff It'll be nothing That's all the sections right there What I put up And that's what we really want Okay So other long-standing bugs So this is sort of getting into The broader team stuff And I'd like to talk about some of the stuff That the rest of the team is doing Rather than just my stuff And we've had several long-standing bugs That were really problematic For the team as a whole One really notable one Especially during the Sarge release Was that we were not up to date at all We shipped x364.3 with Sarge We all know that was a mistake It seemed like a good idea at the time I supported at the time too Even though I wasn't really actively involved In the team at that point But it was a problem And now with the new upstream With x.org We've really tried hard to stay up to date We've tried to really push things back We've tried to really stay involved With communities as a whole And I think that's really important And lately that work has really been done By Julian Christot Who unfortunately does not appear To be in the audience right now Even though he's around And previously for 7.1 And a little bit lately is Drew Parsons Who is also our expert maintainer So we've been pretty good About staying up to date with upstream We've tried to get drivers to you guys quickly And rapidly, if only in experimental But we have tried to do that You guys have the latest stuff And we really appreciate your feedback In order to push it back to x.org Bug reports are something I've been very bad about Brandon Robinson was extremely good about these I've been terrible about them While I was really primarily the maintainer Recently Julian recruited Bryce Goglin To work on these And he, if you haven't seen Has just been doing a phenomenal job I've tried to get a graph of his bugs But I wasn't able to get them I had an old URL unfortunately But he's basically closed about a thousand bugs Over the past several months And forwarded a ton upstream So our BTS is actually now in good shape You can browse it and get a fairly up to date Information on what the package state is like Across the entire x.org package set And you can expect to get a response Pretty quick from him He's been really good And he's generally very bright And making very, very good calls on all the bugs So Bryce has been doing a fantastic job as well More recently, something that people have been complaining about For a very long time Has been the x applications Traditionally, what we've done Is we've bundled them up into x-based clients And I think xutils Including things you don't need Like xis and things you really do Like xinit and startx So people have been begging us To split these things up for a very long time That actually happened in Ubuntu Daniel Stone split everything Each of these little tiny apps Got their one individual package Because that's the way they're handled upstream But I basically looked at it and said No, this is a maintenance nightmare I don't want to deal with it So I bundled them all up again The same way they were in Sarge And shipped them that way in Edge But Timo Altonin Who I hope I vaguely pronounced that correctly Who's actually an Ubuntu guy Has come on and decided to sort of Find a middle ground And what he's done, and most of this I believe is an experimental now Has split the packages Into something following the Fedora model Where we've got some of the basic things You need to just run a server at all Like xinit and startx in one package And then there's a lot of extra things For example, in xis Or xcalc in another package That you just don't need to install If you don't want those apps So there's several of these packages They're in experimental And those are becoming available soon And we'll hopefully be getting those into an unstable As soon as me or Julian Find the time to do it So that's been a longstanding bug That people have been asking after That I'm happy to finally be seen resolved And it's nice to actually get A little bit of input from Ubuntu We haven't had that since Daniel left Things we could really use your help on And I think the project could really benefit From some of this stuff If we could get these specific things done And some of these are very high profile And basically we don't either have The time to do them Or we don't have the time to do them properly And we'd really like someone who's really Really capable to do these Or not even necessarily capable but interested And we can guide you through the process Drivers, first and foremost We'd really like to package the Nouveau driver I don't know if it's ready I haven't evaluated it Nouveau for those of you who aren't aware Is a fork of the free software NVIDIA driver Where they've reverse engineered the 3D The 3D portion of the chipset And implemented DRI for it So you can actually run accelerated Graphics on NVIDIA using this driver With a totally free driver It's not production ready by any means According to the developers It's still in development status But we'd really like to get this into the archive We'd really like to maybe ship this with Lenny And I really want to support this project And I don't have any NVIDIA hardware I know there's plenty of people out there who do Who are running NVIDIA GLX So I'd really like for them If anyone is interested in maintaining this driver It's not that hard We'll guide you through the process We'll sponsor you and we'll help you out Provide you with Git repository Pretty much whatever you need So we'd really like your help Just about a week ago The Avivo driver was announced And this is really exciting Because this is for new radions The traditional ATI driver Only supports up to R300 For accelerated graphics And it was pretty much broken For all things beyond that Including 2D as far as I know The Avivo driver implements Support for newer radions And it's still It's not entirely ready But it's in pretty good shape People are running it And we have this packaged And it's uploaded It's sitting in new right now Julian packaged it But what we'd really like is If someone has a newer radion And for example you're running FGLRX That you If you're interested in maintaining this Please come talk to us There's a fairly large team upstream There's a, well not large But it's significant And they're pretty good And they know what they're doing And they could really use your help Both in developing the driver And we could use your help Maintaining it for our users Another high profile set of packages That has gotten a lot of attention Are comps and barrel Is there anyone who are unaware Of comps or barrel? Okay, that's what I thought It's hot, right? I mean everyone I mean, you know This is the sort of thing People are using to sell Linux And it's really, really hot For those of you who aren't aware Comps and barrel are merging I don't know the state of that I don't follow the projects We do have a comps-maintainer Theory-reading He's really technically outstanding And he's done a very good job But he's been fairly busy And he hasn't had time To say triage bug reports So we could really use someone To work on this project We had a barrel maintainer Who sort of flaked out on us And barrel has a lot of extra utilities That are really nice And should be worked into comps Things like GUIs to configure it And theme managers And all sorts of really nice user level things That should be added onto comps And we really want We don't have these in the archive at all We do have comps We don't have any of these barrel apps And we really like to get them So I know there's got to be someone out there Who's interested in working on these They're just window managers They're in C You can deal with them And they're really cool If you're the comps-maintainer People will flock to you And women will love you So please come talk to us I'd really like to get another Maintainer working on these applications Finally, this is also an unsolved problem We have a lot of packaging infrastructure That we have built up from the past Brandon Robinson wrote An incredible amount of shell And make to handle Packaging the X386 monolith And we've carried over a lot of that Into the modular packages And a lot of them aren't necessary anymore But some of it's pretty good And we really want to keep it around For whatever reason In addition, we've implemented a customized Improved system to use The quilt patch system Which I hope all of you are using Instead of d-patch Because we wanted some extra targets Like a patch auditing target And we really want to push that out To the wider packaging audience We want to allow everyone else to use that And we don't want to be maintaining it anymore Really So I don't know if some of that stuff Some of it's shell scripts I don't know if they should become Dell Helper applications And things like that But that's something I'd really like to do I'd like these to be fairly bare Simple packages to deal with To maintain And I'd like all these tools to be available For the wider distribution Without leaning on the X-strike force To maintain them So finally, I'd like to thank A bunch of people I'd like to thank the rest of the X-strike force There's only one member here, David Who's standing right there Passing around the mic The rest of the team is incredible I tried to credit everyone who Is doing the bulk of the lifting lately And I did not have time to credit all the People who maintain one driver Or something like that They're doing a fantastic job as well It's really a great team now It's not just one person doing everything I might be the best known of the team But I don't necessarily feel like I'm doing a lot of the work The team is fantastic And they really deserve a ton of credit I'd like to thank the rest of X-strike Everyone upstream has been really great It's really a fantastic project And to be honest X.org really needs your help too It's a Harry code base admittedly But you've got a great bunch of people Working on it It's being cleaned up And there's a great deal of Good things to be done I'd particularly like to thank Adam Jackson Who actually critiqued this talk before I gave it and really provided A lot of valuable input I want to thank FTP master very quickly Because during the modular transition They were very quick about Getting to all our packages And getting them uploaded into the archive And I know there was a lot of them But I'd also like to thank all of you For actually getting up on time To see this talk I know that's a real struggle Because I had to do it too And for paying attention at all So with that I'd like to take Whatever sort of questions there might be And discuss things My name is Peter Reynoldsen From the DB and EDU project And I was wondering what do I have to do To get certain bugs fixed in X386 We have one three-year-old bug Where we want to have scripts Running as a route When the user log in To clean up the environment For the next user I've been talking to the X server team For the last two dev contests On IRC and other things Is there anything else? Can I buy a beer or anything? So you want to run You want to run scripts to clean up after Yeah, I want a directory Of fragments to be run by Xreset I'm sorry, I didn't understand that Just kind of echo it I want Xreset to run fragments From a directory Like a startup I honestly don't know We should probably talk about that afterwards I really don't have an answer For you off the top of my head Okay, I'll throw that I think you talked about this earlier But I just probably missed it It's regarding the hardware database How do you keep a collection Of which video cards are supported And things like that Because I see a lot of I see a lot of duplicate effort There with, I think the stuff You kind of mentioned Right, so the way it's done currently The question was about The hardware database And the duplication of effort So the way we do it currently Is in reality there's two major databases That are out there There's Discover And Discover 2 Which are essentially the same thing And they're used by Debian And I don't maintain that anymore I'm still probably listed as a maintainer But I don't work on that Other people do And they basically get There's a centralized list of PCI-IDs That are available And they've mapped them To names of the hardware And then what we do Is just manually update the thing Say, okay, we know this driver supports This PCI-ID and we just add it in There's also the Kudzu database Maintained by Red Hat And I don't know how they update it I assume it's essentially the same thing And the Ubuntu hardware database Do you get anything from that? I don't use that I don't think their scripts use that They want to use Discover or something else They use to I haven't looked at their... Have you guys junk Discover finally? Yeah, they're still using Discover 2 But really the way to do this Is to do it in the X-server All the drivers know what they support already The question is telling the server Which drive with the X-server So the X-server has a database too? No, it currently does not Well, it used to We used to centralize all the PCI-IDs, right? No Okay But essentially each driver knows what it supports If you look in the driver sources They've got a list of PCI-IDs and things like that So the drivers know what they support already There's probably no real need then For a hardware database then That's kind of the idea That's the ultimate idea The question is just how to get that information to the server So it loads the right driver And that's what we need to do Great, thanks No problem A comment on the hardware detection thing I'm the Discover 2 maintainer I had a look at the X-drivers And it's correct that the PCI-mappings are in there But we still need it to be able to pick the correct packet to install If we want to avoid installing all the X-driver packages When we are configuring X It is possible with some Defines and source magic To actually extract the PCI-IDs From the source of the X-drivers And that would be interesting To feed that directly into Discover I haven't gotten around to actually do that I just realized it was possible Because the source is actually structured Fairly consistently across drivers To detect the PCI-IDs Right, that's something we'd actually like to get working We were talking about that the other night At dinner, trying to figure out How to just install the drivers you need Currently we install all the drivers by default So that you don't have to worry about it But obviously that's not the most optimal way To do things in terms of disk space Ideally the server will know what driver needs And then it will somehow tell the packaging structure How to get that, what driver to download And it'll just work I don't have a good method for doing that yet But that's something I'd like to maybe get working Maybe if you're a Debian installer, I don't know I was just wondering What we're going to do about older monitors And that sort of thing Where you can't get the resolution information Is it going to come up in 640x480 Or some same default or what's going to happen Yeah it should have some sort of same default Basically we can't do anything about those monitors anyway You know the default install won't ask them about them So people have to configure them anyway So I think I think that people will just have to keep doing What they're doing unfortunately I mean there's no real good solution If the monitor is spinning out bad information to you Or no information at all You kind of just have to deal with it There is a mode for bad So there are some monitors that actually lie to you They actually just do not tell you the right information And what Keith's implemented is a quirk system Where it just We're aware of these problems in the code of the X server And it just automatically adjusts things So at least for bad monitors we can handle that For old stuff I don't know if there's a good solution Besides manual Yeah by default right now When we don't get EDID from the monitor We use refresh rate ranges That limit the available modes to 654 8x6 and 10x7 at 60 hertz So by default you get Three modes at a relatively low refresh rate And monitors that don't support those are Much older than the current X strike force so Okay well before I say goodbye I'd like to introduce Julian Christo who just walked in Who's over there He's been maintaining a lot of your packages lately And he's been doing a fantastic job of it And I just wanted to thank him for that publicly as well Since he missed that So if there's no other questions If you guys want to find me I'm around I'll be at hack labs and things And thank you all again for coming