xorg-server 1.6 is now stable on amd64, other arches to follow soon

Turned out that xorg-server 1.6 is pretty much ready for stabilization, as only a handful of bugs were reported over the testing period since last week, and they only concerned the stabilization list.

Without further ado, I’ve asked our faithful Arch Teams (pretty much all of ’em) to stabilize xorg-server 1.6 and friends. amd64 was the first one to the finish line with a stabilization done in under a day!

Gentoo is again back in business for X. Woo!

Now to all stable users, don’t forget to read the upgrade guides we wrote :

Don’t forget, please file bugs in bugzilla.

Help neeeded to stabilize libxcb 1.4 and xorg-server 1.6

Here we go again. This time, we’re going for the double sweepstakes as we’re trying to stabilize both libxcb 1.4 and xorg-server 1.6!

For once, the server upgrade shouldn’t be too hard and the server upgrade guide is remarkably slim. There’s been no change in input, nor HAL, nor just about anything else for most users.

Only Intel users might have a few surprises with DRI2 and UXA. But at this point, they should be good surprises 🙂

However, the libxcb upgrade is going to cause more troubles for some users. If you are/were using x11-libs/libX11 with USE="xcb", then you might have to rebuild lots of packages. This is why we’ve taken such a long time to unmask and stabilize libxcb 1.4. But now, we’ve worked hard to write a proper libxcb upgrade guide, which users are definitely going to want to read.

I would say the libxcb guide is more important than the xorg-server upgrade guide.

Anyhow, right now, I calling out for help among our stable users. If you’ve always wanted to contribute to Gentoo but didn’t know how, here’s your chance.

  1. Grab the stabilization list from bug #282290
  2. Append it to your /etc/portage/package.keywords
  3. run : emerge -DuNa world like always to update

Again, don’t forget to read both upgrade guides before running the update, just so you don’t start panicking when portage is unable to continue the upgrade.

As always, you’re more than welcome to CC yourself in the stabilization tracker, but please DO NOT COMMENT IN THE TRACKER if you have issues, you’ll just annoy everyone there. Just file a new bug and we’ll look at it.

Don’t forget that most X maintainers lurk in #gentoo-desktop on FreeNode if you have any questions.

That’s all for today

Xorg 1.5.3 update

Xorg 1.5.3 is now officially stable on 4 of the major arches : amd64, ppc, ppc64 and x86. Props to for ppc/ppc64 for getting there first 😉

With this now done, I’ll slowly start cleaning up old ebuilds. X in Gentoo deserves not to be a big mess anymore.

What bothers me most is that alpha still doesn’t have xorg-server 1.5 keyworded at all. PCI on alpha is apparently more complicated than on other arches and they’re still waiting for proper libpciaccess support.

It’s a shame as I really wanted to get rid of 1.4.2 from portage, as it probably was one of the worst release in recent X history (management-wise).

Other than that, I’ll be AFK for about 2 weeks starting from next Saturday, so don’t expect much from me during this period.

Enjoy 🙂

Xorg 1.5.3 is going stable

Brace yourselves, Xorg 1.5.3 is going stable.

Arch Teams have the final package list and the upgrade guide is now online.

Now I guess I can sit back and watch how it all turns out. I hope things won’t be too bad on the driver front… Time will tell.

Thanks to all who tested the upgrade in the past few weeks, you guys really helped us out.

I think I’ll have a beer tonight to celebrate 🙂

Edit: Don’t report bugs in the comments of this blog, I will not look at them. Please file them in bugzilla.

Oh, and I was just too tired to have a beer… Sad…

Help needed to stabilize xorg-server 1.5.3 and friends

It has indeed been quite a while since I’ve written anything here, but I’ll try to keep it both short and focused. Longer rants on other topics should follow once I have some more time.

So what’s going on in the X/Gentoo land, you ask?

Well, we’re aiming to stabilize xorg-server 1.5.3 and a whole batch of other stuff Real Soon Now ™.

Why is this a big deal?

Because X is pretty much central when it comes to the desktop. While we can’t risk breaking it too often, we can’t afford staying with the current situation for stable users. Xorg 1.3 is old, unsupported, has unfixable bugs and it smells like that piece of meat in the back of your fridge.

But Xorg 1.5 doesn’t do {feature X} or support {hardware Y}!!!

I know, and it’s a tough call. We’ve been putting off the stabilization of newer Xorg servers precisely because of that. But now, we’re in a situation where newer versions fix more bugs and support more hardware. Yes, some people will be pissed off and I’m not exactly thrilled about pissing users off. But we have to move on.

Can’t you wait for Xorg 1.6 then?

No, because there are more users waiting for 1.5 than users who will benefit from 1.6. And by going to newer drivers now, we can help spot issues faster and get more bugs fixed for newer releases. With each new X release, the server handles less and less hardware details directly, leaving the kernel and X drivers do all the dirty work. Once we stabilize 1.5, going to 1.6 should be much easier than older upgrades.

