Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Ian Jackson writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier map,
broken Shift"):
> Julien Cristau writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
> map, broken Shift"):
> > 14:08 < daniels> jcristau: getting an empty modmap is a symptom of running
> > without xkb
>
> Note that the modifier map is only empty early on during
> startup/login. It is apparently populated later, so I
> think Peter Hutterer's references may be more to the point.
I worked around the problem which prevents switching from
xkb-data-legacy to xkb-data, and this made the bug disappear.
Why, with xkb-data, the buggy modifier map should be transient still
isn't clear to me. And even less clear is why if this is the case a
partial map written by xmodmap is not overwritten.
But it does mean that I now have a working setup, thanks.
It might be worth seeing if we can fix #496700 and mark xkb-data as
Replacing xkb-data-legacy, to try to encourage its autoinstallation on
upgrade.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Ian Jackson writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier map,
broken Shift"):
> Julien Cristau writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
> map, broken Shift"):
> > Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks
> > like some Conflicts/Replaces are missing there.
>
> Because that's what an in-place replacement looks like. That's
> precisely the consequence of the Conflicts.
Sorry, thaat was perhaps rather terse. See policy 6.6, bullet 2 and
the rest of the consequences.
Does xkb-data intentionally contain a nondirectory where
xkb-data-legacy contains a directory ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Julien Cristau writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift"):
> Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks
> like some Conflicts/Replaces are missing there.
Because that's what an in-place replacement looks like. That's
precisely the consequence of the Conflicts.
> Anyway, should be pretty easy to work around by removing xkb-data-legacy
> first.
Yes.
Should I file a separate bug ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
On Tue, Aug 26, 2008 at 19:43:09 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
> map, broken Shift"):
> > Julien Cristau writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty
> > modifier map, broken Shift"):
> > > Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks
> > > like some Conflicts/Replaces are missing there.
> >
> > Because that's what an in-place replacement looks like. That's
> > precisely the consequence of the Conflicts.
>
> Sorry, thaat was perhaps rather terse. See policy 6.6, bullet 2 and
> the rest of the consequences.
>
Thanks.
> Does xkb-data intentionally contain a nondirectory where
> xkb-data-legacy contains a directory ?
>
I have no idea. The -legacy version is pretty much abandoned at this
point, but feel free to file a bug since this looks like something we
ought to fix.
Cheers,
Julien
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Julien Cristau writes ("Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift"):
> On Mon, Aug 25, 2008 at 17:00:08 +0100, Ian Jackson wrote:
> > * When xmodmap -pm is run in Xsetup, it prints an empty modifier
> >map. That is, there are no modifiers set.
>
> 14:08 < daniels> jcristau: getting an empty modmap is a symptom of running
> without xkb
Note that the modifier map is only empty early on during
startup/login. It is apparently populated later, so I
think Peter Hutterer's references may be more to the point.
> Does this also happen if xkb-data is installed on the machine running
> the X server?
-anarres:~> dpkg -l '*xkb-data*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++-=-=-==
pn xkb-data (no
description available)
ii xkb-data-legacy 1.0.1-4 Classic
XKB data
-anarres:~> dpkg -s xkb-data-legacy
Package: xkb-data-legacy
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 2956
Maintainer: Debian X Strike Force
Architecture: all
Version: 1.0.1-4
Replaces: xlibs-data (<< 6.8.2-35), xkb-data
Pre-Depends: x11-common (>= 1:1.0.0-1)
Conflicts: xlibs-data (<< 6.8.2-35), xkb-data
Description: Classic XKB data
This package contains the old xkb datasets. Note that this package is more
or less unsupported by upstream, and the new xkb-data package will replace
it.
-anarres:~>
[EMAIL PROTECTED]:~> dpkg -i
/export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb
dpkg: considering removing xkb-data-legacy in favour of xkb-data ...
dpkg: yes, will remove xkb-data-legacy in favour of xkb-data.
(Reading database ... 226123 files and directories currently installed.)
Unpacking xkb-data (from .../xkb-data_1.3-2_all.deb) ...
dpkg: error processing
/export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb
(--install):
cannot remove file `/usr/share/X11/xkb/symbols/pc/vn': Not a directory
Errors were encountered while processing:
/export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb
[EMAIL PROTECTED]:~> dpkg -i
/export/mirror/debian-ftp/pool/main/x/xkb-data-legacy/xkb-data-legacy_1.0.1-4_all.deb
Selecting previously deselected package xkb-data-legacy.
dpkg: considering removing xkb-data in favour of xkb-data-legacy ...
xkb-data is not properly installed - ignoring any dependencies on it.
dpkg: yes, will remove xkb-data in favour of xkb-data-legacy.
(Reading database ... 226328 files and directories currently installed.)
Preparing to replace xkb-data-legacy 1.0.1-4 (using
.../xkb-data-legacy_1.0.1-4_all.deb) ...
Unpacking replacement xkb-data-legacy ...
Setting up xkb-data-legacy (1.0.1-4) ...
[EMAIL PROTECTED]:~>
!
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
On Tue, Aug 26, 2008 at 19:06:52 +0100, Ian Jackson wrote: > [EMAIL PROTECTED]:~> dpkg -i > /export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb > dpkg: considering removing xkb-data-legacy in favour of xkb-data ... > dpkg: yes, will remove xkb-data-legacy in favour of xkb-data. > (Reading database ... 226123 files and directories currently installed.) > Unpacking xkb-data (from .../xkb-data_1.3-2_all.deb) ... > dpkg: error processing > /export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb > (--install): > cannot remove file `/usr/share/X11/xkb/symbols/pc/vn': Not a directory > Errors were encountered while processing: > /export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb > [EMAIL PROTECTED]:~> dpkg -i > /export/mirror/debian-ftp/pool/main/x/xkb-data-legacy/xkb-data-legacy_1.0.1-4_all.deb > > Selecting previously deselected package xkb-data-legacy. > dpkg: considering removing xkb-data in favour of xkb-data-legacy ... > xkb-data is not properly installed - ignoring any dependencies on it. > dpkg: yes, will remove xkb-data in favour of xkb-data-legacy. > (Reading database ... 226328 files and directories currently installed.) > Preparing to replace xkb-data-legacy 1.0.1-4 (using > .../xkb-data-legacy_1.0.1-4_all.deb) ... > Unpacking replacement xkb-data-legacy ... > Setting up xkb-data-legacy (1.0.1-4) ... > [EMAIL PROTECTED]:~> > Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks like some Conflicts/Replaces are missing there. Anyway, should be pretty easy to work around by removing xkb-data-legacy first. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
On Mon, Aug 25, 2008 at 17:00:08 +0100, Ian Jackson wrote: > * When xmodmap -pm is run in Xsetup, it prints an empty modifier >map. That is, there are no modifiers set. > 14:08 < daniels> jcristau: getting an empty modmap is a symptom of running without xkb Does this also happen if xkb-data is installed on the machine running the X server? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
On Mon, Aug 25, 2008 at 07:49:33PM +0200, Julien Cristau wrote: > see the below report about issues running xmodmap on xserver startup. > Do you know if this is fixed in 1.5 or master, or if the same thing > still exists there? This sounds like the evdev xkb issue. If so, it's not fixed in 1.5 or master, but I have a patch in rawhide that avoids the issue. http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.0-force-SwitchCoreKeyboard-for-evdev.patch?revision=1.1&view=markup > > * If I comment out the xmodmap call in Xsetup, everything works fine. > >After logging in I see the expected modifier map. I can then do > >exactly the same xmodmap invocation and it works perfectly - the > >functionality of shift is not affected. This paragraph is the big hint, but if you alread use the above patch than we have to dig deeper. Admittedly, it sounds a bit different and more complicated, but I'd like to rule out this possibility. The upstream bugreport would be http://bugs.freedesktop.org/show_bug.cgi?id=16364 Cheers, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Hi Peter, see the below report about issues running xmodmap on xserver startup. Do you know if this is fixed in 1.5 or master, or if the same thing still exists there? Thanks, Julien On Mon, Aug 25, 2008 at 17:00:08 +0100, Ian Jackson wrote: > Package: xserver-xorg-core > Version: 2:1.4.2-3 > > I'm suffering a problem with xmodmap. Since at least July 1997 I have > swapped control and capslock on my displays, and made certain other > changes to the keymap, by using xmodmap in the xdm Xsetup script. > This no longer works properly. (I do it like this because this > affects all X displays connected to the server, because I want more > than the swapcaps option can provide, and of course because originally > there was no server config file option to change keymaps at all.) > > The symptoms are that on the display running lenny it is not possible > to log in because it is not possible to type shifted letters into the > xdm greeter (eg for one's passphrase). (I'm using the xdm greeter > rather than gdm etc.) > > I have investigated and discovered that: > > * When xmodmap -pm is run in Xsetup, it prints an empty modifier >map. That is, there are no modifiers set. > > * The runes I use for xmodmap to swap control and capslock >explicitly set up mappings for control and capslock, rather than >transplanting them. After xmodmap runs, there are modifier >settings for control and capslock but not for shift. I conjecture >that xmodmap works by reading the whole modifier map and then >writing a modified version. > > * My xmodmap invocation to change the modifier map exits with status >1 without any apparent cause and without printing an explanation. >This would seem to be a bug in xmodmap. > > * If I comment out the xmodmap call in Xsetup, everything works fine. >After logging in I see the expected modifier map. I can then do >exactly the same xmodmap invocation and it works perfectly - the >functionality of shift is not affected. > > * The effect happens nearly every time but doesn't seem to be quite >100% reproducible. I haven't had it fail to go wrong under 100% >controlled conditions so I'm not sure, but I suspect a race. > > A complicating factor is that the xdm host is running sarge. Thus xdm > and the chooser are those from sarge. xmodmap is running on the sarge > host. It would be rather too disruptive to untangle this so that I > could run xdm on what is current the lenny client and I don't have a > spare box right now to use for a specific test. However I have > verified that running lenny's xmodmap (via chroot and NFS) doesn't > help: lenny's xmodmap appears to be identical in behaviour. > > Here are some relevant files: > > My instrumented Xsetup_2 script: > > #!/bin/sh > # $XConsortium: Xsetup_0,v 1.3 93/09/28 14:30:31 gildea Exp $ > > set -e > > echo "1 $0 $*" > echo "2 $0 $*" >&2 > set -x > type -p xmodmap > > xmodmap -pm || echo "x $?" > printenv || sort > rsync -vP $XAUTHORITY /net/anarres/root/.Xauthority > > XAUTHORITY=/root/.Xauthority chroot /net/anarres xdpyinfo || echo "q $?" > XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -pm || echo "y > $?" > > XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -verbose > /root/Xmodmap_local || echo $? > > XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -pm || echo "z > $?" > > xsetroot -fg blue -bg black -bitmap /etc/X11/xdm/defaultroot.bitmap > > Output of xmodmap -pm after Shift has been broken in this way, in a > session obtained by logging in as a user with no shifted characters in > the password: > > xmodmap: up to 1 keys per modifier, (keycodes in parentheses): > > shift > lockCaps_Lock (0x25) > control Control_L (0x42) > mod1 > mod2 > mod3 > mod4 > mod5 > > The xmodmap file Xmodmap_local: > > ! UK keymap, swap capslock and control > clear control > clear lock > keycode 11 = 2 quotedbl > keycode 22 = BackSpace > keycode 48 = apostrophe at > keycode 51 = numbersign asciitilde > keycode 94 = backslash bar > keycode 37 = Caps_Lock > keycode 66 = Control_L > add control = Control_L Control_R > add lock = Caps_Lock > > keycode 113 = Meta_R > > keycode 99 = End > keycode 103 = Prior > > The contents of xdm.log including the debugging output from the > Xsetup_2 script above: > > Mon Aug 25 16:44:42 2008 xdm info (pid 22554): starting X server on > anarres.relativity.greenend.org.uk:2 > Mon Aug 25 16:44:42 2008 xdm info (pid 24883): sourcing > /etc/X11/xdm/Xsetup > 1 /etc/X11/xdm/Xsetup_2 > 2 /etc/X11/xdm/Xsetup_2 > + type -p xmodmap > /usr/bin/X11/xmodmap > + xmodmap -pm > xmodmap: up to 0 keys per modifier, (keycodes in parentheses): > > shift > lock > control > mod1
Bug#496548: xmodmap in xdm Xsetup, empty modifier map, broken Shift
Package: xserver-xorg-core Version: 2:1.4.2-3 I'm suffering a problem with xmodmap. Since at least July 1997 I have swapped control and capslock on my displays, and made certain other changes to the keymap, by using xmodmap in the xdm Xsetup script. This no longer works properly. (I do it like this because this affects all X displays connected to the server, because I want more than the swapcaps option can provide, and of course because originally there was no server config file option to change keymaps at all.) The symptoms are that on the display running lenny it is not possible to log in because it is not possible to type shifted letters into the xdm greeter (eg for one's passphrase). (I'm using the xdm greeter rather than gdm etc.) I have investigated and discovered that: * When xmodmap -pm is run in Xsetup, it prints an empty modifier map. That is, there are no modifiers set. * The runes I use for xmodmap to swap control and capslock explicitly set up mappings for control and capslock, rather than transplanting them. After xmodmap runs, there are modifier settings for control and capslock but not for shift. I conjecture that xmodmap works by reading the whole modifier map and then writing a modified version. * My xmodmap invocation to change the modifier map exits with status 1 without any apparent cause and without printing an explanation. This would seem to be a bug in xmodmap. * If I comment out the xmodmap call in Xsetup, everything works fine. After logging in I see the expected modifier map. I can then do exactly the same xmodmap invocation and it works perfectly - the functionality of shift is not affected. * The effect happens nearly every time but doesn't seem to be quite 100% reproducible. I haven't had it fail to go wrong under 100% controlled conditions so I'm not sure, but I suspect a race. A complicating factor is that the xdm host is running sarge. Thus xdm and the chooser are those from sarge. xmodmap is running on the sarge host. It would be rather too disruptive to untangle this so that I could run xdm on what is current the lenny client and I don't have a spare box right now to use for a specific test. However I have verified that running lenny's xmodmap (via chroot and NFS) doesn't help: lenny's xmodmap appears to be identical in behaviour. Here are some relevant files: My instrumented Xsetup_2 script: #!/bin/sh # $XConsortium: Xsetup_0,v 1.3 93/09/28 14:30:31 gildea Exp $ set -e echo "1 $0 $*" echo "2 $0 $*" >&2 set -x type -p xmodmap xmodmap -pm || echo "x $?" printenv || sort rsync -vP $XAUTHORITY /net/anarres/root/.Xauthority XAUTHORITY=/root/.Xauthority chroot /net/anarres xdpyinfo || echo "q $?" XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -pm || echo "y $?" XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -verbose /root/Xmodmap_local || echo $? XAUTHORITY=/root/.Xauthority chroot /net/anarres xmodmap -pm || echo "z $?" xsetroot -fg blue -bg black -bitmap /etc/X11/xdm/defaultroot.bitmap Output of xmodmap -pm after Shift has been broken in this way, in a session obtained by logging in as a user with no shifted characters in the password: xmodmap: up to 1 keys per modifier, (keycodes in parentheses): shift lockCaps_Lock (0x25) control Control_L (0x42) mod1 mod2 mod3 mod4 mod5 The xmodmap file Xmodmap_local: ! UK keymap, swap capslock and control clear control clear lock keycode 11 = 2 quotedbl keycode 22 = BackSpace keycode 48 = apostrophe at keycode 51 = numbersign asciitilde keycode 94 = backslash bar keycode 37 = Caps_Lock keycode 66 = Control_L add control = Control_L Control_R add lock = Caps_Lock keycode 113 = Meta_R keycode 99 = End keycode 103 = Prior The contents of xdm.log including the debugging output from the Xsetup_2 script above: Mon Aug 25 16:44:42 2008 xdm info (pid 22554): starting X server on anarres.relativity.greenend.org.uk:2 Mon Aug 25 16:44:42 2008 xdm info (pid 24883): sourcing /etc/X11/xdm/Xsetup 1 /etc/X11/xdm/Xsetup_2 2 /etc/X11/xdm/Xsetup_2 + type -p xmodmap /usr/bin/X11/xmodmap + xmodmap -pm xmodmap: up to 0 keys per modifier, (keycodes in parentheses): shift lock control mod1 mod2 mod3 mod4 mod5 + printenv SHELL=/bin/sh -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 PWD=/ SHLVL=2 DISPLAY=anarres.relativity.greenend.org.uk:2 XAUTHORITY=/var/lib/xdm/authdir/authfiles/Aanarres.relativity.greenend.org.uk:2-vtuuyQ _=/usr/bin/printenv + rsync -vP /var/lib/xdm/authdir/authfiles/Aanarres.relativity.greenend.org.uk:2-vtuuyQ /net/anarres/root/.Xauthority Aanarres.r
