crouton: Graphics display refresh problem

name: xenial
encrypted: yes, unlocked
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version 1-20170901092920~master:0216f9d1
release: xenial
architecture: amd64
xmethod: xorg
targets: xorg,xiwi,xfce,extension
host: version 9901.54.0 (Official Build) stable-channel eve 
kernel: Linux localhost 4.4.79-11650-ge987f76b729a #1 SMP PREEMPT Tue Oct 24 23:57:37 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes```

Hi Everyone,

I'm still trying to get used to my new machine and after the issue with the trackpad sensitivity, I am facing another issue with the keyboard this time. I'm not sure what the source of the issue could be, but every time I type something on the keyboard, it takes forever to appear. This is especially noticeable when typing inside a terminal window and less so inside another program like my web browser Firefox. The lag is not consistent and it feels like it get stuck and then suddenly responds...

Thanks in advance for your help.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 77

Most upvoted comments

Further tests suggest that the problem is display lag rather than input lag.

For example, if the Gnome shell clock (in the top bar) is configured to show seconds, one can see that they are not updated regularly. Unless, that is, something is moving continuously on the screen: then there is no perceived input lag and the clock display is also refreshed smoothly. Something moving continuously can be a video playing, or text being printed in the terminal. Also moving the mouse cursor works but it can take some time before it “takes effect” and the lag ceases.

Here is a screencast that illustrates these observations:

  • The clock in the top bar is not updated regularly
  • A shell command runs date in a loop to print the current seconds once per second. The printed times show that the date command is indeed run every second, but the display is updated irregularly.
  • A second shell command is started to print numbers as fast as possible. The makes the display lag disappear.

have you seen this? The issue disappeared for me after changing resolution to 2400x1600. Also, you’ll probably want to run synclient FingerLow=1 FingerHigh=5 or your trackpad will lag. Maybe the the latter could find its way into a target?

I think this is the right issue to add this finding to.

I had the same issue with the Pixelbook (even after the locale and synclient fix, although those were quite helpful) on an admittedly unsupported bionic install, making a Xorg session mostly unusable. I haven’t tried this with Xenial, although I had the same problem with Sid.

Forcing Xorg to use SNA acceleration with the Intel driver fixed all problems with both Gnome and KDE, and I don’t have to play a video in the ChromeOS session anymore. (I just copied /etc/crouton/xorg-intel-sna.conf to /etc/X11/xorg.conf, as a ‘testing hack’). Removing the Intel driver (which should force it to the internal modesetting driver) didn’t seem to help.

Again, I’m not sure this is the same issue. But it’s substantially more responsive, now (feels like a native install). Does anyone else experiencing this want to see if this helps?

I am using multiple displays with my pixelbook. When I use XFCE terminal on the original Pixelbook screen, it lags. When I move the terminal to the external display, it works fine.

XTerm, however, works fine on both displays.

With a bit more time to dig into this, it seems more related to using DRI3 than either the modesetting/sna/intel driver, etc.

Forcing the modesetting driver to use DRI2 seems to work around this, for now. Setting the environment variable LIBGL_DRI3_DISABLE=1 seems to make the modesetting driver work.

EDIT: Having said that, it seems the Intel driver still has better performance and no odd hangups.

Hi everyone, it is now pretty clear that something is wrong with the refresh rate of the video when typing or displaying text, toggling menus, opening windows and it makes it look like a lag. Should this issue be renamed? Any suggestion? Would this increase the chances of this problem being checked and fixed? I can’t wait to be able to use the full potential of my pixelbook display using crouton.

@markstos, you’re absolutely right and I knew as I actually started this thread. However, like many other things, new bug discoveries happen by exchanging findings in completely unrelated threads… So I was hoping for help before actually jumping to the bug conclusion. As of now and until I get someone else’s experience with this, I will not be able to conclude it’s a bug and therefore will not open a new thread. But thanks for your help and your vigilance.