Alright, you win, how can I help?

That’s the spirit! I strongly urge as many stable users as possible to try this because, Xorg 1.5.3 will go stable one way or another. The sooner you test it, the sooner you can adapt.

  1. Go to the stabilization bug,
  2. Fetch the stabilization list “x11.stable.list” and append it to /etc/portage/package.keywords
  3. run emerge -DuNav world
  4. Just to be safe, run emerge $(qlist -C -I x11-drivers/) -1av to rebuild your X drivers (portage may have updated things in the wrong order, better safe than sorry)

Once all this is done, you should have a brand new Xorg on your machine. Here’s a quick list of things you should look out for :

  • HAL support now actually works but may conflict with your xorg.conf, it can be easily solved though.
  • the Intel driver is no longer called i810, but intel. You’ll need to update your xorg.conf, otherwise X won’t start.
  • the open-source ATI driver xf86-video-ati now only supports Radeon chipsets. Rage Pro owners will have to use xf86-video-mach64 or xf86-video-r128 instead.
  • Please don’t comment on the stabilization bug if you have issues. Either come talk to us on #gentoo-desktop or file bugs in our trusty Bugzilla

Please help us move away from Xorg 1.3 and into the present with Xorg 1.5. We’ll take care of the future (aka 1.6) when this is done. 🙂

Cheers

Edit: added bullet on Radeon support
Edit 2: added –one-shot to the emerge command

Intel Drivers 1.x Announcement

Hum, 2 blog posts in a week, this is highly unusual for me 🙂

Anyhow, back to the point.

About a week ago, I added the old i810 drivers (1.6.5 and 1.7.4) to package.mask. Since then, a few people have opened bugs and have sent me emails asking me to take them out of p.mask. I guess I owe an explanation to all who care about Intel drivers.

The situation is quite simple :

  1. The old 1.x drivers are no longer maintained. Period. Upstream no longer cares about them and other distros (at least Fedora and Ubuntu) have started dropping the old drivers from their repositories.
  2. Most importantly, starting with xorg-server 1.5, only 2.4.0 and up build correctly. So all drivers older than 2.3.2 do not work with xorg-server 1.5. I hope I made this statement clear enough.

I know that changing drivers can be a big pain, but there are only 2 good reasons for sticking with 1.x, I’ll list them here because if you don’t care about either, then you should move to 2.x.

  • Old Xinerama support. XRandR is a very good extension but in some cases, the old driver was better. Especially with pre-915 chips where the framebuffer is limited to 2048 pixels in width.
  • Unsupported chips. This one is very uncommon. In fact, I would say Gilles (eva) is the only one that has an unsupported DAC chip on his 830 tablet.

The rest of you, please try 2.x as soon as possible. If you still have issues, here’s what you can do:

  • Remove all HorizSync and VertRefresh from your xorg.conf
  • Remove all “optimizations” from the Device section (such as forcing OffscreenPixmaps and what not)

If that still doesn’t work, please open a bug and we’ll try to sort it out.

Thanks

PS, I finally took care of the pkgmove. So please update VIDEO_CARDS in your make.conf to use “intel” instead of “i810”.

Update: s/xorg.conf/make.conf/ … thanks Donnie 🙂

It’s been too long…

*sigh* I should have written this post a long time ago, but I didn’t. My bad…

And just yesterday, Sune was rightfully complaining about the situation. Now it’s my turn to blog and to let you in on all the secrets I’ve been withholding 🙂

Quick xorg-server 1.5 Input How To:

If you’ve built xorg-server with the USE=hal, you might have weird issues with your synaptics touchpad or weird keyboard layouts.

There are currently 2 ways of configuring input in Xorg :

  1. Disabling HAL in Xorg: it basically tells Xorg not to look at HAL for input devices and it’ll only read your xorg.conf for configured devices. If you don’t want to muck around with HAL yet, it’s probably a good option. Just stick this piece in your xorg.conf and you’ll be fine.
    Section "ServerFlags"
        Option "AutoAddDevices" "false"
    EndSection
  2. Migrate to HAL: this is not exactly trivial and might require a lot of tweaking. But once you wrap your head around it, it’s not that complicated.

    The idea is to completely remove all the InputDevice sections from your xorg.conf (or even to completely remove your xorg.conf) and let Xorg request input devices from HAL. But we can modify HAL to return configuration values to Xorg.

    For some examples of this method, I suggest reading this sample file which contains almost all the needed documentation.

    Don’t forget to read /var/log/Xorg.0.log towards the end, that’s where input handling prints warnings and errors.

Intel graphics driver with xorg-server 1.5

For some reason, the server crashes if your xorg.conf file tries to load the i810 driver instead of the intel driver. This is indeed really weird as the former has been a symlink to the latter ever since 2.0.0 came out. I’m guessing the migration to libpciaccess broke some assumptions about driver names.

