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?

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.

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.

(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.

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

Reassigning to the intel driver per comment #5.

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.

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?

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?

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

@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.

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.

(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.

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.

(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).

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.

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?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/136.