Posts Tagged ‘x.org’
This year I’m suggesting we do the same, on Wednesday of OSCON week. Let me know in the comments or via email if you’re interested.
I’ll also be hosting a RedMonk beering, beginning Wednesday night around 9:30–10pm. Location TBD, watch the Twitters.
Update (2013/07/19): Beers will begin around 9:30pm Wednesday at Bailey’s Taproom (213 SW Broadway, which is downtown). The place is open till midnight and we’ll likely be there till then.
Google Summer of Code (GSoC) is an amazing program for college students that enables them to spend their summers working with open-source projects. Google chips in the money, and FOSS projects provide the mentorship and expertise. In the end, we benefit by gaining both new code and (more importantly) new developers.
I’m very excited this year because both Gentoo and X.Org were accepted for their 6th years in GSoC! Last year, Gentoo had 19 students working on diverse projects including webapps, package management, NetworkManager, the Dracut initrd framework, and more. X.Org, a more specialized project, had 5 students working on various aspects of open-source graphics.
If you’re a college student, I’d like to encourage you to apply for GSoC, whether it’s to Gentoo, X.Org, or another project altogether. It’s great real-world experience where you can prove your expertise to future employers (since the code is freely available), and you can become the world’s expert in your topic. The money doesn’t hurt, either.
To get more info, go to the Gentoo or X.Org GSoC homepages and check out the project ideas. If none of them strike your fancy, propose your own! We love original ideas, but please discuss them with us first to ensure they’ll be realistic and high-priority.
To compete with Remi’s post about getting xorg-server 1.5.3 stable in Gentoo, here’s one about getting xorg-server 1.6, which was released today, into testing in the main tree. We’ve been maintaining the 1.6 release candidates in the x11 overlay for a while now. Tonight I added the final release to the overlay. (Update for Google users) What’s new in 1.6, you ask?
- RandR 1.3: Panning, transforms (fixing projector keystones, etc.), primary outputs
- Xinput 1.5, including input device properties
- Predictable pointer acceleration
What’s left before it can move to the main tree? Here’s what I can think of, offhand:
- The new XRandR stuff needs to get released upstream (randrproto, libXrandr, xrandr). Right now we’ve got the xrandr userland tool depending on live git of libXrandr, which won’t work for the main tree. (Update: randrproto and libXrandr 1.3 are out, just waiting on the userland tool xrandr)
- We need to sort out the issue with XCB’s Xlib library renaming forcing recompiles of practically everything. This is becoming more and more of a blocker because now libXext 7.0.5 requires a new libX11. I think giving ourselves a hard blocker on 1.6 from this will help us get it fixed. See bug #248743 to track progress on this. (Update: solution in x11 overlay for testing)
- The server now has a fix to keep looking for HAL if it’s not running when started. Should we change /etc/init.d/xdm to compensate for this change by no longer depending on hald, thus allowing gdm/kdm/etc to start earlier? This will give us one of the steps taken by the fastboot work seen lately in Moblin and elsewhere.
- I think Remi’s going to add xf86-video-intel 2.6.2. (Update: done)
- Our xinit is crazy stale, mainly because we patch it like crazy and I don’t like porting those. I’d like to get it updated to a current release for 1.6. In the longer term, we need to merge distro-neutral parts of our work upstream, but that’s not a 1.6 blocker.
To sum up, you can try xorg-server 1.6 now by adding the x11 overlay with layman, or you can wait for the above issues to get solved, and it will show up soon in testing in your main tree.
Last night, Dave Airlie released libdrm 2.3.1, which set the stage for all the pieces of the X.Org 7.4 prereleases to actually work (with a couple mesa patches). If you’d like to test 7.4, here’s how. This assumes you’re already running an ~arch (testing) system–if you aren’t, you might want to hold off on testing hard-masked packages. This may not work with binary drivers–particularly ati-drivers. It looks like nvidia-drivers has preliminary support for xorg-server 1.5.
# xorg-server-1.5 prerelease
" >> /etc/portage/package.unmask
emerge -va xorg-server
emerge -va1 $(qlist -I x11-drivers)
I’ve still got 16 more packages to bump before everything’s up to date, but the main parts are in place.
Today I reworked the mesa and xorg-server ebuilds to do things the cool way with the latest git sources. Mesa added an autoconf build, thanks to Dan Nicholson, which makes the ebuild a lot simpler and less error-prone by being more standardized. There’s no XCB support yet–if nobody else adds it, I’ll probably do it eventually. It’s just autoconf, no automake, so the installation side of the ebuild stayed pretty complex. There’s a few strange things going on with what headers mesa installs that I haven’t looked into besides just deleting them.
Also, these updates incorporate the first major step to removing the extra copy of the mesa source code used to build xorg-server. The GLcore module is now built within mesa instead of xorg-server, thanks to George Sapountzis. This created a circular dependency between xorg-server and mesa, so I made a new ebuild called mesa-glcore. Unfortunately this means that libmesa.a still gets built twice. The other half of getting the mesa source out of the xorg-server build is libglx, and I’m hoping someone does it soon (hint, hint!).
This work is all available in the Gentoo x11 overlay, which you can add with the simple command `layman -a x11`.
Live-git packages for much of X.Org (the important parts, anyway) are now available in Gentoo’s x11 overlay, thanks to James Cloos. I hope you’re all very happy that he’s merged his work into the main project overlay–I know I am. Gentoo users can add this overlay by installing layman and running `layman -a x11`. All the live-git packages are in package.mask, so you’ll need to unmask them–portpeek is one easy way of doing this.
xorg-server-1.5 prereleases are also in there. So far that’s just 184.108.40.2061, but more should show up soon. They’ll remain in the x11 overlay until they build against packages that have actually been released, at which point they’ll move to package.mask in the main tree. Any xprint users, feel free to contribute patches to fix its build. I know Debian already has some patches for this, so that would be a good place to start.
I just committed xorg-server 220.127.116.11, which is a prerelease for 1.4.1. Here’s the Gentoo ChangeLog:
Bump to 1.4.1 release candidate. It’s gotta be an improvement over 1.4, so i’m letting it go into ~arch.
(#192221) ‘xorg-server-1.4 – keyboard LEDs do not work’ fixed upstream.
(#201047) ‘xorg-server 1.4 no longer loads xmodmap via xinitrc properly’ fixed upstream.
(#197104) ‘xorg-server-1.3 and 1.4 consumes 100% CPU, locking the keyboard, apparently triggered by opening an OpenOffice pulldown menu’ fixed with patch from master branch.
(#196019) ‘xorg-server creates unnecessary file /etc/X11/X11/Xsession.d/92xprint-xpserverlist’ fixed by not installing the same file twice to 2 different places (Andy Crook).
(#195886) ‘xorg-server-1.4.0-r2 built with hal USE flag crashes on shutdown if dbus service is not running’ fixed upstream.
(#195551) ‘xorg-server-1.4 fails to build w/kdrive on amd64′ fixed with Makefile.am patch designed for easier sed but unsuitable for upstream because the line gets too long (Michael Gorse).
(#194503) Don’t spit versions when showing drivers to rebuild via qlist, and also provide a command for people to do it themselves later.
The upstream X.Org change list is available here.