So starting with the coolest news – the Mesa team is getting close to the GL 3.0 milestone! Yeah, with latest GL_ext_transform_feedback patches from Paul Berry, the last major piece of GL 3.0 spec is getting into place. There are still some extensions missing and lots of smaller tasks to be done, but it is possible to say that we are almost there. I think that this is really exciting for both us, and for all the Linux and open-source users in the world – so yeah – we’ve been good boys and girls during the year and Santa Claus gift has materialized itself in form of almost-full GL 3.0 support in Mesa.

Who knows, maybe prior to the Chinese new year we’ll receive the 2nd part of this gift (in other words, mesa 8.0 release ).

On kernel side, the 3.2-rc6 release brought lots of awesome changes to our drivers. Yes, I am talking about everyone’s favorite rc6 and semaphores features. They are on by default on Ivy Bridge architecture, and are also enabled on Sandy Bridge if VTd is disabled. So most of you should enjoy greatly improved battery life, considerable faster performance and also enhanced stability within the i915 driver when Linux 3.2 will be released.

Besides those patches, work has started on collecting patches for the 3.3 merge window. Daniel Vetter sent his pending patches in a form of tiny 43-patches series. Those patches bring PPGTT support, improve debugfs handling, enhance pread/pwrite performance, fix swizzling for SNB/IVB, improve forcewake operations and enhance debugging support for cases when GPU rings get stuck.

Ben has also sent his patches for scheduling/throttling, but they haven’t received much interest except from myself and phoronix . Those patches add support for more fine-grained GPU scheduling and rings load distribution between individual process. I am really interested in this work, and I hope that they will be accepted into the main kernel in the foreseeable future.

Also on kernel, Rodrigo Vivi and Paulo Zanoni sent out some patches which finally fix some corner cases for TV-out and SDVO outputs. This certainly should make many users happy out there just in time for Christmas.

And finally, for the kernel size, Chris Wilson came with a patch which works around the missed IRQs issues on Ivy Bridge platform. With this patch, and with semaphores being enabled on Ivy Bridge by default, I am very happy to say that we don’t have any blocking bugs for Ivy Bridge in our bugzilla. I think that it comes as a nice Christmas gift for all the users out there (the ones who already have an Ivy Bridge machine, and the ones who will get it by its launch – which is still 4 months away). Of course, I won’t talk much about it prior to its official launch, but trust me – Ivy Bridge rocks!. I can’t wait to have an Ultrabook based on this platform for myself…

Besides mesa and kernel, it is worth mentioning that on the 2D side, Zhigang added full Glamor support into the driver. The Glamor acceleration is still considered very experimental and non-stable, but now it is available for the world to take a peek on it and witness how it works with their own eyes.

So I think that this is pretty much it. We have hundreds of patches floating around for all the projects, thousands of emails and millions of users in the world – and we are working hard to make all of them happy with the results of our work. 2011 was extremely productive and rewarding for us – and I hope that the year of 11111011100 (a.k.a., 0x7DC or 2012_base10 for the ones still reading in decimal numbers out there ) will be even more interesting*!

See you!

(*) Assuming the world won’t end in a core dump caused by the Mayan millennium counter overflow bug .

The focus of this release was on performance and stability improvements in the drivers, and I think we managed to get the job done according to what we expected. Thanks to LLC caching and improvements in both Kernel and Mesa, 3D performance was improved by a large margin on Sandy Bridge generation of GPUs onwards, and many annoying issues were fixed as well (with some of the fixes already queued for Kernel 3.2 release). And I’d also like to highlight lots of work towards GLES compliance on Sandy Bridge architecture, and many and many different stability fixes in all the projects.

For statistical purposes, my saved bugzilla searches count 253 bug reports which were closed after the previous release, and we had 594 bug tickets in total which had any activity since that release. Of course, this does not represents what was done by an accurate number, so please, just use those numbers as some sort of bugzilla pondering references.

So to sum it all up, I’d like to thank all the developers, QA, users, testers, and all the community we have around Intel Linux Graphics project for your amazing work. Yes, the Intel Linux Graphics project has not only a team within Intel – but also a huge community and users all around the world, following the Open-Source road from Kernel up to the UI components. Thank you all guys!

Enjoy!

For the Kernel side, some nice patch series have arrived to the list:

• Daniel Vetter sent his PPGTT enabling patches, which resulted in many interesting reviews and discussions. PPGTT, or Per-Process Graphics Translation Table, is a mechanism for remapping GPU memory into system one. Unlike traditional Graphics Translation Table, which has a global mapping for everything, PPGTT allows each process to have its own level of mapping. On practice, it should improve stability by a large margin and performance by a considerable value, and also is a nice thing to have in general, specially when hardware supports it natively (which it does, starting with Sandy Bridge). Also, if you are interested in learning the details of how GTT and GPU memory management works, you should check this excellent article from 2007 for a great introduction.
• Ben Widawsky has sent a new series of patches for forced GPU throttling and scheduling. I already described them in one of the previous posts, and I am really interested in seeing them accepted to the kernel.
• I’ve sent out some patches for userspace-controled RC6 enabling and tweaking, together with some patches for enabling semaphores and rc6 by default on newer generations of gfx hardware. Those patches, together with Ben’s ones, also raised an interesting point – we have many userspace-controllable items in the debugfs file system, which should probably belong to sysfs instead. This would require a proper definition of their usage and behavior before real userspace applications would be able to use them.
• And Wu Fengguang sent some patches for Display Port and HDMI fixes.

Moving up the stack to the 3D driver, some major news worth highlighting are:

• On Mesa side, the major news is Ian has released Mesa 7.11.2 with some additional GLES and EGL patches, and a small patch which fixed Mesa build on Mandriva (and also on other distributions which use -Werror by default, such as Mageia for example).
• Lots of work is happening in Mesa, targeting OpenGL 3.0 support by the end of the year. GLSL 1.30 is already among us, and most of GL 3.0-required extensions are in place, but there are many things to do. Hopefully they will be all done in the next few weeks.
• Speaking on Mesa, some major news happened for the drivers using the Gallium technology. As you probably heard through Phoronix already, the i965g, Cell and Failover gallium-based drivers were dropped from Mesa due to lack of love, support and care. Sad – but this is life. And in any case, i915g driver is still there, and of course, those events do not affect Intel’s 915 and 965 Mesa drivers at all.
• And also on Mesa, Ian has started the work on GLX_ARB_create_context and the layered GLX_ARB_create_context_profile extension, and came with a question whether it is still worthy to support non-XCB protocol, or if there are any platforms that can’t / don’t use XCB for X protocol yet. The overall feedback so far was to drop non-XCB bits sooner than later. So looks like XCB has won the X protocol war in the end .

And finally, on the xserver side, discussions were raised on the mailing list on the release dates for the next xserver release, and the Xinput 2.2 state in it. It is almost there, and will probably get merged until Christmas. Also, Xorg-server 1.11.2.901 (a.k.a., 1.11.3-RC2) was released.

Speaking about it, it was actually the first LinuxCon I attended (I also went to LinuxWorld Brazil in 2006, but that’s pretty much all the Linux-specific events I’ve been to). So it was really nice to talk to all the people I know from the Internet and put some faces behind the irc nicks and email handles. It was also really nice to meet and talk to Linus, Dirk Hohndel and Lennart Poettering in person, and meet old ex-conectiva people from all over the world.

It was also particularly nice to meet and talk to Christian Reis (a.k.a., Kiko), who is the VP of Engineering at Linaro now. He used to study with me at UFSCar university more than a decade ago and we met on a couple of events at São Carlos previously. He did a very interesting keynote about the state of ARM on Linux at the beginning of the conference, and we talked a lot about GFX drivers on Linux afterwards.

As for my presentation, I’d like to thank you all for attending and asking interesting and technical questions. We actually managed to have a mini real-time debugging session on some lvds issues at the end of the presentation .

And of course, I managed to announce that Mesa 7.11.1 was going to be released about 5 minutes before Ian sent his email – it happened right during my presentation actually . And so.. I spoke of mesa, so yeah, let’s head back to the Intel Linux Graphics news now.

As you all know, Mesa 7.11.1 was released this week. It comes with an absolutely amazing number of 200+ backported patches for performance and stability enhancements in pretty much all the components we have. It is not the last release of the 7.11 branch, so you should expect some more releases in the next couple of months. And perhaps some more even after Mesa 8.0 will be released.

On Kernel side, lots of things happened this week. Linus has released Linux 3.2-rc2 (and also blogged about it in his google+ page while fighting the amazingly fast brazilian 3g connection issues ). It comes with many patches and fixes, for both Intel and non-Intel gfx cards. There is still many patches to get into the 3.2 branch though.

Also, I sent out some patches for once again enabling RC6 and Semaphores by default, but after a discussion on intel-gfx mailing lists I got some ideas on reworking them. And Keith Packard has also sent a rc6-enabling patch earlier today, which probably will fix all the RC6 issues and allow it to enter the kernel. This is the 5th attempt on enabling it by default as far as I remember, so I hope it will get in this time.

On xf86-video-intel, Chris Wilson has released the 2.17 version of the 2D driver, which comes with a large number of fixes for the UXA acceleration. Besides UXA, it also comes with more than 300 patches for SNA – so if you are using it, you really should update. Trust me, you really want to do it .

Still on Kernel, as many of you know, the latest Bios update to the Ivy Bridge bios somewhat broke suspend-resume for IVB machines out there. Keith Packard and Jesse Barnes had already sent some patches to address that, so if you one of the lucky ones out there with an Ivy Bridge, and you do have this issue – please, test it and let us know if it works!

On Mesa side, besides the 7.11.1 release, lots and lots of work is going on to finish GL 3.0 support. Among around a thousand of mails and commits on the mesa-dev list, it is hard to highlight the most important ones, but I’d like to give attention to the Chad Versace‘s patches which bring the HiZ support and enable it by default, and to Paul Berry‘s work on GLSL 1.30.

But besides those, yes, there is a huge number of amazing changes on pretty much everything, with some interesting changes from Eric, Kenneth, Chad, Yuanhan and Ian. Mesa 8.0 ought to be an exciting release!

So that’s it for today. See you!

(of course, if you have attended and want to see it again, you can do this too ).

Have fun!

Intel Linux Graphics

So if you were sad, depressed and crying in despair without having a chance of reading about what was going on with the Intel Graphics for the past days, rejoice!

Those past few days were quite busy on all the projects, and with thousands of emails to keep track of it is hard to select the most relevant news – all of them are! But I’ll try to summarize the most interesting stuff that happened for the past few days.

Starting with kernel, as you all already know, we are living in the post-3.1 era now, with the release of Linux 3.2-rc1. It brings lots and lots of fixes and improvements all around, and much more are yet to come.

On Intel Graphics side, the following items caught my attention for the past days:

