stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Windows key prefix key oddity


From: Bernard Hurley
Subject: Re: [STUMP] Windows key prefix key oddity
Date: Sat, 29 Mar 2014 06:34:22 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 25, 2014 at 12:47:05PM -0400, address@hidden wrote:
> Hi
> 
> 
> 
> I tried to set my windows key as the prefix key according to the instructions 
> in the faq, but it didn't work, so I decided instead to use the grave key. 
> (Backward apostrophe, to the left of 1). This worked, but in order to be able 
> to continue to type the grave character if I needed to, which is rare, I 
> programmed the windows key to type it. This works in xterm if I type 
> shift-windows. If I type windows without shift, you would perhaps expect it 
> to act as the prefix key, but it does nothing.
> 
> In addition, I programmed F9 to send the grave character, but this, as 
> expected, has made F9 act the same as grave, i.e. as the prefix key.
> 
> Here is what I put in .xsession:
> 
> xmodmap -e "keycode 133 = grave"
> xmodmap -e "keycode 75 = grave"
> 
> 133 is the key code for the windows key on my keyboards. 75 is F9.
> 
> Here is what I put in .stumpwmrc
> 
> (set-prefix-key (stumpwm:kbd "`"))

The xorg foundation recommends that you don't use xmodmap any more.  The 
"correct" way to do it is to modify the keyboard's configuration file.  On 
Debian this file is /etc/default/keyboard.

Most of the file will have been generated automatically.  So you should see 
lines, depending on you keyboard, something like:

XKBMODEL="pc105"
XKBLAYOUT="gb"
XKBVARIANT=""

BACKSPACE="guess"

The thing to do is to add an XKBOPTIONS line.

For instance the line:

XKBOPTIONS="lv5:rwin_switch_lock,compose:caps,shift:both_capslock_cancel,nbsp:level3n,misc:typo"

makes the right window key a level 5 switch, capslock a compose key, both 
shifts together a capslock but cancelled by either, a non-breaking space at 
level 3 together with a thin one at level 4, and finally adds various 
miscellaneous typographic symbols.

To find out what to put ins XKBOPTIONS, look in (on a Debian system) 
/usr/share/X11/xkb/rules/evdev.lst and scroll down to the section marked "! 
option."  The possible options are listed sub-sections such as:  grp, lv3, 
ctrl, grp_led, keypad, kpdl, caps, altwin, Compose key, etc.  Each option is 
documented.

You can probably find what you want somewhere here, and as you can see from my 
example XKBOPTIONS is a comma separated string of such options.  If you don't 
find what you want then it is possible in theory to write your own options,  
not many people do but if you do the xorg foundation would probably like to 
know.

Some caveats:

1) You can only have one XKBOPTIONS line so it can get very long!
2) Some, but not many, of the options do more than the documentation suggests. 
I.e. they alter the behaviour of keys you would not expect.
3) Some options are inconsistent with each other and you will get strange 
behaviour if you use them together.  Usually this is obvious, but watch out for 
options mentioned in (2)
4) According to the documentations you should run:

   sudo udevadm trigger --subsystem-match=input --action=change

After updating XKBOPTIONS.  This usually does what you want, but if you delete 
an option from XKBOPTIONS, it will stay at its old value unless you specify 
another, which is probably not what you want; in this case you will need to 
restart the X server.  Actually this doesn't always seem to happen, but I 
havn't worked out when and why.

5) Each keyboard layout sets various options by default so, implicitly, there 
will be options set that you have not specified.  These can be changed but you 
will have to guess what they are.


The behaviour of your windows key will have something to do with (5)

I hope this is of some use to you.

Bernard.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]