Odd Scrolling Behavior with Tmux

[matthew-nm]

I use Tmux extensively and noticed a very strange behavior relating to scrolling with a mousewheel/touchpad. This behavior is only present when using Tmux + WSLtty and does not occur in the normal terminal app that comes with Ubuntu, or in WSLtty when not using Tmux.

Direct	Tmux
WSL Ubuntu	Scrolling works as expected.	Scrolling activates copy mode and begins scrolling page, as expected.
WSLtty	Scrolling works as expected.	Scrolling up/down acts as up/down arrows, cycling through the command history. Scrolling left/right activates copy mode, but doesn't move (nowhere to go). When copy mode is activated, scrolling up/down moves the cursor up/down just like the up/down arrows.

Is there some reason that Tmux would see up/down scrolling as arrow inputs only when in Tmux?

Let me know if there is any other information I can provide.

Thanks.

EDIT: After some more experimentation after turning all mouse settings off, it seems that the WSL Ubuntu terminal + Tmux completely ignores scrolling input whereas WSLtty + Tmux interprets it as arrow keys. I'll try to check out the escape sequences and see what I can do, but this may be a Mintty behavior. Hopefully I can figure out a solution.

[mintty]

You can easily check the escape sequences sent into the shell with the ^V prefix. Applications (like tmux) can set the terminal into application keypad mode or even some other modes, depending on the terminal, so the codes may vary. Which sequences are interpreted by an application in which way is out of scope of the terminal.

[mintty]

Mintty sends ESC [ A on arrow-up (in normal mode), and so does the native WSL terminal. For me, tmux does not behave differently in them.

[mintty]

I'm not familiar with tmux configuration. I suppose there are some key assignments that would enable scrolling via cursor keys, Ctrl+cursor keys etc. Did you check your respective .tmux.conf files? Are they identical?

[mintty]

With those other issues, I'm not getting a clear picture. Is this supposed to be an arrow key issue or a mouse issue? Please provide a focussed and reproducible issue report.

[mintty]

OK, I may have missed the point initially. With the following configuration in ~/.tmux.conf within WSL: set -g mouse on set-option default-terminal screen-256color I can use the mouse wheel and tmux will scroll the screen, as expected. Likewise with WSLtty and native WSL, no difference.

[mintty]

In case your config does not set mouse on: It's also possible that the native WSL/Windows terminal translates touchpad events into mouse sequences, depending on the device. That might explain an apparent difference. Please test.

[matthew-nm]

I created a minimal tmux config for testing,

set -g mouse on
set default-terminal screen-256color

I plugged in a bluetooth mouse with a scroll wheel as well and I get the same results. If I do single jump on the mouse wheel, it sends the arrow up command, but if I do many clicks up, it starts to actually scroll as well as send the arrow command.

If I insert ^V in WSLtty and scroll with the mouse wheel, I sometimes get the up arrow control sequence and sometimes I don't. It seems to mix them in. The same happens with the touchpad, but I'm more likely to get the up arrow control characters. This behavior is apparent with the scroll effect. When using the wheel, it scrolls ok-ish with occasional up arrow input, and with the touchpad it scrolls very poorly with primarily up arrow input.

In the native WSL terminal it always works perfectly; no arrow input regardless of device.

EDIT 1: I'm discussing issue with a tmux dev and we may be onto something: https://github.com/tmux/tmux/issues/2148#issuecomment-608651701

I'll post back here if I have new information.

EDIT 2: Looks like tmux is simply doing what it is being commanded to do. For some reason scroll input includes arrow commands in WSLtty. See issue link in EDIT 1, above.

[mintty]

Please check your mintty configuration. Try to minimize it and upload it.

[mintty]

Also please try to disable the scrollbar.

[matthew-nm]

Configuration attached (added .txt extension so github would accept upload). I've been running without scrollbar.

config.txt

[mintty]

Try setting SuppressMouseWheel=scrollapp please.

[mintty]

Also try setting NoAltScreen=true please.

[matthew-nm]

The NoAltScreen=true setting does allow scrolling to occur, but it scrolls the entire tmux session, leaving the cursor and status bar behind, and doesn't allow selecting text. This makes sense given everything I've learned about the issue (as discovered in the tmux thread, the arrow commands are only sent in alternate screen mode), but it does not yield proper functionality.

The SuppressMouseWheel=scrollapp does actually work to an extent. By examining the control characters, I can see that it only allows the scroll commands through and not the arrow commands. However, the scroll commands are infrequent and they only occur when I scroll very, very quickly. So if I do a very large scroll swipe on the trackpad I may scroll a line or two. Using a mouse wheel is better. Without this setting, the mouse wheel only sends arrow commands when the wheel changes direction, and so with this setting, it seems to behave fairly well. But I never use a mouse and rely on my trackpad on my laptop, so I would like to figure out why the trackpad is sending so many arrow commands and only sends a single scroll command on a big swipe.

[matthew-nm]

I've found similar issues that occured around 2016-2017 in VSCode: https://github.com/Microsoft/vscode/issues/23062

It seems to have to do with the "Precision Trackpad" stuff Windows 10 uses. Looking through the issue linked above and the issues it references, I couldn't figure out what the ultimate solution was, but they seem to have fixed it somehow.

[mintty]

The vscode issue links, in multiple steps, to https://github.com/microsoft/vscode/issues/13612. See also https://github.com/mintty/mintty/issues/262#issuecomment-108889980.

[matthew-nm]

Ok, well, I guess this is the end of this issue. I can't figure out how to fix or update the drivers for my touchpad, and I don't want to fight with Dell or Microsoft to get it fixed, so I'll either try to live with it or move back to the native WSL terminal (even though bold/bright font doesn't seem to be working for me).