• Keith Packard sent yet more eDP-related patches, allowing eDP displays connected to the PCH to, well, work . The main issue came from the fact that the driver incorrectly was treating a PCH-connected eDP panel like a CPU-connected one, setting the wrong bits in the wrong places.
• Daniel Vetter has sent out a series of patches for simulating GPU hangs. As you all know, GPU hangs are an (unfortunate) part of a GPU driver life, and there are many factors which could cause them, ranging from incorrect GL instructions to out-of-bounds variables somewhere in the stream of commands and down to hardware failures. Prior to Daniel’s patches, the only way to see a GPU hang was by having a hung GPU, so most of them were not easy to reproduce and investigate. Now, it is possible to stop the GPU at will, and see the effects. This is particularly interesting at least for me, because I was working on some tools for doing heuristics analysis of the root-causes of GPU hangs. Now, I can do this task with much more ease.
• Jesse Barnes sent out a new round of planes support, and support for SNB and IVB video sprites. The video sprites support different video formats natively and can do scaling as well, and their support was added to the DRM overlay code with this patchset.
• Ken and Daniel did a bit of cleanup of code specific to some pre-production SNB systems. Now that Sandy Bridge is out there, those bits are not necessary anymore, so they were wiped out.
• Daniel has sent a 13-patch series of pwrite/pread reworking. This patchset fixes some spurious -EFAULTS issues which could lead to kernel issues, improves the performance of pread/pwrite calls on LLC machines and cleanups unused code, replacing them with faster execution paths.
• Also on kernel, I’ve found an issue which can cause division-by-zero in kernel when accessing power-related registers from userspace, and sent a small patch fixing it. Apparently, the very same issue was already found back in July by Konstantin Belousov. It is a small fix for a potential kernel crashing issue, and let’s hope it will be picked up in one of the next kernel pull requests.
• And Jesse Barnes sent out some documentation and cleanup patches for the drm subsystem.
• Still on kernel, but outside of our team’s area, one big news for Linux Graphics will certainly make some people out there happy. Yes, I am speaking about Alan Cox moving of basic GMA500 driver out of staging. This driver support accelerated console and non-accelerated KMS on Poulsbo, Oaktrail, Cedarview and Medfield hardware. Note that medfield support in this initial patchset is left out on purpose, as it needs considerable rework to be ready to enter main kernel.

One particular issue worth highlighting is that a long-standing issue on GL-based applications (among which Unigine Tropics and Sanctuary are probably the most notable examples, among many others) was finally fixed, thanks to an amazing work by Eric Anholt, Kenneth Graunke and Keith Packard. This issue can be described as ‘small moving ants on top of image edges’ or ‘flickering pixels‘. So if you have had this issue, make sure to check out the patches!

Going to Mesa, out of hundreds of emails and commits, it is hard to choose the most interesting ones. Work on GL 3.0 support proceeds quickly, and new mesa stability release, 7.11.1 is almost out of the door. Our Q&A team did a full testing of this bugfixing release, and haven’t found much issues. So prepare yourself, as in few weeks we’ll have MESA 7.11.1 out there. Stay tuned for Ian’s announcement in nearby future.

But as for mesa master branch, the following patches called my attention the most:

• Eric sent a patch series to add support for GL_EXT_texture_integer on i965 driver.
• More work towards EXT_transform_feedback was done by Dan McCabe and Paul Berry, and Marek from the community side.
• And we had lots of fixes for potential segmentation faults, safety checks, better hardware specification compatibility, piglit-based fixes and other issues from Yuanhan, Eric, Ken, Chad and Ian.

On Wayland side of the force, lots of patches went in those days. Among those, there was an interesting proposal for the screen locking protocol by Pekka Paalanen, and some bugfixing patches from Juan Zhao.

Going to the other components, we had a release of xorg-xserver 1.11.2 RC2, with several crashes and correctness fixes; and new stable pixman 0.24.0 which brings many performance improvements and usage of architecture-specific instructions to improve overall performance over a number of different operations (such as bilinear scaling for example).

And finally, for the intel-gpu-tools, I was working on a new intel_gpu_analyze application, which I was using to tracing and analyzing CPU and GPU performance data during workloads, and also checking on the corresponding power consumption. This is a very experimental code yet, and it lives at my freedesktop.org git for now. But still, I can already do some nice performance analysis like this one.

It took me longer than I originally expected to write this next post in the series due to some personal problems which kept me out of the virtual world for quite some time, but better late then never.

So, starting with Kernel, as usual, we had lots of updates.

• Jesse Barnes sent out his patches for adding DRM planes and support for a new FB creation ioctl. Planes are similar to half-CRTCs, in the sense that they have a location and fb, but don’t drive outputs directly. His patchset provided two new interfaces: addfb2, a new FB creation ioctl that lets specify a surface format, as defined by a fourcc code from the video4linux headers; and ** planes – ioctls for fetching plane info and attaching an fb to a plane.
• Jesse has also proposed some patches for enabling video sprites via overlays.
• Keith Packard has prepared some patches for flicker-free boot, which attempts to avoid the initial modesetting in drm.
• A very interesting set of patches from Ben which attempt at adding fairness to GPU scheduling, preventing greedy apps from over-dominating the GPU and leaving nothing for other apps. This, of course, is still experimental, but think about this like on what CFS scheduler did to Linux Process Scheduling, and CFQ did to I/O scheduling. Of course, this also raises some concerns, like for example what should happen to benchmarks – which expect to grab all the possible power to get some measurable numbers, but nothing unsolvable here. It would be really interesting to see how it will go.
• Ben has also sent out some patches which attempt to fix recursive unmapping of pages, a side effect of the Ironlake workaround which was done recently.

For Mesa, lots of activities on all fronts too. I won’t be able to cover all of them, but the main highlights of the past days were:

• Work on EXT_transform_feedback by Dan McCabe and Paul Berry from Intel and Marek Olsak. The piglit tests are already in place for some months (I actually started to work on some of them, but then Marek has published his own set of tests, and I left mine in a half-finished state for now at my freedesktop.org personal repo. But I think I’ll finish them at some point). The mesa support for this GL 3.0 extension is approaching its completeness fairly quickly.
• A 33-patch series from Eric Anholt with lots of fixes for batch buffer handling within mesa.
• Lots of different fixes and consistency improvements for Gen6 and Gen7 generations of cards from Ken were also unleashed into the wild.
• A HUGE cleanup of the remaining DRI1 pieces, such as the radeon drivers, dri1-specific extensions and core mesa bits, was carried out by Kristian Høgsberg, Eric and many others who participated in the discussion.
• GLSL and extensions-related work continues, with clean-ups, fixes and improvements from Ian, Ken, Paul Berry and Chad.
• GL_ARB_texture_storage support was brought in by Brian Paul from VMware. It is supported by gallium drivers and swrast for now.
• Chad Versace sent more patches for the Stencil buffer and HiZ support.
• Ian sent out a 20-patch series which completely refactors the handling of uniforms within Mesa.
• Eric has sent 24-patch series for improved renderbuffer mapping (MapRenderbuffer).
• Paul Berry has added support for GLSL 1.30 interpolation qualifiers for Gen6+. This allows to keep track of which fragment shader inputs are overridden with the GLSL “flat”, “smooth”, “perspective” and “noperspective” interpolation qualifiers.
• And Chia-I Wu has sent some new patches for an updated version of glext.h and for improved android-x86 support within core Mesa.

On Wayland land, we also had quite some interesting changes:

• Tiago Vignatti sent several patches for improving input and evdev handling.
• Juan Zhao has put out some documentation about Wayland building.
• Ander, me, Benjamin Franzke, Casey Dahlin, Pekka Paalanen and Juan Zhao has also sent some build, correctness and GL-related patches. In overall, Wayland development is moving on nicely.

Moving to VAAPI, as I already wrote here, Gwenole has released a new version of both libva and vaapi-driver-intel. Also, speaking on new releases, Eric Anholt has also released libdrm 2.4.27, we had the release of xorg-server 1.11.2 RC2, a new pixman 0.23.8 release, which happens to be a release candidate for the stable 0.24 release, and Chris Wilson has put out xf86-video-intel 2.17 RC1, with several fixes and amazing list of 200+ SNA-related patches.

Also on SNA, I’ve put out two patches which would allow to activate SNA by means of a config file option, without recompiling. Those patches patches are floating around the intel-gfx mailing list, and make the task of SNA testing amazingly more easy (at least, for me ).

So – I guess I’ll stop here for now.

See you in the next iteration of The Tales from the Crypt Intel Linux Graphics land .

I am glad to bring you the good news – Gwenole has just releases libva and vaapi-driver-intel version 1.0.15 into the wild! Go ahead and grab them here and here!

And now for the nice details of what you should expect from those releases.

Vaapi-driver-intel

This release improves the VC-1 and MPEG-2 decoding, and fixes some memory leaks:

• Fix VC-1 decoding (TTFRM packing)
• Fix MPEG-2 decoding on Ivy Bridge
• Fix MPEG-2 decoding with sparse QM matrices updates
• Fix slice-param & slice-data buffer memory leaks

Libva

This release moves the i965 driver into its own subdirectory, improves packaging support and build issues, and comes with some miscellaneous fixes.

• API: make {Top,Bottom}FieldOrderCnt signed (Yi Wang)
• Add auto-generated Debian packaging
• Refine VA trace & VA fool utilities
• Move i965 driver to a specific repository (vaapi/intel-driver)
• Fix DSO link issue in tests
• Fix fglrx driver name detection
• Fix API vs. DSO vs. package versioning

As you can see, this is a bugfix-mostly release. Next step is 1.0.16, which will bring some nice features to you in nearby future.

As always, stay tuned .

His testing confirms what I was pointing out with my latest series of the post (however, it always feels great to have independent confirmation of the results). For performance numbers, kernel 3.1 brings around +20% to +40% improvements on top of the previous release for Sandy Bridge architecture. Yeah, this is nice. So if you haven’t updated your kernel to the latest and greatest one (in other words, kernel 3.1), you should really consider doing this.

As for power numbers, we have some good news too. The default kernel power usage on 3.1 is mostly similar to 3.0, with some small variations here and there. However, if one enables RC6 support, the immediate results is that your power usage drops by up to 40% on idle. It is really nice to see less than two-digit watts numbers on current generation of desktop hardware (while it is pretty common to see it on Atom CPUs for some time already, desktop and mobile versions of Intel cards were not that used to such numbers – yet).

One additional bonus Michael has found out is pretty much more interesting one. Apparently, by enabling RC6, the graphics-intensive applications get an additional performance boost of up to 10%. This was a bit unexpected for me, but it is better to have good surprises than bad ones.

From what we have discussed with Jesse Barnes, such improvements could come from several different paths. The first explanation is that, with RC6 enabled, the graphical card can actually consume much less power (down to 0V), so it leaves more room for CPU to use the non-claimed power to do more processing of its own. And the second one is that, thanks to additional thermal bonus which we get from the RC6-provided power economy, the GPU frequency has more room for scaling. So effectively, in both of those case, RC6 allows you to have a better performance, both CPU and GPU-wise – at a cost of somewhat higher power usage coming from such performance.

So, in few words, I would define this situation as battery when you want, performance when you need. When you are on battery, under mostly idle workload (for example, browsing or reading or writing some blog posts), your battery lasts much longer. And when you start some processing-intensive application (say, openarena or angry birds), it gets more horsepower to get the job done, and some extra FPS which could mean life or death – which is specially true in case of said workloads . Of course, those additional horses are hungry, so this incurs in more power being used when such additional performance is there – but it is something to be expected in any case.

While writing this description, I actually came to realize that the feature known as GPU turbo, which is present on Intel graphics cards, could be used to define and control such behavior on a much finer granularity. From what I’ve searched all around, surprisingly, nobody seems to have covered its functionality yet. I guess I’ll try to cover how it works, and how one could use and control it from userspace in one of the next posts, so stay tuned! And meanwhile, enjoy all those nice power and performance-related bonuses which the Intel Linux Graphics team brought to you just in time for Halloween .

