Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graphics display refresh problem #3491

Closed
t0rv1c opened this issue Nov 5, 2017 · 77 comments
Closed

Graphics display refresh problem #3491

t0rv1c opened this issue Nov 5, 2017 · 77 comments
Labels

Comments

@t0rv1c
Copy link

t0rv1c commented Nov 5, 2017

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.
@t0rv1c t0rv1c changed the title Pixelbook keytroke lag Pixelbook keystroke lag Nov 5, 2017
@cresny
Copy link

cresny commented Nov 6, 2017

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?

@t0rv1c
Copy link
Author

t0rv1c commented Nov 6, 2017

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

@brandinchiu
Copy link

@cresny:

synclient FingerLow=1 FingerHigh=5

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

@mikehikes
Copy link

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

@cresny
Copy link

cresny commented Nov 12, 2017

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

@nickjmeyer
Copy link

nickjmeyer commented Nov 12, 2017

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.

@mikehikes
Copy link

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.

@nickjmeyer
Copy link

nickjmeyer commented Nov 12, 2017

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.

@cresny
Copy link

cresny commented Nov 12, 2017

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.

@ghost
Copy link

ghost commented Nov 13, 2017

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.

@cresny
Copy link

cresny commented Nov 13, 2017

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@cresny
Copy link

cresny commented Nov 13, 2017

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@brandinchiu
Copy link

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@brandinchiu
Copy link

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@brandinchiu
Copy link

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@brandinchiu
Copy link

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

@cresny
Copy link

cresny commented Nov 13, 2017

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

@ghost
Copy link

ghost commented Nov 13, 2017

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

@brandinchiu
Copy link

@ikayhan happy to help.

@mikehikes
Copy link

mikehikes commented Nov 14, 2017

@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

@cresny
Copy link

cresny commented Nov 14, 2017

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

@mikehikes
Copy link

mikehikes commented Nov 14, 2017

@cresny Indeed - link added!

@ghost
Copy link

ghost commented Nov 14, 2017

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

@maxme
Copy link

maxme commented Dec 2, 2017

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.

@markstos
Copy link

markstos commented Dec 4, 2017

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?

@cresny
Copy link

cresny commented Dec 4, 2017

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

@markstos
Copy link

markstos commented Dec 4, 2017

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

@knuesel
Copy link

knuesel commented Jan 2, 2018

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

@knuesel
Copy link

knuesel commented Jan 2, 2018

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.

@t0rv1c
Copy link
Author

t0rv1c commented Jan 4, 2018

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

@markstos
Copy link

markstos commented Jan 4, 2018

@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

@t0rv1c
Copy link
Author

t0rv1c commented Jan 4, 2018

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

@knuesel
Copy link

knuesel commented Jan 10, 2018

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.

@t0rv1c
Copy link
Author

t0rv1c commented Jan 18, 2018

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.

@jtr-owncloud
Copy link

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!

@t0rv1c
Copy link
Author

t0rv1c commented Jan 18, 2018

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.

@origints
Copy link

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

@t0rv1c
Copy link
Author

t0rv1c commented Jan 19, 2018

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

@t0rv1c t0rv1c changed the title Pixelbook keystroke lag Graphics display refresh problem Jan 19, 2018
@jtr-owncloud
Copy link

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.

@brendenyule
Copy link

brendenyule commented Jan 31, 2018

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.

@brendenyule
Copy link

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

@malawi89
Copy link

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?

@Dave-G-K
Copy link

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?

@Dave-G-K
Copy link

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

@jackgallant
Copy link

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

@astatide
Copy link

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?

@t0rv1c
Copy link
Author

t0rv1c commented Jun 13, 2018

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?

@donie
Copy link

donie commented Jun 18, 2018

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

@astatide
Copy link

astatide commented Jun 21, 2018

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.

@sumutcan
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests