Crouton: Graphics display refresh problem

Created on 5 Nov 2017  Â·  77Comments  Â·  Source: dnschneid/crouton

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.

Most helpful comment

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.

All 77 comments

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?

@cresny thanks. Funny, I thought I was noticing an improvement after I set my resolution to 1800 x 1200 but I didn't know why (I still don't). I guess it'll take a few days to find out all the secrets to a fully functioning crouton on Pixelbook...
Perhaps @dnschneid has a better idea how to get crouton working smoothly on this new device.

@cresny:

synclient FingerLow=1 FingerHigh=5

This is what I was looking for all night. Thank you, kind gentlesir.

@cresny Are you setting your internal resolution to 2400x1600 and then running in xorg mode? That does not seem to make too much of a difference for me.

@mikelhand Actually I simply tried gnome-desktop target which was already in 2400x1600 and noticed the keyboard lag I saw in XFCE was gone.

I'm running i3 with xenial in crouton and noticing the same keystroke lag. The resolution is already set to 2400x1600. That was the default.

I still had no luck with gnome on stretch. However, running unity on xenial worked perfectly, with respect to keyboard lag on any internal resolution. The touch pad sensitivity issue was easily fixed with the synclient command.

Is Unity the only DE that doesn't experience this lag? Looks like xfce, gnome, and i3 are all have the lag regardless of the resolution.

I'm running the the xenial chroot with gnome-desktop target and it runs great. The only change I made was the xsession file for synclient.

I can confirm this bug is affecting me as well. I tried every possible resolution, changed DPI to 150, etc... all to no avail. The keyboard lag is non-existent when launching in xiwi but when launching in xorg mode, it is totally there making using the terminal very difficult and annoying.

@ikayhan I've created this chroot a couple of times and there is no keyboard lag:
sudo sh ~/crouton -r xenial -t gnome-desktop,extension. Is this similar to what you are doing or is it XFCE?
I never pursued that.

@cresny I'm using XFCE. What is the command you are using to startup GNOME desktop? I'm wondering if I should create another instance/target. I'd probably have to name the new target something different since the name "xenial" is the name of my current instance.

@ikayhan the command is startgnome. I imagine it's possible for a chroot to have multiple targets but you may as well create a new one named gnome.

@cresny so I installed Xenial with GNOME, however I am unable to launch a terminal. Everytime I click on the icon for terminal, it just spins and nothing happens. I installed then uninstalled, then re-installed again and terminal refuses to launch. Are you having the same issue OR are you running the latest version Artful?

@ikayhan this may be a locale issue if you're trying to launch gnome-terminal. I use unity, but prefer gnome-terminal to xterm, but if I install it I need to set up my locale file to support it.

@cresny how is that done again if you don't mind me asking? Just typing random stuff into Libreoffice Writer moments ago and there does not appear to be any keyboard or typing lag using GNOME. This is a very bizarre issue with XFCE.

sorry @cresny I thought you had responded to my last comment. @brandinchiu do you know how to setup the locale file so that my terminal can launch? thanks in advance

@ikayhan

http://codeorangutan.blogspot.ca/2015/06/terminal-wont-launch-after-upgrade-to.html?m=1

You'll need to close your chroot and reopen after this is done.

@brandinchiu sorry, the first command I assume is done in Chrome OS in a Crosh shell since I cannot open terminal inside the chroot? ir should I try the second approach with the bashrc file?

@ikayhan

You have a couple of options. You could try installing a different terminal and hoping it works, or you could trying opening the file with a text editor. If your chroot is not encrypted, then you can make the changes from the chromeos side too. That's probably easier.

@brandinchiu no luck. I changed in both spots (the locale file as well as the .bashrc file in home). Terminal refuses to launch. I used vi to modify the locale file from Crosh since my chroots is not encyrpted. Maybe I should install Artful instead?

@ikayhan

