* Xorg tearing fix on Intel HD Graphics 4000 @ 2017-06-21 7:55 Roel Janssen 2017-06-21 10:38 ` Ricardo Wurmus ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Roel Janssen @ 2017-06-21 7:55 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 470 bytes --] Dear Guix, For a long time now, I have a tearing issue on GuixSD (parts of the screen do not get updated while others do, resulting in dissapearing text in Emacs). With the following patch to the Xorg configuration file, I have a tear-free GuixSD experience. I wonder if this is upstreameable in some way. This patch is probably too broad in effect. Can I change it so that only the graphics card I have will be affected by this patch? Kind regards, Roel Janssen [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-gnu-services-xorg-Fix-tearing-issue.patch --] [-- Type: text/x-patch, Size: 896 bytes --] From 25b431d23071b325b50c584977fcd6c1f9d790af Mon Sep 17 00:00:00 2001 From: Roel Janssen <roel@gnu.org> Date: Wed, 21 Jun 2017 09:44:46 +0200 Subject: [PATCH] gnu: services: xorg: Fix tearing issue. * gnu/services/xorg.scm (xorg-configuration-file): Fix tearing issue. --- gnu/services/xorg.scm | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 5bae8c18e..97f92ab53 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -133,6 +133,13 @@ EndSection Section \"ServerFlags\" Option \"AllowMouseOpenFail\" \"on\" EndSection + +Section \"Device\" + Identifier \"Intel Graphics\" + Driver \"intel\" + Option \"AccelMethod\" \"uxa\" #sna + Option \"DRI\" \"2\" +EndSection " (string-join (map device-section drivers) "\n") "\n" (string-join (map (cut screen-section <> resolutions) -- 2.13.1 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 7:55 Xorg tearing fix on Intel HD Graphics 4000 Roel Janssen @ 2017-06-21 10:38 ` Ricardo Wurmus 2017-06-21 13:26 ` Roel Janssen 2017-06-23 18:00 ` Christopher Baines 2017-06-26 8:55 ` Andy Wingo 2 siblings, 1 reply; 24+ messages in thread From: Ricardo Wurmus @ 2017-06-21 10:38 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel Hi Roel, > With the following patch to the Xorg configuration file, I have a > tear-free GuixSD experience. I wonder if this is upstreameable in some > way. This patch is probably too broad in effect. Can I change it so > that only the graphics card I have will be affected by this patch? I’m not sure about this, but you can apply it only to your system by changing the slim-service’s “startx” value like this: --8<---------------cut here---------------start------------->8--- (modify-services %desktop-services (slim-service-type config => (slim-configuration (inherit config) (startx (xorg-start-command #:configuration-file (xorg-configuration-file #:extra-config (list your-fix))))))) --8<---------------cut here---------------end--------------->8--- But I suppose what you want is to apply it unconditionally in Guix and have the X server ignore it for all but this one graphics card, right? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 10:38 ` Ricardo Wurmus @ 2017-06-21 13:26 ` Roel Janssen 2017-06-21 16:27 ` Kei Kebreau ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Roel Janssen @ 2017-06-21 13:26 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel Ricardo Wurmus writes: > Hi Roel, > >> With the following patch to the Xorg configuration file, I have a >> tear-free GuixSD experience. I wonder if this is upstreameable in some >> way. This patch is probably too broad in effect. Can I change it so >> that only the graphics card I have will be affected by this patch? > > I’m not sure about this, but you can apply it only to your system by > changing the slim-service’s “startx” value like this: > > --8<---------------cut here---------------start------------->8--- > (modify-services %desktop-services > (slim-service-type > config => (slim-configuration > (inherit config) > (startx (xorg-start-command > #:configuration-file > (xorg-configuration-file > #:extra-config > (list your-fix))))))) > --8<---------------cut here---------------end--------------->8--- > > But I suppose what you want is to apply it unconditionally in Guix and > have the X server ignore it for all but this one graphics card, right? No, not necessarily. I could no longer do 'guix pull && guix system reconfigure ...', which I attempted to solve by upstreaming this patch. I wonder if anyone else is having the same problem on this hardware.. Thanks for your snippet! I've done a system reconfigure and the extra configuration applied as expected. If there is anyone with the same problem, we could look further into upstreaming it. Thanks, Roel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 13:26 ` Roel Janssen @ 2017-06-21 16:27 ` Kei Kebreau 2017-06-21 17:23 ` Mark H Weaver 2017-06-25 5:46 ` Chris Marusich 2 siblings, 0 replies; 24+ messages in thread From: Kei Kebreau @ 2017-06-21 16:27 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1842 bytes --] Roel Janssen <roel@gnu.org> writes: > Ricardo Wurmus writes: > >> Hi Roel, >> >>> With the following patch to the Xorg configuration file, I have a >>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>> way. This patch is probably too broad in effect. Can I change it so >>> that only the graphics card I have will be affected by this patch? >> >> I’m not sure about this, but you can apply it only to your system by >> changing the slim-service’s “startx” value like this: >> >> --8<---------------cut here---------------start------------->8--- >> (modify-services %desktop-services >> (slim-service-type >> config => (slim-configuration >> (inherit config) >> (startx (xorg-start-command >> #:configuration-file >> (xorg-configuration-file >> #:extra-config >> (list your-fix))))))) >> --8<---------------cut here---------------end--------------->8--- >> >> But I suppose what you want is to apply it unconditionally in Guix and >> have the X server ignore it for all but this one graphics card, right? > > No, not necessarily. I could no longer do 'guix pull && guix system > reconfigure ...', which I attempted to solve by upstreaming this patch. > > I wonder if anyone else is having the same problem on this hardware.. I have the same problem on Intel GM45 graphics (in the Thinkpad X200). I'm going to try Ricardo's snippet as well and see if things get better. > > Thanks for your snippet! I've done a system reconfigure and the extra > configuration applied as expected. > > If there is anyone with the same problem, we could look further into > upstreaming it. > > Thanks, > Roel [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 13:26 ` Roel Janssen 2017-06-21 16:27 ` Kei Kebreau @ 2017-06-21 17:23 ` Mark H Weaver 2017-06-21 22:21 ` Roel Janssen 2017-06-25 5:47 ` Chris Marusich 2017-06-25 5:46 ` Chris Marusich 2 siblings, 2 replies; 24+ messages in thread From: Mark H Weaver @ 2017-06-21 17:23 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel Hi Roel, Roel Janssen <roel@gnu.org> writes: > Ricardo Wurmus writes: > >> Hi Roel, >> >>> With the following patch to the Xorg configuration file, I have a >>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>> way. This patch is probably too broad in effect. Can I change it so >>> that only the graphics card I have will be affected by this patch? >> >> I’m not sure about this, but you can apply it only to your system by >> changing the slim-service’s “startx” value like this: >> >> --8<---------------cut here---------------start------------->8--- >> (modify-services %desktop-services >> (slim-service-type >> config => (slim-configuration >> (inherit config) >> (startx (xorg-start-command >> #:configuration-file >> (xorg-configuration-file >> #:extra-config >> (list your-fix))))))) >> --8<---------------cut here---------------end--------------->8--- >> >> But I suppose what you want is to apply it unconditionally in Guix and >> have the X server ignore it for all but this one graphics card, right? > > No, not necessarily. I could no longer do 'guix pull && guix system > reconfigure ...', which I attempted to solve by upstreaming this patch. > > I wonder if anyone else is having the same problem on this hardware.. I have the same problem on my Thinkpad X200. For me, it mostly only happens in Emacs graphical frames, and only within GNOME (and I suppose maybe other compositing window managers, though I haven't tried), but the problem for me is quite severe. I've resorted to running Emacs in text mode within GNOME Terminal, because otherwise I cannot trust my editing at all (e.g. I'm not sure if I'm deleting the messages that I intend to delete in Gnus). However, your proposed workaround is not a proper fix, and I don't think we should apply it system-wide in Guix. I don't think it would be accepted upstream. I think there's a real bug somewhere, most likely in Emacs itself, but possibly in the Intel graphics drivers. It's good to have the workaround though. I may apply it to my own system and see how it affects graphics performance. Thank you! Mark ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 17:23 ` Mark H Weaver @ 2017-06-21 22:21 ` Roel Janssen 2017-06-21 23:23 ` William 2017-06-25 5:47 ` Chris Marusich 1 sibling, 1 reply; 24+ messages in thread From: Roel Janssen @ 2017-06-21 22:21 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel Mark H Weaver writes: > Hi Roel, > > Roel Janssen <roel@gnu.org> writes: > >> Ricardo Wurmus writes: >> >>> Hi Roel, >>> >>>> With the following patch to the Xorg configuration file, I have a >>>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>>> way. This patch is probably too broad in effect. Can I change it so >>>> that only the graphics card I have will be affected by this patch? >>> >>> I’m not sure about this, but you can apply it only to your system by >>> changing the slim-service’s “startx” value like this: >>> >>> --8<---------------cut here---------------start------------->8--- >>> (modify-services %desktop-services >>> (slim-service-type >>> config => (slim-configuration >>> (inherit config) >>> (startx (xorg-start-command >>> #:configuration-file >>> (xorg-configuration-file >>> #:extra-config >>> (list your-fix))))))) >>> --8<---------------cut here---------------end--------------->8--- >>> >>> But I suppose what you want is to apply it unconditionally in Guix and >>> have the X server ignore it for all but this one graphics card, right? >> >> No, not necessarily. I could no longer do 'guix pull && guix system >> reconfigure ...', which I attempted to solve by upstreaming this patch. >> >> I wonder if anyone else is having the same problem on this hardware.. > > I have the same problem on my Thinkpad X200. For me, it mostly only > happens in Emacs graphical frames, and only within GNOME (and I suppose > maybe other compositing window managers, though I haven't tried), but > the problem for me is quite severe. I've resorted to running Emacs in > text mode within GNOME Terminal, because otherwise I cannot trust my > editing at all (e.g. I'm not sure if I'm deleting the messages that I > intend to delete in Gnus). > > However, your proposed workaround is not a proper fix, and I don't think > we should apply it system-wide in Guix. I don't think it would be > accepted upstream. I think there's a real bug somewhere, most likely in > Emacs itself, but possibly in the Intel graphics drivers. Thanks for your response! I look forward to finding out what this bug is. If you do, please let us know. > > It's good to have the workaround though. I may apply it to my own > system and see how it affects graphics performance. Thank you! FWIW, I get equal frames per second in SuperTuxKart and Armagetron. Anyway, there's nothing like experiencing it yourself of course. Kind regards, Roel Janssen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 22:21 ` Roel Janssen @ 2017-06-21 23:23 ` William 2017-06-25 11:59 ` Marius Bakke 0 siblings, 1 reply; 24+ messages in thread From: William @ 2017-06-21 23:23 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel The Arch Wiki says that Debian and some others suggest uninstalling xf86-video-intel and relying on the modesetting driver. I have personally found this to help with tearing, but naturally YMMV. See https://wiki.archlinux.org/index.php/Intel_graphics#Installation for more details. Good luck William On 21 June 2017 at 23:21, Roel Janssen <roel@gnu.org> wrote: > > Mark H Weaver writes: > >> Hi Roel, >> >> Roel Janssen <roel@gnu.org> writes: >> >>> Ricardo Wurmus writes: >>> >>>> Hi Roel, >>>> >>>>> With the following patch to the Xorg configuration file, I have a >>>>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>>>> way. This patch is probably too broad in effect. Can I change it so >>>>> that only the graphics card I have will be affected by this patch? >>>> >>>> I’m not sure about this, but you can apply it only to your system by >>>> changing the slim-service’s “startx” value like this: >>>> >>>> --8<---------------cut here---------------start------------->8--- >>>> (modify-services %desktop-services >>>> (slim-service-type >>>> config => (slim-configuration >>>> (inherit config) >>>> (startx (xorg-start-command >>>> #:configuration-file >>>> (xorg-configuration-file >>>> #:extra-config >>>> (list your-fix))))))) >>>> --8<---------------cut here---------------end--------------->8--- >>>> >>>> But I suppose what you want is to apply it unconditionally in Guix and >>>> have the X server ignore it for all but this one graphics card, right? >>> >>> No, not necessarily. I could no longer do 'guix pull && guix system >>> reconfigure ...', which I attempted to solve by upstreaming this patch. >>> >>> I wonder if anyone else is having the same problem on this hardware.. >> >> I have the same problem on my Thinkpad X200. For me, it mostly only >> happens in Emacs graphical frames, and only within GNOME (and I suppose >> maybe other compositing window managers, though I haven't tried), but >> the problem for me is quite severe. I've resorted to running Emacs in >> text mode within GNOME Terminal, because otherwise I cannot trust my >> editing at all (e.g. I'm not sure if I'm deleting the messages that I >> intend to delete in Gnus). >> >> However, your proposed workaround is not a proper fix, and I don't think >> we should apply it system-wide in Guix. I don't think it would be >> accepted upstream. I think there's a real bug somewhere, most likely in >> Emacs itself, but possibly in the Intel graphics drivers. > > Thanks for your response! I look forward to finding out what this bug > is. If you do, please let us know. > >> >> It's good to have the workaround though. I may apply it to my own >> system and see how it affects graphics performance. Thank you! > > FWIW, I get equal frames per second in SuperTuxKart and Armagetron. > Anyway, there's nothing like experiencing it yourself of course. > > Kind regards, > Roel Janssen > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 23:23 ` William @ 2017-06-25 11:59 ` Marius Bakke 2017-06-25 17:13 ` Roel Janssen 0 siblings, 1 reply; 24+ messages in thread From: Marius Bakke @ 2017-06-25 11:59 UTC (permalink / raw) To: William, Roel Janssen; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 647 bytes --] William <w@vieta.uk> writes: > The Arch Wiki says that Debian and some others suggest uninstalling > xf86-video-intel and relying on the modesetting driver. > > I have personally found this to help with tearing, but naturally YMMV. > > See https://wiki.archlinux.org/index.php/Intel_graphics#Installation > for more details. Many distros default to using the built-in xorg modesetting driver. https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/ https://fedoraproject.org/wiki/Features/IntelKMS Could those affected by this bug see if it works for them? Maybe we should follow suit. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 11:59 ` Marius Bakke @ 2017-06-25 17:13 ` Roel Janssen 2017-06-25 17:39 ` Marius Bakke 0 siblings, 1 reply; 24+ messages in thread From: Roel Janssen @ 2017-06-25 17:13 UTC (permalink / raw) To: Marius Bakke; +Cc: guix-devel, William Marius Bakke writes: > William <w@vieta.uk> writes: > >> The Arch Wiki says that Debian and some others suggest uninstalling >> xf86-video-intel and relying on the modesetting driver. >> >> I have personally found this to help with tearing, but naturally YMMV. >> >> See https://wiki.archlinux.org/index.php/Intel_graphics#Installation >> for more details. > > Many distros default to using the built-in xorg modesetting driver. > > https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/ > https://fedoraproject.org/wiki/Features/IntelKMS > > Could those affected by this bug see if it works for them? Maybe we > should follow suit. Maybe I did this the wrong way, but here's what I placed in my config.scm: (kernel-arguments (list "modprobe.blacklist=pcspkr" "quiet" "rhgb" "thinkpad_acpi.fan_control=1" "i195.modeset=1")) I can say that this does not solve the problem in my case. Kind regards, Roel Janssen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 17:13 ` Roel Janssen @ 2017-06-25 17:39 ` Marius Bakke 0 siblings, 0 replies; 24+ messages in thread From: Marius Bakke @ 2017-06-25 17:39 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel, William [-- Attachment #1: Type: text/plain, Size: 1382 bytes --] Roel Janssen <roel@gnu.org> writes: > Marius Bakke writes: > >> William <w@vieta.uk> writes: >> >>> The Arch Wiki says that Debian and some others suggest uninstalling >>> xf86-video-intel and relying on the modesetting driver. >>> >>> I have personally found this to help with tearing, but naturally YMMV. >>> >>> See https://wiki.archlinux.org/index.php/Intel_graphics#Installation >>> for more details. >> >> Many distros default to using the built-in xorg modesetting driver. >> >> https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/ >> https://fedoraproject.org/wiki/Features/IntelKMS >> >> Could those affected by this bug see if it works for them? Maybe we >> should follow suit. > > Maybe I did this the wrong way, but here's what I placed in my config.scm: > > (kernel-arguments (list "modprobe.blacklist=pcspkr" "quiet" "rhgb" > "thinkpad_acpi.fan_control=1" "i195.modeset=1")) You would have to prevent Xorg from selecting the "intel" driver. E.g. by passing #:drivers to (xorg-configuration-file ...). I think changing 'Driver "intel"' to 'Driver "modesetting"' in the configuration snippet you pasted earlier would also override the autoload order. Can you also check if adding "Option TearFree" works with SNA? https://wiki.archlinux.org/index.php/intel_graphics#Tear-free_video [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 17:23 ` Mark H Weaver 2017-06-21 22:21 ` Roel Janssen @ 2017-06-25 5:47 ` Chris Marusich 2017-06-25 8:31 ` Roel Janssen 2017-06-25 11:08 ` Mark H Weaver 1 sibling, 2 replies; 24+ messages in thread From: Chris Marusich @ 2017-06-25 5:47 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 253 bytes --] Mark H Weaver <mhw@netris.org> writes: > However, your proposed workaround is not a proper fix, and I don't think > we should apply it system-wide in Guix. Can you elaborate on why it is not a proper fix? It isn't obvious to me. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 5:47 ` Chris Marusich @ 2017-06-25 8:31 ` Roel Janssen 2017-06-25 11:38 ` Mark H Weaver 2017-06-25 11:08 ` Mark H Weaver 1 sibling, 1 reply; 24+ messages in thread From: Roel Janssen @ 2017-06-25 8:31 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel Chris Marusich writes: > Mark H Weaver <mhw@netris.org> writes: > >> However, your proposed workaround is not a proper fix, and I don't think >> we should apply it system-wide in Guix. > > Can you elaborate on why it is not a proper fix? It isn't obvious to > me. Because it changes Xorg in order to fix a bug in Emacs. A proper fix would be in Emacs. Unless every other piece of software (GTK+, GNOME, Qt) have worked around the bug somehow.. Then it might be a Xorg thing after all. But this seems to be unlikely. Kind regards, Roel Janssen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 8:31 ` Roel Janssen @ 2017-06-25 11:38 ` Mark H Weaver 0 siblings, 0 replies; 24+ messages in thread From: Mark H Weaver @ 2017-06-25 11:38 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel Roel Janssen <roel@gnu.org> writes: > Chris Marusich writes: > >> Mark H Weaver <mhw@netris.org> writes: >> >>> However, your proposed workaround is not a proper fix, and I don't think >>> we should apply it system-wide in Guix. >> >> Can you elaborate on why it is not a proper fix? It isn't obvious to >> me. > > Because it changes Xorg in order to fix a bug in Emacs. A proper fix > would be in Emacs. I'm not sure the bug is in Emacs. That was only a guess based on my limited personal experience. Having read a bit more, I now think it's more likely to be a problem in the Intel driver, but these are only guesses in an area where my knowledge is weak. Mark ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 5:47 ` Chris Marusich 2017-06-25 8:31 ` Roel Janssen @ 2017-06-25 11:08 ` Mark H Weaver 2017-08-07 21:48 ` Clément Lassieur 1 sibling, 1 reply; 24+ messages in thread From: Mark H Weaver @ 2017-06-25 11:08 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 2166 bytes --] Hi Chris, Chris Marusich <cmmarusich@gmail.com> writes: > Mark H Weaver <mhw@netris.org> writes: > >> However, your proposed workaround is not a proper fix, and I don't think >> we should apply it system-wide in Guix. > > Can you elaborate on why it is not a proper fix? It isn't obvious to > me. You're right, it's not obvious, and an explanation is indeed warranted. The problem is that the Device section added by this patch specifies that the "intel" driver should be used. I haven't tested it, but the way xorg.conf generally works is that explicit configuration overrides auto-configuration. Quoting from the introduction of xorg.conf(5): Xorg supports several mechanisms for supplying/obtaining configuration and run-time parameters: command line options, environment variables, the xorg.conf configuration file, auto-detection, and fallback defaults. When the same information is supplied in more than one way, the highest precedence mechanism is used. The list of mechanisms is ordered from highest precedence to lowest. https://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html#sect1 If we want to make UXA the default acceleration method for xf86-video-intel, I've attached a patch that accomplishes this without overriding auto-configuration. Given the severity of the problems on the X200, I would be in favor of applying this patch to master. The X200 is an important system for us because it is one of only two RYF-certified laptops. FWIW, I do not notice any visually apparent difference in performance between UXA and SNA on the X200 for things like web browsing, watching videos, and running gnome-shell. Nonetheless, I've seen reports that SNA performs significantly better than UXA, at least on newer Intel chips: http://cynic.cc/blog/posts/sna_acceleration_vs_uxa/ https://ickle.wordpress.com/2013/10/02/and-over-in-the-red-corner/ https://www.reddit.com/r/archlinux/comments/17sy9l/intel_graphics_uxa_vs_sna/ I would invite someone who cares about this to enhance 'xorg-configuration-file' in (gnu services xorg) to allow users to optionally specify which accel-method to use for each driver. Mark [-- Attachment #2: [PATCH] gnu: xf86-video-intel: Use UXA accel method by default --] [-- Type: text/x-patch, Size: 1532 bytes --] From 745487d79dca402609200f67431ac19eaa99a4eb Mon Sep 17 00:00:00 2001 From: Mark H Weaver <mhw@netris.org> Date: Sun, 25 Jun 2017 05:20:36 -0400 Subject: [PATCH] gnu: xf86-video-intel: Use UXA accel method by default. * gnu/packages/xorg.scm (xf86-video-intel)[arguments]: Add #:configure-flags with "--with-default-accel=uxa". --- gnu/packages/xorg.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm index d4da5d709..c6d194622 100644 --- a/gnu/packages/xorg.scm +++ b/gnu/packages/xorg.scm @@ -1,6 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2013, 2014 Andreas Enge <andreas@enge.fr> -;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org> +;;; Copyright © 2014, 2015, 2017 Mark H Weaver <mhw@netris.org> ;;; Copyright © 2014, 2015 Eric Bavier <bavier@member.fsf.org> ;;; Copyright © 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org> ;;; Copyright © 2015 Eric Dvorsak <eric@dvorsak.fr> @@ -2849,7 +2849,8 @@ X server.") (string-prefix? "x86_64-" system))) %supported-systems)) (arguments - '(#:phases (modify-phases %standard-phases + '(#:configure-flags '("--with-default-accel=uxa") + #:phases (modify-phases %standard-phases (add-after 'unpack 'bootstrap (lambda _ (zero? (system* "autoreconf" "-vfi"))))))) -- 2.13.1 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 11:08 ` Mark H Weaver @ 2017-08-07 21:48 ` Clément Lassieur 0 siblings, 0 replies; 24+ messages in thread From: Clément Lassieur @ 2017-08-07 21:48 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel Mark H Weaver <mhw@netris.org> writes: > If we want to make UXA the default acceleration method for > xf86-video-intel, I've attached a patch that accomplishes this without > overriding auto-configuration. Given the severity of the problems on > the X200, I would be in favor of applying this patch to master. The > X200 is an important system for us because it is one of only two > RYF-certified laptops. On X200 this patch introduces the bug I described here: https://bugs.freedesktop.org/show_bug.cgi?id=101620#c4 > FWIW, I do not notice any visually apparent difference in performance > between UXA and SNA on the X200 for things like web browsing, watching > videos, and running gnome-shell. Nonetheless, I've seen reports that > SNA performs significantly better than UXA, at least on newer Intel > chips: > > http://cynic.cc/blog/posts/sna_acceleration_vs_uxa/ > https://ickle.wordpress.com/2013/10/02/and-over-in-the-red-corner/ > https://www.reddit.com/r/archlinux/comments/17sy9l/intel_graphics_uxa_vs_sna/ > > I would invite someone who cares about this to enhance > 'xorg-configuration-file' in (gnu services xorg) to allow users to > optionally specify which accel-method to use for each driver. That would be useful indeed, I will have a look at it. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 13:26 ` Roel Janssen 2017-06-21 16:27 ` Kei Kebreau 2017-06-21 17:23 ` Mark H Weaver @ 2017-06-25 5:46 ` Chris Marusich 2017-06-25 8:28 ` Roel Janssen 2 siblings, 1 reply; 24+ messages in thread From: Chris Marusich @ 2017-06-25 5:46 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1905 bytes --] Roel Janssen <roel@gnu.org> writes: > Ricardo Wurmus writes: > >> Hi Roel, >> >>> With the following patch to the Xorg configuration file, I have a >>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>> way. This patch is probably too broad in effect. Can I change it so >>> that only the graphics card I have will be affected by this patch? >> >> I’m not sure about this, but you can apply it only to your system by >> changing the slim-service’s “startx” value like this: >> >> --8<---------------cut here---------------start------------->8--- >> (modify-services %desktop-services >> (slim-service-type >> config => (slim-configuration >> (inherit config) >> (startx (xorg-start-command >> #:configuration-file >> (xorg-configuration-file >> #:extra-config >> (list your-fix))))))) >> --8<---------------cut here---------------end--------------->8--- >> >> But I suppose what you want is to apply it unconditionally in Guix and >> have the X server ignore it for all but this one graphics card, right? > > No, not necessarily. I could no longer do 'guix pull && guix system > reconfigure ...', which I attempted to solve by upstreaming this patch. Why wouldn't you be able to do a 'guix pull && guix system reconfigure'? > I wonder if anyone else is having the same problem on this hardware.. Yes, I have this problem. I use a Lenovo X200. Like Mark, graphical Emacs doesn't display characters right, and it's difficult to tell what the buffer actually contains, sometimes. I've reconfigured my system to use the extra Xorg config you've provided in this thread, and I'll let you know in a week or two if it seems to have fixed the problem. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 5:46 ` Chris Marusich @ 2017-06-25 8:28 ` Roel Janssen 2017-07-20 2:43 ` Chris Marusich 0 siblings, 1 reply; 24+ messages in thread From: Roel Janssen @ 2017-06-25 8:28 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel Chris Marusich writes: > Roel Janssen <roel@gnu.org> writes: > >> Ricardo Wurmus writes: >> >>> Hi Roel, >>> >>>> With the following patch to the Xorg configuration file, I have a >>>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>>> way. This patch is probably too broad in effect. Can I change it so >>>> that only the graphics card I have will be affected by this patch? >>> >>> I’m not sure about this, but you can apply it only to your system by >>> changing the slim-service’s “startx” value like this: >>> >>> --8<---------------cut here---------------start------------->8--- >>> (modify-services %desktop-services >>> (slim-service-type >>> config => (slim-configuration >>> (inherit config) >>> (startx (xorg-start-command >>> #:configuration-file >>> (xorg-configuration-file >>> #:extra-config >>> (list your-fix))))))) >>> --8<---------------cut here---------------end--------------->8--- >>> >>> But I suppose what you want is to apply it unconditionally in Guix and >>> have the X server ignore it for all but this one graphics card, right? >> >> No, not necessarily. I could no longer do 'guix pull && guix system >> reconfigure ...', which I attempted to solve by upstreaming this patch. > > Why wouldn't you be able to do a 'guix pull && guix system reconfigure'? Because that would build a system generation which doesn't contain the patched Xorg config. Ricardo's snippet solved that. > >> I wonder if anyone else is having the same problem on this hardware.. > > Yes, I have this problem. I use a Lenovo X200. Like Mark, graphical > Emacs doesn't display characters right, and it's difficult to tell what > the buffer actually contains, sometimes. I've reconfigured my system to > use the extra Xorg config you've provided in this thread, and I'll let > you know in a week or two if it seems to have fixed the problem. Thanks. Kind regards, Roel Janssen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-25 8:28 ` Roel Janssen @ 2017-07-20 2:43 ` Chris Marusich 2017-07-20 10:57 ` Roel Janssen 0 siblings, 1 reply; 24+ messages in thread From: Chris Marusich @ 2017-07-20 2:43 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 2810 bytes --] Roel Janssen <roel@gnu.org> writes: > Chris Marusich writes: > >> Roel Janssen <roel@gnu.org> writes: >> >>> Ricardo Wurmus writes: >>> >>>> Hi Roel, >>>> >>>>> With the following patch to the Xorg configuration file, I have a >>>>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>>>> way. This patch is probably too broad in effect. Can I change it so >>>>> that only the graphics card I have will be affected by this patch? >>>> >>>> I’m not sure about this, but you can apply it only to your system by >>>> changing the slim-service’s “startx” value like this: >>>> >>>> --8<---------------cut here---------------start------------->8--- >>>> (modify-services %desktop-services >>>> (slim-service-type >>>> config => (slim-configuration >>>> (inherit config) >>>> (startx (xorg-start-command >>>> #:configuration-file >>>> (xorg-configuration-file >>>> #:extra-config >>>> (list your-fix))))))) >>>> --8<---------------cut here---------------end--------------->8--- >>>> >>>> But I suppose what you want is to apply it unconditionally in Guix and >>>> have the X server ignore it for all but this one graphics card, right? >>> >>> No, not necessarily. I could no longer do 'guix pull && guix system >>> reconfigure ...', which I attempted to solve by upstreaming this patch. >> >> Why wouldn't you be able to do a 'guix pull && guix system reconfigure'? > > Because that would build a system generation which doesn't contain the > patched Xorg config. Ricardo's snippet solved that. > >> >>> I wonder if anyone else is having the same problem on this hardware.. >> >> Yes, I have this problem. I use a Lenovo X200. Like Mark, graphical >> Emacs doesn't display characters right, and it's difficult to tell what >> the buffer actually contains, sometimes. I've reconfigured my system to >> use the extra Xorg config you've provided in this thread, and I'll let >> you know in a week or two if it seems to have fixed the problem. > > Thanks. > > Kind regards, > Roel Janssen Just wanted to close the loop here: I have not had any tearing problems since applying the patch. Sounds like the problem has been resolved through a slightly different means, though (with commit b049ae2f9708794f83c41171c19ffdfe4f11807e). Accordingly, I've removed the extra xorg configuration from my operating system configuration file and simply reconfigured using the latest origin/master. Thank you for starting this discussion! It's really nice to be able to use graphical emacs now without needing to frequently invoke M-x redraw-display. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-07-20 2:43 ` Chris Marusich @ 2017-07-20 10:57 ` Roel Janssen 0 siblings, 0 replies; 24+ messages in thread From: Roel Janssen @ 2017-07-20 10:57 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel Chris Marusich writes: > Roel Janssen <roel@gnu.org> writes: > >> Chris Marusich writes: >> >>> Roel Janssen <roel@gnu.org> writes: >>> >>>> Ricardo Wurmus writes: >>>> >>>>> Hi Roel, >>>>> >>>>>> With the following patch to the Xorg configuration file, I have a >>>>>> tear-free GuixSD experience. I wonder if this is upstreameable in some >>>>>> way. This patch is probably too broad in effect. Can I change it so >>>>>> that only the graphics card I have will be affected by this patch? >>>>> >>>>> I’m not sure about this, but you can apply it only to your system by >>>>> changing the slim-service’s “startx” value like this: >>>>> >>>>> --8<---------------cut here---------------start------------->8--- >>>>> (modify-services %desktop-services >>>>> (slim-service-type >>>>> config => (slim-configuration >>>>> (inherit config) >>>>> (startx (xorg-start-command >>>>> #:configuration-file >>>>> (xorg-configuration-file >>>>> #:extra-config >>>>> (list your-fix))))))) >>>>> --8<---------------cut here---------------end--------------->8--- >>>>> >>>>> But I suppose what you want is to apply it unconditionally in Guix and >>>>> have the X server ignore it for all but this one graphics card, right? >>>> >>>> No, not necessarily. I could no longer do 'guix pull && guix system >>>> reconfigure ...', which I attempted to solve by upstreaming this patch. >>> >>> Why wouldn't you be able to do a 'guix pull && guix system reconfigure'? >> >> Because that would build a system generation which doesn't contain the >> patched Xorg config. Ricardo's snippet solved that. >> >>> >>>> I wonder if anyone else is having the same problem on this hardware.. >>> >>> Yes, I have this problem. I use a Lenovo X200. Like Mark, graphical >>> Emacs doesn't display characters right, and it's difficult to tell what >>> the buffer actually contains, sometimes. I've reconfigured my system to >>> use the extra Xorg config you've provided in this thread, and I'll let >>> you know in a week or two if it seems to have fixed the problem. >> >> Thanks. >> >> Kind regards, >> Roel Janssen > > Just wanted to close the loop here: I have not had any tearing problems > since applying the patch. Sounds like the problem has been resolved > through a slightly different means, though (with commit > b049ae2f9708794f83c41171c19ffdfe4f11807e). Accordingly, I've removed > the extra xorg configuration from my operating system configuration file > and simply reconfigured using the latest origin/master. I also removed the extra Xorg configuration snippet from my system configuration, and I too don't have the tearing problem anymore. > > Thank you for starting this discussion! It's really nice to be able to > use graphical emacs now without needing to frequently invoke M-x > redraw-display. Thanks for confirming that this issue has been fixed. Kind regards, Roel Janssen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 7:55 Xorg tearing fix on Intel HD Graphics 4000 Roel Janssen 2017-06-21 10:38 ` Ricardo Wurmus @ 2017-06-23 18:00 ` Christopher Baines 2017-06-26 8:55 ` Andy Wingo 2 siblings, 0 replies; 24+ messages in thread From: Christopher Baines @ 2017-06-23 18:00 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 804 bytes --] On Wed, 21 Jun 2017 09:55:46 +0200 Roel Janssen <roel@gnu.org> wrote: > For a long time now, I have a tearing issue on GuixSD (parts of the > screen do not get updated while others do, resulting in dissapearing > text in Emacs). > > With the following patch to the Xorg configuration file, I have a > tear-free GuixSD experience. I wonder if this is upstreameable in > some way. This patch is probably too broad in effect. Can I change > it so that only the graphics card I have will be affected by this > patch? This is awesome, thanks for sharing Roel, like you I found Emacs difficult to use on both of the machines that I run GuixSD on. I've tested the patch you attached, applied with the configuration that Ricardo provided on one of those machines, and it worked perfectly! [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-21 7:55 Xorg tearing fix on Intel HD Graphics 4000 Roel Janssen 2017-06-21 10:38 ` Ricardo Wurmus 2017-06-23 18:00 ` Christopher Baines @ 2017-06-26 8:55 ` Andy Wingo 2017-06-27 17:43 ` Mark H Weaver 2 siblings, 1 reply; 24+ messages in thread From: Andy Wingo @ 2017-06-26 8:55 UTC (permalink / raw) To: Roel Janssen; +Cc: guix-devel On Wed 21 Jun 2017 09:55, Roel Janssen <roel@gnu.org> writes: > For a long time now, I have a tearing issue on GuixSD (parts of the > screen do not get updated while others do, resulting in dissapearing > text in Emacs). Thank you for this work! I notice this since a month ago and haven't had time to delve into it. Horrible stuff. I wonder if it makes sense to update the intel driver to see if it fixed it? Then perhaps we could avoid the hack. There are commits here that touch SNA and things that look like they could be relevant: https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/ As you probably know, the intel driver doesn't get proper releases :( You just have to take a tag from git. That's what we do now and perhaps updating the driver could fix this bug. Andy ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-26 8:55 ` Andy Wingo @ 2017-06-27 17:43 ` Mark H Weaver 2017-06-28 8:24 ` Andy Wingo 0 siblings, 1 reply; 24+ messages in thread From: Mark H Weaver @ 2017-06-27 17:43 UTC (permalink / raw) To: Andy Wingo; +Cc: guix-devel Andy Wingo <wingo@igalia.com> writes: > On Wed 21 Jun 2017 09:55, Roel Janssen <roel@gnu.org> writes: > >> For a long time now, I have a tearing issue on GuixSD (parts of the >> screen do not get updated while others do, resulting in dissapearing >> text in Emacs). > > Thank you for this work! I notice this since a month ago and haven't > had time to delve into it. Horrible stuff. > > I wonder if it makes sense to update the intel driver to see if it fixed > it? Then perhaps we could avoid the hack. There are commits here that > touch SNA and things that look like they could be relevant: > > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/ It's a good idea, but we're already using HEAD (6babcf1) from their repo, and have been since June 11 (guix commit e2de6bbdd5). I can confirm that this didn't solve the problem for me. In the meantime, how would you feel about pushing the following commit to master? It would still allow the use of SNA by explicitly asking for it in xorg.conf, but auto-configuration would choose UXA by default. What do you think? Mark From 745487d79dca402609200f67431ac19eaa99a4eb Mon Sep 17 00:00:00 2001 From: Mark H Weaver <mhw@netris.org> Date: Sun, 25 Jun 2017 05:20:36 -0400 Subject: [PATCH] gnu: xf86-video-intel: Use UXA accel method by default. * gnu/packages/xorg.scm (xf86-video-intel)[arguments]: Add #:configure-flags with "--with-default-accel=uxa". --- gnu/packages/xorg.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm index d4da5d709..c6d194622 100644 --- a/gnu/packages/xorg.scm +++ b/gnu/packages/xorg.scm @@ -1,6 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2013, 2014 Andreas Enge <andreas@enge.fr> -;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org> +;;; Copyright © 2014, 2015, 2017 Mark H Weaver <mhw@netris.org> ;;; Copyright © 2014, 2015 Eric Bavier <bavier@member.fsf.org> ;;; Copyright © 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org> ;;; Copyright © 2015 Eric Dvorsak <eric@dvorsak.fr> @@ -2849,7 +2849,8 @@ X server.") (string-prefix? "x86_64-" system))) %supported-systems)) (arguments - '(#:phases (modify-phases %standard-phases + '(#:configure-flags '("--with-default-accel=uxa") + #:phases (modify-phases %standard-phases (add-after 'unpack 'bootstrap (lambda _ (zero? (system* "autoreconf" "-vfi"))))))) -- 2.13.1 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-27 17:43 ` Mark H Weaver @ 2017-06-28 8:24 ` Andy Wingo 2017-06-28 18:14 ` Mark H Weaver 0 siblings, 1 reply; 24+ messages in thread From: Andy Wingo @ 2017-06-28 8:24 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel On Tue 27 Jun 2017 19:43, Mark H Weaver <mhw@netris.org> writes: > Andy Wingo <wingo@igalia.com> writes: > >> On Wed 21 Jun 2017 09:55, Roel Janssen <roel@gnu.org> writes: >> >>> For a long time now, I have a tearing issue on GuixSD (parts of the >>> screen do not get updated while others do, resulting in dissapearing >>> text in Emacs). >> >> I wonder if it makes sense to update the intel driver to see if it fixed >> it? Then perhaps we could avoid the hack. There are commits here that >> touch SNA and things that look like they could be relevant: >> >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/ > > It's a good idea, but we're already using HEAD (6babcf1) from their > repo, and have been since June 11 (guix commit e2de6bbdd5). I can > confirm that this didn't solve the problem for me. > > In the meantime, how would you feel about pushing the following commit > to master? It would still allow the use of SNA by explicitly asking for > it in xorg.conf, but auto-configuration would choose UXA by default. > > What do you think? Looks good to me. We should report the problem though... ok I did that here: https://bugs.freedesktop.org/show_bug.cgi?id=101620 Looking forward to having a normal Emacs again :) Andy ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Xorg tearing fix on Intel HD Graphics 4000 2017-06-28 8:24 ` Andy Wingo @ 2017-06-28 18:14 ` Mark H Weaver 0 siblings, 0 replies; 24+ messages in thread From: Mark H Weaver @ 2017-06-28 18:14 UTC (permalink / raw) To: Andy Wingo; +Cc: guix-devel Andy Wingo <wingo@igalia.com> writes: > On Tue 27 Jun 2017 19:43, Mark H Weaver <mhw@netris.org> writes: > >> In the meantime, how would you feel about pushing the following commit >> to master? It would still allow the use of SNA by explicitly asking for >> it in xorg.conf, but auto-configuration would choose UXA by default. >> >> What do you think? > > Looks good to me. Pushed as commit b049ae2f9708794f83c41171c19ffdfe4f11807e on master. > We should report the problem though... ok I did that here: > > https://bugs.freedesktop.org/show_bug.cgi?id=101620 Thank you! I see that there has already been an informative response from Chris Wilson: The issue is that gnome-shell is not synchrosing its texture reads with X rendering because mesa's glXWaitX() is broken. Mark ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-08-07 21:48 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-06-21 7:55 Xorg tearing fix on Intel HD Graphics 4000 Roel Janssen 2017-06-21 10:38 ` Ricardo Wurmus 2017-06-21 13:26 ` Roel Janssen 2017-06-21 16:27 ` Kei Kebreau 2017-06-21 17:23 ` Mark H Weaver 2017-06-21 22:21 ` Roel Janssen 2017-06-21 23:23 ` William 2017-06-25 11:59 ` Marius Bakke 2017-06-25 17:13 ` Roel Janssen 2017-06-25 17:39 ` Marius Bakke 2017-06-25 5:47 ` Chris Marusich 2017-06-25 8:31 ` Roel Janssen 2017-06-25 11:38 ` Mark H Weaver 2017-06-25 11:08 ` Mark H Weaver 2017-08-07 21:48 ` Clément Lassieur 2017-06-25 5:46 ` Chris Marusich 2017-06-25 8:28 ` Roel Janssen 2017-07-20 2:43 ` Chris Marusich 2017-07-20 10:57 ` Roel Janssen 2017-06-23 18:00 ` Christopher Baines 2017-06-26 8:55 ` Andy Wingo 2017-06-27 17:43 ` Mark H Weaver 2017-06-28 8:24 ` Andy Wingo 2017-06-28 18:14 ` Mark H Weaver
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.