Bug 99634 - Rendering delayed if mouse not moved in xorg 1.19
Summary: Rendering delayed if mouse not moved in xorg 1.19
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: high major
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-01 23:43 UTC by Frederick Eaton
Modified: 2017-11-19 13:22 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frederick Eaton 2017-02-01 23:43:14 UTC
Description: The problem I'm experiencing is that when I press a key, the "KeyPress" event is not sent until the key is released, or ~200ms passes (my subjective timer, could be way off), whichever comes first. This problem only happens when I send input to a display which I've rotated using xrandr.

More details: https://bbs.archlinux.org/viewtopic.php?pid=1687968#p1687968

Originally submitted to: https://bugs.archlinux.org/task/52800

The problem does not occur with xorg-server 1.18.4-1, but occurs with 1.19.1-1.
Comment 1 Michel Dänzer 2017-02-02 01:58:14 UTC
Output rotation shouldn't affect input event processing, so presumably it's actually the output triggered by the keypress that gets delayed.

Please attach the Xorg log file.

You seem to be using the xf86-video-intel driver, does the problem also occur with the modesetting driver instead?
Comment 2 Frederick Eaton 2017-02-02 02:20:22 UTC
To date, a number of people have commented on this bug in various fora but nobody has actually admitted to trying to reproduce it. Which should be pretty easy, if you have xrandr and xev and the ability to rotate your head (either your meat head or your monitor head) to one side.

However, if you want me to change my config and test again, then I can do that. Just specify exactly what to put in which file (in Arch we have "/etc/X11/xorg.conf.d/"), as I am unfamiliar with the syntax.

The log file is under "more details" in the original post.
Comment 3 Michel Dänzer 2017-02-02 02:47:01 UTC
I can't seem to reproduce the problem with the modesetting or radeon driver, reassigning.

