Apple keyboard - F buttons don't work

Bug #482623 reported by Neil Perry
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Dustin Kirkland 
byobu (Ubuntu)
Fix Released

Bug Description

Can't seem to get F buttons to work, seem to work elsewhere perfectly.

Lsusb output:
neil@desktop:~$ lsusb | grep Keyboard
Bus 001 Device 004: ID 05ac:0221 Apple, Inc. Keyboard (Aluminium) (ISO)

neil@desktop:~$ byobu --version
Screen version 4.00.03jw4 (FAU) 2-May-06

Please ask if you need anymore information.

Related branches

Neil Perry (nperry)
description: updated
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hey Nick-

Assigning you this one, as i think you have an Apple laptop, right? Can you reproduce this? If so, can you suggest a fix?

Changed in byobu:
importance: Undecided → Low
assignee: nobody → Nick Barcet (nijaba)
status: New → Incomplete
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

FWIW, Apple's screen(1) manpage seems to match ours, at least from a documentation perspective:

Revision history for this message
Nick Barcet (nijaba) wrote :

Functions key for byobu work fine on my MacBookPro (running Ubuntu), but as for all function keys on apple keyboards, I need to press the Fn key for F1 - F10 to work as their primary assignment is to perform some other role (screen brightness, sound volume, etc...). Could this be your issue?

Revision history for this message
Neil Perry (nperry) wrote :

No matter weather I press and/or hold FN button it will not work. What seems to be odd is in terminal its print out '~' when i press and hold the FN button then press a button between F1-F10.

Revision history for this message
Nick Barcet (nijaba) wrote :

Neil, can you give us some details on
 * the type of Mac Ubuntu is running on
 * the Ubuntu version you are using (cat /etc/lsb-release)
 * the terminal you are using
Thanks a lot for your help trying to make byobu and Ubuntu better.

Revision history for this message
Neil Perry (nperry) wrote :

 * Its a custom built computer, I just really liked the Apple Keyboard.
 * Confirmed in both Karmic & Lucid
 * gnome-terminal

Hope this helps!

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hi Clint-

You have an Apple keyboard... Any chance you could help me narrow down what works and doesn't work?

If you can give me a list of F-keys that do work with Apple, I could create a second set of keybindings, selectable in the menu or in your ~/.byobu/keybindings...


Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 482623] Re: Apple keyboard - F buttons don't work

On May 15, 2010, at 1:05 PM, Dustin Kirkland wrote:

> Hi Clint-
> You have an Apple keyboard... Any chance you could help me narrow down
> what works and doesn't work?
> If you can give me a list of F-keys that do work with Apple, I could
> create a second set of keybindings, selectable in the menu or in your

F9 is just masked by default by exposé's configuration. It can only really be fixed by a user changing their system configs. On macbooks, thats perfectly acceptable, as the unmodified "f3" key activates exposé on the macbook/macbook pro's.

I'm running byobu 2.74 over ssh on CentOS, and none of the F-keys except F9 work in mac terminal (they do work fine in gnome terminal from an Ubuntu 10.04 instance)

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Okay, thanks for the info.

Revision history for this message
Chris Stork (cstork) wrote :

I have a similar problem. Don't know how much it's related and if it should be a separate bug report.

Server: Lucid with byobu 2.75. Client: MacBook Pro running Snow Leopard 10.6.3.
Empty .screenrc.

When I ssh into the server and run just run screen then dumptermcap dumps the lines


When I run byobu instead it dumps


Which lacks all the k2, k3, ..., k9 capabilities as is to be expected.

However, F2, F3, and F4 don't work, i.e., they only cause the terminal to beep.
Even if I manually enter, say, "^a:bindkey -k k2 screen" the result is the same.
If I enter the same in the first-mentioned screen session I succeed.

Anything ideas?

Revision history for this message
Michael Nagel (nailor) wrote :

this one annoys me royally, too. i did some investigations:

1) on your mac go to the system preferences -> expose and spaces
2) disable everything involving f-keys you might want to use. mac os will eat those key presses and it will never work.

3) launch terminal, connect to linux machine, run byobu
4) fn+f9 will work, other f-keys will not work

5) on the mac launch another terminal
6) set environent like "export TERM=vt100"
7) reconnect to linux machine, run byobu
8) fn+f2 thru fn+f8 will work, fn+f9 will not work

setting TERM=xterm-color results in the behavior described in step 3 and 4

you can set TERM via the preferences gui, too, but only xterm-color (the default) and vt100 will be of any use. both are not perfect though. hopefully someone can combine the benefits of both...

Revision history for this message
Michael Nagel (nailor) wrote :

i found a workaround:

dont use apples terminal app, but launch xterm with the following command:
xterm -class UXTerm -u8
then ssh to the machine running ubuntu and launch byobu. all f-keys should work now. at least they do for me...