Step two would be to try to install a different terminal from a debian package, and then to try to run gnome-terminal from it to see what the actual error is.

I'm running xenial-unity and have had no issues outside of this. And like I said, I've updated my terminal to use gnome. You could try going through the unity target and then installing your preferred gnome components by hand, but that sounds like a colossal chore.

@ikayhan my apologies -- I think this may have escaped me. I tend to disremember such nuisances! Until I get home and check I can't be sure, but I do know it was around Locales or char encoding. Maybe this will help?

@cresny no worries. If you can check when you get home, I'd appreciate it. @brandinchiu thanks for all of your help as well

@ikayhan happy to help.

@ikayhan @cresny Indeed, the precise issue is that locales are not set by default, when using xenial/unity (or stretch). As a result, if you try to use the default terminal icon in unity, it will fail without any error. If you try to run from command line, you may receive a cryptic error that does not indicate that the issue is present.

You'll find that a number of programs will mysteriously break without the locale set.

If you run the locale command, you'll see that none of the system environment variables are set.

To fix, you can reference the following, and adjust based on your language, of course.

https://askubuntu.com/questions/89976/how-do-i-change-the-default-locale-in-ubuntu-server

@mikelhand I think you may have forgotten to insert link
Here worked for me.

@cresny Indeed - link added!

@cresny @brandinchiu @mikelhand I just want to thank each and every one of you. I managed to install Xenial with GNOME, configured the locales using the links provided and I can confirm that not only does terminal now launch properly, the keyboard lag is not present in GNOME. Thanks guys. I love my Pixelbook that much more now that I have Linux properly working without any annoying lag. You guys rock!!

Glad to help. Now try out the dark theme ☺ (tweak-UI)

On Mon, Nov 13, 2017 at 8:48 PM, Kayhan B. notifications@github.com wrote:

@cresny https://github.com/cresny @brandinchiu
https://github.com/brandinchiu @mikelhand https://github.com/mikelhand
I just want to thank each and every one of you. I managed to install Xenial
with GNOME, configured the locales using the links provided and I can
confirm that not only does terminal now launch properly, the keyboard lag
is not present in GNOME. Thanks guys. I love my Pixelbook that much more
now that I have Linux properly working without any annoying lag. You guys
rock!!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/3491#issuecomment-344119260,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjP37Zx5ZcnhTSJT4A9Aty-Ab87Z9eJks5s2PF9gaJpZM4QSZwc
.

Just gave gnome a shot -t gnome-desktop,extension -r xenial and things are working smoothly.

I tried using that same chroot, installing i3 along side gnome. However the lag is back when running i3.

My only concern at this point is heat. I noticed that while running GNOME, the Pixelbook chassis gets noticeably warm (not unbearably hot, but warm) particularly around the hinges. Since this machine is fanless, is anyone else concerned about heat and damage to internals?

Not really. The amount of heat that would need to generated to cause damage is quite high and for a sustained period of time. Modern computers have safety systems to kill the power when it _approaches_ these temperatures.

Its not going to operate at 75+ inside for an hour.

If there was something wrong, you'd feel it in the device itself.

I'm having the same problem with my Pixelbook. I've tried several different DEs to see if one will work (trying GNOME now). However, I discovered that if I have a video playing in Chrome under Chrome OS, there is no lag. As soon as I stop the video, the keyboard lag returns. Every time.

@jtr-owncloud Did you try the synclient fix posted above?

@jtr-owncloud someone mentioned in the post I linked to above that changing DPI from 96 to 150 fixed keyboard lag. Can you check your setting? Otherwise, it's really weird that a concurrent video in Chrome OS would have any effect, let alone a positive one.

I tried changing the DPI setting, with no change. I have not tried the synclient fix. I'm now running GNOME, which does not have the problem.

