Bug 595763

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
inclusion.

*** Bug 607761 has been marked as a duplicate of this bug. ***

No plausible way to fix this in kernel, reassigning to desktop.

Created attachment 432915 [details]
patch

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

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?

Thanks!

--Chris


This event sent from IssueTracker by ctatman 
 issue 1051003

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
working.

Thanks!

--Chris


This event sent from IssueTracker by ctatman 
 issue 1051003

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.

Fixed in gnome-settings-daemon-2.28.2-8.el6

*** Bug 617560 has been marked as a duplicate of this bug. ***

Apparently causes problems typing the "p" letter, oops.

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.

*** Bug 617605 has been marked as a duplicate of this bug. ***

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

Mark has set me up with a T410 that appears to have this behavior. I'll do some tests with it now.

New package works for me too...I can type p again...

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.

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.

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.

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.

*** Bug 617919 has been marked as a duplicate of this bug. ***

I'm still having problems typing 'p', after installing:
 gnome-settings-daemon-2.28.2-10.el6.x86_64
Is there something else I'm missing, or more information I can provide you to help resolve it?

Eric, have you rebooted since installing the package?

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
gnome-settings-daemon-2.28.2-10.el6.i686

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?

# 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

are you running those commands from within the logged in session that's causing the issue? If not, you need to.

Ah - I was running them as root, not as myself.  Trying again with the right uid:

$ cat /tmp/gconf.txt
 /apps/metacity/global_keybindings:
  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
 /apps/metacity/keybinding_commands:
  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 = 
 /apps/metacity/window_keybindings:
  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
 /apps/metacity/workspace_names:
  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 = 
 /apps/metacity/general:
  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
 /apps/gnome_settings_daemon/gtk-modules:
  canberra-gtk-module = true
  pk-gtk-module = true
  gail:atk-bridge = /desktop/gnome/interface/accessibility
 /apps/gnome_settings_daemon/xrandr:
  show_notification_icon = false
 /apps/gnome_settings_daemon/keybindings:
  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
 /apps/gnome_settings_daemon/plugins:
  /apps/gnome_settings_daemon/plugins/keyboard:
   priority = 6
   active = true
  /apps/gnome_settings_daemon/plugins/a11y-keyboard:
   priority = 7
   active = true
  /apps/gnome_settings_daemon/plugins/background:
   priority = 97
   active = true
  /apps/gnome_settings_daemon/plugins/keybindings:
   priority = 20
   active = true
  /apps/gnome_settings_daemon/plugins/xrdb:
   priority = 90
   active = false
  /apps/gnome_settings_daemon/plugins/xsettings:
   priority = 2
   active = true
  /apps/gnome_settings_daemon/plugins/sound:
   priority = 5
   active = true
  /apps/gnome_settings_daemon/plugins/mouse:
   priority = 7
   active = true
  /apps/gnome_settings_daemon/plugins/typing-break:
   priority = 200
   active = true
  /apps/gnome_settings_daemon/plugins/clipboard:
   priority = 99
   active = true
  /apps/gnome_settings_daemon/plugins/housekeeping:
   priority = 300
   active = true
  /apps/gnome_settings_daemon/plugins/xrandr:
   priority = 1
   active = true
  /apps/gnome_settings_daemon/plugins/font:
   priority = 4
   active = true
  /apps/gnome_settings_daemon/plugins/media-keys:
   priority = 98
   active = true
  /apps/gnome_settings_daemon/plugins/smartcard:
   priority = 8
   active = true

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

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.

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?

I'm building a new package:

gnome-settings-daemon-2.28.2-11.el6

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) ?

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
 /desktop/gnome/peripherals/keyboard/indicator:
  secondary = 0
  showFlags = false
  enabledPlugins = []
 /desktop/gnome/peripherals/keyboard/host-tower:
  /desktop/gnome/peripherals/keyboard/host-tower/0:
   numlock_on = false
 /desktop/gnome/peripherals/keyboard/preview:
  x = -1
  y = -1
  width = -1
  height = -1
 /desktop/gnome/peripherals/keyboard/host-office:
  /desktop/gnome/peripherals/keyboard/host-office/0:
   numlock_on = true
 /desktop/gnome/peripherals/keyboard/general:
  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
 /desktop/gnome/peripherals/keyboard/kbd:
  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...

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.

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.

Created attachment 434892 [details]
xmodmap file

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.

working well on T410, can do screen cycles using super+p and Fn+F7. Is this, together with comment 29, enough for verification?

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.

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?

*************

Thanks!

--Chris



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

This event sent from IssueTracker by ctatman 
 issue 1051003

(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?

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.

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.

(Clone filed as bug 629047)

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

and

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.

 Thanks..
    --rez

(i've forwarded that comment to bug 629047)

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.