Xorg tearing fix on Intel HD Graphics 4000

Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

[-- 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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Ricardo Wurmus]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Kei Kebreau]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[William]

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
>

Re: Xorg tearing fix on Intel HD Graphics 4000

[Marius Bakke]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Marius Bakke]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Chris Marusich]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

[-- 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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Clément Lassieur]

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.

Re: Xorg tearing fix on Intel HD Graphics 4000

[Chris Marusich]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Chris Marusich]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Roel Janssen]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Christopher Baines]

[-- 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 --]

Re: Xorg tearing fix on Intel HD Graphics 4000

[Andy Wingo]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Andy Wingo]

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

Re: Xorg tearing fix on Intel HD Graphics 4000

[Mark H Weaver]

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