P.S. Please always attach essential information such as log files here directly instead of referencing external sites.
Comment 4 Michel Dänzer 2017-02-03 00:48:34 UTC
(In reply to Frederick Eaton from comment #2)
> Just specify exactly what to put in which file [...]

Something like

Section "Device"
        Identifier "Device0"
        Driver "modesetting"
EndSection

in /etc/X11/xorg.conf should force the modesetting driver.
Comment 5 Frederick Eaton 2017-02-03 05:02:04 UTC
Thank you Michel. I am *not* able to reproduce the bug with the modesetting driver (i.e. using the fragment you provided).

This is my usual "Device" section which exhibits the bug:

    Section "Device"
       Identifier  "Intel Graphics"
       Driver      "intel"
       Option      "AccelMethod"  "uxa"
    EndSection
Comment 6 Michel Dänzer 2017-02-03 08:56:19 UTC
Reassigning to the intel driver per comment #5.
Comment 7 Sven Greiner 2017-02-10 20:00:42 UTC
This is unrelated to the rotation in my case. I noticed it when I updated to xorg 1.19 a few weeks ago. The screen is only updated on KeyRelease or after ~200 ms. Even the cursor does not blink anymore because the screen is not refreshed.

No compositor, SNA, TearFree enabled, last tested with 169c74f. modesetting driver works fine.
Comment 8 Frederick Eaton 2017-02-10 22:40:07 UTC
Thank you Sven for being the first reproducer, and also for observing the stalled blinking cursor, which perhaps elucidates why the bug is connected to the graphics driver. (I try to avoid blinking things)

I re-confirmed that I only experience the bug with a rotated screen, but I experimented a bit to try to understand the connection to graphics updates. If I open a window and run

    while true; do perl -le 'print rand()'; sleep 0.01; done

then when I try to type in another window, the keypresses are *not* delayed. This random-number loop also eliminates the delay I saw in the 'xev' output. I don't understand why this should be. If the graphics updates are being delayed until an event occurs or 200ms elapses, then the output of the random number loop should be jerky - but it is not. If the graphics updates are triggered by a new line appearing in the terminal, but not by a single character or a blinking cursor, then 'xev' should not have shown a delay, as it outputs several lines per keypress.

Another thing I don't understand is why this appeared in xorg-server 1.19.1. I think 1.19 made some kind of change to use 'libinput' as the default, at least in Arch - certainly when I downgraded I had to install a package called "xf86-input-evdev" to fix up the dependencies, which is an alternative to "xf86-input-libinput". The 1.19.1-1 package depends on "xf86-input-libinput", while the 1.18.4-1 package only dependen on the 'virtual package' "xf86-input-driver". Does this bug have a connection to libinput, or is that just a coincidence?
Comment 9 Frederick Eaton 2017-02-10 23:43:37 UTC
Update: I turned on the blinking cursor in rxvt-unicode, and I was still able to see it blinking even though my keypresses were delayed. Sven: what terminal do you use?
Comment 10 Christian Steck 2017-03-02 16:24:27 UTC
I also experience this bug.

It is independent of output rotation and can be circumvented by *constantly* moving the mouse.

I don't have any manual xorg.conf settings, but is also present with

    Section "Device"
       Identifier  "Intel Graphics"
       Driver      "intel"
       Option      "AccelMethod"  "sna"
    EndSection
Comment 11 Sven Greiner 2017-03-11 12:14:06 UTC
@Frederick Eaton
I meant the cursor in GTK and Qt applications. This is definitely not related to libinput. It's just that the bug is visible especially while typing.

I think that xorg 1.19 changed something related to event processing and xf86-video-intel just does not notice that the content of the screen has changed. If the mouse is moved, some events are sent for every movement/frame so that the rendering works perfect.

@Chris Wilson
Can you have a look at this problem? This is really a blocker for users with xorg 1.19 and might require only a small change in the code. This happens already for several months and is really annoying.
Comment 12 Frederick Eaton 2017-06-23 20:22:49 UTC
During a recent upgrade I sought help from #archlinux on freenode and received the following advice:

    - remove /etc/X11/xorg.conf.d/20-intel.conf

    - remove packages xf86-video-intel xf86-input-evdev (this makes us fallback to the modesetting driver)

These steps seemed to resolve the problem by bypassing the problematic driver.
Comment 13 Sven Greiner 2017-06-23 20:32:42 UTC
(In reply to Frederick Eaton from comment #12)
> During a recent upgrade I sought help from #archlinux on freenode and
> received the following advice:
> 
>     - remove /etc/X11/xorg.conf.d/20-intel.conf
> 
>     - remove packages xf86-video-intel xf86-input-evdev (this makes us
> fallback to the modesetting driver)
> 
> These steps seemed to resolve the problem by bypassing the problematic
> driver.

Seriously? This is not a solution. A well known "solution" because, well, not using a program cannot produce any issues with it, right? It simply avoids the bug by using a totally different driver.

PS: xf86-input-evdev is not related to this, so removing it makes not difference. It isn't used anyway if not configured manually because libinput is the default now.
Comment 14 Frederick Eaton 2017-06-23 21:15:09 UTC
Sven: Yes, I seriously just explained how to avoid the bug by changing to a working driver. I'm glad that you understood that the bug is still present in the Intel driver. Thanks for the tip about xf86-input-evdev.

By the way, if this was all obvious to you then I wish you'd explained it to me four months ago, and saved me the hassle of figuring out how to downgrade the Intel driver packages in Arch.
Comment 15 Sven Greiner 2017-06-23 21:25:17 UTC
(In reply to Frederick Eaton from comment #14)
> By the way, if this was all obvious to you then I wish you'd explained it to
> me four months ago, and saved me the hassle of figuring out how to downgrade
> the Intel driver packages in Arch.

I did. Not how to switch to modesetting (but that can be easily found via Google or in the Arch wiki), but that it works fine with modesetting.

(Sven Greiner 2017-02-10 20:00:42 UTC)
> No compositor, SNA, TearFree enabled, last tested with 169c74f. modesetting driver works fine.

There are some other issues with modesetting, though. For example root-only backlight control (or use of udev rules / acpilight) because of the missing helper or no TearFree (and standalone compositors like compton are broken with the latest xorg version, at least the same issues with amd and intel graphics).
Comment 16 Frederick Eaton 2017-06-23 21:54:29 UTC
Yeah now I see your "modesetting driver works fine" - must have sounded to me like "the part of the driver that sets modes is functional". I didn't realize that "modesetting" is a separate video driver.

Thanks for summarizing the problems with that driver. I'm not sure why I first installed the xf86-video-intel package, maybe just an "OK this looks vaguely relevant to my system" type of judgment.
Comment 17 Sven Greiner 2017-11-19 13:22:37 UTC
This problem still exists.

xf86-video-intel 2.99.917 (37a682aa)
xorg-server 1.19.5

@Chris
Can you please give at least a short response that you are aware of this issue?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.