tag:blogger.com,1999:blog-45355287585909799332024-03-12T19:35:57.633-04:00Casually DefiantInadvertently PretentiousKristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-4535528758590979933.post-80311711680799140872011-01-03T15:29:00.003-05:002011-04-03T10:23:44.695-04:00Multiple backends for GTK+<p>I have to blog about this before <a href="http://blogs.gnome.org/kris/">the other Kristian</a> finds out and beats me to it. Kris <a href="http://blogs.gnome.org/kris/2010/12/29/gdk-3-0-on-mac-os-x/">wrote</a> about the new GDK backend work that Alex Larsson <a href="http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00099.html">started</a> and Benjamin Otte and Matthias Clasen finished. The backend work lets us compile several GDK backends into GTK+ at the same time. Over the holidays I was able to dust off my Wayland backend work for GTK+ and bring it up to date with all the cleanup that's been going on and make it work with the multi-backend stuff. With a little <a href="http://git.gnome.org/browse/gtk+/commit/?id=cacee7e7a380ac9009fc1339a860f563ebe4dc4d">patch</a> to the build system, it is now possible to actually build multiple backends, and <a href="http://git.gnome.org/browse/gtk+/log/?h=gdk-backend-wayland">adding a Wayland backend</a> on top of that lets us try out the new multi-backend functionality:</p>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://people.freedesktop.org/~krh/multi-backend-gtk.png" imageanchor="1" style="margin-left:1em; margin-right:1em"><img border="0" height="250" width="400" src="http://people.freedesktop.org/~krh/multi-backend-gtk-thumb.png" /></a></div>
<p>The screen shot shows the testgtk application running under X (that's the window with decorations) and under Wayland (using the X based compositor, sort of like Xnest but Wayland nested under X instead). The two testgtk windows come from the same application linking to the same GTK+ library. The only difference is that the Wayland instance was started with the GDK_BACKEND environment variable set to "wayland".</p>
<p>I moved my wayland backend branch to the upstream gtk+ git repository, but it's still very much a work in progress. In fact, I'm using testgtk in the screenshot above, because gtk-demo currently doesn't work in the Wayland backend. But like Kris mentions in his post, the cleanups that has landed in gtk+ recently makes it a lot easier to work with and port to other window systems. And Wayland itself is a lot easier to run these days, all the custom branches of mesa, libdrm etc and kernel patches that were necessary a year ago are now upstream. Fedora rawhide has all the packages required to build and run Wayland and Bryce Harrington maintains a <a href="https://launchpad.net/~xorg-edgers/+archive/wayland/">Wayland PPA</a> for Ubuntu (only maverick for now). Or you can <a href="http://wayland.freedesktop.org/building.html">build it yourself</a></p>
<p>And by the way, Wayland moved to freedesktop.org hosting recently: <a href="http://wayland.freedesktop.org/">wayland.freedesktop.org</a>. We now have <a href="http://wayland.freedesktop.org/">web pages</a>, a real <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">mailing list</a>, #wayland on irc.freenode.org and an official looking <a href="http://cgit.freedesktop.org/wayland">git repo</a>.Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com10tag:blogger.com,1999:blog-4535528758590979933.post-590552723454805682009-09-04T15:43:00.003-04:002011-04-21T17:18:22.524-04:00Thanks!<p>Emil got a pair of pirate pants from the GNOME Foundation! This was a "thank you" present for the GNOME git transition work, but the pleasure was all mine. I'm happy to see that the transition has been mostly a non-issue and that GNOME development continues with the same (or maybe even better) pace after this little infrastructure hiccup.</p><p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm3.static.flickr.com/2422/3887164967_6ac1ab7b34.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 500px; height: 333px;" src="http://farm3.static.flickr.com/2422/3887164967_6ac1ab7b34.jpg" border="0" alt="" /></a></p><p>Also in the gift bag was a hand imprint kit, but I had to make a left foot imprint, of course! Unfortunately the kit was a little hard to use, or maybe my craft skillz just aren't up to standard for this stuff.</p><p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm3.static.flickr.com/2450/3887283775_4159927aed.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 500px; height: 333px;" src="http://farm3.static.flickr.com/2450/3887283775_4159927aed.jpg" border="0" alt="" /></a></p><p>There's definitely a foot there though. The white imprint material was very fascinating - light weight and plasticy and it smelled very delicious - I had to resist the urge to bite into it.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com4tag:blogger.com,1999:blog-4535528758590979933.post-52802232853742386572009-07-16T10:42:00.001-04:002009-07-16T10:44:11.370-04:00Fuck the Foundries<p>I'm guessing a lot of people have seen this already, but I just love this rant and can read it over and over again: <a href="http://diveintomark.org/archives/2009/04/21/fuck-the-foundries">Fuck the Foundries</a>. Indeed.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com5tag:blogger.com,1999:blog-4535528758590979933.post-42568700954097089902009-07-08T14:14:00.004-04:002009-07-08T14:59:51.633-04:00The Eagle EGL loader<p>I happen to have a small side project <a href="http://cgit.freedesktop.org/~krh/eagle">over here</a> that's a non-conformant, itty-bitty EGL loader for the DRI drivers. Eagle started as a test case for the <a href="http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/internal/dri_interface.h">dri driver interface</a> changes I was doing for DRI2. Before the interface changes, the driver interface was GLX specific and I wanted to remove all X/GLX dependencies from the driver and make it easy to load the dri driver in an EGL framework. So eagle started as a simple loader for the driver to verify the interface changes. At some point I realized that it was pretty close to working and finished up the remaining pieces. It's still lacking a proper EGLConfig picker, but it's fairly capable and sufficient for Wayland.</p><p>Now, there's also a mesa EGL loader. The mesa code is very generic and supports EGL on GLX, EGL on gallium, EGL on swrast, whereas Eagle is strictly written to just support the new DRI driver interface. That means Eagle is very minimal, while mesa egl has some overhead (more indirection, more .so's to dlopen). The mesa EGL code doesn't have support for the new (DRI2) dri driver interface, so it only works for gallium capable drivers, specifically, it won't work for the Intel DRI driver.</p><p>Merging the Eagle code into the mesa EGL code, has a good number of benefits: the mesa code will learn how to load DRI2 drivers, I won't have to write an fbconfig chooser, and there'll be only one EGL for mesa. So there's a lot of appeal there. The downside, and the main reason I'm still keeping Eagle a separate project is that I want to experiment with the glue code API between EGL and GEM/DRM. The way you create an EGLDisplay or an EGLSurface you have to first somehow create an instance of an EGLNativeDisplayType or EGLNativeWindowType, EGLNativePixmapType and then pass that to an EGL constructor such as eglCreateWindowSurface(). I'm not a diplomat, so let me just say it as it is: that's fricking braindead! See, if you have to go outside the generic EGL API to create an EGLNativePixmapType, why can't we just skip the middle man and create the EGLSurface straight from the implementation specific code. That way we wouldn't have to pollute the EGL API with strange, useless "native" types and we wouldn't need and window and a pixmap constructor for EGL surfaces.</p><p>Anyway, the native type fiasco is just a wart in the API that I like obsessing over. There's nothing that prevents an EGL implementation, such as Eagle, from implementing it's own non-standard entry points to create an EGLSurface straight from a GEM buffer handle, for example. Or non-standard API to get at the GEM handle for the back buffer so that we can use the KMS page flipping API. Which is what Eagle does and it's the main reason that it still exists. Eagle is currently a playground where I can try out different types of constructors and extensions for integrating EGL with GEM and KMS. Once we get the KMS page flipping ioctl worked out, I'm planning to write a Eagle+KMS backend for clutter, so clutter apps can run straight on the KMS framebuffer. Next step from there would be a clutter based Wayland compositor... oh wait, isn't that what Moblin should be?</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com4tag:blogger.com,1999:blog-4535528758590979933.post-41506920535286124512009-06-28T13:36:00.002-04:002009-06-28T13:42:08.752-04:00Out of the Office<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiO2zZsVyAZVdp9q0fmRwYGyaDVp2W4flF5D2pyqMd-QDPGxKcxwAHjMGYq8iZBPZV6spbzE_ZviDYOscvqlwnvEFhl8QvK_7WY9WlClucKqkWCll3EdddQt2aKW_zEzTf53RI0gf2cEN9F/s1600-h/emil.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 213px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiO2zZsVyAZVdp9q0fmRwYGyaDVp2W4flF5D2pyqMd-QDPGxKcxwAHjMGYq8iZBPZV6spbzE_ZviDYOscvqlwnvEFhl8QvK_7WY9WlClucKqkWCll3EdddQt2aKW_zEzTf53RI0gf2cEN9F/s320/emil.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5352434105212683074" /></a></p><p>I have a son! Emil Au Kristensen, born June 25th, 8lbs 12oz, 22 inches.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com11tag:blogger.com,1999:blog-4535528758590979933.post-55458071240828881012009-04-23T23:51:00.002-04:002009-04-24T00:05:33.213-04:00Git day plus a week<p>Woo, the GNOME git migration is complete. We got the bulk of the repos converted Thu-Fri last week, but it took a little longer than estimated because of an update to the the commit message rewriting step. The remaining days have been spent trying to fix and reimport the repos that were broken during the import. I sent out <a href="http://mail.gnome.org/archives/gnome-infrastructure/2009-April/msg00165.html">this status</a> a couple of days ago, and just now I copied the last fixed repo in place on git.gnome.org.</p><p>I'm looking forward to closing the door on this and to contribute to GNOME through git. And now that I have the scars to prove it, let me just end by saying: friends don't let friends use svn.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com5tag:blogger.com,1999:blog-4535528758590979933.post-19218385332237145442009-04-15T15:33:00.003-04:002009-04-15T17:38:23.324-04:00Git day minus 1<p>Tomorrow, Thursday April 16th, is the big flag day for the GNOME repositories. We've moved over quite a few repositories from SVN, GitHub, freedesktop.org and other places that people have put GNOME git repositories, but tomorrow we finish the migration and move over everything else. We've timed it so that the 2.26.1 release could be finished first, and since that just happened, now is the time to push the big button. Thanks to a lot of sysadmin legwork from Owen, the GNOME git infrastructure is looking great: we have cgit set up on <a href="http://git.gnome.org">git.gnome.org</a> and the various commit hooks and mailing lists scripts have been setup and tuned.</p><p>What will happen tomorrow is that all SVN repositories will be marked readonly in the morning, around 10am EST, and then we'll start the migration. The git repositories will show up as they're converted and will be ready to clone and push to. We've done a few test runs on all the GNOME repos and I expect the conversion process to take most of the day.</p><p>Part of the migration project has been to update the documentation and there's a <a href="http://live.gnome.org/GitMigration/Git">introduction document</a> in place for developers and a <a href="http://live.gnome.org/GitMigration/Translators">guide for translators</a> as well. There's room for improvement still, but in the meantime a lot of GNOME contributers are already familiar with git and can help out on irc etc.</p><p>See you on the other side!</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com1tag:blogger.com,1999:blog-4535528758590979933.post-61318482723586188992008-12-10T17:49:00.004-05:002009-04-28T09:17:36.154-04:00Two X servers and a microphone<p>Oh, ok, so getting X.org running under Wayland was easier than expected. Or I guess, it was as easy as expected, which is usually never the case.</p>
<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl9yrvWAWW4EH84TOMxXzVjf6u_eZl0N3jSBDY64PBjPQ_991nzyPvbRpTm9dnFJCGvprF_J_Z0Cy9WjE6LNUmg0MdrkIc6j-VGxyFU-JpuuomADOrVe2nLTinTNkK4v9gpp3yYquYnGOz/s1600-h/two-xservers-and-a-microphone.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl9yrvWAWW4EH84TOMxXzVjf6u_eZl0N3jSBDY64PBjPQ_991nzyPvbRpTm9dnFJCGvprF_J_Z0Cy9WjE6LNUmg0MdrkIc6j-VGxyFU-JpuuomADOrVe2nLTinTNkK4v9gpp3yYquYnGOz/s320/two-xservers-and-a-microphone.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5278300010166595954" /></a>
<p>What's running here are two X.org servers, side by side under Wayland. It's not Xnest or Xephyr, it's the full X server with DRI2, GLX, Xv and UXA acceleration. The only difference is that the server passes its front buffer handle to Wayland instead of passing it to kernel modesetting and it receives input events from Wayland instead of evdev. And Whenever the Intel DDX driver flushes its batchbuffer it now also sends a damage event to Wayland.</p><p>There's some weird transparency going on, and the reason is that the X servers window pixmap doesn't have a well-defined alpha channel. Which doesn't matter when the hardware is scanning it out to a display, but in this setup it causes some unintended transparency.</p><p>The Wayland server transforms the input events to the surface coordinate system of the client surfaces, which means that the X servers are fully functional, and you can click the icons and move the tiny windows around. It's all very cute. Keyboard input isn't working yet, but it shouldn't be too hard, since I think can get away with just passing the scan codes to the X server.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com17tag:blogger.com,1999:blog-4535528758590979933.post-91638668360290529512008-12-08T14:56:00.007-05:002009-04-28T09:23:35.978-04:00Wayland gets a terminal<p>Still hacking on the Wayland project. I've spent some time getting the repaint loop and repaint notifications right, which is surprisingly tricky if you want to sync to vblank and make sure every client gets a chance to paint every frame. But I think I got it right and it looks beautiful when everything is synced to vblank and animating every frame. I've started looking into getting a fullscreen X server running under Wayland, which should be a matter of just passing the front buffer handle to Wayland instead of setting the mode. So far though, it's only crashing or locking up, so I wrote a terminal for Wayland as a small diversion</p>
<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlf5MeGZuatKvVYtlKZEk6BftJjG5J6RgvV4Quyi5dv84XVMQfJidYv0komxliMj3dED4NjU2wWiFBH0G6sFcVbDAPzv1pPMNWdKd3DJQWCxcGo9ovMuphTqq2T0CYflzfjXKIwUYJ71tT/s1600-h/wayland-dec-8.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlf5MeGZuatKvVYtlKZEk6BftJjG5J6RgvV4Quyi5dv84XVMQfJidYv0komxliMj3dED4NjU2wWiFBH0G6sFcVbDAPzv1pPMNWdKd3DJQWCxcGo9ovMuphTqq2T0CYflzfjXKIwUYJ71tT/s320/wayland-dec-8.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5277512849602298978" /></a>
<p>This is not a long term solution though, it has very limited ANSI support and I don't expect to extend it much (maybe enough to run emacs and irssi). The plan is to add a Wayland backend to GTK+, which should be a lot easier when Alex's <a href="http://live.gnome.org/GTK%2B/ClientSideWindows">client-side window work</a> lands, and then just use VTE. For now, this goes a long way and the resizing is smooooth...</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com6tag:blogger.com,1999:blog-4535528758590979933.post-81086899175820293462008-12-04T15:45:00.002-05:002008-12-04T15:48:40.650-05:00Git is better than X<p>I found this link over on the <a href="http://github.com/blog">github.com</a> blog:</p>
<blockquote><a href="http://whygitisbetterthanx.com/">http://whygitisbetterthanx.com/</a></blockquote>
<p>Of course, git is awesome and doesn't need selling, but if it did, that page does a pretty good job at it.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com5tag:blogger.com,1999:blog-4535528758590979933.post-50028954028751439652008-11-03T19:54:00.004-05:002009-04-28T09:22:02.750-04:00Premature publicity is better than no publicity<p>I guess. Maybe. At any rate, my latest secret project, is no longer secret: Phoronix ran <a href="http://www.phoronix.com/vr.php?view=13065">an article</a> about <a href="http://cgit.freedesktop.org/~krh/wayland/">Wayland</a> and slashdot in turn <a href="http://linux.slashdot.org/linux/08/11/03/2217216.shtml">picked it up</a>. They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.</p><p>The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the <a href="http://cgit.freedesktop.org/~krh/wayland/tree/NOTES">NOTES file</a> of the project.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com11tag:blogger.com,1999:blog-4535528758590979933.post-19446275918690272462008-07-06T19:43:00.002-04:002008-07-06T19:52:43.106-04:00UghOk, I went through my old post and deleted blog spam and closing old post for comments and now all these posts appear brand new. Sorry about the noise.Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com2tag:blogger.com,1999:blog-4535528758590979933.post-6657386372766303532008-03-31T21:43:00.009-04:002008-07-06T19:35:42.442-04:00DRI2 Direct Rendering<p>I just committed the last bit of DRI2 work for now to the xserver, mesa and xf86-video-intel repos. This work enables direct rendering to redirected windows:</p>
<a href="http://people.freedesktop.org/~krh/bunny-on-a-cube.png"><img src="http://people.freedesktop.org/~krh/small-bunny-on-a-cube.png" style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" border="0"/></a><p>So what's going on in this screenshot? Totem is playing the trailer from the new blender open movie project, <a href="http://www.bigbuckbunny.org">Big Buck Bunny</a>. While this looks to be a great follow-up to their previous movie, <a href="http://www.elephantsdream.org/">Elephants Dream</a>, the interesting thing here is that it's playing using textured video under the batchbuffer branch of the intel driver, backed by the kernel video memory manager (TTM). Traditionally the X video extension (Xv) has been implemented by an overlay mechanism that lets the driver configure the hardware to scan out the pixels in the video area from a different buffer, doing color conversion and scaling on the fly. In other words, as the hardware scans through video memory to send the pixels to the monitor, it flips to read from a different buffer as it enters the window that shows the video. It's a fairly simple mechanism and it's cheap to implement in hardware, but it doesn't work for redirected windows. Textured video uses the 3D hardware to do scaling and color conversion, and since that is just regular 3D rendering, it can be redirected just fine, as seen in the screenshot. The textured video work was done by Eric Anholt and it's been in the intel driver for a while now - what's new here is that it runs under DRI2.</p><p>Also in this screenshot we have good old <a href="http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark">glxgears</a> and MacSlows cool <a href="http://cgit.freedesktop.org/~macslow/rgba-glx/">RGBA GLX demo</a>. Both of these GLX applications are doing direct rendering to redirected windows. The main motivation behind the DRI2 work was to get redirected, accelerated rendering working. The first step got AIGLX (indirect rendering) working, and with this last bit, direct rendering now also works. The RGBA demo further demonstrates that we can now create a window with an RGBA visual and render to it from OpenGL and the compositing manager (in this case compiz) will composite it and blend it correctly with the rest of the desktop contents.</p><p>With Xv and Open GL finally working under composite, the intel driver is in pretty good shape. We're getting closer to a point where we can ship with a compositing manager enabled by default. In Fedora 9, we're shipping all this as a technology preview kind-of thing. DRI2 still has a number of crashers that I'm chasing and it's very new code. There will be an xorg.conf option or similar that will enable the batchbuffer branch of the intel driver and the DRI2 infrastructure. Hopefully by the time Fedora 10 comes out, it will be on by default.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com23tag:blogger.com,1999:blog-4535528758590979933.post-5946726211688463412008-02-11T15:53:00.001-05:002008-07-06T19:35:08.031-04:00Building and installing the DRM/DRI/X stack<p>When I work on the X stack I typically compile and install all the packages into an install prefix in my home directory, typically <code>$HOME/install</code>. That way I can keep my system packages intact and even have multiple versions or branches of the stack installed. This recently got a lot easier with the autoconfiscation of mesa so I decided to write up a short tutorial on how to do this. I like to first uninstall my distributions development packages for the projects involved just to make sure the configure scripts don't pick up a wrong version. For Fedora this is something like<blockquote><code>rpm -e libdrm-devel xorg-x11-server-devel</code></blockquote>In previous Fedora releases, the xorg-x11-server-devel package was called xorg-x11-server-sdk.</p><p>To bring up an X server with DRI, we'll need to clone the drm, mesa, xserver, xf86-input-evdev and a video driver repository. By default, git will check out the master branch when you clone, but if you want to try a different branch of a repository you have to say</p><blockquote><code>git checkout -b intel-batchbuffer origin/intel-batchbuffer</code></blockquote><p>after cloning to check out the intel-batchbuffer branch</p><p>First step is building drm</p><blockquote><code>git clone git://git.freedesktop.org/git/mesa/drm<br>cd drm<br>./autogen.sh --prefix=$HOME/install<br>make<br>make -C linux-core<br>make install</code></blockquote><p>The <code>make -C linux-core</code> step will build the DRM modules for the current kernel and needs the kernel-devel package on Fedora.</p><p>For the rest of the builds, we'll need this environment variable set:</p><blockquote><code>export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig</code></blockquote><p>Now that we have libdrm built and installed we can build mesa. Mesa doesn't use automake and doesn't come with an <code>autogen.sh</code> script so we have to bootstrap it a little differently:</p><blockquote><code>git clone git://git.freedesktop.org/git/mesa/mesa<br>cd mesa<br>aclocal<br>autoconf<br>./configure --prefix=$HOME/install --with-driver=dri --with-dri-driverdir=$HOME/install/lib/dri<br>make<br>make install</code></blockquote><p>Optionally, pass <code>--disable-glu</code> <code>--disable-glw</code> to the configure script to cut down build time a bit if you don't need these libraries (who does?).</p><p>Now we can build the X server. The configure script doesn't pick a good default for the font path, and the X server is going to bitch about this when we try to start it. I find that it's easiest just to built in the couple of core fonts the X server needs:</p><blockquote><code>git clone git://git.freedesktop.org/git/xorg/xserver<br>cd xserver<br>./autogen.sh --enable-builtin-fonts --prefix=$HOME/install --with-mesa-source=$HOME/src/mesa<br>make<br>make install</code></blockquote><p>With the X server installed in the prefix, we can start building drivers. The X server installs a couple of autoconf macros that aclocal needs to be pointed to, so for building drivers we need to set the ACLOCAL variable to:
<blockquote><code>export ACLOCAL="aclocal -I$HOME/install/share/aclocal"</code></blockquote>Having set this, building the intel and evdev drivers is easy:</p><blockquote><code>git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel<br>cd xf86-video-intel<br>./autogen.sh --prefix=$HOME/install<br>make<br>make install</code></blockquote></p>To run the new server I usually just cd to <code>$HOME/src/xserver/hw/xfree86</code> as root and run the Xorg binary there, but first load the DRM modules we compiled above. You typically need to unload the old versions first and then load the ones you compiled (assuming intel hardware):</p><blockquote><code>rmmod i915<br>rmmod drm<br>insmod $HOME/src/drm/linux-core/drm.ko<br>insmod $HOME/src/drm/linux-core/i915.ko</code></blockquote><p>Second, remember to set<blockquote><code>export LD_LIBRARY_PATH=$HOME/install/lib</code></blockquote>after changing to root so the X server picks up the right <code>libdrm</code>. The X server will use the system <code>xorg.conf</code> from <code>/etc/X11</code> by default, but that can be changed by passing an option to the X server configure script or passing the <code>-config</code> option to the server.</p><p>To actually launch applications under the server I typically just use a lame hack such as</p><blockquote><code>./Xorg && gnome-terminal --display=:0</code></blockquote><p>or more often I just run the X server and applications from a remote login. Before running direct rendering OpenGL applications, you need to the path to the DRI drivers:</p><blockquote><code>export LIBGL_DRIVERS_PATH=$HOME/install/lib/dri</code></blockquote><p>and voila, you can now run OpenGL applications on your very own, hand-built X/DRI/DRM stack. It's not terribly useful for daily use, but I find that it's the best set up for developing and tracking upstream development.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com7tag:blogger.com,1999:blog-4535528758590979933.post-25030066483641056792008-01-08T17:57:00.003-05:002008-07-06T19:34:53.391-04:00Awesome prize of the day...goes to Dan Nicholson for adding autoconf support to mesa. For the first time, mesa can now pick up libdrm from a non-standard location (say, ~krh/install/lib/libdrm.so) automatically through pkg-config. With that, it's possible to build the entire X/DRI/OpenGL stack in a non-standard prefix, so you can work on the stack, without having to overwrite system libraries. And it's a simple and clean solution that can co-exist with the old hand-rolled config system. Good work!Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com3tag:blogger.com,1999:blog-4535528758590979933.post-27143639374146617792007-11-28T17:24:00.001-05:002008-07-06T19:34:17.854-04:00New version of cgit<p>Lars Hjemli recently released a new version of <a href="http://hjemli.net/git/cgit/">cgit</a>, the unbelievably fast web front-end for git. I just updated the cgit installation on <a href="http://cgit.freedesktop.org">cgit.freedesktop.org</a> and the end result is pretty nice. It still has good looking, easy to type URLs such as</p><blockquote><a href="http://cgit.freedesktop.org/xorg/xserver">http://cgit.freedesktop.org/xorg/xserver</a></blockquote> <p>and a cool new feature is the ability to only show the 10 most recently active branches and tags in the summary page. The X server has over 50 old branches sitting around from the CVS import and they're typically not interesting. Also new is the sidebar, which has a very useful drop-down box for switching between branches, and the fast and useful search field.Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com2tag:blogger.com,1999:blog-4535528758590979933.post-78071189427613026382007-10-18T19:19:00.001-04:002008-07-06T19:33:32.536-04:00I'm in ur X server adding visuals!<p>Maybe you've wondered why, when you run xdpyinfo, the X server reports a bunch of identical looking visuals. And in fact, for all xdpyinfo and X cares, they <em>are</em> identical. However, to GLX, the visuals are all different and they give you different features when you use them with OpenGL. Some specify a double buffer, some have a stencil buffer, and some have buffers I don't really know anything about. glxinfo is a good way to find out. In GLX version 1.3 and up, a new mechanism for specifying the configuration of the OpenGL drawable is introduced. Using a so called <em>GLXFBConfig</em>, you can specify, more or less orthogonal to the visual you're using, the OpenGL properties of your drawable.</p><p>What I've been working on recently is to clean up the way visuals are initialized and handled in the X server and to disentangle GLX visuals and GLXFBConfigs. There's a lot of nice code clean-up landing and the X server now has a lot less visuals by default. There's a new xorg.conf option that lets you pull in all the visuals or a minimal set if you want. The git version of glxinfo (found in mesa in progs/xdemos) will list GLX visuals and GLXFBConfigs separately now so you can see how the X server sets it up. It's bound to break something, but we'll fix it.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com1tag:blogger.com,1999:blog-4535528758590979933.post-40093443753604726022007-08-19T22:47:00.002-04:002008-07-06T19:33:02.431-04:00Git survey<p>The git developers are doing a git survey again, follow <a href="http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9">this link</a> to take it.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com1tag:blogger.com,1999:blog-4535528758590979933.post-15314319235858994092007-08-16T12:59:00.001-04:002008-07-06T19:32:41.775-04:00Compiz and Fedora<p>There was a <a href="https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00559.html">big discussion</a> about enabling compiz by default in Fedora on <a href="http://www.redhat.com/mailman/listinfo/fedora-devel-list">fedora-devel</a> list a couple of days ago. Reading through the thread I realized that we never really communicated our plans here very well. I sent out the writeup below to explain a bit where we're going with Fedora and what the road blocks are, but I figured it wouldn't harm to also blog it.</p><h4>We are working towards being able to enable a compositor by default.</h4><p>Redirected direct rendering, Xv, Java problems, these are problems in the drivers and X server and affects all compositors. To get this done, we need to land a big chunk of code in the kernel (the DRM memory manager), we need to update the X server, the 2D drivers and the 3D drivers to take advantage of the new memory manager. We need to fix Xv. Hopefully the OpenGL support will broaden to support more chipsets (nouveau, avivo). Getting all this to a shippable state may take years, and in the mean time, the composited desktop, whether it's compiz, kwin4 or something else will only be an opt-in tech demo.</p><h4>Once we get there, the default compositor will be compiz.</h4><p>Some people can't get over on the wobbly windows and spinning cube, and claim it's over the top or apparently get nauseous. At the core, compiz is just a very efficient OpenGL redraw loop with a flexible plugin architecture. Compiz allows burning windows and spinning cubes, but we ship it in a very toned down default configuration that looks a lot like good old metacity. Consider xeyes; like wobbly windows, it's a neat tech demo and shows off the flexibility of X, but just because nobody runs xeyes for more that 2 minutes at a time that doesn't mean that X (or shaped windows) isn't useful.</p><p>A valid point about compiz is that it is not yet a great window manager. Metacity has a few years of head start there, but that doesn't mean that we can't fix compiz or that it'll be duplicated effort. For now, our (Red Hat) efforts have gone towards fixing the big underlying shortcomings in the X and OpenGL stack, which has left compiz in Fedora with a set of minor (but certainly annoying) windows manager bugs. Other spins (Fedora KDE or Fedora XFCE) can set up different default compositing managers, and they will of course benefit from the infrastructure work mentioned above.</p><h4>We're not working on making metacity a compositing manager.</h4><p>We tried it and decided that the metacity code base was not a welcoming place for a compositor. When we put down the work in metacity, the conclusion was to leave this very stable and well tested code base alone instead of injecting an OpenGL based compositor. The flip side of this decision is that we can now do a clean break in compiz and assume throughout the code that we're an OpenGL based combined compositing and window manager.</p><h4>Compiz fusion and configuration tools.</h4><p>desktop-effects is close to what we want to ship by default, perhaps we want to fold it into the new gnome-appearance-properties capplet as a new tab. The default compiz configuration and the set of options we expose outside gconf-editor is intended to be very conservative. At the same time, we want to allow installation of other compiz configuration managers and the compiz fusion plugins for people who like the tweak-ui kind-of tools.</p><h4>Power consumption and other hand-wavey fud arguments.</h4><p>Clearly running a 3D screen saver at the full frame rate is going to burn more battery than the blank screen saver, but that's not really relevant here. When idling, compiz and metacity use exactly the same amount of power. There are no code paths anywhere in the stack that "turn on 3d powerplanes". My bet is that it's more power consuming to wake up all applications to redraw their exposed areas under the window you're dragging than it is for compiz to just recomposite that out of textures already in video memory.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com7tag:blogger.com,1999:blog-4535528758590979933.post-61650089916682419772007-08-08T11:36:00.000-04:002007-10-30T10:20:21.503-04:00Redirected direct rendering<p>Also known as AWESOME. Normally, when an application renders to an X window, the contents appear in the framebuffer immediately. The COMPOSITE extensions lets an application, typically the compositing manager, redirect that rendering to an offscreen pixmap. The compositing manager is then responsible for compositing the window contents into the framebuffer, for example by mapping it onto a cube or a wobbly window. All regular X rendering respect this redirection, since the rendering requests go to the X server, which can then target it to whichever pixmap it wants.</p><p>However, the default rendering mode for accelerated OpenGL, <em>direct rendering</em>, is a little different. With direct rendering, the application goes through an initial setup sequence with the X server, to acquire the address of the framebuffer and the shared back and depth buffers. After this step, the application renders by programming the GPU directly to render into those buffers. This, of course, is a feature - direct rendering acheives a siginificant performance boost over having to send every request to the X server. However, the direct rendering application isn't aware that a window
might have been redirected and renders to the framebuffer regardless. This is typically not what you want:</p><center><a href="http://people.freedesktop.org/~krh/do-not-want.png"><img style="margin:0px auto 10px; text-align:center;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhR4_ojw4Cm7A1oNeqUf_adeSnALJVm5u4loFn5KHPekYpKzppXaW6cNUB7uhYJOkwVay6uFhBQ8Y5F4B3ZhnKb3LZ6FJu6MWSZd85HULe0M4jVlzotUzb509n8KouyMLcv2UcF0GWoq9MF/s320/do-not-want-small.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5096355087357918882" /></a><br><em><small>DO NOT WANT</small></em></center><p>To me, this is one of the biggest problems in our rendering stack. I'm convinced that the composited desktop has to be a standard feature of the future Linux desktop: Whether or not you want spinning cubes and wobbly windows, there is no denying the benefits of flickerless redraws and ARGB visuals. Unfortunately, with a bug like this, we can't really enable it by default. Especially when interest in OpenGL backed toolkits (<a href="http://clutter-project.org/">clutter</a> and <a href="https://core.fluendo.com/pigment/trac">pigment</a>) is starting to pick up.</p><p>What you want, is to let the OpenGL driver know when a window is redirected and make it target its rendering to the offscreen pixmap. Conceptually, it's easy enough and we've known <a href="http://dri.freedesktop.org/wiki/DirectRenderingToRedirectedWindows">how to do it</a> for a while, but there's a lot of details to get right. One of the big pieces of the puzzle fell in place with Tungstens Graphics' DRM memory manager (TTM). Dave Airlie and I added TTM support to EXA and the intel DDX driver, and from there I was able to make the DRI driver render into the TTM buffers allocated by EXA. And given that the Pixmaps for the redirected windows are now backed by TTM buffer objects, we can add a zero-copy texture from pixmap implementation to the mix:</p><center><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhodusOnPUH7GgqRh04SuAfx8w2xWZ2xINUqOsUJ1nimacD9uSxL7jQfeiAx-qZI88P_vwkIsgbfXYOVr9DaEqHNmq7DvQJcHdMdsyZTD0p8BBMO4gVQV89LgcZGW5ury6iXK8C5gGT8ERD/s1600-h/delicious.png"><img style="margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhodusOnPUH7GgqRh04SuAfx8w2xWZ2xINUqOsUJ1nimacD9uSxL7jQfeiAx-qZI88P_vwkIsgbfXYOVr9DaEqHNmq7DvQJcHdMdsyZTD0p8BBMO4gVQV89LgcZGW5ury6iXK8C5gGT8ERD/s320/delicious.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5096379822074576562" /></a><br><em><small>DELICIOUS</small></em></center><p>If you want to try it out, I have the code in the exa-ttm branch in my personal drm, xserver, mesa and xf86-video-intel repositories on freedesktop.org. It's not at all easy to set up and the current implementation is only a prototype. It will be a while before this stuff can get upstream; we need to discuss how we want the interfaces between DRI/DDX/DRM/EXA to look etc, but hopefully we can figure that out at <a href="http://www.x.org/wiki/Events/XDS2007">XDS</a>.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com14tag:blogger.com,1999:blog-4535528758590979933.post-13064781215569633592007-06-26T14:30:00.001-04:002008-07-06T19:31:59.311-04:00Death to xfs<p>That's xfs the <a href="http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-x-fonts.html">X font server</a>, I have no beef with the xfs filesystem. We've been using xfs for core fonts[1] since Red Hat 6, mainly because we've had the <a href="http://linux.about.com/library/cmd/blcmdl8_chkfontpath.htm">chkfontpath</a> tool for editing the xfs config file and restarting xfs. This tool lets us add and remove new font directories to the xfs config file and restarts xfs when necessary, so that a running X server will pick up new fonts as new font packages are installed.</p><p>While all that is nice, it's a pretty weak reason for running an system daemon, considering the maintenance overhead, security problems and boot time slowdown. So to get the best of both worlds, I wrote a <a href="http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=c5ab59762c4ad5def68436d55937a2bd558d5c99">patch</a> to <a href="http://cgit.freedesktop.org/xorg/lib/libXfont">libXfont</a> (which is what xfs and the X server uses for locating and rendering fonts) to let it pick up fonts paths in a rc.d style way. Instead of relying on a config file for the font path, you can now additionally redirect to a directory of symlinks, such as <code>/etc/X11/fontpath.d</code>. The symlinks point to the directories that make up the font path and the symlink names can include attributes such as <code>:unscsaled</code>. libXfont will automatically detect when links are added and removed and rescan the directory.</p><p>No, core fonts are not going away. We can't ever do that, to much legacy. But since Fedora have the two required core fonts ("misc" and "cursor") compiled into the X server, you can have a usable setup with no core fonts (say, maybe you don't like bitmap fonts, or maybe you're OLPC), no xfs, no chkfontpath installed. And at the same time, if you must have that belowed bitmap courier in your terminal or are stuck with an old motif app, install the core font you need and it will just work.</p><p style="font-size: small;">[1] Core fonts is the font mechanism originally designed into the X server. The X server locates and renders the fonts on behalf of the client. This requires the X server to know about parsing font files, glyph rendering and arbitrary encodings, which you typically would want to keep out of a priviledged process. Modern applications locate fonts using fontconfig, render glyphs using freetype, and only upload the resulting images to the RENDER extension.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com9tag:blogger.com,1999:blog-4535528758590979933.post-63863152263066849542007-06-13T13:40:00.001-04:002008-07-06T19:31:41.761-04:00Setting up a cloned git repo<p>I was going to set up a clone of the xserver git repo in my people.freedesktop.org home directory and I figured I'd document the steps. If you want the cheat sheet just skip to the last couple of paragraphs. First of all, to set up a repo I need ssh access to people.freedesktop.org, but since I was going to put the repo in my home directory there, I already have that. Now, the official git repos are read only mounted on <tt>/git</tt>, so the obvious thing to do is to say</p><pre>krh@annarchy:~$ git clone --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
...
krh@annarchy:~$ du -sh xserver.git/
24M xserver.git/
</pre><p>Most of this space is in the objects representing the files, directories and commits of the project history. Compared to the repo we cloned from, it's pretty efficient, as git compresses all those object into a <em>pack</em> as part of the cloning process:</p><pre>krh@annarchy:~$ du -sh /git/xorg/xserver.git/
135M /git/xorg/xserver.git/</pre><p>But given that both repos are on the same filesystem, we can ask git clone to share the underlying objects. This is a pretty clever trick that uses the fact that git objects are immutable. Once you've stored a file or an entire revision of you project as part of a git commit, that object never changes. It would be nice if git could just detect this and do the right thing, but you have to pass a couple of options:</p><pre>krh@annarchy:~$ git clone -s -l --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
krh@annarchy:~$ du -sh xserver.git/
1.3M xserver.git/</pre><p>That's a lot better though, we're down to 1.3M for my own little copy of the xserver repo. However, when you think about it, it's just a glorified symlink to <tt>/git/xserver.git</tt> and 1.3M is a pretty heavy symlink. It's pretty easy to spot the problem</p><pre>krh@annarchy:~$ du -h xserver.git/
252K xserver.git/refs/heads
932K xserver.git/refs/tags
1.2M xserver.git/refs
...</pre><p>When we converted the xserver repo over, we of course imported all branches and tags, most of which now are just in the way—when was the last time anybody looked at <tt>xprint_packagertest_20041125</tt>? One solution is to just nuke the branches and tags you don't care about. But if you need to preserve this important historical information in your repo or are just to lazy to weed it out, you can say</p><pre>krh@annarchy:~$ GIT_DIR=xserver.git git-pack-refs --all
krh@annarchy:~$ du -sh xserver.git/
124K xserver.git/</pre><p>Again, git should just do this by default in the same way it compresses the objects when cloning. As a final step, I want the gitweb script and the git daemon to pick up my new repo so I can browse it on <a href="http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=summary">gitweb.freedesktop.org</a> (or <a href="http://people.freedesktop.org/krh-cgi/cgit?url=~krh/xserver.git">cgit</a>) and clone it using the git protocol. To do that I need to touch a special file in the repo:</p><pre>krh@annarchy:~$ touch xserver.git/git-daemon-export-ok</pre><p>which is just a way to say that it's ok to export this repository to the world. It typically takes a little while before the gitweb script finds your repo.</p><p>I'm sure there's somebody shaking their head now thinking, "gah, git is useless, look at all those commands", so to address that let me first sum up what you have to do to create your own repo and make it visible to the world:</><pre>krh@annarchy:~$ git clone -s -l --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
krh@annarchy:~$ touch xserver.git/git-daemon-export-ok</pre><p>Second, this is my own repo, I can create all the branches I want and commit crazy stuff, without affecting the upstream repo. I set it up without bugging any of the freedesktop.org admins and I didn't even need xserver commit access. Third, if it turns out that I do <a href="http://people.freedesktop.org/krh-cgi/cgit?r=~krh/xserver.git&p=log&h=dri2">useful work</a> there, we can merge it back into the main repo, without loosing any history, and without polluting the upstream branch name space with branch names suchs as <tt>gah</tt>, <tt>doh</tt> and <tt>gahgah</tt>, which are among my favorite choices. Allthough, they'd fit right in with the rest of the xserver branches.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com1tag:blogger.com,1999:blog-4535528758590979933.post-36854339489334131822007-06-07T15:18:00.001-04:002008-07-06T19:31:21.146-04:00Version Control<p>Everybody is <a href="http://log.ometer.com/2007-06.html#7">blogging about SCM tools</a>, and since I have this soapbox at my disposal I might as well too. I've been using git for over a year now, and I think I've earned the right not to have my preference dismissed as flavor of the week at this point. And I feel that the time I've spent learning git has been more than recuperated, and I'm sure anyone who sits down and learns git will feel the same way within a month or so. But OMG it has over 100 commands in /usr/bin, there's this thing called the index, sometimes you have to edit a text file, and hey I got this scary looking warning, bla bla... still, I'll claim—and I don't do this lightly—that git is the single most useful software development tool I've learned in the past 10 years or so.</p><p>CVS is shit. Subversion is gold plated shit. Some people claim that SCMs doesn't matter and that we should just keep using what "works". I hear this from people who typically don't do much development anymore, and certainly haven't tried anything other than CVS or SVN. If you truly don't care about SCMs, get out of the way and let people that care and have investigated the options pick a system that actively assists us in software development.</p><p>Centralized SCM advocates often think that it's either or; either it's the SVN/CVS model or it's the Linux model where everybody has his own tree, everybody pulls from everybody and nobody knows where the latest official version is. The way it works, though, is that most distributed systems provide a superset of functionality of centralized systems, and can be set up—through configuration and convention—to work with a centralized repository. This is how most of the <a href="http://people.freedesktop.org/krh-cgi/cgit">freedesktop.org git repositories
</a> work.</p><p>People have been using cvsup, rsync or other mechanisms to copy and synchronize remote cvs repositories long before distributed systems were available. git can clone an svn repository to a local git repository where you can commit and branch, and then eventually push those changes back to the upstream svn repository. However, if you're choosing an SCM for your new project why would you choose a system that requires your developers to jump through these hoops to achieve that? Given that git can be set up with a central repository, ssh accessible to a group of developers just like cvs and svn, there is no reason to cripple your co-developers workflow, just because you feel that distributed SCMs have nothing to offer.</p><p>Another point often raised about distributed SCMs is that they encourage private development. No they don't. My CVS workflow when implementing a new feature used to be: hack on huge patch, break it, fix it, add more stuff, break it, fix it, etc until the patch was done. <em>That</em> is private development. Now, with git, I add a branch in a private copy, work on the feature in a <a href="http://people.freedesktop.org/krh-cgi/cgit?r=~krh/mesa.git">series of commits</a>, and if the feature works out alright, merge it to the upstream repository. During the entire process the branch is visible and the repository can be cloned by people who wants to test or contribute.</p><p>One tool I'd like to do if I ever get some spare time is a svn commandline compatible wrapper for git. It's entirely doable, and shouldn't be too much work. <tt>svn checkout</tt> becomes <tt>git clone</tt>, <tt>svn update</tt> becomes <tt>git pull</tt>, <tt>svn commit</tt> becomes <tt>git commit -a; git push</tt>. I'm sure the devil is in the details, but having this wrapper lets you choose a <a href="http://keithp.com/blog/Repository_Formats_Matter.html">repository format</a> that preserves branching and merging history and is designed to support cloning, while still letting people use the CVS/SVN workflow.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com9tag:blogger.com,1999:blog-4535528758590979933.post-61295874542258944122007-05-21T15:37:00.001-04:002008-07-06T19:31:05.527-04:00i830 Update<p>Since my previous post about the intel X.org driver and the i830 chipset, <a href="http://keithp.com">Keith</a> has fixed the remaining issues and as far as I can tell, everything is working as expected. Specifically, the load detection code now works and can see whether or not there's an external monitor connected, scaling of non-native panel modes work, and the output code does a better job of automatically assigning CRTC to outputs.</p><p>If anybody out there with i830 laptops wants to give this a spin, that'd be great. The master branch in the xf86-video-intel git repository should work out of the box, or you can try one of these RPMs, if you have at least a 1.3 X server:</p><blockquote><a href="http://people.redhat.com/krh/i830/">http://people.redhat.com/krh/i830/</a></blockquote><p>Once rawhide gets rolling again, we'll push it in there, and if everything goes well, phase out the old bios-based driver.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com2tag:blogger.com,1999:blog-4535528758590979933.post-2581053256098659422007-05-15T10:22:00.001-04:002008-07-06T19:29:43.110-04:00Testing cgit<p>Loading the <a href="http://gitweb.freedesktop.org">gitweb.freedesktop.org</a> front page takes about 10 seconds, and it annoys me whenever I load that page. I typically only load it once and then keep it open in a tab. This prompted me to set up a test of Lars Hjemli's <a href="http://hjemli.net/git/cgit/">cgit</a> which is 1) written in C instead of <a href="http://perl.org">that horrible language</a>, and 2) has a built-in cache.</p><p>It's still pretty new, but it's come a long way in a short time, and has cool features such as a <a href="http://people.freedesktop.org/krh-cgi/cgit?r=xorg_driver_xf86-video-intel.git&p=commit&id=b31bef1a8effa9acb6de7edd206b9d8c48d88144">graphical diffstat</a>. Try it out here: <a href="http://people.freedesktop.org/krh-cgi/cgit">http://people.freedesktop.org/krh-cgi/cgit</a>.</p>Kristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.com0