Bug 106171 - Ctrl+Alt fails in default (GNOME) session; may be caused by Xsession
Summary: Ctrl+Alt fails in default (GNOME) session; may be caused by Xsession
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-applets   
(Show other bugs)
Version: 9
Hardware: All Linux
Target Milestone: ---
Assignee: Mark McLoughlin
QA Contact:
: 90114 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-03 13:54 UTC by Toralf
Modified: 2007-04-18 16:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-04 08:37:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Toralf 2003-10-03 13:54:01 UTC
Description of problem:
Ctrl+Alt key combinations, such as Ctrl+Alt+<F-Key> to change VT or
Ctrl+Alt+Backspace to kill the X server, fail when logged in with default
session (i.e. GNOME desktop.)

To make a long story short, I think the xmodmap/setxkbmap logic in Xsession is
causing the problems. The following comment from the file sais a bit about this:

# xkb and xmodmap don't play nice together

Well, the default setup will try to make them play together because:
1. XFree86 has already set and xkb map through options in XF86Config.
2. xinitrc has /etc/X11/Xmodmap, but not /etc/X11/Xkbmap.

Suggested update:
1. Remove system xkb map support from Xsesssion. It is redundant because
Option      "XkbLayout"

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
Enough said, I think.

Comment 1 Toralf 2003-10-03 13:59:22 UTC
Right. Sumbitted this a bit soon by mistake. To continue what I was saying.

Suggested update:
1. Remove system xkb map support from Xsesssion. It is redundant because
     Option      "XkbLayout"
in XF86Config is normally used to load the correct xkb map.

2. Execute xmodmap commands if, and only if, the X server was started with 
"XkbDisable on" (I'm not sure how to find out, though...) Check for *user*
xkblayout if not (or drop it and require to layout to be set globally.)

Comment 2 Toralf 2003-10-03 14:38:14 UTC
No, sorry. It's not quite as simple as I thought. I have found two different
causes for this problem on two different setups:

One had a "real" /etc/X11/Xmodmap as opposed to the one supplied with xinitrc,
where everything is commented out, for historical reasons. (But this didn't
cause problems with earlier OS revisions.)

The other would (re)load the keymap via gkb_xmmap for the user that reported the
problem, because he was using the GNOME Keyboard Layout Switcher applet (which
calls gkb_xmmap by default.)

I still think this is a real issue, but I'm no longer sure if it belongs in this
product. A cleanup of Xsession might still be good, though (so that it would
*never* load Xmodmap.)

Comment 3 Toralf 2003-10-03 14:45:38 UTC
Bug 90114 is clearly related to this.

Comment 4 Mike A. Harris 2003-10-09 02:23:24 UTC
The problem with Xmodmap in general, is that it is an end user/admin addon
"hack".  The X server's supplied xkb keymap files are what are officially
supported, and any Xmodmap customization is considered unsupported, as it
highly depends on the skill of the person performing the customization,
as well as them tracking xkb developmental changes that modify how Xmodmap
customizations will work.

xkb has changed rather dramatically in the 4.3.0 release, and many of these
changes have caused many people's previously working Xmodmap customizations
to cease to work.  The majority of bug reports received both at Red Hat, and
at XFree86.org concerning issues where the user supplied their own custom
Xmodmap or ~/.Xmodmap, .~/xmodmaprc, etc. customizations have been determined
to not be bugs at all, but changes in the way that the X server works, which
require changes in how the user or admin creates their customizations.

IMHO, if any issues such as this are worth changing anything in the X server,
or in the startup scripts, then they are worth doing globally for all users
of all distributions, or not at all.  As such, requests to change startup files
in this manner should take place in XFree86.org mailing lists, developmental
discussions, and XFree86 bugzilla.  If there is concensus amongst developers
of XFree86 as a whole, that these types of changes are required globally,
then they may be made in a future XFree86 release, and will likely be
incorporated into future Red Hat Linux release as well.

I'm not comfortable however with making custom Red Hat specific changes like
this which may have unforseen consequences, and break from upstream practice
in a distribution specific way.

Closing WONTFIX.

Comment 5 Toralf 2003-10-09 06:16:18 UTC
Most of what you are saying here can of course be used as an argument for making
the changes you suggest, but I accept that is perhaps not up to Red Hat to address.

However, one point remains: The xmodmap files I'm having problems with are not
user or admin customisations; they are supplied with Red Hat Linux. Also, the
GNOME keyboard layout applet may be seen as encouraging their use.

=> Reopen as gnome-applets bug, I think.

Comment 6 Toralf 2003-10-09 06:18:40 UTC
*** Bug 90114 has been marked as a duplicate of this bug. ***

Comment 7 Mark McLoughlin 2004-07-19 13:06:49 UTC
Is this still a problem with Fedora Core 2? Lots have changed in this
area since then.

Comment 8 Toralf 2004-07-29 09:04:17 UTC
I'm unable to reproduce with the new Keyboard configuratur/Layout
switch via "Keybaord Indicator". I'm also no longer able to choose
between Xkb and xmodmap setup. That's probably just as well, but you
should verify that the right method is used. The correct way is to
switch via Xkb maps most of the time, but use xmodmap if the X server
config has 'Option  "XkbDisable"', I think.

Comment 9 Mark McLoughlin 2004-08-04 08:37:41 UTC
Thanks, closing.

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