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.