It is strange that playing a video would affect the keyboard. I was listening to a video play while configuring things in my Linux install and noticed the lag was gone. Later when the video was finished I noticed it was back. I tried a number of things to recreate the circumstances that led to the lag disappearing and tried playing another video. It is clearly the video playing that eliminates the lag. It is reproducible every time.

Btw, I don't seem to have any lag with the trackpad. The only issue I have is the pressure needed to move the cursor; I have to press more firmly in Linux to get it to move. The synclient fix is related to the trackpad.

I have created multiple chroots and as for keyboard lag, the gnome-desktop chroot works perfectly "out-of-the-box". I also happen to be on the Chrome OS beta channel in case that means anything. If your lag/video thing persists then maybe it's cause for concern. It's been a while since I last read about these things but if the video co-processor is embedded on the CPU then there may be some sort of problem with its ability to switch context or something. Not to be an alarmist, but I'd see this issue through just to be sure you don't have a defective CPU.

To those with the locale problem and gnome-terminal not opening: 'sudo dpkg-reconfigure locales' will enable you to select your locale systemwide.

cresny, can you verify whether playing a video in one of your non-GNOME chroots eliminates the lag? A CPU problem sounds severe! Not being present in GNOME makes me think it's not a hardware problem (I'm not a dev), and if others can verify that playing a video eliminates the lag, then either we all have bad CPUs or the problem lies elsewhere.

OK, I misread that it's working for you in Gnome. I'll see if the video
thing affects me too when I get home tonight.

On Nov 20, 2017 11:47 AM, "jtr-owncloud" notifications@github.com wrote:

cresny, can you verify whether playing a video in one of your non-GNOME
chroots eliminates the lag? A CPU problem sounds severe! Not being present
in GNOME makes me think it's not a hardware problem (I'm not a dev), and if
others can verify that playing a video eliminates the lag, then either we
all have bad CPUs or the problem lies elsewhere.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/3491#issuecomment-345755614,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjP30ZsG_mZ8TFO7QLh9AqlyYo8150Rks5s4a07gaJpZM4QSZwc
.

@jtr-owncloud I have a similiar experience. No keystroke lag in Gnome, but keystroke lag with other DEs / WMs. When you say that playing a video fixed the lag, what were you using to play videos? Youtube? I'd like to try and replicate what you saw.

nickjmeyer, in the Chrome browser under Chrome OS, if I play a youtube video and then switch to Linux while it's playing, the lag disappears. If I switch back, stop the video, and then return, the lag is there.

@cresny @jtr-owncloud I somehow doubt that there is a flaw in the hardware itself. If the keyboard lag is non-apparent in GNOME but present in other DMs, then I'm thinking that there is probably some sort of library that is either present in GNOME and not the other DMs (or it could be vice versa...XFCE and other DMs may have some piece of software that is missing in GNOME). If it was a strict hardware issue, then one would think that it would exist consistently across the board on all DMs. The hardware itself is solid. no other issues to report on my end.

I can confirm what @jtr-owncloud is saying. I played a 15-minute YouTube video in ChromeOS, launched XFCE and the lag in terminal is non-existent. I then switched back to ChromeOS (using Ctrl-Alt-Shift-Back) paused the video, switched back to XFCE using the 4-key combo, and the lag in terminal was back. I was able to reproduce this 3 times by switching back and forth. There is something here that is truly very bizarre. I'm thinking that playing a YouTube video in ChromeOS starts up some sort of process or sequence of events.

ikayhan, I'm glad I'm not crazy! I've seen similar things with enlightenment: bugs in nVidia show up in that DE but not in others. E uses the hardware in ways the other DEs do not, so what you've said about GNOME either using or not using some specific library or function call makes sense to me.

Isn't Gnome one of the only DEs to use Wayland directly? Many are still
using XWayland on top of Wayland.

On Mon, Nov 20, 2017 at 3:39 PM jtr-owncloud notifications@github.com
wrote:

