I enabled ctrl+alt+bksp per a recent email from Andrei Popescu on debian- user@lists.debian.org. I tested the change. I could not kill X, even after rebooting. I used startx to start X. The command worked correctly for startx initiated X session. I speculate that the problem is not in keyboard- configuration nor can it be in startx, I'm left with gdm3 as a newish package that is easy to blame. The fact that it worked under startx also implies that I did not make a mistake in using dpkg- reconfigure.
Hello,
just a little more information on this issue...
This problem does still exist in 2.30.5-4 and turns up whenever gdm3
starts any session- or window-manager that does not fiddle around with
the xkbmap itself - i.e. virtually every session- and window-manager
except Gnome.
gdm3 removes the terminate(ctrl_alt_bksp) symbol from the xkbmap but
does not restore it when firing up user's X session.
Here is the output of `setxkbmap -print' under Fvwm started via startx
or via kdm:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwertz)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+de(nodeadkeys)+inet(evdev)+terminate(ctrl_alt_bksp)" };
xkb_geometry { include "pc(pc105)" };
};
Here is the output of `setxkbmap -print' under Fvwm started via gdm3:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwertz)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+de(nodeadkeys)+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
regards
Mario
retitle 590534 gdm3: changes xkb options
thanks
Hello,
I was affected by the same bug, so I tried to find out what was wrong.
I am using no GNOME stuff, not even a gnome-settings-daemon, except
gdm3 to log in. I have no /etc/X11/xorg.conf, and in my
/etc/default/keyboard, I have:
XKBOPTIONS="compose:menu,terminate:ctrl_alt_bksp"
This gets exported correctly by udev:
% grep XKB /dev/.udev/db/input:event*
/dev/.udev/db/input:event0:E:XKBOPTIONS=compose:menu,terminate:ctrl_alt_bksp
When I start a session with startx, I get the expected keyboard setup:
% setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(azerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+fr(oss)+inet(evdev)+compose(menu)+terminate(ctrl_alt_bksp)" };
xkb_geometry { include "pc(pc105)" };
};
But when I start my session with gdm3, the options compose(menu)
and terminate(ctrl_alt_bksp) disappear:
% setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(azerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+fr(oss)+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
So it looks like gdm3 is:
* interpreting what it can from udev or xkb configuration: geometry and
layout;
* discarding the remaining: compose(menu) and terminate(ctrl_alt_bksp);
* overriding the xkb configuration with what it could understand;
* not setting the initial xkb configuration back after login.
I think the appropriate behaviour for a display manager should be not to
touch to the keyboard configuration at all, unless explicitely told to
do so.
Regards,
The source of the problem resides in file /etc/gdm3/Init/Default
In the following lines at the end of the file the actual changing of
the Xorg's defaults go.
SETXKBMAP=`gdmwhich setxkbmap`
if [ "x$SETXKBMAP" != "x" ] ; then
# FIXME: is this all right? Is this completely on crack?
# What this does is move the xkb configuration from the GDM_PARENT_DISPLAY
# FIXME: This should be done in code. Or there must be an easier way ...
if [ -n "$GDM_PARENT_DISPLAY" ]; then
# Hurray for awk
XKBARGS=$( (DISPLAY=$GDM_PARENT_DISPLAY
XAUTHORITY=$GDM_PARENT_XAUTHORITY $SETXKBMAP -v -v) | awk '/^model:/ {
printf "-model %s ", $2 } /^layout:/ { printf "-layout %s ", $2 }
/^variant:/ { printf "-variant %s ", $2 } /^options:/ { printf
"-option %s ", $2}' )
XKBSETUP=`( DISPLAY=$GDM_PARENT_DISPLAY
XAUTHORITY=$GDM_PARENT_XAUTHORITY $SETXKBMAP -v )`
if [ -n "$XKBARGS" ]; then
$SETXKBMAP $XKBARGS
fi
fi
fi
These lines should be commented out/removed or at least changed to
something more
sane.
Le samedi 18 décembre 2010 à 01:44 +0200, Роман Якубук a écrit : I don’t think it’s possible, unless you have fiddled with the GDM_PARENT_DISPLAY variable. Patches welcome. I know this code is ugly, but it’s the only thing I found that works. Regardless, it only does something for nested sessions. This code does *nothing* for regular sessions. Cheers,
Josselin Mouette <joss@debian.org> (18/12/2010):
Indeed, using set -x, adding some echo to a temporary file, or
checking various gdm log files will confirm that. To make sure, one
can even move setxkbmap and xmodmap out of $PATH, the same behaviour
will happen again and again.
To witness the issue:
* Set some options in /etc/default/keyboard
- Example: XKBOPTIONS="terminate:ctrl_alt_bksp"
- Read keyboard-configuration's README.Debian and use the udevadm
magic to get that taken into account.
* Restart gdm3.
* In a root shell:
XAUTHORITY=$(find /var/run/gdm3 -name database|head -1) DISPLAY=:0 setxkbmap -print
* See the terminate:ctrl_alt_bksp in xkb_symbols.
* Start a session.
* Run the setxkbmap -print again (directly in a shell in the session,
or the same command as previously from the same shell), options are
gone.
Now, looking at anything mentioning "layout" in the code, it looks
like there's some signal to handle layout updates. Let's check that
hypothesis.
New protocol:
* Restart gdm3.
* Make sure the options are set appropriately.
* Pick a user.
* Pick another layout. Say dvorak if you're using azerty, or the
other way round.
* Check the options. Tada, gone.
I suspect the same somehow happens when the session is started. Like
“let's set the layout anyway, just to make sure”, and tada the fuckup
happens. I'll try and look closer, but gnome+dbus+gdm isn't exactly my
cup of coffee…
I'm tempted to raise the severity, it's really fucking up people's XKB
settings, even when no such layout changes happen before starting a
session. :(
KiBi.
Cyril Brulebois <kibi@debian.org> (19/01/2011):
To narrow it down:
* Restart gdm3
* Attach gdm-simple-greeter:
gdb attach $(pidof gdm-simple-greeter)
b xkl_config_rec_activate
c
* Pick a user, notice the password prompt doesn't show
up. Breakpoint's been reached.
* Back to gdb:
up
# moved to gdm_layout_activate
p config->options
(gchar **) 0x0
Unsurprisingly, since gui/simple-greeter/gdm-layouts.c says:
| void
| gdm_layout_activate (const char *layout)
| {
| #ifdef HAVE_LIBXKLAVIER
| XklConfigRec *config;
| char *p;
|
| init_xkl ();
|
| config = xkl_config_rec_new ();
| config->model = g_strdup (initial_config->model);
|
| if (layout == NULL) {
| config->layouts = g_strdupv (initial_config->layouts);
| config->variants = g_strdupv (initial_config->variants);
| config->options = g_strdupv (initial_config->options);
Here you'd get options.
| } else {
| config->layouts = g_new0 (char *, 2);
| config->layouts[0] = g_strdup (layout);
|
| p = strchr (config->layouts[0], '\t');
| if (p != NULL) {
| config->variants = g_new0 (char *, 2);
| config->layouts[0][p - config->layouts[0]] = 0;
| config->variants[0] = g_strdup (p + 1);
| }
Here you're fucked.
| }
|
| xkl_config_rec_activate (config, engine);
|
| g_object_unref (config);
| #endif
| }
KiBi.
Cyril Brulebois <kibi@debian.org> (19/01/2011):
To narrow it down:
* Restart gdm3
* Attach gdm-simple-greeter:
gdb attach $(pidof gdm-simple-greeter)
b gdm_layout_activate
c
* Pick a user, notice the password prompt doesn't show
up. Breakpoint's been reached.
* p *config → options is 0.
Unsurprisingly, gui/simple-greeter/gdm-layouts.c says:
| void
| gdm_layout_activate (const char *layout)
| {
| #ifdef HAVE_LIBXKLAVIER
| XklConfigRec *config;
| char *p;
|
| init_xkl ();
|
| config = xkl_config_rec_new ();
| config->model = g_strdup (initial_config->model);
|
| if (layout == NULL) {
| config->layouts = g_strdupv (initial_config->layouts);
| config->variants = g_strdupv (initial_config->variants);
| config->options = g_strdupv (initial_config->options);
Here you'd get options.
| } else {
| config->layouts = g_new0 (char *, 2);
| config->layouts[0] = g_strdup (layout);
|
| p = strchr (config->layouts[0], '\t');
| if (p != NULL) {
| config->variants = g_new0 (char *, 2);
| config->layouts[0][p - config->layouts[0]] = 0;
| config->variants[0] = g_strdup (p + 1);
| }
Here you're fucked.
| }
|
| xkl_config_rec_activate (config, engine);
|
| g_object_unref (config);
| #endif
| }
KiBi.
Le jeudi 20 janvier 2011 à 01:34 +0100, Cyril Brulebois a écrit :
Thanks a lot for the analysis, you found the place where things actually
happen.
It turns out that the XKB configuration is passed between the greeter to
the daemon as a string, which contains "layout\tvariant". This is the
string that is stored in your .dmrc as the Layout key.
This might be fixable for the first login by exchanging more complete
information, but anyway starting from the second login, gdm will use the
string stored in the .dmrc file, so this would still fail.
Fixing the bug requires at least one of the following changes (and
ideally, both):
* changing the logic so that the XKB settings are not stored if
the default keymap was not changed;
* changing the specification for the Layout key in the .dmrc file.
The first change is complex and implies code that, touching XKB, is
scary by definition. The second one requires synchronisation with all
other DMs which could make use of that key.
I’ve forwarded the bug upstream. I hope they can find a solution, but
this will definitely not be for squeeze, even in a point release.
Cheers,
2011/1/24 Josselin Mouette <joss@debian.org>: May I venture gdm3 ſhould not be included in Squeeze? People really need keyboards workiŋ as expected.
Hi,
Thanks to the findings of Cyril, I built a gdm solving my problem, which
was the miss of Compose key when using a non-gnome session manager. I
think this will resolve also others missing XKBOPTIONS problems, and may
avoid the need to deal with .dmrc file.
Here is the patch :
diff -Naur gdm3-2.30.5.orig/gui/simple-greeter/gdm-layouts.c gdm3-2.30.5/gui/simple-greeter/gdm-layouts.c
--- gdm3-2.30.5.orig/gui/simple-greeter/gdm-layouts.c 2010-08-11 19:40:07.000000000 +0200
+++ gdm3-2.30.5/gui/simple-greeter/gdm-layouts.c 2011-03-03 15:34:57.000000000 +0100
@@ -249,11 +249,11 @@
config = xkl_config_rec_new ();
config->model = g_strdup (initial_config->model);
+ config->options = g_strdupv (initial_config->options);
if (layout == NULL) {
config->layouts = g_strdupv (initial_config->layouts);
config->variants = g_strdupv (initial_config->variants);
- config->options = g_strdupv (initial_config->options);
} else {
config->layouts = g_new0 (char *, 2);
config->layouts[0] = g_strdup (layout);
Le jeudi 03 mars 2011 à 21:31 +0100, Julien Pinon a écrit : Thanks for the idea. I think the patched behavior is incorrect as well, but it might be better than the current situation. It will apply the XKB options in the Xorg configuration, regardless of the layout chosen by the user. The correct solution would be to store the options along with the layout and variant, but it implies changing the semantics of the .dmrc file. I’m probably going to apply it until upstream comes up with a better fix.
Le jeudi 03 mars 2011 à 21:42 +0100, Josselin Mouette a écrit : I’ve just been explained by Julien Cristau that XKB options are independent from the layout, so actually that makes your patch absolutely correct, since it will just apply them regardless of the layout. Thanks,
Please test gdm3 2.30.5-8 that I just uploaded to unstable. If people confirm that Julien’s change works correctly and leaves no regressions, I will push the update in squeeze too.
We believe that the bug you reported is fixed in the latest version of
gdm3, which is due to be installed in the Debian FTP archive:
gdm3_2.30.5-8.debian.tar.gz
to main/g/gdm3/gdm3_2.30.5-8.debian.tar.gz
gdm3_2.30.5-8.dsc
to main/g/gdm3/gdm3_2.30.5-8.dsc
gdm3_2.30.5-8_amd64.deb
to main/g/gdm3/gdm3_2.30.5-8_amd64.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 590534@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Josselin Mouette <joss@debian.org> (supplier of updated gdm3 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Thu, 03 Mar 2011 22:10:30 +0100
Source: gdm3
Binary: gdm3
Architecture: source amd64
Version: 2.30.5-8
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Josselin Mouette <joss@debian.org>
Description:
gdm3 - Next generation GNOME Display Manager
Closes: 590534 614972 615720
Changes:
gdm3 (2.30.5-8) unstable; urgency=low
.
* README.Debian: document the xauth stuff. Closes: #614972.
* 31_xkb_options.patch: patch from Julien Pinon to always pass XKB
options regardless of the layout. Closes: #590534.
* 13_gdmsetup.patch: updated to link to the libs required by the usage
of libgdmcommon. Closes: #615720.
* 90_relibtoolize.patch: updated accordingly.
Checksums-Sha1:
ac6b7f95f8414ed0e9846f58bfb966824908cb06 1856 gdm3_2.30.5-8.dsc
f76b600ef25ac9212e40edc40c5ba07b0cb17ee1 407916 gdm3_2.30.5-8.debian.tar.gz
26a0ebc528e9a528f3a2819858043bd7d0fe3e3e 1686468 gdm3_2.30.5-8_amd64.deb
Checksums-Sha256:
179f91060fb9f7e8f21942a3bfe6fd1cdc34b7b0ec0cda56a89e1298a743fcb0 1856 gdm3_2.30.5-8.dsc
4b09561922ce88f9b01dc5b9720ce3a5c06c0d4016cc0add684dddadb6eec864 407916 gdm3_2.30.5-8.debian.tar.gz
2ed874fd8599d307d3e9b21e1317bbfb250ab802ddac5c5d46802d2a95fe7071 1686468 gdm3_2.30.5-8_amd64.deb
Files:
2ee9be9287affe3120361d275505f4e4 1856 gnome optional gdm3_2.30.5-8.dsc
cc0c47ad6000150edd66018beac0a09a 407916 gnome optional gdm3_2.30.5-8.debian.tar.gz
9ab5b7935fd51a9033ae5f24ff7ee7d5 1686468 gnome optional gdm3_2.30.5-8_amd64.deb
iD8DBQFNcAburSla4ddfhTMRAnEwAKC2zy/Gn56S7QaJ3FNVh3aDxyemEwCfR883
uaKSx/GuUQgOIsgBDYpIK2Y=
=L31h
-----END PGP SIGNATURE-----
[resubmitting explanation of status change to 590534@bugs.debian.org. Apparently I should have waited until it was unarchived. Also, maybe "reopen" was a mistake...?!] This bug is still present in the squeeze version of the package. It should be fixed in squeeze too as it affects the usability of the whole system. The patch by Julien Pinon applies cleanly to the stable version of gdm3 and works well. thanks in advance.
I have also recompiled the gdm3 package in debian squeeze from the source package after applying Julien Pinon's patch. Just wanted to inform that I have been using the patched gdm3 package for about 3 weeks so far without any problems/visible regressions on my system (using Debian squeeze, linux-image-2.6.32-5-amd64) Also hoping there will be a new fixed version of gdm3 coming soon in debian squeeze. Thanks, Dimitrios Liappis
Le lundi 26 septembre 2011 à 15:25 +0300, Dimitrios Liappis a écrit : I am not confident applying this patch to squeeze, because it is not a proper fix. The proper fix would be to store xkb options together with the layout, and it requires changing the specification for .dmrc files. In gdm 3.x upstream abandoned keyboard configuration in the greeter entirely so this is no longer a problem.
Dear Maintainer, Tell me if you think this is the same bug : I'm using 2 differents keyboards, with two differents layouts; each keyboard has it's own layout. The second (a dvorak-like) is defined in a Xorg rules wich works fine (see Xorg logs) In the GDM login, only the default layout is used, the second keyboard is also using the default layout. When I start a session with startx, the two keyboards uses the correect layout each other.
I am Mrs. Jenifer Cox, i have charity proposal which i intend to finance through you. Please contact me on if you are interested in doing a charitable work.Regards,Mrs. Jenifer Cox.