[Nix-dev] What kills my xserver?

Mathijs Kwik mathijs at bluescreen303.nl
Thu May 10 15:24:27 CEST 2012


On Thu, May 10, 2012 at 2:38 PM, Arie Middelkoop <amiddelk at gmail.com> wrote:
> On 10/05/12 10:57, Cillian de Róiste wrote:
>> On Thu, May 10, 2012 at 12:05 AM, Arie Middelkoop<amiddelk at gmail.com>  wrote:
>>> Actually, I recall that the Nixos manual mentions that it's possible to test
>>> your system in a virtual machine. I wonder if this could help in ruling out
>>> hardware issues. Virtualized hardware is hopefully more deterministic among
>>> different systems than real hardware...
>>
>> That's a nice idea, I ran some tests based on the instructions here a
>> while back: http://nixos.org/wiki/NixOS_VM_tests
>
> Ok, I can confirm that the shutdown issue must be a hardware issue,
> because I have no problems when running my system in a virtual machine.
> I should have thought of this earlier :)
>
> This also means that it is for me rather hopeless to try and fix this...

Just a wild guess, but if I remember correctly, you had these
black-blocky artifacts under kde some time ago right?
I had those too, and found upgrading the intel driver to at least 2.15
or higher (I'm using 2.17) fixed this.
Officially, 2.15 is not really meant to work with the current xserver
version we have in nixpkgs.
I remember slightly upgrading a few x proto thingies as well to get
around compile-time version issues.

As you can see at http://intellinuxgraphics.org , intel does a rather
good job of maintaining and testing the entire driver architecture
(from kernel level to high level x/opengl/va), but they only test
specific combinations of the stack. Probably, little differences like
1.2.2 -> 1.2.3 aren't gonna cause trouble, but 1.2.2 -> 1.3.x might.

If we look at Xorg versioning in general, it's quite messy. There are
some big "official" releases, like Xorg 7.6 or Xorg 7.7, which exactly
specify which versions of xserver and every lib/proto are sure to work
together. But those releases are so far apart, that just
conservatively sticking to those versions will lead to recent hardware
being unsupported. So every distro I know of just upgrades the
individual packages, and usually everything works out pretty well when
you stick to the latest versions of everything (as those are probably
tested together a lot by individual X developers).

However, it seems nixos X11/xorg maintainers just cannot always keep
up with all these upgrades. I really don't blame them, as there are
really a lot of x-related changes all the time, and they aren't just
simple version-number-changes every time, but packages
splitting/merging too and dependencies changing. So, with the small
contributor-base we have, the X11 upgrades cycle seems to be driven by
individual needs, and probably by the big overall Xorg releases. There
was a nice mesa/drm/opengl/3d upgrade a few months back, but on
average, there's not a lot of X upgrades. As X issues tend to be
hardware-related most of the time, just blindly upgrading things is
likely to cause errors for certain users, that won't be caught at
compile-time. So in fact it's probably safer most of the time to just
stick to stuff that works.

Well, back to my original story (I should probably just start a blog,
I seem to write long emails all the time :)...
Looking at all current versions of x-related components on nixos, the
one thing really lacking behind is xserver itself. It's 1.9.x, which
was last tested by intel for their 2010Q4 release, with the old (2.14)
driver (the black-blocky one).
The 2.15 driver recommends xserver 1.10.x, while the 2.17 one I'm
using recommends 1.11.x.

I'm not saying this _is_ the problem, but if you really don't know
where to start, I think upgrading xserver might be a good start. I
looked into it some time ago, but it's quite a few dependencies there.
xserver itself doesn't cause a lot of rebuilds, but most
libraries/proto stuff does trigger a rebuild of all gui apps.

I hope this helps.
Mathijs

>
> Arie
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


More information about the nix-dev mailing list