I tried to summarize all the patches and changes which went to this kernel release which somehow affected the drivers/gpu/drm/i915 directory (and, therefore, the kernel part of our driver).

To give proper credit to all the authors whose code was accepted into the official kernel between the 3.0.0 and 3.1 release, here is the full list:

• Adam Jackson: drm/i915/dp: Better hexdump of DPCD
• Adam Jackson: drm/i915/dp: Don’t turn CPT DP ports on too early
• Adam Jackson: drm/i915/dp: Explicitly disable symbol scrambling while training
• Adam Jackson: drm/i915/dp: Explicitly request 8/10 channel coding
• Adam Jackson: drm/i915/dp: Move DPCD dump to common code instead of PCH-only
• Adam Jackson: drm/i915/dp: Read more DPCD registers on connection probe
• Adam Jackson: drm/i915/dp: Retry DPCD fetch on G4X too
• Adam Jackson: drm/i915/dp: Zero the DPCD data before connection probe
• Adam Jackson: drm/i915/pch: Fix integer math bugs in panel fitting
• Adam Jackson: drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
• Ben Widawsky: drm/i915: add module parameter compiler hints
• Ben Widawsky: drm/i915: hangcheck disable parameter
• Ben Widawsky: drm/i915: provide module parameter description
• Chris Wilson: drm/i915: Add an interface to dynamically change the cache level
• Chris Wilson: drm/i915/bios: Avoid temporary allocation whilst searching for downclock
• Chris Wilson: drm/i915: Cache GT fifo count for SandyBridge
• Chris Wilson: drm/i915: Combine pinning with setting to the display plane
• Chris Wilson: drm/i915: Disable FBC across page-flipping
• Chris Wilson: drm/i915/gtt: Split out i915_gem_gtt_rebind_object()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gpu()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gtt()
• Chris Wilson: drm/i915: Mark the cursor and the overlay as being part of the display planes
• Chris Wilson: drm/i915: Only export the generic intel_disable_fbc() interface
• Chris Wilson: drm/i915: Perform intel_enable_fbc() from a delayed task
• Chris Wilson: drm/i915: Remove vestigial pitch from post-gen2 FBC control routines
• Chris Wilson: drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()
• Chris Wilson: drm/i915: Set persistent-mode for ILK/SNB framebuffer compression
• Chris Wilson: drm/i915: Share the common work of disabling active FBC before updating
• Chris Wilson: drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes
• Dave Airlie: Revert “drm/i915: Try enabling RC6 by default (again)”
• Eric Anholt: drm/i915: Use the LLC mode on gen6 for everything but display.
• Eric Anholt: drm/i915: Use the uncached domain for the display planes
• Hugh Dickins: drm/i915: more struct_mutex locking
• Jesse Barnes: drm/i915: add GPU max frequency control file
• Jesse Barnes: drm/i915: allow cache sharing policy control
• Jesse Barnes: drm/i915: apply phase pointer override on SNB+ too
• Jesse Barnes: drm/i915: apply timing generator bug workaround on CPT and PPT
• Jesse Barnes: drm/i915: check for supported depth at fb init time
• Jesse Barnes: drm/i915: don’t set SDVO color range on ILK+
• Jesse Barnes: drm/i915: don’t set transcoder bpc on CougarPoint
• Jesse Barnes: drm/i915: don’t use uninitialized EDID bpc values when picking pipe bpp
• Jesse Barnes: drm/i915/dp: wait for previous AUX channel activity to clear
• Jesse Barnes: drm/i915: enable ring freq scaling, RC6 and graphics turbo on Ivy Bridge v3
• Jesse Barnes: drm/i915: fix CB tuning check for ILK+
• Jesse Barnes: drm/i915: flush plane control changes on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: HDMI source product description infoframe support
• Jesse Barnes: drm/i915/hdmi: send AVI info frames on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: split infoframe setting from infoframe type code
• Jesse Barnes: drm/i915: load a ring frequency scaling table v3
• Jesse Barnes: drm/i915: load the LUT before pipe enable on ILK+
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: set bpc for DP transcoder
• Jesse Barnes: drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge
• Jesse Barnes: drm/i915: show interrupt info on IVB
• Jesse Barnes: drm/i915: split out Ironlake pipe bpp picking code
• Jesse Barnes: drm/i915: split out PCH refclk update code
• Jesse Barnes: drm/i915: split out plane update code
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculation
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculations
• Jesse Barnes: drm/i915: use pipe bpp when setting HDMI bpc
• Kamal Mostafa: i915: do not setup intel_backlight twice
• Keith Packard: drm/i915: Call intel_enable_plane from i9xx_crtc_mode_set (again)
• Keith Packard: drm/i915: Cannot set clock gating under UMS
• Keith Packard: drm/i915: Can’t do accurate vblank timestamps with UMS
• Keith Packard: drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
• Keith Packard: drm/i915: Enable dither whenever display bpc < frame buffer bpc
• Keith Packard: drm/i915: Enable i915 frame buffer compression by default
• Keith Packard: drm/i915: FBC off for ironlake and older, otherwise on by default
• Keith Packard: drm/i915: Fix PCH port pipe select in CPT disable paths
• Keith Packard: drm/i915: Fixup for ‘Hold mode_config->mutex during hotplug’
• Keith Packard: drm/i915: Flush other plane register writes
• Keith Packard: drm/i915: Hold mode_config->mutex during hotplug processing
• Keith Packard: drm/i915: i915_gem_object_finish_gtt must always release gtt mmap
• Keith Packard: drm/i915: Ignore GPU wedged errors while pinning scanout buffers
• Keith Packard: drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
• Keith Packard: drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri
• Keith Packard: drm/i915: Leave LVDS registers unlocked
• Keith Packard: drm/i915: Remove unused ‘reg’ argument to dp_pipe_enabled
• Keith Packard: drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
• Keith Packard: drm/i915: Select correct pipe during TV detect
• Keith Packard: drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_set
• Keith Packard: drm/i915: Skip GPU wait for scanout pin while wedged
• Keith Packard: drm/i915: Try enabling RC6 by default (again)
• Keith Packard: drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
• Keith Packard: drm/i915: Use dp_detect_common in hotplug helper function
• Keith Packard: drm/i915: Wait for LVDS panel power sequence
• Keith Packard: Revert and fix “drm/i915/dp: remove DPMS mode tracking from DP”
• Keith Packard: Revert “drm/i915/dp: Zero the DPCD data before connection probe”
• Matthew Garrett: i915: Fix opregion notifications
• Matthew Garrett: Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
• Michel Alexandre Salim: drm/i915: Add quirk to disable SSC on Sony Vaio Y2
• Pieterjan Camerlynck: i915: add Dell OptiPlex FX170 to intel_no_lvds
• Simon Farnsworth: drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
• Thomas Jarosch: drm/i915: Fix wrong initializer for “locked” variable in assert_panel_unlocked

If we count the final number of changes between the 3.0 and 3.1 versions, we come to the following results:

drivers/gpu/drm/i915/i915_debugfs.c     |  232 +++++++-
drivers/gpu/drm/i915/i915_dma.c         |   10 +-
drivers/gpu/drm/i915/i915_drv.c         |   69 ++-
drivers/gpu/drm/i915/i915_drv.h         |   51 +-
drivers/gpu/drm/i915/i915_gem.c         |  193 +++++-
drivers/gpu/drm/i915/i915_gem_gtt.c     |   39 +-
drivers/gpu/drm/i915/i915_irq.c         |   22 +-
drivers/gpu/drm/i915/i915_reg.h         |   59 ++-
drivers/gpu/drm/i915/i915_suspend.c     |   13 +-
drivers/gpu/drm/i915/intel_bios.c       |  140 +++--
drivers/gpu/drm/i915/intel_display.c    | 1028 +++++++++++++++++++++++--------
drivers/gpu/drm/i915/intel_dp.c         |  135 +++--
drivers/gpu/drm/i915/intel_drv.h        |   38 +-
drivers/gpu/drm/i915/intel_hdmi.c       |  166 +++++-
drivers/gpu/drm/i915/intel_lvds.c       |   90 ++--
drivers/gpu/drm/i915/intel_opregion.c   |   16 +-
drivers/gpu/drm/i915/intel_overlay.c    |    6 +-
drivers/gpu/drm/i915/intel_panel.c      |   76 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c |   13 +-
drivers/gpu/drm/i915/intel_sdvo.c       |   88 +--
drivers/gpu/drm/i915/intel_tv.c         |   46 +-
21 files changed, 1879 insertions(+), 651 deletions(-)

So, in sum, there are changes all around the driver. Among the most interesting ones (in my humble opinion), are:

• Frame Buffer Compression is now enabled for Gen6 onwards (in other words, starting with Sandy Bridge). Of course, you can always enable it manually on your machine as well by using the i915.i915_enable_fbc=1 kernel parameter.
• FBC should work better in general, thanks to patches from Chris Wilson which disable it across page-flipping and before updating, persist framebuffer compression mode for Ironlake and Sandy Bridge, and also making a proper use of fences after CPU writes.
• RC6 was attempted to be enabled, but it was reverted early in the development cycle. As we had unusual time frame for this kernel release, by the time we have hit RC8, all the remaining RC6-related issues were tracked down. But as it was already too late for kernel 3.1, its enablement by default should happen in kernel 3.2. The usage of RC6 brings amazing power usage benefits, so you can enable it by yourself via the i915.i915_enable_rc6=1 kernel parameter – and letting us know about any non-covered issues it may bring.
• DCPD, or Display Port Configuration Data handling has received lots of attention, and in general one should have a much better support for Display Port outputs.
• configuration parameters for changing the cache level, maximum GPU frequency, cache sharing policy and GPU ring frequency scaling.
• additional debugging output when mode setting fails, information about interrupts on Ivy bridge, hangcheck disabling support and better DPCD hexdump.
• improvements for HDMI support, SDVO and LVDS handling, better pipe handling of EDID bpc values and proper panel fitting calculationsl
• usage of LLC mode (usage of CPU cache for GPU instructions) for Gen6. This one-lined (excluding comments ) change alone was responsible for about 20% performance improvements for openarena in full-screen mode, and about 12% improvements in nexuiz.

The i915 driver in kernel 3.1 received a total of 95 new patches when compared to 3.0 (excluding merges), coming from 14 different authors – both working at Intel and not. Now the road is open for 3.2. So fasten your seat belts and prepare for the next ride .

As a shameless self-promoting plug, let me start by sharing the presentation about Linux and Open-Source which I did last week. As with all my other presentation, I put it on scribd:

Linux e Open-Source: o que são e como podem me ajudar durante a faculdade?

I hope it would be as much interesting for you to access it, as it was for me to have the opportunity to write and present it. Thanks to all who attended the event, it was great!

But going back to the technical items in the agenda, let me start with the Kernel progress over the past week:

