[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] Windows key prefix key oddity
From: |
iii_iii |
Subject: |
Re: [STUMP] Windows key prefix key oddity |
Date: |
Sat, 29 Mar 2014 09:51:00 -0400 (EDT) |
I could write up what I have written here:
http://lists.nongnu.org/archive/html/stumpwm-devel/2014-03/msg00061.html
Unfortunately I changed the subject so maybe it will go unnoticed.
I haven't looked into the newer method yet. According to this page:
https://wiki.archlinux.org/index.php/xmodmap
"Generally it is not recommended to use xmodmap, except maybe for the
simplest tasks. "
What I have done seems to work, and as I have done it I should think
it's a simple task. :)
-----Original Message-----
From: David Bjergaard <address@hidden>
To: Bernard Hurley <address@hidden>
Cc: iii_iii <address@hidden>; stumpwm-devel <address@hidden>
Sent: Sat, Mar 29, 2014 1:32 pm
Subject: Re: [STUMP] Windows key prefix key oddity
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
- Re: [STUMP] Windows key prefix key oddity, (continued)