bug#69182: home-xmodmap-service-type requires restart to work

bug#69182: home-xmodmap-service-type requires restart to work

[Ian Eure]

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.

bug#69182: home-xmodmap-service-type requires restart to work

[Nicolas Graves via Bug reports for GNU Guix]

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