A lot of people have been bit by this, including me, but I of course do intend to properly fix this. First I need to do the pkgmove, and then I’ll just remove all references to “i810” from installed files (mostly the symlink to the driver and the duplicate man page). Finally, I’ll make the driver print out elog messages if you still have the old driver name in your xorg.conf

GEM

Although I first believed otherwise, a lot of users were actually using TTM with xorg 1.4. Since TTM has been dropped from Mesa and the supporting bits have been removed from the Intel driver, a lot of people are anxiously waiting for GEM support to arrive.

First the good news, I’m actually working on that. I’m tracking branches and building code.

The bad news… it doesn’t work, at least not yet. Intel developers are busy adding support for G4x chipsets and older ones such as my 855GM are not the immediate priority. I’ve asked for help on the various mailing lists but I’m still waiting. To be honest, I’m not even sure I’ve built the various components with the right configure options…

My plan is to wait a little bit for the kernel bits to settle (right now, devs are hacking up 5~10 patches per day for the 2.6.28-rc1 merge window!) before asking again.

Watch this space in the coming weeks if you are interested in Intel graphics on a Gentoo system near you 🙂

Cheers

Intel Drivers… again…

Just a quick post to let you all know that xf86-video-i810-2.4.2 has hit portage in ~arch.

Here’s my request : please test the hell out of it !! 🙂

It seems to be a good improvement over the original 2.4.0 release as it has less flicker, but it needs some serious testing. I think there are still cases where I can see flickering but the conditions seem to vary over time and I can’t reliably reproduce the issue.

So please test this new release as much as you can and let me know how it works for you. Bugs should be filed in Bugzilla and not in the comments 😉

As for the new 2.5 branch, it should hit ~arch with a big fat package.mask over the next couple of days.

Oh, and now I’m part of the X11 Team as I have to work with X stuff for my job, I might as well contribute some efforts there too.

Cheers!

Update : Please please file bugs if you still see flickering! Bugs won’t solve themselves! Thanks 🙂

Intel driver update

Hi all,

Just a quick update to let you know that I’ve just put x11-drivers/xf86-video-i810-2.4.1 to Portage.

Overall, I’m not very happy with this release. It’s definitely not as smooth as 2.3.2 which turned out to be very solid. So please test it out with a recent xorg-server (read, 1.4.2) and let me know in bugzilla if anything breaks.

Again, be prepared to continue the bug hunt in FreeDesktop’s bugzilla as my Intel Powers ™ are very limited. It just so happens that half a dozen Intel developers also roam there, so all in all, it’s a good place to file bugs. Just add “remi at gentoo dot org” as a CC on those bugs so I can keep track of the issues.

Thanks

Update :

Josh asked me a couple questions and the answers might interest all those of you who have Intel chips but don’t follow X development closely. So here goes :

My Thinkpad R61i has an Intel X3100 chip, so I’ll be sure to test out the new drivers. I am sorta scared by your blog post, but, well, as long as I quickpkg the relevant packages before upgrading, I should be okay, right? 😉

Yes, let’s get this straight, the driver won’t eat your laptop and won’t kill kittens either. A lot of the core features do work, but there are some instabilities and some quirky behaviors, and those are the issues I’m worried about.

I normally run the hardmasked/~arch X and Intel packages, with all their quirks, on that machine, so 2.4 shouldn’t all that different.

Yep, 2.4.1-r1 is in ~arch, so ~ users will probably already have it installed by now.

I wasn’t aware of the git overlay. Are there any fixes in upstream’s git that just didn’t make it into 2.4.1? If so, I may have to make the move to the overlay.

Donnie’s X11 overlay has live ebuilds for the “master” branch of all X packages. Beware that intel/master is very different from intel/xf86-video-intel-2.4-branch. I’m currently backporting patches from the latter into Portage as they will end up in the next release anyway. So there’s no need to create a live git ebuild for this particular branch.

As for the current git master, as you may have read on Phoronix and Planet FreeDesktop, the driver is going through major changes. Definitely not for the faint of heart.

Also, when’s the namechange to xf86-video-intel?

I plan to tackle this tiny issue when Donnie decides to put Xorg 7.4 (aka xorg-server-1.5) into portage.

Replying to Ryan’s post

https://bugzilla.mozilla.org/show_bug.cgi?id=384090#c41

And I’ll just quote that comment here:

Firefox-3 (now that the patch is applied) will behave like Gtk, i.e. it will read the font dpi from any standards-compliant XSETTINGS manager. If Gtk programs have the right font dpi on your system, then so will firefox.

As for the gconf key, it won’t help you unless you are also running gnome-settings-daemon (the default XSETTINGS manager for the Gnome desktop).

Let’s not spread unnecessary false information, shall we? 😉