For those who are interested, I have a Dell XPS 13 9350.

[adamk33n3r]

I just ran into this issue. I had been using WSL1 with wsltty. I just upgraded to WSL2 and had to upgrade my wsltty install (because it would just crash on start). I then started seeing this issue. The previous version of wsltty I had installed was 3.0.5 and now I have 3.2.0. So I don't know if it was the WSL2 upgrade or the wsltty upgrade but I would assume its the wsltty upgrade since the native wsl terminal scrolls tmux fine.

I am seeing the same effect where if I scroll normally it just sends up arrow. But if I scroll REALLY fast it sends a couple actual scrolls and enters copy mode.

It's honestly very frustrating as wsltty has been my favorite terminal to use for wsl. But it's just really impossible to use right now.

[adamk33n3r]

I found out that if I completely delete my tmux conf file (therefore not enabling mouse) it is still sending the arrow keys when scrolling, but wont do the "scroll really fast to send real scroll sequences" thing

[adamk33n3r]

Also, restoring my config with set -g mouse on, I notice that if I hold shift it will also never send real scroll sequences

[mintty]

Shift is the default "Modifier for overriding default" mouse functions (see Options dialog).

[adamk33n3r]

I apologize for posting so many comments, but I just had a recollection that I also had run sudo apt update; sudo apt upgrade so maybe one of the packages updated broke something. Perhaps tmux itself or maybe a package it depends on. Looking in the log I can see the following Unpacking tmux (2.6-3ubuntu0.2) over (2.6-3ubuntu0.1).

Additionally, I just installed Ubuntu-20.04 as a separate wsl instance as WSLv1 and reinstalled wslttyv3.0.5 and ran tmux inside and found that this same issue is happening in the old version that used to work fine for me!

[adamk33n3r]

Reading through the issue that @matthew-nm made on tmux https://github.com/tmux/tmux/issues/2148#issuecomment-608589181 I tried what they did. This is run in wsltty and NOT in tmux. I honestly don't know what that printf is doing so hopefully you do! Something about an "alternate screen". But since it's happening without tmux running, that makes me thinking something else fishy is going on.

