Remap Super-key keyboard

[No20]

Hi,

I would like to know how I could remap the SUPER-key in Qubes to use it for smaller and bigger.
Right now the key has no function at all under Qubes. I could use an extra key.
I have tried /usr/shsareX11/xkb/symbols/. However that did not work. Hopefully, anyone here has a good idea? Am I on the right track or completely wrong?

Thanks in advance for an answer

[fsflover]

One possibility is explained here:

Qubes Clipboard™ is painful

You can rebind dom0 copy/paste shortcuts to for example Super-c and Super-v in /etc/qubes/guid.conf. This decreases the number of keypresses by 33%. For your specific method, you can probably figure out something with xsel, qvm-run-in-vm, and the dom0 clipboard file. For example, copy might be implemented by triggering a keyboard shortcut that runs qvm-run-in-vm -p $activevm xsel > /var/run/qubes/qubes-clipboard.bin Here $activevm can be obtained from parsing the output of xprop -id $(xdotoo…

I personally use the super key to change the language. Super key for the main language and “right menu” key for the second language. It work amazingly well and I never ever have problems with language switching unlike with standard alt+shift method.

[unman]

Hi,

[quote]
I would like to know how I could remap the SUPER-key in Qubes to use it for smaller and bigger.
Right now the key has no function at all under Qubes. I could use an extra key.
I have tried /usr/shsareX11/xkb/symbols/. However that did not work. Hopefully, anyone here has a good idea? Am I on the right track or completely wrong?

[quote]

Thanks in advance for an answer

In Xfce, the default zoom is Alt+ScrollWheel. You can do this from the
keyboard using xdotool keydown Alt click 5 keyup Alt to zoom in, and
xdotool keydown Alt click 4 keyup Alt to zoom out.
Put these command in to a simple script in dom0. Make it executable
with chmod +x, and test it works.
In Xfce, open “Keyboard” from the Menu - Select “Applications Shortcut”
and “Add” a link between the key combo and your new scripts.

In KDE it is, of course, much easier.
Open Settings, then Shortcuts.
The defaults to zoom are Ctrl++ and Ctrl±, but you can customise these
to use the Super key. No need for little scripts, the keyboard zoom
function is built in.

[No20]

Thanks for the answers.

I found the following solution which also survives reboot:

cd ~/.config
xmodmap -pke > .Xmodmap
vi .Xmodmap

and adjust key accordingly.

[No20]

There is a following up question.
I did remapping according to my solution.
However, I only did it in dom0 and the other VMs are not affected. I’d like to do it for all the VMs. Now my issue is that the .Xmodmap file is placed in the home directory whch however as you all know is only permanent per app. I tried creating .Xmodmap in the root directory of my template. This did not have any effect on the AppVMa.
Has anyone a good solution for my issue to change keys via xmodmap in a template so it takes effect not only in the template but on all the AppVM based on it?

[unman]

There is a following up question.
I did remapping according to my solution.
However, I only did it in dom0 and the other VMs are not affected. I’d like to do it for all the VMs. Now my issue is that the .Xmodmap file is placed in the home directory whch however as you all know is only permanent per app. I tried creating .Xmodmap in the root directory of my template. This did not have any effect on the AppVMa.
Has anyone a good solution for my issue to change keys via xmodmap in a template so it takes effect not only in the template but on all the AppVM based on it?

Read the docs on inheritance for templates
You need to put the file in /etc/skel and it will be propagated for each
file afterwards created from that template.
If you’ve already created many qubes, this is no help.
You can either spin up a batch file, or (better) use salt to create the
file in each qube.
If you’re not familiar with salt, let me know and I’ll help you put
something together. Take a look at GitHub - unman/notes for
notes on salt - the official docs are at Salt (management software) | Qubes OS

[No20]

Thanks for your reply. I always very much appreciate your support.
I’ve created a bash script that automates the creation of the required Xmodmap file.
Unfortunately, I have no experience with salt. I’d like to copy the script from dom0 to every qube (Template and AppVM) and execute it after copying.
How can I do that?

[unman]

Thanks for your reply. I always very much appreciate your support.
I’ve created a bash script that automates the creation of the required Xmodmap file.
Unfortunately, I have no experience with salt. I’d like to copy the script from dom0 to every qube (Template and AppVM) and execute it after copying.
How can I do that?

Salt has a nice feature for managing files, using the files state.
At its simplest, you write a file like this, as the state file:

/home/user/.Xmodmap:
  file.managed:
    - source:
      - salt://Xmodmap
    - user: user
    - group: user

So instead of running the script in each qube, cerate the required file
once and copy it in to place.

[No20]

I tried Salt. However, I couldn’t get it working and did not want to spend days figuring it out so I wrote a bash script to cycle through the VMs and use qmv-copy-to-vm and qvm-run qvm-shutdown (not the neatest solution of course).
The issue, however, was that the remapping did not work on the VMs. ~/.Xmodmap was not used. It probably is connected to how Qubes handles the keyboard in the VMs. I am not that into the Qubes architecure to know why it works on dom0 but not on the UserVMs. It seems like a Qubes-specific issue.

I came up with the idea of adding a systemwide startup script in the TemplateVMs (so I wouldn’t have to implement it in every VM) that does:

xmodmap /nothomedirectory/path/to/.Xmodmap

I tried all the usual ways with rc.local, crontab and so on. It did not work for me.
In the end I came up with two solutions:

1. Use

/etc/profile.d/[script]

I only need the changed key in terminal so that would have worked for me.

2. The one I integrated. Creating a systemd service. This however was not very easy. Xmodmap relies on the X-Window-System to work. In the end my service file looked like:

[Unit]
Description=…
[Service]
Type=simple
Environment=“DISPLAY=:0”
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/autostart_keymapping.sh
[Install]
WantedBy=default.target

The Environment variable is needed since xmodmap relies on X. That is also the reason for the ExecStartPre=sleep.
There are some discussions on superuser and stackoverflow how to get the service running after Xorg started. However, this was just to complex for me. I did not really understand what they did so I just used the sleep command which works fine for me.

If anyone likes to comment why some stuff I tried did not work or how to implement it in a better way or a better systemd service, you are more than welcome to comment.
I am not a superuser and I am just trying to get around with internet search and some logical understanding.

[pillule]

No20 via Qubes OS Forum qubes_os@forum.qubes-os.org writes:

I tried Salt. However, I couldn’t get it working and did not want to spend days figuring it out so I
wrote a bash script to cycle through the VMs and use qmv-copy-to-vm and qvm-run qvm-shutdown (not
the neatest solution of course).
The issue, however, was that the remapping did not work on the VMs. ~/.Xmodmap was not used. It
probably is connected to how Qubes handles the keyboard in the VMs. I am not that into the Qubes
architecure to know why it works on dom0 but not on the UserVMs. It seems like a Qubes-specific
issue.

I came up with the idea of adding a systemwide startup script in the TemplateVMs (so I wouldn’t have
to implement it in every VM) that does:

xmodmap /nothomedirectory/path/to/.Xmodmap

I tried all the usual ways with rc.local, crontab and so on. It did not work for me.
In the end I came up with two solutions:

1. Use

/etc/profile.d/[script]

I only need the changed key in terminal so that would have worked for me.

2. The one I integrated. Creating a systemd service. This however was not very easy. Xmodmap relies
   on the X-Window-System to work. In the end my service file looked like:

[Unit]
Description=…
[Service]
Type=simple
Environment=“DISPLAY=:0”
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/autostart_keymapping.sh
[Install]
WantedBy=default.target

The Environment variable is needed since xmodmap relies on X. That is also the reason for the ExecStartPre=sleep.
There are some discussions on superuser and stackoverflow how to get the service running after Xorg
started. However, this was just to complex for me. I did not really understand what they did so I
just used the sleep command which works fine for me.

If anyone likes to comment why some stuff I tried did not work or how to implement it in a better
way or a better systemd service, you are more than welcome to comment.
I am not a superuser and I am just trying to get around with internet search and some logical understanding.

Hi No20,

Now I have a script that source my xkb map on
/etc/X11/Xsession.d/95x11custom_keymap
That works for debian VMs. I haven’t searched yet for fedora.

That is from here that qubes usually load your custom keyboard settings
provided from dom0 for the vms, at this moment you have not to deal with
the display environnement and so on, you are already in.

In dom0, I use a systemd unit that wait for my window manager to start
to source the keymap. It does not handle exiting the window manager and
coming back.

Another way is to use localectl to source your xkb settings. That is the
“right thing to do” for systemd. However the last time I tried it was
buggy as hell (I could change the map only once, after that if I had new
changes to do I was good to reinstall the template). So I stick with the
Xsession option and won’t touch again localectl, even with a stick.

If what you have done is working for you, that’s fine, kuddo.
At least as you see I have nothing better to share

[No20]

hello @pillule
Thanks for your reply.
I tried out your way but it did not work on fedora. I probably did not understand your solution fully.
What is the 95x11…file?
is it a keymap file you created via

xmodmap -pke

or is it a bash script and if yes what does it do?

In dom0 I use the .Xmodmap file in my home directory. That is loaded by X at startup. As I said it does not load it in AppVMs probably Qubes related bug/feature (or whatever ).

[pillule]

No20 via Qubes OS Forum qubes_os@forum.qubes-os.org writes:

hello @pillule
Thanks for your reply.
I tried out your way but it did not work on fedora.

debian and fedora vm differs on how they uses the /etc/X11/ directory.

The file you want to look at is probably the one that qubes ships to
source its keymaps.

In the case of fedora it is :
/etc/X11/xinit/xinitrc.d/qubes-keymap.sh

I probably did not understand your solution fully.
What is the 95x11…file?

Files prefixed that way are usually meant to be run with their whole
directory by run-parts. The prefixes then determines the order of
execution.

is it a keymap file you created via

xmodmap -pke

or is it a bash script and if yes what does it do?

Files here have a shebang. They are scripts. Besides I do not use
xmodmap, I use a xkb map. So it looks like
xkbcomp /some/dir/custom_map.xkb $DISPLAY

In dom0 I use the .Xmodmap file in my home directory. That is loaded by X at startup. As I said it
does not load it in AppVMs probably Qubes related bug/feature (or whatever ).

Maybe it is simply overwritten by the qubes keymap scripts. That would
actually make sense.

[No20]

@pillule

Files prefixed that way are usually meant to be run with their whole
directory by run-parts . The prefixes then determines the order of
execution.

Thank you for explaining this to me. I wondered some time why it is named so awkwardly.

@pillule

Files here have a shebang. They are scripts. Besides I do not use
xmodmap, I use a xkb map. So it looks like
xkbcomp /some/dir/custom_map.xkb $DISPLAY

Thanks for your reply. It helped me

@pillule

Maybe it is simply overwritten by the qubes keymap scripts. That would
actually make sense.

Yes this my assumption as well.

[kippakap]

Hey, I have a closely related problem, and I’m trying to figure out how to use your solution. I think it’s just that I’m not sure how to define a keymap that can be loaded by xkbcomp. On all my previous systems, I’ve been using a custom layout defined in /usr/share/X11/xkb/symbols/us by adding in a block

partial alphanumeric_keys
xkb_symbols "custom" {
    include "us(dvorak)"
    name[Group1]= "US (dvorak custom)";
    key <CAPS> { [ ISO_Level3_Shift ] };
    key <AD01> ...
    ...
};

and then selecting US (dvorak custom) as the variant.
I’ve tried saving the contents of that block as a file (test.xkb) and running

xkbcomp test.xkb $DISPLAY

and nothing is changed. I’m probably just misunderstanding how a symbols map should be defined for xkbcomp.

Alternatively, is there a smart way (possibly salt?) to make my modified /usr/share/X11/xkb/symbols/us be loaded in dom0 and all VMs during xinit rather than using a systemd service to have xkbcomp load a separately defined map?

Thanks

[pillule]

kippakap via Qubes OS Forum qubes_os@forum.qubes-os.org writes:

Hey, I have a closely related problem, and I’m trying to figure out how to use your solution. I
think it’s just that I’m not sure how to define a keymap that can be loaded by xkbcomp. On all my
previous systems, I’ve been using a custom layout defined in /usr/share/X11/xkb/symbols/us by adding
in a block

partial alphanumeric_keys
xkb_symbols "custom" {
    include "us(dvorak)"
    name[Group1]= "US (dvorak custom)";
    key <CAPS> { [ ISO_Level3_Shift ] };
    key <AD01> ...
    ...
};

and then selecting US (dvorak custom) as the variant.

Where ? With the qubes interface or with the regular command setxkbmap ?

I’ve tried saving the contents of that block as a file (test.xkb) and running

xkbcomp test.xkb $DISPLAY

and nothing is changed. I’m probably just misunderstanding how a symbols map should be defined for xkbcomp.

From memory xkbcomp only load a map, if you want to assemble it, you
have to look at the setxkbmap command, and here you can specify
includes in the files, or specify variants and options on the command
line. xkbcomp expect a full keymap (except the useless geometry section).

If that confuse you, look a the map dumped by your actual config with
$ xkbcomp $DISPLAY test.xkb

That is a keymap already assembled, to use again with xkbcomp. It is
different of what you find in /usr/share/X11/xkb/* that are part of
configurations waiting to be assembled, as the different directory names
suggest.

Note that if you understand the syntax, you can simply edit by hand the
map dumped, and load it again with your change rather to have to deal
with setxkbmap.

Alternatively, is there a smart way (possibly salt?) to make my modified
/usr/share/X11/xkb/symbols/us be loaded in dom0 and all VMs during xinit rather than using a systemd
service to have xkbcomp load a separately defined map?

You could modify /etc/X11/Xsession.d/90qubes-keymap (debian) and
/etc/X11/xinit/xinitrc.d/qubes-keymap.sh (fedora) with a script to load
your custom options.

Or modify /usr/share/X11/xkb/symbols/us by inlining your modifications
in the default keymap and expect it to be loaded by default. In both
case you have to chattr theses files so updates won’t overwrite your
changes.

I think I would do one of them when I will rewrite that part of my
configuration and effectively that can be done easily enough with a
file.managed an a cmd.run states with salt.

[kippakap]

Ah perfect. I see, yes that solves my confusion about what xkbcomp expects. So I should use a modified /usr/share/X11/xkb/symbols/us in all my qubes as I have before in monolithic systems, and there is a good way to systematically change that file in all templates including dom0 via salt. I haven’t dug into salt yet, but I think I get the idea and know what to try Thanks!