As a Friday gift for you readers, I have another round of updates about the Intel Linux Graphics development during this week.
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?