ikayhan, I'm glad I'm not crazy! I've seen similar things with
enlightenment: bugs in nVidia show up in that DE but not in others. E uses
the hardware in ways the other DEs do not, so what you've said about GNOME
either using or not using some specific library or function call makes
sense to me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/3491#issuecomment-345824117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABk5f-wUp04GQusWifEN3bNCwdr-D2mks5s4eNugaJpZM4QSZwc
.

So this is beyond me, but I read Gnome uses some sort of LLVM-assisted
software driver. From what I know LLVM is usually a way for software to
fill in where there are gaps in HW support, but maybe for Gnome it's always
favored? So maybe what we are witnessing is a case where the HW resources
are being borrowed for the video and SW if properly filling in for XFCE?
Sort of also explains why XIWI (Sp?) also is smooth since it does not use
HW acceleration?

If so then I guess it means whatever native driver Crouton uses does not play well with fonts or typematic rate or something. However I do also use Kodi on the Pixelbook for watching timeshifted TV and it's super smooth, FWIW.

On Mon, Nov 20, 2017 at 3:39 PM, jtr-owncloud notifications@github.com
wrote:

ikayhan, I'm glad I'm not crazy! I've seen similar things with
enlightenment: bugs in nVidia show up in that DE but not in others. E uses
the hardware in ways the other DEs do not, so what you've said about GNOME
either using or not using some specific library or function call makes
sense to me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/3491#issuecomment-345824117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjP31C-rmUvsi_cvwjh4AqVzXuli0tXks5s4eNugaJpZM4QSZwc
.

Sounds like @ikayhan already confirmed the video interaction. But FWIW, I just ran the same experiment with i3 and the video did indeed fix the keystorke lag.

The exact same behavior happens to me. I get a keyboard input lag when I use i3wm on xorg or x11.

I tried to play a youtube video in Chrome before switching to i3, and it makes the keyboard lag disappear. As soon as the video stops playing, input lag comes.

I tried other workarounds: deactivate keyboard auto-correct, change the screen dpi, but that doesn't work for me.

This issue seems worth mentioning in the Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/list

While they don't support Crouton, it certainly seems buggy that starting an additional activity (playing video) would speed up another action. (keyboard lag). It's reasonable question to ask-- Whatever Chrome is doing when playing a video to reduce keyboard lag-- can it just do that all the time?

@markstos It seems to me that when Chrome OS is rendering a video it's forcing the chrooted Linux display to fall back to a Software driver rather than the native xorg one, which ironically works better for fonts. In other words, it's a Crouton issue, not a Chrome OS one.

@dnschneid does playing-a-video-fixes-crouton-keyboard-lag appear to be a Chrome bug or a Crouton bug to you?

To add one data point:

  • I see the same input lag when using Gnome in a debian stretch chroot (an X11 session, not a Wayland session)
  • The lag disappears if I start playing a youtube video before switching to Gnome
  • While in the Gnome session, the lag reappears when the video on the Chrome OS side reaches the end

Turns out the lag is also fixed when playing a video inside the chroot, in a Chromium or Firefox window.

(With Firefox, a part of the video must be visible on screen for the input lag to disappear. With Chromium the fix works even if the video is playing behind other windows)

EDIT: further tests show that the lag is also fixed in the following cases

  • playing a video in Totem
  • playing a synthetic video stream with gst-launch-1.0 videotestsrc ! ximagesink
  • just printing stuff in gnome-terminal with a Bash loop, e.g. while true; do x=$((x+1)); echo $x; done

In all these cases the video (or terminal text in the last case) must be visible for the input lag to disappear.

Hi @cresny I noticed you're using gnome-desktop and I gave it a try today. It's pretty nice but I just noticed something that's a big problem for me: when I close the lid (or let the computer idle), it doesn't lock the session but it locks the chrome OS session. So there is no security... Have you noticed the same thing. How can it be fixed? Thanks

@t0rv1c, your comment has nothing to do with the "keystroke lag" bug report. If you feel you've found a seperate bug in Crouton, open a new Crouton bug report

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

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.

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.

t0rv1c, you CAN use it without a problem, provided you run GNOME. I use it regularly without a problem, though I often find myself using just the CLI from the browser (via 'sudo enter-chroot'). I spend most of my time writing in vim and using mutt and only occasionally need to enter a full Linux environment. When I need full Linux, I can do so with no lag in a console.

Interestingly, I find that when I'm running a full Linux session ('sudo startgnome') with Ubuntu, my battery life is more than halved. Running in a CLI in Chrome I get 10 hours or so but when I run GNOME I get about 4-1/2 hours or so. In my many years of Linux experience I find Ubuntu tends to be much heavier on resources than other distros. I had a laptop several years ago that ran 30-40 degrees cooler running Debian/GNOME than it did running Ubuntu/GNOME (this was pre-Unity). Crazy!

thanks a lot @jtr-owncloud. yes I know, but this is not really what I want. My chroot is already set up with xfce and I don't really want to change anything. I would like to fix my pixelbook so that what was already working before very well on my previous chromebook, works very well again. Not really looking for a workaround.

@t0rv1c I'm not certain whether it needs a new name or not, but I was going to open a bug report for (what appears to be) the same issue on my Asus C302CA, when I discovered this one. I was running crouton w/ xfce as well under both stable and beta-channels of ChromeOS and experienced similar keyboard/trackpad lag that later appeared to be display-related.

@jsv106 this is really interesting because the chromebook I mentioned I had before and worked without problem was the Asus C302CA like yours. So this must be a problem that came with a more recent Chrome OS release, just before I got the Pixelbook...

Changing the title to "Graphics display refresh problem" doesn't seem helpful. While that may be the cause, most people experiencing the problem will describe it as a keystroke lag.

This bug is super weird. Even with the fixes from this thread, if you play some source games (gmod, half life 2) there is visual lag. If I open up the prop menu in gmod, and I wave my mouse around, then lag will go away as long as I move the mouse around.

Ok, it looks like you can get past visual lag in games by switching to windowed mode.

I bought a c302ca for a coding course and have been having problems where every minute or so it will freeze for a few seconds when typing and then continue on. Is this related to the problem you guys are having?

I see the delay problem in LXDE on stretch on my Pixelbook. Based on the statement that "it works OK on Gnome" I added the Gnome target to my LXDE chroot When I started Gnome on that chroot, the delay was TERRIBLE. When I started LXDE on that chroot the delay was no worse than before.
As Gnome did not work well in this case, is that somehow related to

markstos commented on Nov 20, 2017
"Isn't Gnome one of the only DEs to use Wayland directly? Many are still
using XWayland on top of Wayland."

Would Gnome use XWayland when added to a chroot originally built for LXDE?

Problem seems to be resolved after installing updates today - both ChromeOS 65 and latest Crouton updates for LXDE on stretch
Version 65.0.3325.184 (Official Build) (64-bit)
Not sure if it's related, but I also had done a hard reset in an attempt to resolve the bluetooth drop problem
https://productforums.google.com/forum/#!topic/pixelbook/GvZ4QjZ4q_w

The problem has not been resolved for me. I'm running crouton on a new pixelbook, and I get all the stated lag problems....

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?

Thanks so much @ajoshpratt . This worked for me as well. I've been so desperate to see this work.
I'm on XFCE Bionic. What is the xorg-dummy.conf by the way?

Thanks to @ajoshpratt . Forcing SNA acceleration worked for me. Curios to see if there's going to be a supported driver?

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

duck955 picture duck955  Â·  5Comments

jbaum98 picture jbaum98  Â·  4Comments

shichuzhu picture shichuzhu  Â·  5Comments

kiorpesc picture kiorpesc  Â·  4Comments

El-t0ro picture El-t0ro  Â·  4Comments