In Ubuntu, X is one of the more critical pieces in the stack. As such, we get a TON of questions and bug reports about it, probably about 100 times as many as we have manpower to handle.

Canonical is hiring additional engineers to work on X which will help, but still there are many things that are outside the scope of what Canonical can do, so I feel it is really important to have a strong community involved in improving X in Ubuntu, particularly around getting all these massive amounts of bug reports answered, triaged, and (hopefully) solved.

However, it's tough to find people to work on X or to convince people that it is worthwhile for them to invest their time in it. How would you suggest going about encouraging people to get involved, who might not otherwise be thinking of working on X?

  • 3
    I would suggest making this a Community Wiki entry. Aug 10, 2010 at 0:08
  • Where can people wanting to start have an easy entry to help?
    – txwikinger
    Aug 10, 2010 at 0:12
  • At least you aren't asking how to get more people involved with XFree86 ;) Aug 10, 2010 at 3:23
  • 1
    We've got a bunch of docs at wiki.ubuntu.com/X to help people who want to help on X. Covers basic X issues, describes some of the X bug handling processes, and so on. It's a wiki so feel free to add to it, too.
    – Bryce
    Aug 11, 2010 at 20:12

5 Answers 5


The reason X doesn't get alot of work is that it requires an enormous amount of knowledge about how GPU's, memory etc.. work as well as familiarity with the X.org code base and to some extent kernel programming. It's not a trivial thing to get into and from a community perspective those who are interested in working on X or X drivers are probably already doing so. There is currently no motivation for a developer for developer to work on Xorg aside from personal interest.

The thing that the community has which X.org developers don't necessarily have, is access to a wide variety of hardware. Having people who are willing to spend the time to write 'good' bug reports and test drivers and parts of the Xorg stack before a release is probably going to help the engineers more than anything.

Currently there is an Xorg edgers repo which I use to test drivers on my stable system. It's pretty easy to roll back a single package after i'm done testing. However the only other way we can test is to either build X yourself or to install the edgers repository which builds from upstream. This does a wholesale X replacement as far as i can tell. This means it's an all or nothing approach to testing X.

Having a way to have 2 versions of X ( and fairly easily choose) which one you want to use would allow testers to not only test X , but subsequently get back to a working Xorg so they can submit the bug report.

  • 3
    Actually, what we need is not really more bug reports (we've got TONS), but rather people to go through all the reports that people have sent in to Ubuntu, sort the good from the bad, and help users where possible. We actually have fairly little trouble getting lots of people to test; many of them don't know how to write 'good' bug reports, but with some triaging work they can be improved (and forwarded upstream for further work). It's
    – Bryce
    Aug 11, 2010 at 20:22
  • 1
    Maybe we should do a bug hugging day for x-server?
    – txwikinger
    Aug 22, 2010 at 21:30

Speaking as a developer who is casually interested in X, here are my issues:

  1. I only have access to a handful of graphics cards and I suspect most people only have access to one. Thus I can't do much for the vast majority of bugs, which will always be on "some other card".

  2. Unlike most packages, I can't trivially create a test environment for a new driver version; virtual machines have their own X drivers.

  3. I can't easily update to the latest driver, test it out, then revert. This discourages experimentation (because if something goes wrong I might as well be bricked); it also hinders regression testing.

  4. Last time I looked, successfully applying a patch, compiling and running X was difficult to do, stepped all over the package manager, required kernel modules to be patched as well, and was pretty much an irreversible step.

  5. Nowadays, X drivers split their code between kernel, Mesa, udev (for settings and defaults), and userland drivers. Which means patches get split as well...

So I guess the answer is to make applying and reverting changes something that is handled by the package manager and easy to recover from when it breaks your system.

Also, a system like DKMS should be looked at for X drivers; if I could easily patch/compile/test/uninstall, say, the input driver for my touchscreen without having to rebuild the whole monolithic contraption (with its threat of making X completely unusable), you'd get more casual contribution and motivate me to look at triaging bugs and testing patches relating to that bit of hardware.

  • I think you're right that these are all issues that a potential volunteer might think as being reasons they couldn't work on X. However, there's a lot of stuff that doesn't require "opening the hood" that a person could do to help a lot - triaging bugs, answering user's questions, tracking down good patches worth including in Ubuntu. Stuff that doesn't really face these particular problems.
    – Bryce
    Aug 11, 2010 at 20:31
  • 1
    I'm more afraid of X than I am of the kernel. I can boot an older kernel easily.
    – maco
    Aug 21, 2010 at 16:29
  • 1
    I'm never afraid :o You can easily set up a dualboot environment where you can test kernel-patches as well as unstable Xorg servers. It doesn't even have to be that big since you don't need most of the GUI tools to do simple, and while compiling you can be in your normal environment and chroot in to the unstable system. Aug 23, 2010 at 20:09

Well like everything a lot of it is making it easy and accessible for people to find out about it. So from what I remember with bug triage originally there wasn't a lot of help coming from the community. Then when some wiki pages explaining the regular processes in triaging bugs and some bug days got a lot more community members involved. Also if you can start a regular activity for the community to do and offer help to those that try it you will get some interest.

If you need help with the activity you can email me and ill help with organizing it.

So my answer is making a wiki page with questions and commands for getting good bug triage info to get people involved in that.

For development its a big problem. Xorg and Kernel stuff require low level programming skills for most bug fixing and implementing features. So you have to target a specific group of programmers and get them interested. I dont have any suggestions here except ask around a bit and see who hangs out in #ubuntu-x and ask them if they can help.

  • Isn't it targeted to implement Wayland in the future? Would it then not be better to get people work on that?
    – Ingo
    Feb 15, 2011 at 19:26

To complement what jbowtie said, I would add that, as a bug triager, I find X bugs very challenging to deal with, simply because X is a very complex beast. This is reflected in the complexity of the troubleshooting wiki page. What would definitely help is a sort of mentorship program for BugSquad members to learn how to deal with X bugs better. Maybe do a bug hug day around it? Or a hands-on training session in #ubuntu-classroom?

  • A mentorship program is actually a really good idea. We've talked about some ideas around that, but the challenge so far has been finding people willing to give it a try.
    – Bryce
    Aug 25, 2010 at 7:03
  • I've done two bug hug days for X so far. Hardly anyone showed up to do triaging, and we did not gain any new members from it.
    – Bryce
    Aug 25, 2010 at 7:05

It's difficult to improve X.org when many users use proprietary drivers that replace portions of the graphics stack and then look to the X.org team when a kernel upgrade / X.org upgrade breaks their driver install.

A lot of the talk about "I don't have all the cards available" is also valid.

Graphics programming is fairly hard if you're not a good programmer. Debugging can be a real pain, especially if you can't see what's going on.

  • I agree with you about the pain of proprietary drivers from a developer perspective. But at the ubuntu distro level mostly we're interested in the packaging of the drivers, which is open source and could benefit from community involvement in improving it.
    – Bryce
    Aug 25, 2010 at 6:58
  • Having a variety of graphics cards seems like it should be important but in my experience so far, it's useful but not critical. What I find most useful is having 2 computers - one for your regular daily use that's kept stable, and a second one you can break X, debug, ssh into, etc.
    – Bryce
    Aug 25, 2010 at 7:01

Not the answer you're looking for? Browse other questions tagged .