Revision history for this message
Ross Lawley (ross-lawley) wrote :

On leopard <fn> + <cmd> + <f9> works for me on

I have expose bound to <f9> but using <cmd> stops that activating.



Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Thanks for all the info and hints, guys.

I'd like to move this from a Bug to a Question, as it seems that quite a number of Apple users have this same experience.

I don't know that there's anything I can do from a Byobu/Screen perspective to fix this behavior, except for documenting it in the manpage.

Can anyone suggest a concise bit of text that would be appropriate for instructions in a manpage?

Thanks for all the info!

Changed in byobu:
assignee: Nick Barcet (nijaba) → nobody
Revision history for this message
Marco Ferragina (ferama) wrote :

I use an alias in my .profile for ssh sessions

alias ssh='TERM=vt100 ssh'

Using this alias function keys work well on remote machine and on local you have fancy colors as always ;)

Revision history for this message
Dustin Kirkland  (kirkland) wrote :


Awesome, thanks! I'll add this to the byobu.1 manpage.

Changed in byobu:
assignee: nobody → Dustin Kirkland (kirkland)
status: Incomplete → In Progress
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Committed revision 1309.

Added a note to the manpage:

+Apple Mac keyboard users may need to specify a vt100 terminal by adding this to your OSX profile, in order to get Byobu's function keys and colors to work:
+ alias ssh='TERM=vt100 ssh'

This is the best we can do with this bug. Thanks!

Changed in byobu:
status: In Progress → Fix Committed
Changed in byobu (Ubuntu):
status: New → Fix Committed
importance: Undecided → Low
Changed in byobu:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package byobu - 3.29-0ubuntu1

byobu (3.29-0ubuntu1) natty; urgency=low

  [ Dustin Kirkland ]
  * usr/share/man/man1/byobu.1: document PS1 workaround, LP: #525552
  * usr/share/man/man1/byobu.1: fix minor manpage typo, add SERVICES example
  * usr/lib/byobu/wifi_quality, usr/share/man/man1/byobu.1: support overriding
    the default wireless interface, LP: #723260
  * usr/share/man/man1/byobu.1: document TERM=vt100 for Mac keyboard users,
    LP: #482623
  * usr/bin/byobu-janitor: use readlink, much more graceful
  * usr/lib/byobu/time_binary, usr/share/byobu/profiles/common,
    usr/share/man/man1/byobu.1: fixup a couple of minor issues with the binary
    clock commit
  * usr/bin/byobu-status: switch the interpreter from sh to bash; this is
    needed to support James' time_binary script, which is bash and cannot be
    simply sourced by byobu-status; if significant performance regressions
    occur, we will need to back this change out and approach it a different

  [ James Hunt ]
  * etc/byobu/statusrc, usr/bin/byobu-config, usr/lib/byobu/time_binary,
    usr/share/byobu/profiles/common, usr/share/man/man1/byobu.1:
    - add support for the super-geeky-but-fun binary clock; requires
      UTF8 support in GNU Screen, LP: #705037

  [ Chow Loong Jin and Dustin Kirkland ]
  * usr/lib/byobu/disk_io: canonicalize symlinks so that disk_io works
    with raid, lvm, dm volumes, LP: #709224, #711373, #723187
 -- Dustin Kirkland <email address hidden> Wed, 23 Feb 2011 16:24:38 -0600

