Bug 595763 - Laptop Display Switch Key Does Not Work
Summary: Laptop Display Switch Key Does Not Work
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnome-settings-daemon
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: desktop-bugs@redhat.com
: 607761 617560 617605 617919 (view as bug list)
Depends On:
Blocks: 557931 629047
TreeView+ depends on / blocked
Reported: 2010-05-25 14:57 UTC by Marko Myllynen
Modified: 2013-01-10 08:08 UTC (History)
19 users (show)

Fixed In Version: gnome-settings-daemon-2.28.2-11.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 617728 629047 (view as bug list)
Last Closed: 2010-11-10 20:33:19 UTC
Target Upstream Version:

Attachments (Terms of Use)
patch (13.38 KB, patch)
2010-07-19 15:22 UTC, Bastien Nocera
no flags Details | Diff
xmodmap file (4.33 KB, text/plain)
2010-07-28 02:34 UTC, Eric Blake
no flags Details

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 623223 0 None None None Never

Description Marko Myllynen 2010-05-25 14:57:42 UTC
Description of problem:
This is a generic bug about a display switch key not working on various new laptop models. The following blog entry has more details why the key does not work:


As of RHEL 6.0 Snapshot 4 this is still an issue with RHEL 6.

Comment 2 RHEL Program Management 2010-06-04 14:03:15 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Peter Hutterer 2010-06-30 01:32:11 UTC
*** Bug 607761 has been marked as a duplicate of this bug. ***

Comment 8 Matthew Garrett 2010-07-14 12:50:47 UTC
No plausible way to fix this in kernel, reassigning to desktop.

Comment 11 Bastien Nocera 2010-07-19 15:22:03 UTC
Created attachment 432915 [details]

Implement this. Works on my RHEL-6 machine, but might need a bit of cleaning up.

Comment 12 Issue Tracker 2010-07-20 20:11:46 UTC
Event posted on 07-20-2010 04:11pm EDT by ctatman

Hey All,

Can we get either Dell or Red Hat to verify the patch so we can get the QA
department to sign off on this?

Rez: Are you willing to test this patch out and verify it for us?



This event sent from IssueTracker by ctatman 
 issue 1051003

Comment 13 Issue Tracker 2010-07-20 20:14:55 UTC
Event posted on 07-20-2010 04:14pm EDT by ctatman

Hey All,

Dell has agreed to test this for us in snap8 and verify whether it works
or not.

Rez: Once snap8 comes out please test it and let us know if this is



This event sent from IssueTracker by ctatman 
 issue 1051003

Comment 14 Owen Taylor 2010-07-22 17:42:05 UTC
Note for QE: I'm not sure if we have the necessary hardware to test the "display switch key" problem in-house, but on any computer, you should be able to test the new packages by pressing Super-p and verifying that it properly cycles the video outputs.

Comment 16 Bastien Nocera 2010-07-22 19:38:22 UTC
Fixed in gnome-settings-daemon-2.28.2-8.el6

Comment 17 Bastien Nocera 2010-07-23 13:16:59 UTC
*** Bug 617560 has been marked as a duplicate of this bug. ***

Comment 18 Bastien Nocera 2010-07-23 13:17:44 UTC
Apparently causes problems typing the "p" letter, oops.

Comment 20 Bastien Nocera 2010-07-23 14:35:19 UTC
There are 2 problems I saw:
- first is that the unmodified key seems to be captured. We're only supposed to
capture the key with the actual modifiers, and all the combinations of unused
modifiers (so Num-lock doesn't cause the key not to be captured for example)
- the 2nd problem is that despite the key being captured, we never match the
key, and pass GDK_FILTER_CONTINUE, but the key never gets to the applications.

Ray will look into this in my absence.

Comment 21 Mark Gordon 2010-07-23 15:05:37 UTC
*** Bug 617605 has been marked as a duplicate of this bug. ***

Comment 22 Ray Strode [halfline] 2010-07-23 16:10:14 UTC
I've addressed the issue mentioned in comment 18 in gnome-settings-daemon-2.28.2-9.el6.

I haven't tested the implemented feature as a whole.  I'll need to track down hardware that has this unfortunate Windows-P thing to do that.  Matthew or Cameron, can one of you help with that?  Also, in the mean time, for anyone willing to help, I'd appreciate testing of two things in gnome-settings-daemon-2.28.2-9.el6 :

1) That the 'can't type "p"' problem is fixed
2) That the initial reported problem is resolved

Comment 24 Ray Strode [halfline] 2010-07-23 17:31:27 UTC
Mark has set me up with a T410 that appears to have this behavior. I'll do some tests with it now.

Comment 25 Bill Burns 2010-07-23 17:45:42 UTC
New package works for me too...I can type p again...

Comment 26 Ray Strode [halfline] 2010-07-23 17:55:35 UTC
So the T410 isn't appropriate hardware after all.  fn-F7 emits XF86Display.

There is definitely a lingering problem in the patch though.  It's doing a synchronous d-bus call to itself which blocks until timeout (~25 seconds i think) since there's no way it can answer a call to itself while blocked.

I'll look into correcting that specific issue, but ideally I'm still going to need to obtain hardware that has the problem mentioned in comment 0.

Comment 27 Ray Strode [halfline] 2010-07-23 19:22:50 UTC
I'm building a new package that should take care of the blocking issue.

I've also talked to John Feeney.  He loaned me a laptop that may be susceptible to the problem mentioned in comment 0. I'll do some testing with it now.

Comment 29 Ray Strode [halfline] 2010-07-23 19:46:53 UTC
I've done some testing with John's Dell Precision M6500.

The patch works fine with the caveat that there seems to be an orthogonal nouveau driver issue that prevents it from detecting the monitor layout.  It thinks there is only one monitor hooked up, so hitting fn-F8 does initiate a cycle, but it just cycles back to the same configuration over and over again with each keypress.

I'll file that bug separately.

Comment 30 Ray Strode [halfline] 2010-07-23 19:57:38 UTC
The problem mentioned in comment 29 was a false alarm.  I just didn't have the nouveau driver installed so it was falling back to vesa.

Everything seems to work fine.

Comment 31 Ray Strode [halfline] 2010-07-26 18:03:54 UTC
*** Bug 617919 has been marked as a duplicate of this bug. ***

Comment 32 Eric Blake 2010-07-26 22:13:41 UTC
I'm still having problems typing 'p', after installing:
Is there something else I'm missing, or more information I can provide you to help resolve it?

Comment 33 Ray Strode [halfline] 2010-07-26 22:38:56 UTC
Eric, have you rebooted since installing the package?

Comment 34 Eric Blake 2010-07-26 23:02:37 UTC
Yes, and I'm still seeing the issue, in both a 32-bit VM and a 64-bit bare metal install.  By the way, it has been interesting (to put it mildly) figuring out tricks to get around the lack of a 'p', such as:

$ /bin/r?m -q gnome-settings-daemon

Comment 35 Ray Strode [halfline] 2010-07-27 14:20:27 UTC
Eric, can you post the output of

gconftool-2 -R /apps/metacity >> /tmp/gconf.txt
gconftool-2 -R /apps/gnome_settings_daemon >> /tmp/gconf.txt


Also, if you run gconf-editor and then navigate to 

apps > gnome_settings_daemon > plugins > media-keys

and uncheck the checkbox next to "active", logout and log back in, do you get your p key back?