• As you all know, Kernel 3.1 was just released. It comes with a nice set of patches for Intel Graphics, so we hope you’ll enjoy it. Expect all range of improvements – from performance boosts to lots of stability and feature-wise fixes.
• As a major news, we had a pull request for the drm-intel-next branch from Keith Packard, for inclusion into the 3.2 version of Linux kernel. It comes with lots of interesting patches, among which I’d like to highlight the Ivybridge 3-display pipe support, lots of fixes for Embedded Display Port (eDP) handling on Sandy Bridge architecture, workarounds for the VT-d-related issues on Ironlake family of GPU, fixes for interrupt race conditions, among many others.
• Still on kernel, there was a number of conversations – all over the IRC channel, bugzilla and mailing lists – about GPU hangs and backlight-related issues. Some of those investigations resulted in new patches which could possibly solve – or, at least, help identifying the issues.
• On the FBC front, I’ve sent an initial patch for enabling Frame Buffer Compression on Ivybridge. It still needs testing and verification though, and lots of changes in code style and content, many of which were pointed out by Chris Wilson. So I’ll work on it this week.
• And as a bonus news, it looks like all the critical RC6-related issues (e.g., crashes or hangs) are now gone. There are still rendering-related problems though, some of which I came to figure out through this blog of mine (thank to you all for reporting!!). This is still not the ideal solution, but heck – it is a large step forward. Based on latest performance and power-related investigations which both we carried out internally, and the ones reported by community – by activating RC6 one could expect up to 50% improvements in power consumption. Definitely a nice thing to have.

On mesa front, we had a number of news as well:

• A discussion about moving the DRI1 radeon drivers into the land where the old drivers live happy forever-after was started by Eric and picked up by a number of Mesa developers. Those are possibly the last remaining drivers using DRI1 code path out there, and I guess we won’t have them around for much longer. Specially now that gallium backend is among us.
• Some optimizations about dead and non-reachable code cleanups were proposed by Ian.
• And we had several fixes for Gen6 and Gen7 architectures from Kenneth and Yuanhan.

An interesting collection of news came from the X.org development land:

• The discussion about Glamor server project was carried on, with a number of interesting opinions and talks. Glamor project, which was initially sent to the X developers mailing list some weeks ago, is aiming at introducing a new hardware-independent DDX which can use the GPU acceleration via OpenGL interface. One of the concerns expressed by the X development community about it is that, well, there are already too many different acceleration projects for X out there. So, after a number of very insightful discussions about Glamor, it was agreed that its development will be split into two different branches – one device-independent library, which could be reused by all the other DDX drivers; and intel-specific bits will be developed and integrated on their own incremental pace.
• Besides Glamor, lots of activity came from the Xinput developers and documentation updates.
• A number of coverity-discovered patches was sent by Dave Airle.
• And as a major news, we had a new security update for the Xserver project, fixing two security vulnerabilities: CVE-2011-4028 and CVE-2011-4029. One of the vulnerabilities allows to disclose the existence of a privileged file, and another allows to reset permissions of a restricted file to 444 via a symlink attack. So it would be a good idea to update your Xserver installation with those fixes included.

On Cairo side, there was an interesting discussion about slow HTML5 rendering in Firefox, coming from the non-optimal usage of X shared memory. The root of the problem is that code path used in this case does not uses BigReq extension, so it is limited to allocating a fixed 16Kb buffer – which is obviously not enough for the data it needs to process. So it results in lots and lots of small transmissions, and incurring in around 25k context switches per second.

Those are the major highlights of what I’ve seen over the past few days. See you on the next post .

I’ll do two Linux and open-source-related presentations in the coming weeks.

The first one would occur at the IV Semana Nacional de Ciência e Tecnologia, promoted by the Instituto Federal de Educação, Ciência e Tecnologia de São Paulo – campus São Carlos, this Friday as 20:30 at UFSCar. I’ll give a presentation about Linux, Open-Source, and why it is a good idea to work and contribute to it during the (under)graduation. The title of the presentation is Linux e Open-Source: o que são e como podem me ajudar durante a faculdade?, and it will be in portuguese. The link to the event and additional details about it are listed here.

The second will be at the LinuxCon Brazil conference, where I’ll have a presentation with self-explained title Intel Linux Graphics – Following the Open Source Road from Kernel to UI Toolkits. The LinuxCon conference needs no introduction, and it will have lots of amazing presentations, so be sure to check it out!

Also on LinuxCon, we’ll have a presentation by Guilherme Moro, who replaced my at Mandriva when I left. He’ll talk about Managing IT infrastructure with Open Source Multiplatform Tool Pulse 2. He is a great developer and a good friend of mine – I actually was responsible for bringing him to mstech, and later to Mandriva, to work in my teams. So it would be a great presentation to watch as well.

But in general – if you happen to come to any of the aforementioned presentation, I’ll be happy to talk about linux, intel, open-source, mandriva, mageia, football, programming and all other nice and endless issues .

Since last update, we had a very productive weekend , and 2 days of work on all the projects. In this time span, on intel-gpu-tools front, we had some interesting commits:

• One from myself, to add non-interactive logging of GPU activity, parseable by other scripts and applications
• Several from Daniel, improving the debugging facilities of the tools
• A new intel_reg_checker application from Eric Anholt, which attempts to discover possibly incorrect settings which could lead to the crash/hang/issue.
• And I’ve sent some heuristics patches for intel_error_decode and intel_decode which attempt to identify the root cause of the problem (e.g., if it came through mesa codepath, or 2D driver, or VA). After discussion on both mail and IRC with Chris and Daniel, we came to the conclusion that this approach should be better approaches from a separate script or app, which would do the analysis of the trace.

On Kernel, we had some nice news too:

• QA has carried out the performance and functionality testing for my edid patch, and it gave a really nice performance boost in all cases. After sending the final version of the patch, we had some comments from Jean Delvare and Alex Deucher about possible issues this could bring to radeon-based cards, if the fix would be implemented inside DRM. So I am still not sure about what to do here – I have two versions of the same fix, both are working, but I don’t know which one will be the final one.
• Lots of activity and discussion on SNA, VA and RC6-related issues took place from Daniel, Ben, Chris and myself. Some of the reported issues have been isolated (well.. mostly ), and some have some patching attempts. The root cause of the problems is not clear yet. But on the bright side, apparently, we don’t have any crash or hang-related issues coming via RC6, only some rendering corruptions. So hopefully RC6-by-default will see the light of day again in some point in the future .
• Some (possibly) final patches from Ben Widawsky and David Woodhouse arrived, attempting to fix the VTd-related problem on Ironlake chipsets.

Meanwhile, Mesa has had lots of activity too:

• Chad Versace sent out some dozens of patches which added support for HiZ infrastructure in core mesa, adding new driver hooks and small changes all around. Note that HiZ is supposed to be supported by i965 family of the chips (e.g., 5th (Ironlake) generation onward).
• Lots of piglit and conformance patches arrived from Eric, Yuanhan and Chad.
• Stencil buffer support has received some updates from Chad as well.
• And an improved math performance patch was sent by Ken. It should improve math-related operations by a nice margin on Ivybridge, and also allows it to work in a workaround-free way .

On DDX front, as usually, we had an impressive number of patches from Chris for SNA. On a related note, past weeks had given us lots and lots of feedback about SNA and how people are using it. This is great – it means that it works (despite some issues, many of which are already filed as bugs, or being investigated right now)! I’ve been using SNA by default on all my machines for a couple of months, and it works just fine for me. Only faster .

And finally, on Xserver-related work, we had a new Glamor pull request from Zhigang Gong, lots of man and documentation-related patches, Xinput and evdev development, and a small patch which drops support for the bsdi. I am actually quite curious about this one – it has been a really, really long time since I’ve seen a bsdi system out there. Does anyone still has one around? It would be nice to play with it those days…

EDIT: Update from Daniel Vetter – HiZ is available in hardware starting from Ironlake. I updated the post accordingly.

There was much activity all around those days, so I decided not to wait until next week and do this update earlier. Certainly until next week lots of things will still happen.

But let’s get started. And first of all, I’d like to thank you all for the feedback I had on this blog – both by emails and comments and IRC and bugzilla – I was really and truly pleasantly surprised with your comments. Looks like this sort of information I am putting here is interesting to many people out there, so I’ll try to keep up to the task.

And one important reminder which somehow slipped out from the previous posts in the series – if you want to report an issue related to the Intel Graphics stack, there is a comprehensive guide on what you need to report here. For debugging suspend-resume issues, there is a separate guide as well. And, of course, if you want to build the latest versions of the drivers (or their snapshots) as well, there is a tutorial to get you started. Those links are hidden deep in the Intel Linux Graphics web page, so they are not easy to find sometimes – so I hope they will be useful to you.

But let’s go to the development progress on the components of the stack for this 2nd week of October.

• I sent out yet another round of my EDID fixes. Thanks to the testing by Mike Lothian (thanks!!), the i915-specific fixes gave no visible regressions (however, no visible improvements improvements either), but the drm-specific fix managed to do something wrong with the Radeon adapter. So I switched the focus to the i915-specific version for now, as I don’t have non-intel hardware to do the debugging, and put it on my fd.o repository. Hopefully I’ll have more testing results next week, or maybe other comments on this patch. At least on all my machines, it managed to improve the monitor detection timing by a considerable margin.
• Also on Kernel, Adam Jackson from RedHat sent out a nice patch that work around the limitations of active dp->any connectors. Quoting his patch description, ” Many such (including all DP->VGA chips I can find on the market) come equipped with only 2 DP lanes, which clips your dotclock to 144MHz at8bpc.  Of the standard DMT modes, that means you lose 1600×1200@60 and above.  Since these adaptors are marketed as supporting 1920×1200, we might as well make that work, otherwise it’s the driver that comes out looking bad.”.
• Still on Kernel, Jesse Barnes had sent new iterations of his 3-display-pipes patches, which have evolved into more than that by now, improving lots of display handling aspects within the driver. Also within this context, Paulo Zanoni has worked around a bug with multiple VGA outputs by using some intel_reg_dumper/intel_reg_write magic , and came with a kernel patch for fixing such problems. This patch was further adapted according to Chris and Jesse’s comments, and is floating around the intel-gfx mailing lists at the moment.
• Also on kernel, Daniel Vetter and (by a much smaller margin) myself were been doing lots of investigation for GPU hangs, corruptions, suspend-resume and rendering problems. Some of the problems has possible patches, some of them are still out in the wild. For the currently alive suspend-resume issues, looks like they happen when the Kernel Mode Setting (KMS) is being used, and go away with the nomodeset kernel parameter. So if you are affected by any of those, it would be worth trying that parameter in grub or kernel command line to see if it helps.
• On development side of kernel, Jesse Barnes sent out a modeset verification patch, which could help identifying modeset-related problems; and Ben and Daniel Vetter did many code cleanups, sent out patches on hangcheck robustification, and overall were working on improving the debugging facilities of the driver.

Moving to the DDX (a.k.a., 2D display driver, usually known by its friendly nickname of xf86-video-intel), there was quite an activity as well:

• Chris has sent out lots of SNA-related patches.
• Daniel Vetter has sent some Sandy Bridge-specific fixes, and was also investigating SNA-related bug reports.
• And I’ve managed to find a new GPU hang which only happens when SNA is active on an Ivy Bridge system. Somehow I suspect not many people out there besides myself are affected by it though .

On Mesa front, there were some new patches from Chad on Stencil Buffer development; lots of patch reviews by Eric Anholt and Ian, some Ivy Bridge-specific fixes from Ken, many code cleanups and refactoring by Ken again, and some patches from Yuanhan Liu for bug fixing, improved Ivy Bridge functionality, and better GL conformance. Besides Intel-specific development, there were some interesting patches from VMware developers (Thomas Hellstrom, José Fonseca and Brian Paul) which landed into master branch as well.

