GNU bug report logs - #69182
home-xmodmap-service-type requires restart to work

Previous Next

To reply to this bug, email your comments to 69182 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: bug-guix <at> gnu.org
Subject: home-xmodmap-service-type requires restart to work
Date: Sat, 17 Feb 2024 11:38:54 -0800

I recently set up home-xmodmap-service-type so I could change the 
PrtSc key on my ThinkPad into a Hyper modifier.  This is my 
configuration:

  (service home-xmodmap-service-type
           (home-xmodmap-configuration
            (key-map '("clear mod3"
                       ("remove mod4" . "Hyper_L")
                       ("keycode 107" . "Hyper_R")
                       ("add mod3" . "Hyper_L Hyper_R")))))

However, after logging into an EXWM session, the PrtSc key is a 
Super modifier, not Hyper.  The service appears to be starting 
successfully:

   l0p!ieure~$ herd status xmodmap
   Status of xmodmap:
     It is running since 11:20:59 AM (35 seconds ago).
     Running value is #t.
     It is enabled.
     Provides (xmodmap).
     Requires ().
     Will be respawned.

The output of `xmodmap -pm' reports:

   xmodmap:  up to 4 keys per modifier, (keycodes in 
   parentheses):

   shift       Shift_L (0x32),  Shift_R (0x3e)
   lock
   control     Control_L (0x25),  Control_L (0x42),  Control_R 
   (0x69)
   mod1        Alt_L (0x40),  Alt_R (0x6c),  Alt_L (0xcc), 
   Meta_L (0xcd)
   mod2        Num_Lock (0x4d)
   mod3        ISO_Level5_Shift (0xcb)
   mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce), 
   Hyper_L (0xcf)
   mod5        ISO_Level3_Shift (0x5c)

Some of my configuration is applied, while other parts are not:

- "clear mod3" isn’t working; mod3 is ISO_Level5_Shift, which is 
 the default.
- "remove mod4 = Hyper_L" isn’t working.  Hyper_L is still on mod4 
 (which is the super modifier), which is the default.
- "add mod3 = Hyper_L Hyper_R" isn’t working.
- The "keycode 107 = Hyper_R" config *is* working, which is what 
 makes PrtSc a super modifier.

If I restart the service, the modifiers work as expected:

   l0p!ieure~$ herd restart xmodmap
   Service xmodmap has been started.
   l0p!ieure~$ guix shell xmodmap -- xmodmap -pm
   xmodmap:  up to 4 keys per modifier, (keycodes in 
   parentheses):

   shift       Shift_L (0x32),  Shift_R (0x3e)
   lock
   control     Control_L (0x25),  Control_L (0x42),  Control_R 
   (0x69)
   mod1        Alt_L (0x40),  Alt_R (0x6c),  Alt_L (0xcc), 
   Meta_L (0xcd)
   mod2        Num_Lock (0x4d)
   mod3        Hyper_R (0x6b),  Hyper_L (0xcf)
   mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce)
   mod5        ISO_Level3_Shift (0x5c)

I haven’t set up anything else that manipulates keymaps, so I’m 
not sure why this isn’t working after login.

I had a suspicion that another service might be running after 
xmodmap and changing the keymap.  The only home service that looks 
like it might do that is x11-display.  However, copying 
`home-xmodmap-service-type' and `my-xmodmap-shepherd-service' into 
my home.scm and editing it to add (requirement '(x11-display)) to 
the shepherd-service doesn’t fix the issue.

This appears to be a timing problem.  If I remove the service from 
my home configuration, but manually run `guix shell xmodmap -- 
xmodmap /gnu/store/g3hgzx8za4qrrdgn5hjqd80gxkb6sifx-config' after 
I log in (the file being the xmodmap configuration created by 
`serialize-xmodmap-configuration'), the keymap is set up how I 
declare it.  So *what* home-xmodmap-service-type does is correct; 
but *when* it does it is not.

Message #8 received at 69182 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: 69182 <at> debbugs.gnu.org
Subject: home-xmodmap-service-type requires restart to work
Date: Mon, 19 Feb 2024 20:16:03 +0100

Maybe that's because x11-display take a few milliseconds to start, and
that xmodmap actually starts before x11-display is actually done
loading.

I've encountered this type of issue with emacs-server, where I used this
solution on RDE, but it's emacs/service specific :
https://lists.sr.ht/~abcdw/rde-devel/patches/48753

I can't help you more, I don't use x11 anymore, but if that's the issue,
maybe go through the x11 documentation, find if you can start it with a
pid file, and if that's the case, you can try using a background
shepherd process waiting for the pid-file instead of a foreground one.

-- 
Best regards,
Nicolas Graves

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.