akeenan ~ $ printf '\033[?1049h\033[22;0;0t\033[?1h\033=\033[?1006h\033[?1002h'
akeenan ~ $ cat # Here I scroll slowly upwards
^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^C⏎                                                            
akeenan ~ $ cat # Here I scroll somewhat more quickly upwards
^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^C⏎                                                                                      
akeenan ~ $ cat # Here I scroll **very** quickly. As fast as I can. You can start to see the mouse scrolls come in with some up arrows intermixed.
^[[<64;24;13M^[[<64;24;13M^[OA^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[[<64;24;13M^[OA^[OA^[OA^[OA^[OA^[OA

[adamk33n3r]

I will also add that this is affecting my vim installation (outside of tmux). I have mouse mode enabled there as well but now scrolling is just moving the cursor up and down instead of just scrolling the page (of course unless I scroll very quickly like previously mentioned)

[mintty]

Depending on selected mouse modes (\033[?1006h\033[?1002h) and settings (Options - Mouse - Default click target Window/Application) I get either mouse reports (^[<64...M) or mousewheel-triggered cursor key reports for mintty' scrolling support for legacy applications. But I never get a mix of both. It is still obscure under what conditions you make that strange observation. What's your environment? (WSL distro, shell, mintty config file, tmux if active..)

[adamk33n3r]

Distro is Ubuntu-18.04 Shell is both fish and bash mintty config

Font=DejaVu Sans Mono for Powerline
FontHeight=10
ThemeFile=
Term=xterm-256color
BellType=0
BoldAsFont=yes
AllowBlinking=yes
FontSmoothing=full

BackgroundColour=66,66,66
ForegroundColour=241,241,241
CursorColour=241,241,241

Black=31,31,31
BoldBlack=128,128,128

Blue=0,142,196
BoldBlue=32,187,252

Green=16,167,120
BoldGreen=95,215,175

Yellow=168,156,20
BoldYellow=243,228,48

Red=195,7,113
BoldRed=251,0,122

Magenta=114,93,150
BoldMagenta=104,85,222

Cyan=32,165,186
BoldCyan=79,184,204

White=217,217,217
BoldWhite=241,241,241

Transparency=low
CtrlShiftShortcuts=yes
CursorType=block
CopyOnSelect=no
CopyAsRTF=no
Locale=C
Scrollbar=none

tmux config

# color
set -g default-terminal "xterm-256color"

bind-key y run "tmux save-buffer - | xclip -i -selection clipboard"
bind PageUp copy-mode -eu

set -g set-titles on
set -g set-titles-string "#T"

# set window split
bind-key v split-window -h
bind-key b split-window

# Status Bar
set -g status-interval 5
set -g status-justify centre # left align window list

set-option -g prefix C-space
bind-key C-space last-window

# Start numbering at 1
set -g base-index 1

# Allows for faster key repetition
set -s escape-time 0

# Rather than constraining window size to the maximum size of any client 
# connected to the *session*, constrain window size to the maximum size of any 
# client connected to *that window*. Much more reasonable.
setw -g aggressive-resize on

# Allows us to use <prefix> a <command> to send commands to a TMUX session inside 
# another TMUX session
bind-key a send-prefix

# Activity monitoring
setw -g monitor-activity on
set -g visual-activity off

# Vi copypaste mode
set-window-option -g mode-keys vi

# hjkl pane traversal
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

bind-key C command-prompt -p "Name of new window: " "new-window -n '%%'"

# reload config
bind r source-file ~/.tmux.conf# \; display-message "Config reloaded..."

# auto window rename
set-window-option -g automatic-rename on

setw -g mouse on

# status bar
#set-option -g status-utf8 on

# https://github.com/edkolev/dots/blob/master/tmux.conf
# Updates for tmux 1.9's current pane splitting paths.
if-shell "[[ `tmux -V` == *2.* ]]" 'unbind c; bind c new-window -c "#{pane_current_path}"'
#if-shell "[[ `tmux -V` == *2.* ]]" 'unbind s; bind s split-window -v -c "#{pane_current_path}"'
if-shell "[[ `tmux -V` == *2.* ]]" 'unbind b; bind b split-window -v -c "#{pane_current_path}"'
if-shell "[[ `tmux -V` == *2.* ]]" 'unbind v; bind v split-window -h -c "#{pane_current_path}"'
if-shell "[[ `tmux -V` == *2.* ]]" 'unbind %; bind % split-window -h -c "#{pane_current_path}"'

#run-shell -b "powerline-daemon -q 2>/dev/null"
source "/usr/local/lib/python3.6/dist-packages/powerline/bindings/tmux/powerline.conf"

# vim: ft=tmux

though, the issue still occurs even with a simple config only with setw -g mouse on

I will also note that I am using trackpad scrolling on an xps just like the OP. I did try using my bluetooth mouse with those tests and while the scrolling events are coming in more frequently, I can still get arrows to show up.

Here's a sequence I performed with the bluetooth mouse which has notches on the scrolls (as opposed to continuous).

Up           Up           Down    Down         Down         Up      Up           Down    Up      Down    Up      Down
^[[<64;57;20M^[[<64;57;20M^[OB^[OB^[[<65;57;20M^[[<65;57;20M^[OA^[OA^[[<64;57;20M^[OB^[OB^[OA^[OA^[OB^[OB^[OA^[OA^[OB^[OB

So it has this weird behavior where changing scroll directions (alternating) causes it to send the arrow keys. This is "better" but it still causes situations in tmux where I scroll to the bottom, then i start scrolling up and the first scroll "tick" brings up my last command (because of the up arrow) and then subsequent up-scrolls scrolls the pane up.

[mintty]

the issue still occurs even with a simple config only with setw -g mouse on

Nice to know, so the other config was white noise.

Assuming you do not run a cygwin environment, please use the attached drop-in replacement in %LOCALAPPDATA%/wsltty/bin and run it as follows: cd %LOCALAPPDATA% mintty -l logfile /bin/mintty --WSL=Ubuntu mintty-mou.zip

Then check whether the pattern of logged Windows events changes when your symptoms change.

[adamk33n3r]

Using my bluetooth mouse, the events I'm seeing are identical no matter if it behaves as an arrow key or an actual scroll. In my previous example of the up down repeat pattern where the alternating would cause arrow keys, it prints out the same Windows events as if I kept going in one direction. In this image here are the events using the bluetooth mouse. I start by scrolling up a few times. Then go alternate up and down. And then down a few times.

Corresponding cat output ^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[[<64;60;17M^[OB^[OB^[OA^[OA^[OB^[OB^[OA^[OA^[OB^[OB^[OA^[OA^[OB^[OB^[OA^[OA^[OB^[OB^[[<65;60;17M^[[<65;60;17M^[[<65;60;17M^[[<65;60;17M^[[<65;60;17M

Here is a test I did with my trackpad. I scrolled down super fast (only way I can get the scroll escape sequences to show up) in cat. Here is the output in cat and the corresponding windows events.

[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FECC0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF7E0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF6C0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF560000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF5B0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF5D0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF5D0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF750000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF860000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFA60000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF5D0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FE980000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF970000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FEF30000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FEF00000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF310000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF350000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FEC10000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFE70000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FE260000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF870000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF350000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF240000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF0F0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFDB0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF3E0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF8B0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFA30000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FF8C0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFBB0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFC50000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFB90000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFD00000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFC80000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFEF0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFD60000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFE30000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFEF0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFF00000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFF30000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFF90000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFFA0000 02D2014A)
[1593468191]->0x220abe 020A WM_MOUSEWHEEL (FFFE0000 02D2014A)

^[[<65;45;19M^[[<65;45;19M^[OB^[OB^[[<65;45;19M^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[OB^[[<65;45;19M^[OB^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[OB^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[OB^[OB^[[<65;45;19M^[[<65;45;19M^[OB^[OB^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[OB^[OB^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[[<65;45;19M^[OB^[[<65;45;19M^[OB^[OB^[OB^[OB^[[<65;45;19M^[[<65;45;19M^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB

Let me know if there is anything else I can do.

[mintty]

Try printf '\033[?1007l' and printf '\033[?7786l' before testing please.

[adamk33n3r]

Ok so after running the three commands

printf '\033[?1049h\033[22;0;0t\033[?1h\033=\033[?1006h\033[?1002h'
printf '\033[?1007l'
printf '\033[?7786l'

only the scroll escape sequences are showing up in cat. And when in tmux I am not getting any up/down arrow behavior. It seems to be just "supressing" them though. Because I still have to scroll somewhat fast on my trackpad to get any scrolling behavior and also with my bluetooth mouse, the alternating up/down pattern doesn't scroll (like it is doing the up/down arrow but just ignoring it).

I hope that is what you were looking for! It's definitely "better" than before. Still annoying to have to swipe really fast on my trackpad though.

[mintty]

I'm seeing some suspicious logic in the code that could cause the irregular behaviour. I had just not taken notice as such behaviour had never happened before this issue. Still curious about its dependencies. Please test the attached version, again with logging for some debug output. It might be necessary to adjust mouse wheel scaling to some system settings related to your device, but I wouldn't know which. mintty-appmou.zip

[adamk33n3r]

I just tested that version and it seems to have fixed the issue! The debug log output looks the essentially the same as before, but seems to be including higher numbers (which I am guessing is like a "speed").

[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00080000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00070000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00090000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00090000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00090000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00080000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00280000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00070000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00080000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00050000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00090000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00040000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00070000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00060000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00050000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00060000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00030000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00040000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00040000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00070000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00020000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00020000 01440272)
[1593552961]->0x6a14ee 020A WM_MOUSEWHEEL (00050000 01440272)

Used to only hit 2 or 3 but now it seems to be hitting up to 7 or 9 consistently.

In both the printf/cat test and actually using tmux, the scrolling behavior seems feel like it used to.

[mintty]

Thanks for cooperation to debug this issue and reveal its covered cause. I'm reopening the issue until the fix is released.

[alexbr]

Awesome, the patched version fixed this issue for me as well. Thanks all!

[mintty]

Released 3.3.0.