 Hello, I'll talk a bit about what the work that's been done in the X world in the last release cycle. So first, a few words about the X team. It consists of about three people who touch pretty much that food. Okay. Is better? Okay. There are a few people who, sorry, who touch quite a broad spectrum of the stack and a few more people who focus on specific packages like companies or specific drivers. Overall, this means there are over 1,200 open bugs and many packages and various upstream mailing lists that we need to follow to keep track of all the work that's going on. So a few words about the stages in Lenny. So there was a lot of work before Lenny to almost get rid of the config file by default and the last thing that was there was the keyboard layout and so now we remove that even. So Lenny also introduced R&R 1.2 for the major drivers and there was some transition from an old acceleration architecture to a new one, which was starting at that time and which was done for Intel and Radeon was ongoing and so what, where are we now? So the input world has been completely changed once again with everything hot plugged and the other config is completely gone. There are some more changes to the to the Excel frameworks for better render acceleration and so we had the sort of free driver for NVIDIA which used to be maintained by NVIDIA people for basically just basic mod setting and no acceleration at all and now we managed to get the new driver integrated in squeeze, which will be used by default for NVIDIA hardware and which does not yet allow 3D Excel but has better mod setting and 2D acceleration than the NV and which doesn't have the issues of, I mean there was a very, very old RC bug on the NV driver about how it was obfuscated and not really source code. Also one important bit of work was moving the mod setting from the X driver to the kernel and so now this is done in squeeze for all three major drivers and well this was quite a bit of work by Keith and other people at Intel Red Hat and AMG and others and also in squeeze the Debian installer is now using X instead of using direct FB for the graphical installer so this was, I mean this means basically that we don't have to maintain a separate backend for GTK and KRO and stuff like this for direct FB and everything is just using X11 like in the normal system and this work was surprisingly easy I mean it just was adding a new pass to build a UDeb for a few packages and it just worked. So some words about input. So before we had just one core pointer and one core keyboard and well you couldn't have various input driver hotplugged and just work so this was changed so that we were using UDeb to get the list of devices and to just add them to the server at runtime and so this meant some changes to the configuration stuff so instead of having static input device sections you can just say okay every time I see a touchpad I set these options I use this driver and it just works when you don't really hotplug a touchpad but even if you hotplug a tablet or keyboard or stuff like this you can just okay this just works. There was also a new API to set options like this at runtime which is used by various frontends. Now on the output side the mode setting code was moved to the kernel. This means instead of doing all the work in X in user space the X driver just talked to the kernel via a new API which is basically similar to the Render API and this means we get for free a native mode frame buffer for the console and we can play with other stuff than X because you can just now that you have an API to talk to the kernel to set modes and create buffers and stuff like this. You can have other display servers without so much so much work in user space. This means you can more easily have HGMI, Ojo and stuff like this and new connector types which work in KMS which didn't work before in UMS. The work that was done before that was to add memory managers to the kernel because you need to have a unified API to manage video memory instead of having statically allocated some space for 2D PIX map and some space for 3D textures and stuff like this. The kernel now has a memory manager for video memory. There are basically two backends for this one which is used for Intel and others for Radeon and Nouveau and VMware I believe. Now I talk a bit about the versions of the different packages that you were using in squeeze. The kernel team decided last year in Portland I think that they were going to use 2632 and initially we were supposed to freeze I believe in March or beginning of this year so at the time the versions of packages were decided based on that and so we are using X server 1.7 which was released I don't know Christmas or was it before I don't know before and Mesa 7.7 was the stable branch at the time. Now I think it's replaced by 7.8 and Intel is released every three months and now in squeeze we have 2.9 and the current version is 2.12 which means we are quite a lot of stuff that we are missing and Radeon basically is in the latest release. So for the kernel actually the graphics stack is the one from 2333. There was because that's where Nouveau was introduced that's where I think Radeon was a lot more stable and Intel has a lot of bug fixes too and other distros are using also this stuff so this means they're less work than using the older version. So Mesa is basically the same version as six months ago because well we don't have anyone specifically working on that and it's quite a beast. It includes all the 3D drivers, core of the jail library and it's quite hard to keep track of it and keep track of regressions and stuff like this and without anyone working specifically on that then it's quite hard to keep up. Intel will probably move to 12 soon because well that has a lot of bug fixes and also better support for the newer hardware so yeah and Keith will release the server 1.9 this month next week okay. There are some RCS in experimental but hopefully we'll see the new release soon but hey if you want to keep see that sooner then we welcome the help. So a few words about the upgrade path from Lenny to squeeze. There is the interaction with kernel mode setting which means that you need a new kernel and the fact that we are using Udev means you need the new Udev which means you need the new kernel as well so basically if you upgrade X you can't really keep your old kernel so this will have to be documented and there's no real good way around that so but I think Udev anyways will require that you reboot on your new kernel anyway and until last week I think if you tried to dist upgrade from Lenny to squeeze then apt would decide to remove all of X because there was some API change between the core server and the drivers and well the package manager decided it was a good idea to just remove the server and the driver and do the upgrade so with some help from the app people will manage to work around that with more conflicts and this would be fixed and I think aptitude is still doing the wrong thing and removing stuff on upgrade. We have the same problem with H2 Lenny I think and hopefully it will be fixed for the next release and we won't need so many conflicts. So I talked about Intel, Radeon and VDrivers and basically the rest is un-maintained. I think Open Chrome is still maintained upstream sort of but I don't know. I don't follow that it's not on x.org and I don't have the hardware so it would be nice to have a maintainer for that stuff and the rest of the drivers are as un-maintained in Debian as they are upstream so they are kept building but I don't know if anybody test them so if you have other hardware then your help would be appreciated to make sure that this still works. So I mentioned that we have quite a lot of bugs and quite few people so how can you help? Well the first step is to file good bugs when you have issues with x. First use report bug to include all the information that is needed from the bug script and it's important that you try the latest call to make sure that the issue is not yet fixed and that you file the bug upstream as well because usually there will be some back and forth between upstream and the bug reporters to test stuff and get some more information and so we can't really just forward the bug and forward yet about them. It's easier if the bug submitter files the bug upstream directly and it's important that to be as specific as possible when reporting a bug about how to reproduce it what are the symptoms and what software you're running and stuff like this to make sure to reduce the need for back and forth and to make it easier for upstream to reproduce because if they can reproduce then usually the bug gets fixed a lot faster and one thing that is really really needed for x is to have some more up-to-date documentation. There are some old stuff and people refer to old stuff and there have been a lot of changes in the last year and this is not always included in the documentation so that was been good to have some more up-to-date stuff and finally we need somewhere to try out all the bugs that we have open to make sure that they have as much information as possible that some for some of them that we write patches and send them upstream or or ask people to test again and report the bug upstream and this is not really doable for two or three people with 1200 bugs so there are some hard bugs and some complicated code and stuff like this in X but not all of it is like this. There are some bugs that are already fixed or easily reproducible where writing a patch is not too hard or thus there's a lot of bugs that are just user error that need to be explained and well once we're done with the bugs on the BTS then there are many more on X.org bugzilla. So any questions? Christian? Thank you very much Julian. Questions? Stand back a little bit from the... Do you hear me? Okay. Yeah, Christian Perrier speaking. Oh that's not a question actually. I'm completely amazed by the work done by the X-strikes boss. Only these three people and apparently it's very hard to work on X so nobody is coming helping them and this guy over there work on one week and in one week integrated X in the DBN installer so it's very easy to work on X so it's really a cry for help because these guys are dying you know really really we discussed with Julian these guys are dying and if we don't do anything we won't have X anymore in DBN so instead of maybe that's a good thing I mean maybe replace X with something else yeah for the beige box we don't need X maybe. I counted 139 ITP bug reports out of 800 males in DBN Devel for the last four weeks so I think in some way we are driving crazy and I think we are driving so crazy that our core packages just like this one X everybody has X on your computer nearly everybody there's only three people and 1200 bugs think about it maybe you have an answer an answer to I think we pretty much all agree I think we pretty much can all agree that X is pretty critical I don't know we don't have any other alternatives right well at this point I don't think so yeah not really um so I have a oh here yeah it's just sort of curious BDL um sort of curious from a strategic standpoint for coping with the open bug logs and so forth um with a lot of the other things that I helped to maintain outside of X um particularly the complicated things GNU radio is a good example but there are others um the thing that I've done that's helped me the most with the bug situation has actually been to be much more rabid about closely tracking upstream's release processes and trying to minimize the lag time between an upstream release and things showing up in unstable and I understand because I've been here through all of the history why there has been you know more inertia around putting new versions of X into unstable and there's certainly been some interesting situations in the past but when I look at this I wonder if we aren't somehow mistakenly making lots of extra work for ourselves if we are you know still talking about and using a 1.7 server when 1.8 has been out for six months and 1.9 is about to release and similarly with the various drivers and the other packages and you know I'm just curious you know what you're thinking on this is strategically not I'm not trying to you know pick on a particular version of a particular package but I wonder if strategically it might be smarter for us to try and you know stay as close as possible upstream so that there's sort of the minimum distinction between the code we're trying to to make stable on the code that they're trying to improve so that you know if we ended up in a situation where lots of the open bugs you know turned out to already been fixed by something upstream and someone just has to discover that in triage that that wouldn't necessarily be a bad thing I don't know what you're thinking on this is I think in most of the case we are in the situation when where the bugs just need to be triaged and mostly already fixed and the problem we have with okay so first for most of the release cycle I've been trying to follow upstream quite closely and upload releases quite soon after the their release I've stopped doing that after 1.7 because while the Frids was approaching and there were quite some bugs in the initial 1.x server 1.8 and maybe they are fixed now but yeah when we are approaching a Frids or we are supposed to be approaching a Frids also I stopped doing I pretty much stopped doing X work in Debian for a few months last year and well nobody to get up so you asked a really I mean you asked a really interesting question which is you know when we're getting close to a Frids when should you upload some new major thing and when should you not and I always find myself a little conflicted about this because on one hand it's very tempting when you get to a Frids to not want to introduce major changes at the last minute on the other hand when you get close to a Frids you're getting close to a point where the bits that are in testing are the ones you're going to have to live with for a stable support cycle and so this is one of those things where I think we have to keep asking that question and we have to keep watching when the Frids dates are really going to be and thinking about and comparing those to where the various upper upstream release points are it's certainly a huge challenge when we allow a freeze to to drag on or to be delayed you know by some number of months because then we end up in the situation where a decision that seemed good in January February is not so good in August but you ask a really good question I don't know the answer but I tend personally to be more aggressive about making sure I'm as close as possible to upstream when we get close to a Frids point because I know I'm going to spend the next however many years having to find and fix problems there and being as close as possible to where you know upstream's brain is at that moment has always seemed to be a more successful strategy to me yeah this is this is I believe why we're we'll move to a 2.12 Intel driver soon because well the 2.10 didn't have many changes apart from removing the user mode setting code which if it's not used by default anyway having it doesn't hurt so much it even helps some people for whom kernel mode setting is not working so well then I think 2.11 had a few regressions because I'm trying to I mean we're trying to track also the upstream break tracker and see what kind of regression there are because there are always regressions in your release and we're trying to make a decision based on that and so we have 2.12 announced in experimental for some for about a month now I think since it's released basically and so I we usually ask people who have trouble with 2.9 whether it's fixed or in 2.12 or not and so far the answer seems to be yes so that's why we're moving to it so and yeah the problem of living with with some version some fixed version in stable has been quite a problem with Lenny because there is some specific Intel series of chip that well apparently had lockups for some reason like every day or every week or whatever and and that was a problem with the driver we have in Lenny and I don't know whether whether it was fixed later and I mean apparently it's fixed now but I don't know when and I don't know does it make sense to freeze the the x related packages at the same time as the rest of deviant and it's a relatively small group of extremely complicated packages so perhaps it makes more sense to sort of freeze it much closer to the overall freeze date than everything it's also a set of packages where we have regressions with every release and which are used by a lot of people and so it's hard to say that we need some time between uploading some version to the archive and knowing whether it's good enough or not I mean basically when you upload a new driver you know basically from the bug from the bug opening rate in the next month or so you know whether it's relatively good or not but the problem is that the hardware changes so frequently current hardware because nobody's using hardware that's a few generations out of date uh well people do as well but which basically if you're using new hardware then don't choose deviant stable well right um my name is ben armstrong I'm uh I lead the deviant EPC team and I wonder if you said you need more triage and better um uh bug reporting if groups like ours that care for a particular aspect of a particular hardware platform could be being a little bit more useful to the x-strike force by encouraging our users and and you know educating them how to to make these bug reports rather than just leaving it to the ad hoc individual efforts of yes of all the users that would probably be quite useful yeah okay I'll make an effort to do that um actually let me follow up on that point um one of the things that I think as a user of x that is really really difficult is that it's really hard as a user to track down bugs because when there's a bug in x your your whole system goes away your whole workspace goes away so the normal ways that a user or at least for me and able to figure out what's wrong doesn't work so if I think that the most important thing that the x project needs in terms of getting better feedback as to what's going on and better characterization of bugs is some sort of um well obviously some sort of help page to help figure out how to debug it but also if there was some sort of system well there are things like um x and x or whatever the whatever those packages are but if there were sort of step by step ways that you could help guide people through trying to replicate what the bug is without necessarily totally disrupting their their workflow to have to like you know restart x you know 10 times or whatever to try to figure out what the problem is but I mean maybe that's just something fundamental to to x being the display you know what's yeah working on your display but if there was a way to get to that easier I think it would be easier for users to help contribute yeah basically when you debug x you have to connect from a different machine over ssh and well many people don't do that or virtual terminals or whatever no gdb from a virtual terminal won't work because well when you're switching virtual terminals you're sending a signal to x and if it's blocked in the debugger then would it be wise for me at this point to be directing some of the more um capable users to the experimental version of x if say they were uh unable to resume from a high bernade or something like that that might conceivably be related to x or is it or is that more likely that's more likely to be a kernel problem right in the kernel or there was some problem with hibernation when when they come out of a suspend that's probably a kernel that's also a kernel level thing and it's hard for me to know because you know you get a black screen so you're thinking is this x the thing is the the people who work on this stack are the same whether it's in x or in the kernel yeah this is Keith's team this is the people at redhat or md or whatever but this is the same the same groups so whether the bug is filed against x or the kernel it can be reassigned it's not really a problem okay it's using the same bugs you know upstream and don't really one of the things that you mentioned um was the problem with regressions and I know I've seen it on lots of hardware that suddenly stops working is there any movement upstream to become better uh at testing I know it's one of the hugest problems because you need so much hardware but Keith probably will address this I see um my team at intel for the 212 release I've changed the process there so that our bug triage process within within the intel team is to focus on regressions and every other bug is a lower priority than a regression and I think the results in the 212 release were pretty positive in that regard I don't think we have any any node regressions in 212 from 211 now 211 I think 211 211 had a few regressions and rendering stuff and we were working on those um the other thing is that the kernel is where most of the difficult hardware manipulation and very hardware specific manipulation comes and if we're talking about releasing a 2633 based kernel stack that's that's a kernel stack that can't support current laptops yes um and it would be nice to know how we can release a version but apparently to to 635 still has problem with current laptops yeah well BDL's laptop is ancient um and so we should um there are there will be fixes in 2635.1 that should fix the current HP iron like laptops at least the the the intel HD graphics and those should be back portable to 2633 quite easily uh more importantly for the EP the EPC crowd is that the 2635 kernel release has a tiny little patch that keeps the 945 laptops from locking up especially the atom based atom based 945 yeah this one was back ported to the two seats kernel the one that was released last week the fix from Dave yeah cool okay good yeah i'm trying to follow some some of the more important fixes this is like a two line fix it's like yes the default mode for the 945 was that if the if the if the gmch had gone into a lower power mode it would just not do writes to memory it was like the you know hurt me harder bit except we didn't use the word hurt and it's like why would the hardware have a mode that was like just don't write to memory yeah and is it possible that this particular bag was also in the ums code before and that's oh yeah oh yeah we yeah this this never had this because we had many lockups in the 945 in Lenny and yeah for the last five years yeah yeah so i'm hoping that we'll make that go away um the X server 1.9 release is coming out in a week and a half um i don't have in bugzilla at this point ones that are marked as regressions because i'm not getting a lot of testing yeah um what i would like to see in experimental is instead of experimental drivers um and an experimental server that don't work together yeah um i would like to figure out a way where we can have either alternate repository or some mechanism where i can say i'm running debian and i want to test the current rc series so that i can make sure that the 1.9 release is going to work on my laptop yeah that would be quite useful because right now we have the choice of having uh so uploading new driver to experimental built against the unstable server which means people can test whether the driver is improving stuff for them or we can have it built again the experimental sex server which means they need to upgrade the whole stack and right um we don't really have yeah there is one new one experimental version so yeah do do we need a different do we need a different repository or do we just need to make it so that the experimental versions are only work with the experimental versions do you update everything all i think it would be useful to have multiple repositories to i mean to be able to to mix and match well the the trouble with making experimental being drivers against the new uh new drivers against the new servers that you can't test to see if the new driver that's going to go into squeeze is going to work yeah so how do i get how do i get people to test why 1.9 rc server in debian i think we need uh i mean at this point we need an external repository and somebody who builds the drivers and put them there so i could do something on free desktop or something that had that yes or on on aliot or okay wherever i should do that yes so i have one question for you who wants to be the new ex-maintenor for the next release cycle your uh actually not just last comment i completely support bidale stands on being aggressive in uploads for the major package we need to be more aggressive in uploads and following upstream i definitely support that i did that for sambar and i took a lot of risks for sambar sometimes even uploading packages without testing them but following upstream so that we can give the best feedback we can give to upstream we have like five or six branches in sambar just to be able to follow all upstream versions so we really should do that for the major packages and another comment i just upgraded my driver to uh whatever 212 or something in five minutes it's res suspends resume it's just working so please guys do that now now from experimental you can do that all your all your driver if you are intel or whatever driver do it and help the ex-maintenors to track this issue down and please upload to a stable maybe don't do it right now so we don't flood the network all right we have one one more one minute question um yeah um swookie here so um i was just gonna say i'm an average user i suspect there's a lot of people in my situation every so often i have something's wrong in x and i'd quite like to help but i haven't faintest idea how it works and i find it very hard to work out how it works and it all seems to change from last time i looked and there's all these you know x this and x the other and dr something and think i haven't and i always find it extremely difficult to work out fits together so i can say anything intelligent about which bit broke now res is not a very helpful comment because there's not much you you can do about that but i i i suspect this is a common problem in terms of trying to do anything useful i find myself lost every time i look and just kind of go i think that's related to the comment that i made earlier that we definitely need to have some sort of uh go to help page that can help people figure out where to go to look all right let's thank the speaker again