F1-F12 and arrow keys not functional

[mzvast]

Problem Describe

F1-F12 not functional,Just print out "~" .

When I ssh into a remote machine,I can't get shift+arrow keys or alt+arrow keys working either.

On the remote machine I'm using byobu to manage tmux windows and sessions, which binds most functions to F1-F12 as well as shift/Alt/arrow keys.

Reproduce&Env

1607 fresh install lxss 14.04

My Thought On This

I think this may have something to do with the cmd new console.
But I toggle back to legacy version of console and launch bash, Boom, the bash just flash and exit.

[fpqc]

mzvast are you using ConEMU or PuTTY or cmder?

[mzvast]

@fpqc I'm using the native terminal.
I also tried cmder, which not functional either.

[fpqc]

Does it work from PuTTY?

[fpqc]

Just so you know, mzvast, you're going down the rabbit-hole of "weird bugs that can be caused by terminfo and locale stuff", even on Linux natively (and also possibly console bugs).

[carlpaten]

I have the same problem. Build 14965, Ubuntu 16.04, Surface Book keyboard.

[zadjii-msft]

Ah. byobu. My nemesis.

@mzvast I've been investigating for many months (on and off) why the F keys don't work SPECIFICALLY in byobu.

As of about October, the F1-4 keys got better, and most keys will work occasionally, although modifiers+Fn rarely work. I have no idea as to why in byobu specifically, these keys don't work. I've bound the same commands to the same functions in tmux, and they work just fine. That's the part that gets me.

I have a current email thread open with @dustinkirkland about this exact issue, hoping to figure out a solution.

[carlpaten]

FWIW I'm not using Byobu and I have the same symptoms (though I am using TMUX).

[fpqc]

@LilRed doesn't happen for me on tmux with my config:

tmuxconf.zip

I use the xterm-keys function in my conf.

Also contains overrides to force truecolor support and some other crap.

Note:
Also, that will possibly not work with the ubuntu terminfo database. That one uses the arch terminfo db (ubuntu's doesn't have a tmux-256color). Also, I'm using a git build of tmux.

tmux is literally notorious for this kind of problem.

@zadjii-msft Yeah, F1-F4 work ,but F5-F12 are still messed up in my tmux setup. However, this also happens in Mintty (also on tilda and gnome-terminal on my secondary-boot Arch installation, and it happens in both bash and zsh with or without tmux). I bet you that this is just an xterm thing.

Edit: @zadjii-msft this could just be a readline thing. Tmux should probably be able to bind them. The keys F5-F12 didn't exist on the DEC Terminals up to the VT220 and it seems like libreadline just assumes that you're using the easy ones.

As an aside, it is funny though. But wouldn't it have been so much easier to be compatible with a from-scratch terminal effort like st? It seems like xterm was written by insane people!

[zadjii-msft]

@fpqc See, I think it might be a readline thing too. I also noticed this same kind of incorrect behavior happens trying to use the mouse with byobu on WSL. You'll see much of the escape sequence echo'd to the input, as if it tried to read the first few bytes, then decided it was a noop sequence and echo'd the remainder.

Again, these scenarios work fine in tmux, so I'm at a loss.

[carlpaten]

@fpqc: I installed tmux-sensible and that fixed it. Thanks for the help.

[bdbch]

It also doesn't work with "Hyper" from zeit.

vercel/hyper#1127

[zadjii-msft]

@DB2K That's probably more related to #111 than anything else. At this point in time, conhost consumes the input sequences and doesn't pass it up to any other terminal application that might be scraping the console. That thread has more info.

I've found at least internally that the function keys are suddenly working much better in byobu. I don't think I did anything that made it work better, maybe @Brian-Perkins can weigh in if the kernel folks changed anything to improve this.

Anywho, expect better behavior in a coming build :)

[t-anjan]

I am on build 15025. I still have to press my F-keys and other Byobu shortcut keys (e.g. Shift+arrows, Alt+arrows) multiple times, repeatedly, in quick succession, before one of the keypresses gets recognized. It is really irritating, especially because it is unpredictable. Sometimes, the first keypress gets detected. Other times, when I am repeatedly and quickly bashing the keys, two or three successive keypresses get detected, when I wanted just one.

Is there any solution in sight? Or should we switch to using tmux directly?

[dustinkirkland]

The Windows terminal isn't catching the F-keys and passing through to tmux correctly. :-Dustin

…

On Mon, Feb 6, 2017 at 7:35 AM, t-anjan ***@***.***> wrote: I am on build 15025. I still have to press my F-keys and other Byobu shortcut keys (e.g. Shift+arrows, Alt+arrows) multiple times, repeatedly, in quick succession, before one of the keypresses gets recognized. It is really irritating, especially because it is unpredictable. Sometimes, the first keypress gets detected. Other times, when I am repeatedly and quickly bashing the keys, two or three successive keypresses get detected, when I wanted just one. Is there any solution in sight? Or should we switch to using tmux directly? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzMhmsVHOy2-lCgF6AYO-tMZbDiKuqCks5rZyGqgaJpZM4LKyZI> .

[benhillis]

@zadjii-msft - Should this be resolved by your recent checkin?

[zadjii-msft]

@benhillis I do believe you're right.

I can't say for sure, as I stopped noticing problems with byobu about a month or two ago, but I do know that byobu still works, so that's a good sign.

Long story short - I made a change to the lxss kernel last friday that should make input sequences that are generated by a single keypress all get injected into the subsystem at the same time, as opposed to character by character. This was in response to a number of issues, #425, #933, #980, and a reported issue with ghci.

Ideally, this should be fixed in an insiders build soon^tm. If it's not, then I have NO idea what's happening any more.

[dustinkirkland]

Fantastic! Thanks! :-Dustin

…

On Mon, Feb 6, 2017 at 10:17 AM, Mike Griese ***@***.***> wrote: @benhillis <https://github.com/benhillis> I do believe you're right. I can't say for sure, as I stopped noticing problems with byobu about a month or two ago, but I do know that byobu *still* works, so that's a good sign. Long story short - I made a change to the lxss kernel last friday that should make input sequences that are generated by a single keypress all get injected into the subsystem at the same time, as opposed to character by character. This was in response to a number of issues, #425 <#425>, #933 <#933>, #980 <#980>, and a reported issue with ghci. Ideally, this should be fixed in an insiders build soontm. If it's not, then I have *NO* idea what's happening any more. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzMhpZooXZ-CryiLzPyzwoMaRhUa1CIks5rZ0eqgaJpZM4LKyZI> .

[t-anjan]

@zadjii-msft - Do you know if your fix has shipped in any insider's build? I am guessing not, because even on 15063, the issue remains.

[zadjii-msft]

@t-anjan I believe this should be in the creator's update. I'm certainly not seeing it repro anymore on creator's update.

If you're still seeing this, could you do the following for me?
In emacs, press the following keys:
Ctrl+h, k, Ctrl+F12

You should see the following in the status line:

<C-f12> is undefined is the important part.
(it might be something else if you've mapped C-F12 to something in emacs)

(MSFT:11360877 is tracking making SURE that this is fixed. I've battled far too long with this to have it come back.)

[avimehenwal]

I encountered the same problem today using byobu on WSL windows 11 terminal.
Suddently all function keys <F-..> stopped working ! after some-time