Changed in byobu (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Paul V. Stodghill (paul-stodghill) wrote :

I think that I can provide some more info. According to,

X11R6 xterm and XFree86 xterm produce difference keysequences for F1-F4(!). gnome-terminal and generate the same sequence as XFree86, but identifies itself as "xterm-color".

Workaround: I found that if I changes the default keybindings in for F1, etc. from ^[OP, etc. to ^[[11~, etc., then all of the F keys work within byobu _without_ changing $TERM. I.e., TERM == xterm-color.

Another data point. Open the native xterm under Apple's X11 (which generates the XFree86 keysequences),
- Run byobu (I'm using the version from homebrew). F1-F4 work.
- Exit byobu. "export TERM=xterm-color
- Run byobu. F1-F4 do _not_ work.

The difference lies in how byobu handles TERM==xterm and TERM==xterm-color.



Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Actually, I just came across this:

Which suggests adding the following to ~/.screenrc:
terminfo * k1=\EOP
terminfo * k2=\EOQ
terminfo * k3=\EOR
terminfo * k4=\EOS
terminfo * k5=\E[15~
terminfo * k6=\E[17~
terminfo * k7=\E[18~
terminfo * k8=\E[19~
terminfo * k9=\E[20~
terminfo * F1=\E[23~
terminfo * F2=\E[24~

Could someone who can still reproduce this bug please try this and let me know the result?


Revision history for this message
Erik Bryn (ebryn) wrote :


Adding those terminfo commands to my .screenrc fixed my problems while using Apple's


Revision history for this message
Erik Bryn (ebryn) wrote :

Well, I spoke too soon. The F-keys work on their own, but with modifiers they don't - I'm trying to create a split window using Shift-F2 or Ctrl-F2. Nothing happens...

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hmm, okay, thanks. Partial fix. Will need to dig a bit deeper ...

Revision history for this message
Charles H. Leggett (cleggett) wrote :

Can we open this one back up (or create a new one) b/c I am new to byobu (installed via Homebrew) and I am having similar trouble.

Mac OS X Lion 10.7.3 (11D50b)

$ byobu --version
byobu version 5.12
tmux 1.6

$ echo $TERM

I am using and have disabled all of the F<anything> keybindings in System Preferences-> Keyboard-> Keyboard Shortcuts.

Things that work:

F2, F3, F4, F6, F7, F8

Challenges that I am having:
F1 (1: config* "flashes" but, does not "stick")
F9 (1: config* "flashes" but, does not "stick")
Shift-F2 (does nothing)
Ctrl-F2 (does nothing)

I have also tried all of this with xterm (installed via MacPorts) and I have the same result except that Shift-F2 and Ctrl-F2 work there.

Let me know what I can do to help resolve these issues.

Thanks and keep up the good work.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Reopening. I don't have a Mac or a Mac keyboard. I'll look into getting one sometime, perhaps, and try and get this working better. No timeline commitment though :-)

Changed in byobu:
status: Fix Released → Confirmed
Revision history for this message
Frank Laub (frank-laub) wrote :

This bug also occurs in a totally different environment. I have an Apple keyboard connected to a Windows 7 workstation. I'm using cygwin + ssh to login to a remote Ubuntu machine. Whenever I use byobu from the Ubuntu machine, I get broken behavior with F-keys. When trying to use F3 or F4 to enumerate windows I usually get "^[OR" or "^[OS" respectively show up without the window actually flipping. Every 1 in ~10 times the function does work.

Using "TERM=vt100 ssh" when logging into the remote Ubuntu machine does not fix the issue.

I should note that I'm using the tmux backend in this setup.

Revision history for this message
Dustin Keeler (fishfilet) wrote :

I don't know if this is still open or not as it has been a while since the last comment.

I did have a few things to add that may be related to some of the problems described.

First I have a Macbook Pro about 5 years old now. While there are function keys they do not operate as function keys by default. Instead they are used to control the screen brightness, volume, keyboard backlight, etc. To use them as function keys you have to hold down the fn key next to the left control key as mentioned in an earlier comment. This can however be changed in "System Preferences > Keyboard". Just check the box that says "Use all F keys as standard function keys". If you do this then the behavior is reversed. All function keys work like function keys and if you use the fn key next to the left control key they will then operate screen brightness, sound, etc.

In addition to knowing about this setting and it's effect you also may need to disable some Keyboard shortcuts as the operating system may be using them. This is done again under "System Preferences > Keyboard" under the Keyboard Shortcuts tab.

The last thing is this. I was able to use F2 to open a new window but I could not split the window with Shift-F2 or Control-F2. This drove me mad until I found a setting to fix this. I use the built in terminal app in OSX. If you go to the preferences menu in the terminal app you will see a few buttons at the top. Under the settings button there are a few sub sections on the right side such as "Text, Window, Shell, Keyboard, Advanced". Go to the Keyboard section and you will see a list of keys and the action they are mapped to. For me the F2 key was mapped to \033OQ. I noticed though that there was no mapping for Shift-F2 or Control-F2. This must be my issue right?

So I found a byobu config file at /usr/share/byobu/keybindings/f-keys.screen. In this file I found that Shift-F2 was expecting O1;2Q and Control-F2 was expecting O1;5Q. The ^[ is the escape key which in the terminal app is \033.

So I then added the mappings in the terminal app so that Shift-F2 was \033O1;2Q and Control-F2 was \033O1;5Q. After doing that I could now split windows.

So it seems that for some reason the apple terminal app simply did not send the sequence byobu was expecting. There may be other keys as well that you need to map in the terminal app. I assume that other terminal applications may have similar settings that need to be configured.

While this may not be relevant I have to ask. How can I find out what sequence a program is expecting? While I found this f-keys.screen file for byobu I have not been able to find out the information I need for other programs. For instance tmux without byobu. Is there an all inclusive list of what sequence a key should send somewhere? For instance I need to know what to send for Control-Left, Control-Right, Alt-Left, Alt-Right and others.

Revision history for this message
Lee Mendelowitz (lmendy) wrote :

I posted a solution that worked for me using iTerm2 on OS X to StackOverflow:

It involved removing OS X keyboard shortcuts that could interfere, updating the iTerm2 profile key map to send the correct escape sequences, and setting the TERM environment variable to "linux".

The read utility was useful for returning what escape sequences the shell is seeing for different key combinations.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.