guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xorg tearing fix on Intel HD Graphics 4000


From: William
Subject: Re: Xorg tearing fix on Intel HD Graphics 4000
Date: Thu, 22 Jun 2017 00:23:03 +0100

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 <address@hidden> wrote:
>
> Mark H Weaver writes:
>
>> Hi Roel,
>>
>> Roel Janssen <address@hidden> 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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]