Re: [STUMP] Windows key prefix key oddity

[David Bjergaard]

If it's not too much trouble could you write this up on our wiki? If not I will 
if someone opens an issue referencing this thread. 

    Dave

> On Mar 29, 2014, at 2:34 AM, Bernard Hurley <address@hidden> wrote:
> 
>> 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.
> 
> 
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel