[Solved] Significant input lag in terminal prompt

eduncan911 · 2015-07-03 02:53:12

After a pacman update today I'm experiencing a serious delay in keyboard input in all terminals I have, except xterm. gnome-terminal, terminator are the ones with the same issue.

Well, anything that is a letter key that is... Backspace, arrow keys, enter actually function instantly as expected. But entering anything such as:

$ asddkdalsdlasdlasd
$ ls -l
$ nano ~/.profile

Are all delayed by 2 to 5 seconds before showing partially, or all of it.

Entering into nano, vi, etc all works fine. I can type at normal speeds. It is only the Prompt that i am experiencing this odd delay with.

Rebooting into multi-user.target works fine.

All other apps are fine with keyboard input, such as Chrome (writing this post with it), gedit, etc. Even using nano from that same terminal works fine for keyboard input.

GDM
i3wm (no Gnome)
gnome-terminal
Lenovo Helix tablet/keyboard dock

If it helps, here's what I've been doing today that may be related...

* copyed a VMware VM to disk, configured it and got it to boot natively on the laptop.

(input was working fine)

* deleted /etc/X11/xorg.conf to remove vmware's specifics (mouse, keyboard, video, etc). booted without it made no difference.
* created a new one with X -configure, and moving it from root to /etc/X11. didn't make a difference.
* edited grub entries
* get grub "malformed file" error on reboot

(rebooted, keyboard input issues now appear)

Last edited by eduncan911 (2015-07-22 03:55:47)

dice · 2015-07-03 10:39:39

Do you have problems on a TTY too?
What does your grub config look like, and what did you change?
Which packages were updated?

As your machine is kind of fancy regarding its keyboard there might be a module or configuration you need to explicitly enable.

eduncan911 · 2015-07-03 22:48:29

TTY, as in booting into multi-boot.target? No, no problem at all.
Pacman actually didn't finish updating - had a conflict (now resolved). About 117 packages updated.

Here's some additional information:

* plugging in a USB keyboard actually fixes both the Helix keyboard and the USB keyboard!

* I have "xset r rate 250 40" in my i3wm config. When plugging in my USB keyboard I noticed that it isn't set. I have to run it again.

* Rebooting with the USB keyboard connected breaks it all over again. No amount of unplugging/replugging the USB KB and rebooting works. I have to POWER OFF, unplug USB KB, boot up and then plugin the USB KB and it fixes the issue.

* Noticed that using the mouse to highlight any portion of a line in gnome-terminal has the exact same 2 - 5s delay.

BACKSPACE, Arrow Keys and ENTER works instantly as it should. Again, this happens with both gnome-terminal and terminator.

It's like there is something monitoring the keyboard keys, but ignore BACKSPACE.

Any help in trying to diagnosis this would greatly be appreciated.

Grub changes was just adding an entry to boot in multi-boot.target. Nothing real much with the config:

$ cat grub 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable Hidden Menu, and optionally hide the timeout count
#GRUB_HIDDEN_TIMEOUT=5
#GRUB_HIDDEN_TIMEOUT_QUIET=true

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter 
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx" 
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=false

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper 
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-blue/black"
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

GRUB_SAVEDEFAULT="true"

GRUB_DISABLE_OS_PROBER="true"

dice · 2015-07-03 23:19:10

I'd guess this is somehow related to the xorg but I haven't seen this kind of problem yet.
Are there any errors in your system and xorg logs?
Does the delay reoccur after unplugging the USB keyboard? If so what your logs in that moment (e.g. with journalctl -f) and see if any errors show up

As there was a xorg update a few days ago this might have caused the problem. Maybe try downgrading it and see if it works.
What caused the conflict on updating? Is it related?
You said this occurred after updating therefore it is likely caused by some package that was updated.

Head_on_a_Stick · 2015-07-04 00:05:43

eduncan911 wrote:

Nothing real much with the config

That's not your GRUB configuration file, that's the configuration file for the GRUB configuration file (don't you just love abstraction & obfuscation?) -- the actual configuration file is at /boot/grub/grub.cfg

If you start one of your problematic terminals from a functional terminal (xterm), do they return any error messages?

Is there anything in the journal?

journalctl -xf

Follows journal entries as they are written (best use xterm for that as well)

PBS · 2015-07-04 02:06:16

Here are some really last-resort suggestions:

Does gnome-terminal have the lag when run under weston (if it runs)? That could diagnose whether xorg is causing the issue.
Do you have the time to make a debug build of gnome-terminal, and run it under a profiler to see where it's spending its time while lagging? In some userspace library or syscalls?
You could also get the latter information by running the non-functional terminal under "time" or "/usr/bin/time", entering lots of text to cause delays, and comparing the user/sys times to those of the same terminal when its working.

I also just have to point this out (in case you hadn't noticed already):

eduncan911
Posts: 48

Head_on_a_Stick
Posts: 2,304

2304 = 48^2

eduncan911 · 2015-07-04 02:26:50

Ha, 48^2 = 2304.

I am still working through everyone's suggestions... But I noticed something else.

I am using i3status/i3bar from within i3wm to update my status bar. It is set to 5s.

If I press and hold the "a" key for repeating, the aaaaaaaaaaaaaaaaaaaaaaaaaa shows up every 5 seconds - exactly when the i3status bar refreshes on the screen (shown by the seconds in the time).

I confirmed that changing it to 1 second intervals, now aaaaaa aaaaaa aaaaaa shows every 1 second if I press and hold a.

If i disable the i3bar completely, I get NOTHING! aaaaaaaaaaaa will never show, until I press ENTER. Pressing enter shows it on the last command line.

One other piece I forgot to mention... I recently went from vmware to native install on my laptop. I did not have the "intel" driver loaded for video. I loaded that, wiped out the xorg.conf and rebooted to rebuild it with the Intel driver loaded. I did everything else I mentioned above before that big reboot as well. That's when things started.

Oh, and btw...

$ journalctl -xf
Error was encountered while opening journal files: Invalid argument

?

Last edited by eduncan911 (2015-07-04 02:28:15)

PBS · 2015-07-04 12:29:20

Ignore my earlier suggestions, apart from the one about weston.

Are you sure it's input lag? From your last post it sounds more like the input is getting to the terminal but the redraw is delayed. (if you type a command into the terminal and press enter before the text is displayed, does it execute immediately or after the text appears?)
You said that i3bar refreshing causes the terminal to repaint - what if you run something that continuously updates itself like glxgears? If this fixes the problem, then I suspect intel's graphics driver, especially if it also happens under weston.
You seem to have intel graphics. I wonder if this could be related to a recent bug I observed: random temporary loss of all hardware acceleration (I haven't made a thread because I was silently hoping it's gone). You can tell if this has happened by running glxinfo (in extra/mesa-demos), and you get
```
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits)
```
instead of something like
```
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
```
Disable SNA?
Downgrade xorg/mesa/kernel?

Head_on_a_Stick · 2015-07-04 14:44:01

eduncan911 wrote:

Oh, and btw...
$ journalctl -xf
Error was encountered while opening journal files: Invalid argument
?

https://bugs.archlinux.org/task/45451

eduncan911 · 2015-07-04 15:39:29

@PBS: I'll continue with all of your examples later today.

But, you are getting much hotter. Yes, you are exactly right: the input and ENTER key all works instantly and fast. It's just not get displayed. You did better conveying that experience than I have above. Even Backspace works instantly and fast (which is odd).

Yesterday, there was a time I rebooted and the laptop keyboard was nice and fast. I just reached over to see if the USB keyboard, which was already attached, was fast and as soon as I pressed a single letter - the "delay" happened all over again - on both keyboards. Again, the input is nice and fast - just nothing is shown on the screen for those 5s intervals.

Head_on_a_Stick wrote:

eduncan911 wrote:
Oh, and btw...
$ journalctl -xf
Error was encountered while opening journal files: Invalid argument
?
https://bugs.archlinux.org/task/45451

Thanks. Yeah, I found this and decided to just wipe my journal logs - can run journalctl now.

So far nothing suspicious that i can recognize in the logs; though, it has shown other issues that i have mostly resolved.

Last edited by eduncan911 (2015-07-04 15:41:02)

eduncan911 · 2015-07-04 16:45:09

PBS wrote:

Ignore my earlier suggestions, apart from the one about weston.

Logging into Gnome has always worked. It's only an issue with i3wm.

[*]Are you sure it's input lag? From your last post it sounds more like the input is getting to the terminal but the redraw is delayed. (if you type a command into the terminal and press enter before the text is displayed, does it execute immediately or after the text appears?)[/*]

Warmer... As mentioned, pressing ENTER works instantly, as well as backspace and arrow keys. Only pressing keys is delayed in showing. The input does get registered behind the display.

[*]You said that i3bar refreshing causes the terminal to repaint - what if you run something that continuously updates itself like glxgears? If this fixes the problem, then I suspect intel's graphics driver, especially if it also happens under weston.[/*]

Warmer... Running glxgears does INDEED refresh the screen often enough that I all input shows near instantly - as long as the glxgears demo is running on the same screen/in view.

[*]You seem to have intel graphics. I wonder if this could be related to a recent bug I observed: random temporary loss of all hardware acceleration (I haven't made a thread because I was silently hoping it's gone). You can tell if this has happened by running glxinfo (in extra/mesa-demos), and you get
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits)
instead of something like
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
[/*]

Colder... Output has:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile

[*]Disable SNA?[/*]

DING DING DING.

Following the guide at https://wiki.archlinux.org/index.php/In … SNA_issues

I disabled SNA and fell back to UXA.

Everything is back to the way it should be.

So, I still have acceleration I think. If I run glxgears, I still get 65 FPS (in near full screen) abd 78 FPS in 1/2 screen, on battery. I think that's good? It's the same numbers I got with SNA.

Will hold off updating the title to SOLVED just yet, as I ran into things "working" last night several times before it stopped after a few reboots and other configs.

gauteh · 2016-06-14 08:28:50

eduncan911 wrote:

[*]Disable SNA?[/*]
DING DING DING.
Following the guide at https://wiki.archlinux.org/index.php/In … SNA_issues
I disabled SNA and fell back to UXA.
Everything is back to the way it should be.
So, I still have acceleration I think. If I run glxgears, I still get 65 FPS (in near full screen) abd 78 FPS in 1/2 screen, on battery. I think that's good? It's the same numbers I got with SNA.

Replacing SNA with UXA worked for me on a Macbook 11,3 after this started happening to me after upgrading today.

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod" "uxa"
EndSection

liticovjesac · 2016-06-15 18:14:54

I had a same problem and fixed it with removing xf86-video-intel driver.

nacnudus · 2016-06-20 15:45:58

Replacing SNA with UXA worked for me on a Dell Latitude E7440 after upgrading yesterday. The problem didn't appear in last-week's upgrade.

hobarrera · 2016-06-21 08:35:57

Removing xf86-video-intel introduced new issues for me (I'm using a 2013 MBA Air):

If the screen got turned off due to DPMS, hitting keys or moving a mouse would not turn it on.
The mba_bl driver stopped working, so after suspension, brightness could not take any values other than 0 or 100%.

I also had a few minor issues I can't recall right now.

Replacing SNA with UXA seems to be working for me, and did not introduce further issues.

pooldoo · 2016-07-08 23:16:52

Changing to UXA fixed the keyboard lag for me, but caused jumpy display problems playing DVD's with VLC on my Dell Latitude laptop. Also using i3wm.

pooldoo · 2016-07-09 12:08:48

Solution for me was to replace lilyterm with xterm. Lesson learned - there is value in staying with "standard" software.

Gusar · 2016-07-09 12:29:25

The actual problem here is the same as in this thread: https://bbs.archlinux.org/viewtopic.php?id=213533 - the problem is framebuffer compression and can be disabled by loading the i915 kernel module with enable_fbc=0

Switching to UXA or removing xf86-video-intel are not "fixes", they just avoid the issue, but the issue is still there. Disabling framebuffer compression isn't a fix either btw, but it at least addresses the problem where it actually is.

Arch Linux

#1 2015-07-03 02:53:12

[Solved] Significant input lag in terminal prompt

#2 2015-07-03 10:39:39

Re: [Solved] Significant input lag in terminal prompt

#3 2015-07-03 22:48:29

Re: [Solved] Significant input lag in terminal prompt

#4 2015-07-03 23:19:10

Re: [Solved] Significant input lag in terminal prompt

#5 2015-07-04 00:05:43

Re: [Solved] Significant input lag in terminal prompt

#6 2015-07-04 02:06:16

Re: [Solved] Significant input lag in terminal prompt

#7 2015-07-04 02:26:50

Re: [Solved] Significant input lag in terminal prompt

#8 2015-07-04 12:29:20

Re: [Solved] Significant input lag in terminal prompt

#9 2015-07-04 14:44:01

Re: [Solved] Significant input lag in terminal prompt

#10 2015-07-04 15:39:29

Re: [Solved] Significant input lag in terminal prompt

#11 2015-07-04 16:45:09

Re: [Solved] Significant input lag in terminal prompt

#12 2016-06-14 08:28:50

Re: [Solved] Significant input lag in terminal prompt

#13 2016-06-15 18:14:54

Re: [Solved] Significant input lag in terminal prompt

#14 2016-06-20 15:45:58

Re: [Solved] Significant input lag in terminal prompt

#15 2016-06-21 08:35:57

Re: [Solved] Significant input lag in terminal prompt

#16 2016-07-08 23:16:52

Re: [Solved] Significant input lag in terminal prompt

#17 2016-07-09 12:08:48

Re: [Solved] Significant input lag in terminal prompt

#18 2016-07-09 12:29:25

Re: [Solved] Significant input lag in terminal prompt

Board footer