About Xserver, lots of emails on most different areas have been floating around, as usual, but not much Intel-specific activity took place. Among the discussions and patches which caught my attention the most were an interesting discussion about patches which allow X server to run without root user; a patch which adds support for running a backtracer in case of fault; a new round of Xinput fixes, a patch for setting a default DPI value from EDID data by Michal Suchanek, and more bus cleanups by Jeremy Huddleston. On a related note, Xserver 1.11.2 RC1 release is approaching fairly quickly.

Moving to Wayland, we had lots of x11-specific patches from Kristian, and some compositor bugfixes from Benjamin Franzke.

And finally, on LIBVA there was a one bugfixing patch from Gwenole for proper driver name detection with fglrx-powered cards.

Besides those news, we also have had a new pixman release, which added some nice optimizations by using SSE2 instructions on x86 platforms, and iwMMXt ones on ARM.

So yeah, quite some changes so far.

So this is the end of this semi-periodic-update about the state and news from the Intel Linux Graphics (and related) world – see you in the next one.

P.S.: On a slightly related note – I have received some comments which say that this kind of posts, when they do not directly mention Mandriva or Mageia, should not belong to the respective planets. However, I also received some posts saying that the Graphics-related news affect pretty much all the distributions out there. So I am open for opinions – what do you suggest, should such post be excluded from the syndication to Planet Mandriva and/or Mageia feeds, or they could fit there as well?

another week, another update .

Lots of major things happened for the past week over all the Intel Linux Graphics-related projects. Let me highlight some of them for you.

• On kernel side, the major feature is, certainly, the enablement of the 3rd display pipe for the Ivy Bridge architecture in the intel-gfx mailing list, by Jesse Barnes. Lots of things were already said about Ivy Bridge, which will arrive next year to your favorite reseller, and the Open Source drivers for it will be ready by the time it gets there. The enablement of the 3rd display pipe – and, therefore, the possibility of having 3 independent displays up and running on Linux – certainly is a major step forward. And having those patches in the open-source world early, months before the hardware will arrive to the vast majority of the users, is certainly a big plus for everyone (and specially for the open-source community)!
• Lots of work for next stable release of mesa (7.11.1) was done, resulting in cherry-picking hundreds of commits to the stable branch.
• MRT rendering support in OpenGL ES 2.0 was added to Mesa by Ian Romanick. This change brought the GL_NV_draw_buffers and GL_NV_fbo_color_attachment OpenGL extensions to ES 2.0.
• Lots of internal shaders cleanup was also done by Ian Romanick.
• Paul Berry has sent yet more patches for gl_Clip_Distance and gl_ClipVertex to mesa-dev mailing list. Also, a (possibly final) version of clipping series of patches for Gen6 is floating around mesa-dev mailing list now.
• Also on mesa side, some work on GLES 1.1 conformance was done by Kenneth Graunke, together with new patches for HiZ support by Chad Versace and some GLSL 1.30 fixes by Carl Worth. Speaking on GLSL 1.30, it has received lots of commits from Eric Anholt, Kenneth Graunke and Paul Berry as well. The OpenGL 3.0 and GLSL 1.30 support is getting closer and closer now.
• On intel-gfx mailing lists, irc and bugzilla, lots of discussion and possible fixes for the RC6-related problems I mentioned in the previous post took place by myself, Daniel Vetter, Chris Wilson and many others. So far, a workaround for bug 38567 seems to be found, while the bug 41226 is still playing tricks with us. Those are the only rc6-related bugs we are aware of at the moment, so hopefully they will be solved pretty soon.
• Also on kernel side, some patches from Daniel Vetter and Ben Widawsky landed in the intel-gfx mailing list, which enable more verbose per-ring information collection. This would result in a much more accurate problem diagnosis – as newer GPU hardware has multiple rendering rings, the crash dumps not always provided all the necessary information. Now they should.
• Some more timing and display detection-related patches from Keith Packard arrived to the intel-gfx mailing list, which greatly improve the monitor detection timings and provide support for new MacBook Air displays. They should probably get into the Kernel 3.2, but can already be used to testing with the 3.1 (and, with some adaptations 3.0) kernel series.
• And finally, I’ve finally sent my patches for fixing the long display discovery issues to intel-gfx mailing list. According to the tests, they should improve the display detection timing by 30%–300%, by giving up earlier on non-working output ports. The effects should be more visible on machines which has lots of such ports – which is becoming quite common those days with the DisplayPort, HDMI, VGA, S-Video, and all the others connections we have out there.

On a related note, Mageia kernel was updated to 3.1-rc9 – so all the Mageia Cauldron users should experience a nice performance improvements with their Intel graphics cards. Mandriva kernel is at 3.1-rc9 as well, both distributions are on a similar page now.

What is this patch about? In many cases, when you have a system with different video outputs (say, VGA, HDMI, DP, among others), sometimes a simple xrandr execution takes too long – sometimes even longer than 1 second (the famous BUG #41059).

The first two iterations of this fix managed to improve the timing by a huge margin – as much by a factor 100x actually in some cases. But the drawback is that the fix also managed to exclude some valid port connectors sometimes, so it wasn’t a valid fix after all.

After more investigation, I came to realize that what happens in some cases is that the pins used for detection are stuck while the the connector is not plugged in; and suddenly come to their senses when the connector is there. So we couldn’t just ignore those pins in all cases – even if they seem to be invalid, they could change their mind at some point.

So I came with two different sets of patches – one which fixes the issue directly in drm, and should benefit all the video cards using it for edid detection; and another which does the same thing but within the i915 driver. In both cases, I have experienced a 30%-300% improvements in output detection on all the machines I have tested, which also resulted in some seconds of boot-time optimizations in total. So it is a nice improvement in my opinion .

The advantage of the first approach is that it should work with each card; but the disadvantage is that I don’t have any non-intel cards around for a long time already – well, technically, for 6 months, since my ASUS G1S passed away after 4 years or use, 2 years of disk uptime according to S.M.A.R.T.. He was solely responsible for all the builds of 4 Mandriva releases (2010.2 and all the 2011 preliminar ones) – so indeed, it was a hero notebook.

But back to the topic – if by a chance you experience slow xrandr execution; or you think that your machine takes a long time to start X or during the boot while attempting to find out all the video output it has – give them a try! I’d be very interested in any feedback.

Continuing my updating on latest intel linux graphics-related activity, some hours ago Jesse Barnes’ patches which add support for 3 display pipes to our Linux i915 driver have landed onto intel-gfx mailing list. This is one feature I am particularly very interested in, and it is great to have those patches available in the open-source world now – months before the IVB-based hardware will arrive at the consumer market.

Yes, as it was announced in several conferences, notes and even IDF, the Ivy Bridge graphics will bring out some impressive changes. Besides a greatly improved performance and new features, they also bring the support for 3 independent displays with them. So yes, it would be possible for one to have up to three independent video/audio streams being output to 3 different monitors at the same time (or having your display extended over 3 different monitors to bring you closer to the matrix reality ).

As for the user interface to configure such display – pretty much everything stays the same. You just have more options in the xrandr tool (and its GUI frontends out there).

So if you’ve been waiting for watching 3 HDTV 1080p (or even twice-that-resolution) videos at the same time, on 3 different monitors, this time is approaching very fast.

As you already know, since August I am working at Intel, within the Intel Linux Graphics group. And, as many of you know as well, the news about Intel Linux graphics out there vary a lot, but usually just between the “it just works” and “nothing works” states, with few intermediate points in between (many of which are usually covered by phoronix news).

So to fill those empty spots, I thought on getting back into the habit of semi periodic write-ups I got while at Mandriva – just giving out some insights, overviews and overall updates about what is going on with Intel Linux Graphics and related open-source projects from time to time.

But first of all, let me do a quick review about what Intel Linux Graphics is all about. Unlikely other drivers project, the Linux Graphics does not consists from a single and unique driver. By the contrary, it has a lot of ground to cover, working directly on the upstream projects which compose the graphical stack – ranging from the i915 driver in kernel to the entire MESA 3D/GL stack, passing through libdrm and vaapi and all the way up to x11-server, cairo and wayland – among others. So when you read about an Intel Linux Graphics release, it considers a snapshot version of each of those components.

Of course, each of those projects has a different release goals and timelines, different sets of features to cover, and so on. And, of course, there is a matrix of different generations of graphical hardware, different variations of the models and revisions, and a multitude of OEM platforms to cover.

So, in short, “it’s complicated” .

In this sense, the Intel Linux Graphics project so far was doing quarterly releases of the entire stack, as one could see at 2011Q3, 2011Q1, 2010Q4 and all the previous ones. However, one of the problems with the quarterly releases, specially over such a big and varying stack, is that they don’t fit all the situations. So starting with the next release, we’ll be changing our process to carry out more specific releases, based on pre-defined release criteria for each of them. And the next release will be focused specifically on performance and stability enhancement over our current code.

What do I mean by performance and stability? While most of the people out there do not experience any issues with the drivers (e.g., “they just work” category I mentioned out there), we are by no means perfect, and yes, we have bugs which affect different users, operating systems and hardware components (all the way to that “nothing works” category of people – which is thankfully quite small, and of course we hope to promote it to the “just work” category of the people ASAP). And we are trying to get better and better for each release, at the same time trying to maintain the same level of openness as one would expect from open-source projects.

If you look at the freedesktop bugzilla, for intel graphics-specific issues, there is a quite complete list out there. Of course, many of those bugs are old, or do not apply to the current state of the code anymore, but some of those are valid – and they don’t get the level of attention they need. Specially considering the large number of reports, it is really hard to keep track of all of them, and it is specially easy to get lost among all of them. So if your bug is not getting enough attention – just go over to it, and ping us. We do not ignore you, but sometimes we lose track of specific issues out there, and we’ll be happy to be reminded either when an issue is fixed, or whether it is still out there and needs some love .

So, as I said previously, I’ll try to cover up the details of each part of our drivers stack, and try to keep updated the list of the current work and goals we have in mind. So I’ll start with this first post, and will try to cover a bit about the areas we’ve been focused the most for the past months – specially considering the “performance” and “stability” criteria, and the most interesting features we have out there.

RC6

The first feature which I’d like to mention, which is probably unknown to most of you out there, is the support for RC6 technology. This is a feature which allows the GPU (in other words, the graphical adapter) to enter an extremely low power-consuming state while the graphical card is idle. This feature has drastic effects on the power usage of the system – up to 26% power usage improvements according to Phoronix testing. So in theory, having this feature enabled by default would allow a much better battery life for a casual system out there equipped with an Intel graphical card.

However, one drawback to the rc6 is that in some very rare cases, it results in different set of issues. The good part is that very few systems are affected by this bug, and none of the machines either the developers or QA team has managed to reproduce the problems, so chances are very high that it could just work for your by adding a ‘i915.i915_enable_rc6=1′ parameter to the kernel. The bad part is.. well.. the same as the good part – we could not reproduce the issues on any of the machines we had. So by a chance, if you enable this feature and hit some unexpected behavior or issue – please, let us know! We would be really interested in fixing this for all the systems out there. But, with all the magnitude of different x86-based machines, it is virtually impossible to test them all. So we need your help to help of us fix this issue, in case it affects your machine. All the details, such as the vendor, model, installed OS, whether the issue happens with a new install from scratch, bios configuration – would help.

FBC

Besides RC6, one other interesting feature present in the Intel graphical drivers is the support for framebuffer compression, of fbc. This feature allows the driver to store the contents of the picture on screen in a compressed format, effectively reducing the amount of energy (and, therefore, power) required to update the screen. On some hardware revisions, however, this feature sometimes causes the GPU not to redraw the display correctly, resulting in only partial screen updates, sometimes visible only after a few suspend-resume sequences. The solution for this problem was to disable this feature by default on such machines, while having it enabled automatically on the chips which do not reproduce the problem. However, even on those chips, you can always enable it manually, by using a i915.i915_enable_fbc=1 kernel parameter.

Semaphores

And finally, the 3rd major issue being worked on the kernel side is the usage of semaphores in the graphical driver, which allows for a big jump in performance, and also in stability in some cases. However, not everything is perfect in this world , so on some hardware models this feature results in performance choppiness or GPU hangs. It is within of the nature of the bug to appear only on some selected machines, most of which are out of our reach, so chances are, like with the RC6 and FBC features, it should just work out of the box. But if it does not – please, let us know!

Apart from those 3 big items, lots of work has been carried out on different components of the stack in the past months. I’ll try to summarize the most interesting points for each component below.

Kernel

The Linux kernel 3.1, which is quickly approaching its release date, brings lots of stability and performance improvements over 3.0 version. The performance results are the most notable ones, as according to the initial testing, you could expect about 25% performance improvements in 3D games and performance benchmarks (and even up to 40% in some of them). I won’t enter into the details here, as I am certain that Michal Larabel from Phoronix will do his usual round of benchmarks soon enough and provide the numbers .

Besides the performance fixes, the timing for detecting the different video outputs has also received lots of attention. Some of the fixes will appear in 3.1 kernel, and some of them are already being prepared to get into 3.2 as soon as its merge window will open.

And of course, there were lots of patches for stability and error recovery within GPU.

Out of the major distributions out there, as far as I know, only Mandriva Cooker has already updated its kernel to the latest 3.1 pre-released version, so its users already have most of those features with them. So if you are a brave soul and are willing to try this as soon as possible, you could either try Mandriva’s development version; or download and build the 3.1-git kernel yourself. Or just wait a few weeks and it will came to you as soon as your $FAVORITE_DISTRIBUTION would update it in the repository.

So, leaving kernel area, let’s move to another major component of the stack, which is well-known by its name..

MESA

(No, it is not the Black Mesa Research Facility, so you may put away your crowbar )

Lots of work has been done on Mesa library, and some thousands of emails on the mesa-dev mailing list complement this statement.

Some initial patches for HiZ support from Chad Versace landed on the list, and Phoronix has also performed initial testing on them, obtaining very impressive results.

Also, a huge cleanup of old drivers, together with the removal of old DRI1 code and overall refactoring of the code in preparation for the GL 3.0 was done by Ian Romanick. Kenneth Graunke provided lots of patches for both performance and stability improvements for a large number of cases, together with the IvyBridge-specific optimizations. New Vertex Shader backend, lots of TextureImage development by Eric Anholt, work on gl_ClipDistance and the layout of vertex attributes by Paul Berry, lots of GLSL 1.30 development and overall bugfixing complement the picture of what happened with Mesa for the past month or so.

As mesa-dev list, and the git source tree, are quite busy places, there were lots of other development and updates all around which I haven’t covered here. Mesa 7.11.1 and 7.12 are really going to be amazing releases when they will come out!

But leaving mesa, the next stop in the Intel Linux Graphics stack overview leads us to..

DDX, or xf86-video-intel X driver

The video driver for Intel graphics cards has received lots of attention for the past weeks. Most of the patches came from Chris Wilson, and were related to further improvements in the SNA backend, and a fix for a non-SNA-related X crash. Besides those, we also had some IvyBridge-specific fixes from Kenneth Graunke and cleanup of some warnings from Paulo Zanoni.

Cairo

On Cairo side, a huge work has been made on performance, stability and testing. In some workloads, the performance improved by several orders of magnitude, and in average, one could expect better performance for Cairo on most cases when comparing with the previous release.

Wayland

For Wayland compositor, lots of discussions took place in the wayland-devel mailing list, covering a large collection of topics, randing from the best way to process configuration events and requests, similarities and differences between the wayland protocol and X operations, window management and overall interaction between the clients and the compositor within the Wayland world. From the technical side, there were lots of patches from Tiago Vignatti and Kristian Høgsberg on both core wayland and the wayland-demos repository. One notable change was the change of the GPLv2 headers to MIT for the remaining files where such change wasn’t applied previously.

Intel-gpu-tools

The package for providing tools for debugging, analyzing, tracing and profiling the Intel graphical cards on Linux/Unix has received some code cleanups from Paulo Zanoni, some news tests from Daniel Vetter, and also a small series of patches from myself which allows it to work in a non-interactive way, generating a tab-separated list of performance values for each capturing points. Those events can be further analyzed with a statistical tool, or plotted with gnuplot, or dumped into openoffice calc/excel applications – you name it.

Libdrm

Libdrm, which is a glue between the kernel and the userspace applications that use the kernel graphical driver, has received some fixes from Daniel Vetter last week. Besides those, there was a fix to make ‘make check’ work correctly, and a support for using xf86drm.h from C++ applications.

Xserver

X.org X server has received lots of updates and merges since the 1.11.0 release in the past weeks. Among the most notable ones, there were some enhancements to the DRI2, XRANDR and DAMAGE extensions, documentation, comments and scripts fixes, besides the changes in the input framework.

VAAPI

And finally, as for VAAPI, not much activities happened in the git repo for the past weeks besides some refinements on the API and the vatrace tool.

So, as this post has already grown past the size I originally expected, I think that I’ll stop about here this time.

I’ll try to continue with the semi-regular blogging about the news in the graphics land of Intel world on a weekly basis.

See you! Eugeni

so, today is my last week at Mandriva/Conectiva! I think I said everything I had to say about this experience I had here in my previous posts, and I’d like to thank you a lot for all your kind words and feedback. So, as a parting gift for you, I prepared one small open-source tribute to the communities, users and developers out there.

As you all know, Mandriva (and now, Mageia as well) has its own set of tools and applications, some of which were developed solely – or mostly – by me for the past few years. Whenever possible, I was trying since the beginning to develop such tools and applications in a distribution-agnostic way, and I think I managed to do it fairly well (well, I tried ). Nothing in any of them depends specifically on Mandriva or Mageia, and not even on rpm infrastructure itself – and when it does, it is split into a separate plugin or customizable option.

However, as their customization and development outside of Mandriva/Mageia distributions is a bit hard due to the subversion repository access and availability, it certainly made them a bit non-inviting to new contributions (IMHO). So I decided to update those applications a bit in the past few days, and also made them available at my github site. I think that now, as we have both Mandriva and Mageia (at least) using some of the tools which share common code, it would be only fair to convert those projects into upstream ones, instead of making them incompatible forks of each other.

They are fully synchronized with Mandriva’s svn repository, but not with Mageia patches yet (however, this is easy to be done considering git flexibility, I just lacked time and bandwidth to do so). So yes, I’ll be still maintaining and developing them for the foreseeable future, but – as always – everyone is free to contribute, adapt and use them in the way you think the best.

So, without further words, those are my preciousssss toys:

• msec – Multi-Security Tool (a.k.a. Mandriva Security Tool and Mageia Security Tool), probably the one of the most hated (yet useful ) tools in Mandriva history. It is responsible for defining security on your machine, controlling file permissions, running periodic security checks, and so on. There are plenty of posts in this blog about its evolution for the past years as well. It was fully redesigned for Mandriva 2009.1 originally, and after that it gained a new UI, support for plugins, checks with customizable periodicity and arbitrary user-defined security levels. It does not depends on Mandriva/Mageia infrastructure for about 95% of its features, and the remaining 5% are controlled via plugins and configuration parameters.

• netprofile – Network profile tool. It allows you to define multiple network profiles, each with its own network, proxy, urpmi, firewall and other settings, and easily switch among them. Its UI is provided by drakx-net package (available only in Mandriva/Mageia), but the core functionality is distribution-independent. And at least I use it only in console, so it does not matters much for me .

• net_monitor – Network monitor. A simple network monitor which, besides network traffic accounting, also allows you to monitor the wireless signal level, used ports statistics, and integrates itself into network scripts via ifup/ifdown-based plugins. It also works with vnstat for nice usage statistics and reports generations. I also started to write a plasma backend for it, but never managed to finish it. Yet.

• Tomoyo GUI – Graphical Tomoyo configuration tool. Probably the first (and as far as I know, still the only one out there) graphical configuration utility for Tomoyo Security framework. It should work with both ccs-tools and tomoyo-tools, and supports automatic security profile generation, application behavior learning, profiles exporting/importing, and so on.

• s2u – Services 2 User, a small Mandriva tool used to share system messages with user desktop sessions via dbus. It is used by drakx-net infrastructure to notify user sessions when host name changes (thus assuring that the desktop continues working with new hostname), by msec to provide desktop notifications for security events, and by netprofile to provide desktop notifications on profile changes. It is a small tool, but as some of the aforementioned apps rely on it, it deserved its place on github as well.

There are many other Mandriva/Mageia-specific utilities, such as ldetect, mandi, drakx and its friends, drakguard, among many many many others. But they are very Mandriva/Mageia specific tools, and I don’t believe that their usage could be used outside of the scope of those distributions. But as for the aforementioned ones, I think that they could be very useful for other distributions as well.

Of course, besides me, all of those tools has received numerous contributions from old Mandriva/Mandrake/Conectiva developers, community members, translators and users. And I could not thank them more than by making their efforts available for the next generations of open-source users and communities!

So have fun and may the source be with you!

This topic arises frequently in all the corners of the world – how to remove even the smallest presence of pulseaudio and systemd from the system. Most Linux-aware people already know that, at least in most modern Linux distribution, there is no need to remove them at all – at least on Mandriva/Mageia-based distributions, both pulseaudio and systemd can be disabled entirely with a click of a mouse (inside draksound, or via ln -sf /etc/sound/profiles/alsa /etc/sound/profiles/current), or with a package removal/replacement (urpmi sysvinit) – but still, I frequently have the chance to met people who are offended by mere presence of said packages and files bearing the smallest similarity to the terms ‘pulse’, ‘audio’, and ‘systemd’ in their list of installed packages in files.

I have to say that I never had any problems with either pulseaudio or systemd for the past years, and I personally consider them as probably one of the most useful items in current generation of Linux distributions – they use most of computer features to provide many different multimedia aspects which otherwise are almost impossible to achieve without hard and tedious scripting and hacking (in case of pulseaudio); and they finally provide a powerful, modern and extremely efficient boot mechanism for Linux distributions (systemd). But.. each one has its own opinion, so who am I to speak for everyone?

So this motivated me to write this post – I’d like to specially thank the people from probably the best Russian open-source-oriented site – opennet.ru – for asking me for doing it. I decided to write it in English however, for 2 reasons:

1. Those questions arise in each and every language out there, and English is the lingua franca of todays world; and

2. I write much faster (and probably better ) in English than I do in Russian, specially when it comes to technical items and descriptions .

So let’s begin. I’ll split this tutorial in 3 big sections – how to find all the traces of pulseaudio and systemd in your system; how to exorcise all the traces of pulseaudio and systemd from all the found packages; and how to make a holy crusade to deliver those packages for the world (we all leave in open-source community after all) .

So..

PART I – how to find all the packages which rely on pulseaudio and systemd?

In Mandriva/Mageia and other rpm/urpmi-based systems, a very handy command is urpmf, which allows to search in the repositories for provides, conflicts, files, and so on. In our case, let’s start with pulseaudio, which is considered by The Root Of All Evil on Linux, Unix, and in All The World Under The Sun by some people out there.

To locate all the packages which require pulseaudio stack, let’s search for the packages requiring ‘libpulse’ – this will match packages which require the libpulse.so itself, libpulse-simple.so, libpulse-mainloop-*, and so on. This magical command would be:

# urpmf --requires libpulse

which will output something similar to:

padevchooser:libpulse-browse.so.0()(64bit)
padevchooser:libpulse-mainloop-glib.so.0()(64bit)
padevchooser:libpulse.so.0()(64bit)
lib64alsa-plugins-pulseaudio:libpulse.so.0()(64bit)
lib64mediastreamer1:libpulse.so.0()(64bit)
mplayer:libpulse.so.0()(64bit)
libpulsezeroconf0:libFLAC.so.8
libpulsezeroconf0:libICE.so.6
libpulsezeroconf0:libSM.so.6
libpulsezeroconf0:libX11-xcb.so.1
libpulsezeroconf0:libX11.so.6
...

The output format is: package:requires – e.g., it says for example that mplayer package is requiring libpulse.so.0()(64bit). However, as you can see, it would also list pulseaudio own packages as well (namely, libpulsezeroconf0). So let’s do a different command with some filtering:

# urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' | sort -u

This will list all the packages available in the repositories which require libpulse pattern.

However, as it is usually the case, not everyone wanting to get rid of pulseaudio wants to remove it completely from the distribution. Most of the time, he just wants to have his small, cozy system to be Truely Free from Lennart’s evil applications (c). So in this case, the following command will compare the results of the previous urpmf command with the list of the installed packages, and print the names of the source rpm files of installed packages which need to be exorcised:

# rpm -q $(urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' |\
  sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

This will pass the urpmf output to ‘rpm -q’ command, asking it to print the names of the source rpm files for each found package, skips the packages which are not installed, and sorts the output removing duplicates. In my case, the list became fairly small, containing only:

alsa-plugins-1.0.24-1.src.rpm
gstreamer0.10-plugins-good-0.10.30-2.src.rpm
kdebase4-runtime-4.6.5-6.src.rpm
kdemultimedia4-4.6.5-2.src.rpm
libcanberra-0.27-3.src.rpm
mplayer-1.0-1.rc4.0.r32713.6.src.rpm
paprefs-0.9.9-8.src.rpm
pavucontrol-0.9.10-8.src.rpm
phonon-4.5.0-4.src.rpm
pulseaudio-0.9.23-1.src.rpm
qemu-0.14.0-1.src.rpm

So, now we have the list of all packages which must be exorcised from the Pulseaudio evil influence! Let’s head for the Systemd-corrupted packages now.

In similar way to what we did to locate packages which need libpulse, let’s do a search for packages which have /lib/systemd files somewhere inside, with a simple:

# urpmf /lib/systemd

Once again, the list is quite bit – and it is a good thing, which means that most of the developers and packagers are adopting the systemd native units already! However, our goal is to remove the evil roots of systemd from such packages, so let’s find out which packages installed on our dear, sweet and comfortable system were possessed by the systemd spirit:

# rpm -q $(urpmf /lib/systemd | awk -F: '/:\/lib\/systemd\//{print $1}' \|
  | sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

Once again, the list is quite small (for my machine):

abrt-1.1.14-11.src.rpm
acpid-2.0.10-1.src.rpm
alsa-utils-1.0.24.2-1.src.rpm
avahi-0.6.29-1.src.rpm
consolekit-0.4.5-1.src.rpm
cups-1.4.6-5.src.rpm
dbus-1.4.6-2.src.rpm
initscripts-9.25-5.src.rpm
libcanberra-0.27-3.src.rpm
lm_sensors-3.3.0-5.src.rpm
rsyslog-5.8.2-1.src.rpm
rtkit-0.10-1.src.rpm
smartmontools-5.41-1.src.rpm
systemd-29-3.src.rpm
udev-168-1.src.rpm

But nonetheless, it is quite complete.

So, now we found packages which were tainted by the evil hands of Lennart Poettering (all credits for this phrase belong to opennet.ru), so let’s strip them of this unspeakable evil in the next part!

PART II – exorcising evil beings from innocent packages

Now that we have the list of packages tainted by evil spirits of pulseaudio and systemd, the next step is to remove their dependencies on such entities to make the users who are unable to tame with such unbelievable requirements became happy and in piece with their inner voices!

This section requires a bit of patience and rpm editing skills, so if you lack them probably it will be a bit confusing. In this case, I suggest you to read some references on how to package rpm files (this and this are a nice place to start in case of Mandriva and Mageia distributions).

For the old-school hackers out there, who install src.rpm packages by hand, the initial packaging unpacking is trivial – download the said packages and run rpm -ivh *.src.rpm, and you are done. For the ones who got used to Mandriva/Mageia facilities provided by repsys or mgarepo, the following commands probably would come in handy:

1. First, we need to find out the name of the package repo – in case of abrt-1.1.14-11.src.rpm it is ‘abrt’, in case of udev-168-1.src.rpm it is ‘udev’, and I’ll let you figure out the remaining ones as an exercise .

2. Second, for each package, we should run repsys co PACKAGE (or mgarepo co PACKAGE).

3. After that, package with all its sources and specs will become available in PACKAGE directory. So just go there, install the package build requirements, and you are all set.

Now, let’s go to the package exorcism itself. First at all, you have to figure out IF the pulseaudio evil could be stripped from the package during the build process. If it is not possible, well, you have no other solution besides:

1. Writing your own clone of the package
2. Writing a patch to the package to not require pulseaudio anymore
3. Ask upstream developers to remove those functionality from their packages specially for you, out of good will and companionship spirit.

(Somehow I suspect that the 3rd alternative won’t be quite easy in some cases, but one never knows…).

Let’s take for example mplayer package, and use it as example of pulseaudio exorcism. Looking at mplayer.spec file, we cannot find anything which looks like disable this option to disable pulseaudio forever, which is, without any doubts, sad. However, if we take a closer look, there is a %define build_pulse 1 option which definitely looks a bit suspicious. If we change it to %define build_pulse 0, search deeper within the package for the build_pulse flag usage, and add a --disable-pulse option to the build, and rebuild the package with bm -l – then voila! It will build mplayer package without any reference to pulseaudio. Yes, we just had our first package liberated from pulseaudio evil!

In other words, simple patch the package with as follows:

Index: SPECS/mplayer.spec
===================================================================
--- SPECS/mplayer.spec  (revision 691091)
+++ SPECS/mplayer.spec  (working copy)
@@ -56,7 +56,7 @@
 %define build_alsa 1
 %define build_jack 1
 %define build_openal   0
-%define build_pulse    1
+%define build_pulse    0
 %define build_schroedinger 1
 %define build_twolame 0
 %define build_lame 0
@@ -206,6 +206,7 @@


 Name:      %{name}
+Epoch:     9999 # to prevent future upgrades
 Version:   %{version}
 Release:   %{release}%{?extrarelsuffix}
 Summary:   %{Summary}
@@ -630,6 +631,8 @@
 %endif
 %if %build_pulse
        --enable-pulse \
+%else
+   --disable-pulse \
 %endif
 %if !%build_openal
        --disable-openal \

We could check it with rpm -qp --requires RPMS/*/*rpm | grep pulse.

And one important thing comes into mind – how to prevent future upgrades from the distribution to remove all your hard work and changes? One extremely evil, painful and non-rollbackable solution would be to add something like:

Epoch: 9999

into each .spec file. This way, until the distribution reaches this number of package versioning resets, your own packages will take priority above anything distribution says (yes, I told that it would be an evil and extremely hackish solution) .

Now it is only necessary to repeat the same process with all other pulse-depending packages. Of course, for some of them (for example, qemu) it is not easy, because pulseaudio support is builtin. In this case, the following options apply – you could either write a patch to remove its support, or ask upstream to build a specific qemu package specially for you without pulseaudio support .

As for systemd, the similar strategy applies – with the difference that it would be easier to strip support for systemd in the packages. Just remove all the ‘/lib/systemd’ entries in .spec files, or prepend them with ‘%exclude’ tag, and the support for systemd in said packages will be gone.

In short, resuming this section, if you want to remove pulseaudio and systemd support from your packages, you have to exercise some coding and packaging skills. Unfortunately (for you), most of Linux distributions and environments believe that pulseaudio and systemd are cool and great technologies, so they provide them by default, and it is not very likely that you’ll have any distribution with such changes applied by default… So what could you do now?

The next part explains..

PART III – carrying on a anti-pulse-and-systemd crusade in 2 simple steps

If you want to have any distribution come out without systemd and pulseaudio, you basically have 2 choices.

1. Make a fork of a distribution, maintain it yourself, and add the packages without pulseaudio/systemd support there. This is the most suitable thing to do if you want to have your own distribution and become rich and famous . Alternatively, you have the solution 2. Yet more alternatively, there is always a way to start a brand new distribution yourself.

2. Create your own repository for packages liberated from pulseaudio and systemd evil influence. This is easier because you don’t need to do the entire distribution on your own, and usually a simple directory on a web-server or ftp would suffice. To follow this path, the following steps should be done:

   2.1. Copy all the resulting packages into a directory

   2.2. Run genhdlist2 directory

   2.3. Put the resulting directory on your http/ftp/rsync server for others to grab it.

This will prepare a Mandriva/Mageia-compatible repository, and when you put it onto a web or ftp server, just share its address with the world, and everyone will be able to add it by running:

# urpmi.addmedia diepulseandsystemd http://your.server.address/repository/$ARCH

This way, on the next urpmi --auto-update run, urpmi will discover that packages from such repo has absolutely higher priority over all possible packages provided by the distribution, and will install them automatically, replacing the currently installed and the available ones. With this, having all the packages freed from the evil pulseaudio and systemd reference, pulseaudio-related packages and libraries will be marked as orphans, and will be removed automatically when you run urpme --auto-orphans.

Therefore, this completes my quick tutorial on how to cleanup the evil presence of pulseaudio and systemd from the packages on a Mandriva/Mageia-based system. Of course, it is possible to improve the packaging, define custom disttags and –with flags for the build, but this text is already becoming too big so I left it out of the scope for now.

So to conclude, I hope you have enjoy reading it as much as I enjoyed this writing .

If you tried to install VirtualBox from its official binaries available at the official site on Mageia, you perhaps have realized that it won’t install itself due to a missing libcrypto.so.0.9.8.

Where this library comes from? Let’s go for a bit of history of openssl in latest Mandriva releases..

Back in pre-Mandriva-2010.1 era, I was the one responsible for upgrading openssl library to the official 1.0.0 release, which was released after almost a decade of development. And according to Mandriva library policy, which allows multiple libraries with different major versions to coexist, this resulted in having available both libopenssl1.0.0-version-release.rpm and libopenssl0.9.8-version-release.rpm, which was carried out from the old build. It was still kept for backward-compatibility issues, and also for third-party packages compatibilities (as almost nobody has migrated to openssl 1.0.0 back then). And at some point, (almost) all of the Mandriva packages were rebuilt to use OpenSSL 1.0.0 libraries correctly.

However, this also resulted in the package libopenssl0.9.8 becoming orphan – it had no corresponsing .src.rpm in the repository, as the source rpm was providing only libopenssl1.0.0 library now. But as for binary package, it was left there, as there were additional applications requiring it.

When Mageia folks has forked the Mandriva repository, they did a correct think – they fully rebuilt all the packages from their source files, resulting in a complete, fully rebuildable and non-ambiguous repository. However, the libopenssl0.9.8 went missing in action – as it had no corresponding source package anymore, it became unavailable.

So finally, after almost a year since the openssl 1.0.0 migration, I’ve discovered one 3rd-party package which was still relying on openssl 0.9.8 to be available – Oracle’s VirtualBox packages. This is why such question arose.

There are many ways to solve this problem, ranging from creating a new package specifically for openssl0.9.8 (most ugly one), to creating dumb symlinks from libcrypto.so.1.0.0 to libcrypto.so.0.9.8 (most workaroundish and dangerous one), to persuading Oracle devs to build their VirtualBox packages on post-2010.1 Mandriva versions (most correct one), and so on.

However, I just took a simple route, and simple did

urpmi http://ftp.free.fr/pub/Distributions_Linux/MandrivaLinux/devel/cooker/x86_64/media/main/release/lib64openssl0.9.8-0.9.8n-1mdv2010.1.x86_64.rpm.

(or, for 32bits installations):

urpmi http://ftp.free.fr/pub/Distributions_Linux/MandrivaLinux/official/2010.1/i586/media/main/release/libopenssl0.9.8-0.9.8n-1mdv2010.1.i586.rpm

This is certainly not the right thing to do, but it works .

(Of course, everything said here is my personal opinion, and in no way I am trying to say something on behalf of Mandriva Board of directors)

First of all, what comes into mind when you think about the term ‘Linux Distribution’? I bet that names like Fedora, Ubuntu, Mandriva, Debian, Slackware, Arch, Gentoo – and many others come into mind.

However, what names come into mind when you think about Desktops? I believe that in this case, the names which feel most like it are Mac, Windows, Android, Meego, BeOS, ChromeOS, JoliCloud, and so on. Some of them are running proprietary OSes, some of them are partly open, and some of them are actually based on a Linux distribution or a Linux kernel and libraries stack.

And finally, what comes into mind when you think about the term ‘Linux Desktop’? Without holy wars and discussion which distribution is better (notice the word distribution here), I believe that it is hard to escape from the names as Ubuntu, Mandrake, Linspire, SLED, and similar solutions.

Some of you perhaps have already got my point. What makes a “Desktop” is not a mere combination of packages, applications, community and artwork; but it is the integration and common feeling among all of its components, and somewhat inherited desire of having a ‘standard’ way of doing everything. And Linux Distributions, on their turn, inherently have the essence of freedom of choice, flexibility and multitude of combinations of applications and goals within, which make them much more flexible on one hand, but much less focused on another.

Why Linux distributions will never (in my humble opinion) beat Windows or MacOS on desktop? By a one simple reason – they are too flexible. They provide too many options and possibilities by default, without a ‘standard’ way of doing things, and while everything works and is usually tightly integrated, this is still a combination of packages and applications, and not a Desktop. This is not a bad thing – by the contrary, I believe that this is awesome! But this opposite to what is expected from a Desktop experience.

On other turn, the Desktops which managed to succeed in the history of computers are the ones which started with a vision, and according to this vision, has evolved into a combination of applications, features, standardization and look-and-feel which made them unique.

If you think about productive and efficient desktop, Mac OS comes into mind. Even if it (with some bit of imagination) could be considered a distribution (it has lots of non-apple applications, gnu stack, unix infrastructure under it, and so on) – it is rarely seen as one. It is a desktop, it has its own unique feeling and usage.

It is the same feeling which we have for Android, Chrome, JoliCloud – even if they are, in fact, Linux distributions, they are not seen as such. They are products – with their own features, functionality, feeling, goals, and so on. They have a focus, they have a unique and controlled roadmap and goal, and this is what makes them more focused on that goal.

And this is the road where Ubuntu, and now Mandriva, are headed – running away from being ‘Linux distributions’ in the most common sense of the word, towards becoming Desktops. Ubuntu GNU/Linux Distribution has already become just ‘Ubuntu’. It is still a Linux distribution, it is based on shoulders of the giants, but it is not just another distribution out there – it became a Desktop, with its own look-and-feel, functionality, goals, features and behavior.

This is how Android and ChromeOS evolved as well – even if they are, in fact, Linux distributions, they are not seen as such, but as separated and unique products. This is what JoliCloud did as well, and this is what Linspire did in the past.

In other words, when separating Linux Distributions with Desktop solutions, it is possible to imagine a simple scale, ranging from freedom of choice, flexibility and non-prioritization of specific DEs and UIs – to single and unique look-and-feel, restricted flexibility and focus on specific features and details. The further away from the ‘flexibility’ and ‘freedom of choice’ a solution is moving, the closer it gets to become a product with ‘Desktop’ name in it.

Most Linux distributions value freedom of choice and diverse and mulch-opinionated community among everything else. They treat KDE as good as GNOME, and do not consider XFCE and LXDE as 2nd-class citizens. Every one is able to select what he wants to use, mix applications – and there are no restrictions nor enforcements on how his desktop should work.

In other corner, there are Desktop products – which enforce a single and common look-and-feel and mode of operation, define behaviors, and are focused on one single and unique way of doing anything.

And this is basically what I think on the matter .

So now it is powered by the amazing Suffusion theme for wordpress. And, at least in my opinion, it looks much more clean and cool. Please let me know if you find any problems, or if anything that was working suddenly has stopped.

Having said that, the ones of you running wordpress blogs on custom mandriva-based sites, please note that there is a new version of it in Mandriva available in cooker (contrib/release) and 2010.1 and 2011 branches (in contrib/testing), thanks to Adam Williamson, its maintainer.

Yes, yes – I believe that you have noted that there is a new 2011 branch of Mandriva now, which is going on in parallel with Mandriva cooker! As I promised last year, our idea for Mandriva was to provide this a bit before the release – a rolling cooker version of the distribution; and a stable branch which will be supported for 3 years. It is called just 2011, and will have the same way of living and being supported as we did with Mandriva 2010.2 – the first release will become 2011.0; after 6 months or so there will be just an incremental updated isos and images (2011.1), and then 2011.2 which should be out of the door somewhat together with the Mandriva 2012 version.

As for Mandriva 2013, I won’t promise anything now – with all that Maya prophecies it is hard to forecast something. (Just kiddin’ of course )

Hi folks,

as some of you already know, this is my last month at Mandriva/Conectiva.

So I am writing this blog post to summarize a bit of what the Mandriva experience was for me.

When I came to work officially at Mandriva back in 2008 (I was already in close contact with many Conectiva and Mandriva developers for some years then), I was expecting a lot from this challenge. The possibility to work in an open-source-based company, developing open-source solutions and products for everyone – it was practically my geek dream coming true. And I have to say now, after 2.5 years since that moment, that it was certainly an amazing experience.

While at Mandriva, I managed to work on many challenging yet amazingly interesting projects; I had the privilege to work with extremely talented people from all the corners of the world – Canada, Brazil, France, Sweden, Russia – just to name a few! And it certainly was an unforgettable experience for me.

During all those years, I managed to work a bit on probably each and every Mandriva product – as a developer/maintainer for Mandriva Distribution (2009.0, 2009.1, 2010.0, 2010.1, 2010.2, 2011); as member of Mandriva Security team first with Vincent Danen, and then with Oden Eriksson, providing several thousands packages via official updates for the whole range of Mandriva products (MNF2, CS3, CS4, Mandriva 2007.0 to 2010.2); working on dozens of research and development projects (msec, tomoyo-gui, mandriva cloud, mandriva edu, and many others, some of which did not came out of the door yet, so I won’t comment on them ), developing several custom solutions for Brazilian customers, and of course countless packages..

For the past year, I also had the honor to be the technical leader and manager of Conectiva team in Brazil. And of course, as you all know, for past 9 months I was the responsible for Mandriva Desktop distributions development, leading the Mandriva 2010.2 and Mandriva 2011 products (which should be out in less than 2 months from now!).

During those years, I had the privilege to get to know and work alongside such legendary figures in the open-source world as ennael, cavassin, blino, tv, fcrozat, pterjan, rtp, teuf, neoclust, ahmad samir, götz, misc, pixel, pcpa, claudio, miura, herton, santiago, jbj, boiko, tmb, rda, colin, guillomovitch, lcapitulino, vdanen, heliocastro, bogdano, oden, aginies, anssi, adamw, … just to name a few, and of course many many others! It was a real honor, and I learned a lot with you all!

And of course, I had the chance to meet (and be the one responsible for bringing some of them ) the newly-rising stars in both Mandriva and open-source world, such as gmoro, wiliam, paulob, alexandrefm, edgard, franck, jvdm, leonardoc, denis koryavov, alex burmashev, eugene sokolov, ural mullabaev, kirill monakhov – and many other talented developers from Mandriva, Conectiva and ROSA! If you are using Mandriva, or will be using its 2011 version – you’ll certainly encounter the fruits of their work!

So, definitely, it was an amazing and priceless experience!

However, times change, people change, and I realized that time has come for me to sail to new horizons and look for new challenges. Many things changed in Mandriva during those 2.5 years, and it is a completely different company from what it once was. Many people had left, and many new faces has arrived as well during this time. But nonetheless, albeit all the challenges, problems, disappointments and achievements, we managed to stay alive and kicking even in cases where nobody was believing that Mandriva would survive. But it did.

So I’d like to thank you all for the time we spent together trying to make a Linux distribution which would change the world – I believe that we did a not that bad job over those past years!

Mandriva 2011 is almost at the release bay with all of its enhancements and unique features; Mageia 1 is there and Mageia 2 is starting its sail towards its exciting new release. Future looks bright for everyone – and I am really happy about it.

So, I’ll be around in Mandriva (the company) until the end of this month, and I’ll certainly be around in Mandriva and Mageia communities afterwards! And, of course, in the open-source world as a whole .

Cheers,

Eugeni

The pictures from my previous post, of AltLinux booth at FISL – the ones saying that the Russian President and Prime-Minister are users of AltLinux distribution – has caused lots of repercussion on several sites and forums.

Unfortunately, from what I was told, such pictures were done for marketing purpose-only (or in some sort of a joke), are purposely misleading, and were limited to Brazil only. Central AltLinux office did not knew anything about them, and it is not clear whether they were done as some sort of joke, PR or attempt to spread some of the Russian culture in South America via some “unconventional” means (according to what I learned on ru-foss livejournal community).

So I’d like to apologize here for publishing them if it caused any sort of distress or confusion. In my personal opinion, I believe that if you put some misleading public posters on your company’s official booth, on an international and widely-known conference, just for some PR effect, it is not a correct thing to do. And if you do it, be aware that a Linux-related conference certainly will have lots of people taking and sharing what you are demonstrating.

So, just to clarify and answer to all the questions I am receiving:

NO, VLADIMIR PUTIN AND DMITRY MEDVEDEV ARE NOT USING AltLinux – or any other Linux distribution at all.

However, I still hope that perhaps they will use Linux some day .