Comment 36 Eric Blake 2010-07-27 15:08:44 UTC
# gconftool-2 -R /apps/gnome_settings_daemon >> /tmp/gconf.txt
Failure listing entries in `/apps/gnome_settings_daemon': Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
# cat gconf.txt
# gconf-editor
bash: gconf-editor: command not found
# yum install -y gconf-editor
# gconf-editor
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
...[lots more of those]

and I can't see anything other than / in the gconf-editor gui

Comment 37 Ray Strode [halfline] 2010-07-27 15:39:44 UTC
are you running those commands from within the logged in session that's causing the issue? If not, you need to.

Comment 38 Eric Blake 2010-07-27 15:49:50 UTC
Ah - I was running them as root, not as myself.  Trying again with the right uid:

$ cat /tmp/gconf.txt
  cycle_group_backward = disabled
  switch_to_workspace_1 = disabled
  switch_to_workspace_2 = disabled
  switch_to_workspace_3 = disabled
  switch_to_workspace_11 = disabled
  switch_to_workspace_12 = disabled
  switch_to_workspace_6 = disabled
  switch_to_workspace_4 = disabled
  switch_to_workspace_7 = disabled
  switch_to_workspace_9 = disabled
  switch_to_workspace_8 = disabled
  show_desktop = <Control><Alt>d
  switch_to_workspace_10 = disabled
  cycle_group = <Alt>F6
  switch_to_workspace_left = <Control><Alt>Left
  switch_windows = <Alt>Tab
  switch_panels = <Control><Alt>Tab
  switch_to_workspace_down = <Control><Alt>Down
  switch_to_workspace_5 = disabled
  switch_windows_backward = disabled
  switch_to_workspace_right = <Control><Alt>Right
  cycle_windows_backward = disabled
  cycle_panels = <Control><Alt>Escape
  run_command_1 = disabled
  run_command_2 = disabled
  run_command_3 = disabled
  run_command_4 = disabled
  run_command_5 = disabled
  run_command_6 = disabled
  run_command_7 = disabled
  run_command_8 = disabled
  switch_group = disabled
  switch_group_backward = disabled
  cycle_windows = <Alt>Escape
  run_command_10 = disabled
  run_command_11 = disabled
  run_command_12 = disabled
  switch_to_workspace_up = <Control><Alt>Up
  run_command_screenshot = Print
  panel_main_menu = <Alt>F1
  switch_panels_backward = disabled
  run_command_9 = disabled
  cycle_panels_backward = disabled
  run_command_terminal = disabled
  panel_run_dialog = <Alt>F2
  run_command_window_screenshot = <Alt>Print
  command_11 = 
  command_12 = 
  command_screenshot = gnome-screenshot
  command_1 = 
  command_2 = 
  command_3 = 
  command_4 = 
  command_5 = 
  command_6 = 
  command_7 = 
  command_8 = 
  command_9 = 
  command_window_screenshot = gnome-screenshot --window
  command_10 = 
  minimize = <Alt>F9
  begin_resize = <Alt>F8
  maximize = disabled
  move_to_center = disabled
  move_to_side_e = disabled
  move_to_workspace_1 = disabled
  move_to_workspace_2 = disabled
  move_to_workspace_3 = disabled
  move_to_workspace_4 = disabled
  activate_window_menu = <Alt>space
  toggle_fullscreen = disabled
  move_to_workspace_6 = disabled
  move_to_workspace_7 = disabled
  move_to_workspace_8 = disabled
  move_to_workspace_9 = disabled
  move_to_workspace_5 = disabled
  lower = disabled
  maximize_horizontally = disabled
  raise = disabled
  toggle_shaded = disabled
  move_to_corner_ne = disabled
  move_to_workspace_right = <Control><Shift><Alt>Right
  raise_or_lower = disabled
  unmaximize = <Alt>F5
  move_to_side_w = disabled
  move_to_side_s = disabled
  move_to_side_n = disabled
  move_to_workspace_up = <Control><Shift><Alt>Up
  toggle_maximized = <Alt>F10
  move_to_workspace_left = <Control><Shift><Alt>Left
  begin_move = <Alt>F7
  move_to_workspace_down = <Control><Shift><Alt>Down
  move_to_corner_nw = disabled
  close = <Alt>F4
  toggle_on_all_workspaces = disabled
  move_to_corner_sw = disabled
  maximize_vertically = disabled
  move_to_corner_se = disabled
  move_to_workspace_10 = disabled
  move_to_workspace_11 = disabled
  move_to_workspace_12 = disabled
  toggle_above = disabled
  name_1 = 
  name_2 = 
  name_10 = 
  name_11 = 
  name_12 = 
  name_13 = 
  name_14 = 
  name_15 = 
  name_16 = 
  name_8 = 
  name_9 = 
  name_7 = 
  name_5 = 
  name_6 = 
  name_3 = 
  name_4 = 
  visual_bell_type = fullscreen
  auto_raise_delay = 500
  titlebar_font = Sans Bold 10
  reduced_resources = false
  application_based = false
  theme = Clearlooks
  mouse_button_modifier = <Alt>
  focus_new_windows = smart
  action_double_click_titlebar = toggle_maximize
  audible_bell = true
  resize_with_right_button = false
  new_windows_always_on_top = false
  compositing_manager = false
  titlebar_uses_system_font = false
  num_workspaces = 2
  button_layout = menu:minimize,maximize,close
  action_middle_click_titlebar = lower
  no_focus_windows = 
  disable_workarounds = false
  focus_mode = click
  raise_on_click = true
  action_right_click_titlebar = menu
  auto_raise = false
  visual_bell = false
 volume_step = 6
  canberra-gtk-module = true
  pk-gtk-module = true
  gail:atk-bridge = /desktop/gnome/interface/accessibility
  show_notification_icon = false
  volume_down = XF86AudioLowerVolume
  media = XF86AudioMedia
  screensaver = <Control><Alt>l
  home = XF86Explorer
  pause = XF86AudioPause
  search = XF86Search
  volume_up = XF86AudioRaiseVolume
  email = XF86Mail
  previous = XF86AudioPrev
  sleep = 
  help = 
  power = <Control><Alt>Delete
  stop = XF86AudioStop
  eject = XF86Eject
  next = XF86AudioNext
  volume_mute = XF86AudioMute
  www = XF86WWW
  play = XF86AudioPlay
  calculator = XF86Calculator
   priority = 6
   active = true
   priority = 7
   active = true
   priority = 97
   active = true
   priority = 20
   active = true
   priority = 90
   active = false
   priority = 2
   active = true
   priority = 5
   active = true
   priority = 7
   active = true
   priority = 200
   active = true
   priority = 99
   active = true
   priority = 300
   active = true
   priority = 1
   active = true
   priority = 4
   active = true
   priority = 98
   active = true
   priority = 8
   active = true

Then using gconf-editor as described let me type p again.  Thanks for the tips.

Comment 39 Ray Strode [halfline] 2010-07-27 16:40:14 UTC
It's not clear to me yet why the bug is happening for Eric, but it clearly is a problem for him, caused by these changes, so moving back to ASSIGNED.

Comment 40 Ray Strode [halfline] 2010-07-27 16:45:19 UTC
Eric, would you mind also posting the output of:

gconftool-2 -R /desktop/gnome/peripherals/keyboard


Does your keyboard have a Windows key on it?  If so, have you configured things to treat the Windows key as some other key (say meta, compose, altgr, etc)


I'm just trying to figure out what's different about your setup to make it not work for you.  Does the problem happen for you with a freshly made user?

Comment 41 Ray Strode [halfline] 2010-07-27 17:45:29 UTC
I'm building a new package:


This package does two things:

1) It adds a sanity check to make sure unmodified keys like "p" can never be grabbed.  That should take the teeth out of this bug and any future bugs along these lines.

2) It adds a warning message to ~/.xsession-errors whenever that sanity check kicks in with some of the context surrounding why its kicking in.  That combined with the info I requested in comment 40 should hopefully help us track down the remaining problem.

Eric, would you mind upgrading gnome-settings-daemon, firing up gconf-editor, re-enabling the media-keys plugin, logging out, logging back in and then posting ~/.xsession-errors (along with the info requested in comment 40) ?

Comment 43 Eric Blake 2010-07-27 23:26:04 UTC
With -10 still installed:

$ gconftool-2 -R /desktop/gnome/peripherals/keyboard
 bell_custom_file = (no value set)
 bell_pitch = 400
 rate = 30
 remember_numlock_state = true
 bell_duration = 100
 click = true
 click_volume = 0
 repeat = true
 disable_xmm_and_xkb_warning = true
 bell_mode = on
 delay = 500
  secondary = 0
  showFlags = false
  enabledPlugins = []
   numlock_on = false
  x = -1
  y = -1
  width = -1
  height = -1
   numlock_on = true
  defaultGroup = -1
  update_handlers = [.xmodmap-office]
  handleIndicators = false
  disable_sysconfig_changed_warning = false
  groupPerWindow = true
  known_file_list = [.xmodmap-office~,.xmodmap-office,.xmodmap-office.bak,.xmodmap-office.bak~]
  layoutNamesAsGroupNames = true
  loadExtraItems = false
  layouts = [us]
  options = []
  model = 

My main keyboard is a wireless USB Logitech MK300 connected to my F13 laptop.  It differs slightly from the standard 104-key: it has a left Win but only a right Fn key so that it has fewer physical keys but more than the typical 104 scancodes (Fn-PrtSrn maps to the windows Menu key; Fn-Pause maps to ScrlLk).

For both RHEL hosts where I'm experiencing the issue, I'm generally accessing X (and thus gnome) through my F13 laptop's keyboard - my 32-bit VM RHEL host is going through the vnc connection created by libvirtd, and my 64-bit raw metal RHEL host is being shared through synergy-plus (I'm typing this from my laptop, where 'p' has no problems, so it's all in how 'p' is interpreted when it gets to the RHEL X layer).  I've also used xmodmap on my laptop to change things up from the default: I like my left and right alt keys (nearest the spacebar) to be Meta, and the (left) Win key to be Alt (sadly, the Fn key can't be remapped, so I can't have a right Alt).  Since I share my /home drive via NFS among all three hosts, that means that logging in to my RHEL host will pick up the same .xmodmap as my laptop, even if I'm not directly doing input to those machines.

Given your comments, I re-enabled the gnome_settings_daemon (still at -1), plugged in a standard 104-key Lenovo keyboard directly to the 64-bit raw metal RHEL, and confirmed that it to has the problem with lower-case 'p', even without going through synergy (typing 'p' still causes the screen to flash, and all input over the next fraction of a second to be lost); 'P' continues to work.

I also confirmed the login screen accepts 'p' when typing a username or password.  And, as requested, when I logged on as a different (new) user, with no .xmodmap interference, the 'p' key worked just fine.  So I'm wondering if the problem is related to the fact that both my RHEL hosts are loading a potentially problematic .xmodmap.

This comment is getting long; I'll save it now, and do my testing with -11 as another comment...

Comment 44 Eric Blake 2010-07-27 23:46:23 UTC
With -11 installed, and the gconf-editor enabling media-keys, I logged out and back in.  This time, typing 'p' worked.  However, ~/.xsession-errors was empty for the entire time of typing 'p' and other combinations while logged in, and it remained empty even after I logged out and re-checked the file as root.  This remained the case even after cycling through two more logins, one with gconf-editor media-keys disabled and another with it re-enabled.  So I have no idea if the sanity check was kicking in, but life is certainly nicer with -11.

Comment 45 Ray Strode [halfline] 2010-07-28 01:49:56 UTC
Thanks for the detailed information.

Can you attach your .xmodmap file?  It should be fairly easy for me to reproduce the bug with that file and get to the bottom of things.

Comment 46 Eric Blake 2010-07-28 02:34:46 UTC
Created attachment 434892 [details]
xmodmap file

Comment 47 Ray Strode [halfline] 2010-07-28 12:40:35 UTC
Ah okay, so in that file you have:

clear Shift
clear Lock
clear Control
clear Mod1
clear Mod2
clear Mod3
clear Mod4
clear Mod5

add    Shift   = Shift_L Shift_R
add    Lock    = Caps_Lock
add    Control = Control_L Control_R
add    Mod1    = Meta_L Meta_R
add    Mod2    = Num_Lock
add    Mod4    = Alt_L Alt_R
add    Mod5    = Scroll_Lock

That's essentially stripping Super out, so I guess my workaround patch is more than just a sanity-check-last-line-of-defense kind of thing.  It's actually a fairly reasonable way of dealing with this kind of scenario.

Thanks, so much for being so responsive and helpful.  moving back to MODIFIED.

Comment 49 Vladimir Benes 2010-08-17 14:21:57 UTC
working well on T410, can do screen cycles using super+p and Fn+F7. Is this, together with comment 29, enough for verification?

Comment 50 Ray Strode [halfline] 2010-08-17 14:39:57 UTC
Ideally, we'd test this on a broad range of affected laptops, but I can see how that might not be feasible.  As mentioned in Comment 14, hitting "Super+P" is enough to touch some of the affected code paths, so it's certainly a reasonable approximation for testing on affected hardware.

I'll leave it up to QE to decide how comfortable you guys are with that level of testing.

Comment 54 Issue Tracker 2010-08-19 21:04:03 UTC
Event posted on 08-19-2010 05:04pm EDT by ctatman

Hey All,

Dell tested with snap10, and has the following to report:

I have tested with RHEL6 Snapshot10 on 2 different systems:

1) On M6500 with nouveau driver, display switching works great.

2) On M4500 with nouveau driver, display switching doesn't work. However,
I believe this is an issue with the Gfx driver. "xrandr -q" on this
system doesn't even detect the external monitor. Just to remind everyone,
this system has eDP which needed some extra work in nouveau previously.

Can the RedHat developer at Brisbane who has this system to check
displaying video on external monitors?




Internal Status set to 'Waiting on Engineering'
Status set to: Waiting on Tech

This event sent from IssueTracker by ctatman 
 issue 1051003

Comment 55 Ben Levenson 2010-08-20 12:57:30 UTC
(In reply to comment #54)
> 2) On M4500 with nouveau driver, display switching doesn't work. However,
> I believe this is an issue with the Gfx driver. "xrandr -q" on this
> system doesn't even detect the external monitor. Just to remind everyone,
> this system has eDP which needed some extra work in nouveau previously.

^^^ Should we open a separate bug for this issue?

Comment 57 Ben Skeggs 2010-08-22 22:12:37 UTC
How is Dell connecting the external display?  Last time it was checked, the system in the Brisbane office worked just fine on the VGA port, and with a DVI monitor plugged into the DP connector with an adaptor.  Even native DP should be *detected*, it just won't display an image.

Comment 60 Ray Strode [halfline] 2010-08-31 19:08:28 UTC
Given this issue has been confirmed by several people, including dell, i'd say this should be moved to VERIFIED.

I'll clone the issue mentioned in comment 54.

Comment 61 Ray Strode [halfline] 2010-08-31 19:13:33 UTC
(Clone filed as bug 629047)

Comment 62 Chris Tatman 2010-08-31 19:31:12 UTC
In reply to comment#57...Dell had this to say:

I tested with __only__ VGA port and it didn't work.

I have tested the below scenario:

1) Booting up the system while a monitor is connected through the VGA port


2) Trying to switch the display after cold and hot plugging the monitor connected through the VGA port.

In neither situations above do I see any display at all on external monitor.


Comment 63 Ray Strode [halfline] 2010-08-31 19:55:00 UTC
(i've forwarded that comment to bug 629047)

Comment 65 releng-rhel@redhat.com 2010-11-10 20:33:19 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.