On Thu, May 10, 2012 at 2:38 PM, Arie Middelkoop <[email protected]> wrote: > On 10/05/12 10:57, Cillian de Róiste wrote: >> On Thu, May 10, 2012 at 12:05 AM, Arie Middelkoop<[email protected]> 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 > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
