Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #243144 > unrolled thread

xmodmap settings lost when (usb) keyboard reattached.

Back to article view | Back to linux.debian.user

Contents

  xmodmap settings lost when (usb) keyboard reattached. Tim Woodall <debianuser@woodall.me.uk> - 2021-12-15 18:00 +0100
    Re: xmodmap settings lost when (usb) keyboard reattached. Vincent Lefevre <vincent@vinc17.net> - 2021-12-15 18:10 +0100
      Re: xmodmap settings lost when (usb) keyboard reattached. Anssi Saari <as@sci.fi> - 2021-12-17 11:40 +0100
    Re: xmodmap settings lost when (usb) keyboard reattached. John Crawley <john@bunsenlabs.org> - 2021-12-16 03:30 +0100
    Re: xmodmap settings lost when (usb) keyboard reattached. David Wright <deblis@lionunicorn.co.uk> - 2021-12-17 18:00 +0100

#243144 — xmodmap settings lost when (usb) keyboard reattached.

I run the following command to switch my caps-lock to escape:
xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape'

However, if I disconnect and reconnect my keyboard (I have a KVM switch
box so this happens quite a lot) the setting is lost.

Before I start writing udev rules to auto reapply this setting when the
keyboard is (re)attached, is there some other, better, way to make this
setting stick?

Tim.

[toc] | [next] | [standalone]

#243145

On 2021-12-15 16:53:54 +0000, Tim Woodall wrote:
> I run the following command to switch my caps-lock to escape:
> xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape'
> 
> However, if I disconnect and reconnect my keyboard (I have a KVM switch
> box so this happens quite a lot) the setting is lost.

FYI, there are bugs that were reported about 10 years ago:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541388
"xserver-xorg: Xmodmap settings lost across suspend/hibernate"

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849
"xserver-xorg: XKB settings lost after suspend (hibernate) / resume
or USB keyboard plugged in"

> Before I start writing udev rules to auto reapply this setting when the
> keyboard is (re)attached, is there some other, better, way to make this
> setting stick?

Note that this is a bit tricky as you need to remember $DISPLAY and
a "xhost +si:localuser:root" is needed. In the past, I wrote a script,
put in the /etc/pm/sleep.d directory:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849#92

but there were some issues with it, as I mentioned there.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#243219

Vincent Lefevre <vincent@vinc17.net> writes:

> In the past, I wrote a script, put in the /etc/pm/sleep.d directory:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849#92
>
> but there were some issues with it, as I mentioned there.

It's also not directly applicable when the issue isn't related to
pm-utils or suspend or hibernate. I have the same annoyance as the OP,
USB keyboard connected to a USB switch so that I can switch between my
work and personal computers in my home office easily. I have an alias fk
for fix keyboard which just runs xmodmap with some input, basically it
sets Alt_R to Mode_switch and then maps a bunch of chars (20 total)
behind mode_switch.

What I see in my script where I switch the USB is a little weird. I can
run xmodmap from the script but it doesn't apply the layout. No error
either. I've tried to use a delay and that sometimes works but not
consistently. I've also tried to monitor for changes in xmodmap output
even up to a minute since that changes some time after the keyboard is
plugged in, after a while Alt_R appears on the mod1 line of xmodmap
output.

What I found just now as I played with this is that if I have just one
call xmodmap then things work. I had a leftover second call to xmodmap
which makes caps to control but I don't need that with my current
keyboard.

[toc] | [prev] | [next] | [standalone]

#243157

On 16/12/2021 01:53, Tim Woodall wrote:
> I run the following command to switch my caps-lock to escape:
> xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape'
> 
> However, if I disconnect and reconnect my keyboard (I have a KVM switch
> box so this happens quite a lot) the setting is lost.
> 
> Before I start writing udev rules to auto reapply this setting when the
> keyboard is (re)attached, is there some other, better, way to make this
> setting stick?

I don't know if it's better, but there's a simple thing you can try first:

I used to run

setxkbmap -option compose:caps

in my startup script to map the Capslock key to a Compose key. But this would unpredictably drop out.

Now, in /etc/default/keyboard

XKBOPTIONS="compose:caps"

keeps the mapping reliably applied. Maybe there's a similar setting you could try?

-- 
John

[toc] | [prev] | [next] | [standalone]

#243222

On Wed 15 Dec 2021 at 16:53:54 (+0000), Tim Woodall wrote:
> I run the following command to switch my caps-lock to escape:
> xmodmap -e 'clear Lock' -e 'keycode 0x42 = Escape'
> 
> However, if I disconnect and reconnect my keyboard (I have a KVM switch
> box so this happens quite a lot) the setting is lost.
> 
> Before I start writing udev rules to auto reapply this setting when the
> keyboard is (re)attached, is there some other, better, way to make this
> setting stick?

You could try editing /etc/console-setup/remap.inc and running
# dpkg-reconfigure console-setup
A change at that level might be inherited by whatever's
restarting and causing you to lose the settings.

Note that for whatever reason (lost in the mists), I always
run dpkg-reconfigure console-setup while X is not running,
ie not even in a C-A-Fn virtual console. That constraint
might have changed, IDK.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web