> So the question is that is there any way VirtualBox can be causing this, I
> don't think it is interfering but you be the judge of that.
I suspect that this is the root of the weird behaviour.
One can think of various way of mapping key events from host to guest.
The one extreme is to do the
> I am writing today to add my voice to the longstanding complaints that the
> Caps LOck off key is very slow to respond, which makes double uppercase
> letters LIke this more common than I'd like when typing.
If "slowness" technically means that Caps unlocks only when the
CapsLock key is
> I'm trying to create a bunch of mappings like this:
> `Hyper+Shift+C` -> `Ctrl+Shift+C`
> `Hyper+Left` -> `Alt+Left`
> `Alt+Left` -> `Ctrl+Left`
> `Super+Left` -> `Home`
> How can I do it in xkb config files?
You can change the modifiers with Redirect actions. For example, for
the LEFT key,
> Question is, was it there for 22 years cause it's unfixable or because
> nobody uses overlay? :)
I guess Mihail is right, overlays are certainly little used. I do use
overlays myself, but only as as lock, where the bug is not likely to
occur.
You might want to look at Redirect actions,
> - press caps
> - press f
> - release caps
> - wait
> - release f
In xserver/xkb/xkbPrKeyEv.c, there is a bug that prevents key
press/release to be tracked properly for keys with overlays, in case
such a key is down while the overlay state changes. There is even a
comment (from 9/11/94) that
> So there's no way to work around this?
I can think of three:
- You have two Shift keys and most likely two Mod4 keys. This gives you
three more possibilities to enter the same combination. If any of
this combinations works and is sufficiently convenient to type, that
would be the
> Long story short: do you see any chance in making this bit of
> legacy (nostalgia?) code configurable, or remove it altogether?
I do not know, but I do not see the benefit of doing that. It certainly
would not fix your problem, which I still think is hardware.
Andreas
> And moments after clicking send, I realized this is really just hardcoding
> US keyboard layout & ASCII encoding - Shift-2 is '@' and Ctrl-@ is '\0'.
Oh, yes. And Ctrl+3-7 get mapped to 0x1b-0x1f, the control codes beyond
Ctrl-Z. Ctrl+8 becomes 0x7f, that is, ASCII DEL. So the full ASCII
> I am trying to determine the license for font-bh-lucidatypewriter-dpi75,
> which appears to be under the Bigelow & Holmes copyright. Any information
> would be appreciated.
I do not really know, but as nobody else replies, let me at least provide
three pointers:
The freedesktop repository
I haven't found why my keyboard produces keycode 92 for AltGr, though the
layout
uses RALT = 108; so it should produce 108.
Maybe you looked at the xev output line 'XKeysymToKeycode returns
keycode'? If multiple keys produce the same keysym (as here, RALT and
LVL3 both produce
Hello Knut,
Apparently, your keyboard attempts to make its special keys usable
without special drivers. Many layouts have @ on the AltGr-layer of the
2 key. So, to implement a @ key with such a layout, the keyboard
firmware could emulate pressing AltGr+2 simultaneously. Moreover, on
Windows,
And it uses vmods1 in place of vmods_mask1
Where?
But I think there is still a bug: High and low bytes for virtual
modifiers and masks are swapped, compared to the XKB protocol
specification (the protocol uses big endian, the macros use little
endian). Is this worth fixing?
Andreas
An apparent copy/paste bug in the macro XkbSARedirectSetVMods, which breaks
using RedirectKey actions with virtual modifiers.
Signed-off-by: Andreas Wettstein wetts...@gmail.com
---
XKBstr.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/XKBstr.h b/XKBstr.h
index
But, interpret F5+Exactly(Super) doesn't seem to work. While testing. I
found that interpret F5 {...}; works just fine. It is as if using
+Exactly(Super) doesn't capture the key.
Yes. The modifier specified with interpret is not related to the
status, but with to modifier map. So
Anyway, right now I stumbled upon a strange fact that when I am
replace an original «libX11.so.6.3.0» with a newly compiled one, the
compose key just stops working. I didn't changed anything except that
configured compilation with «-g3» added to CFLAGS and CPPFLAGS. Have
anybody an idea what
If you are willing to modify your libX11, something you might want to
try is to change libX11/modules/im/ximcp/imLcFlt.c such that the calls
to XLookupString are done with a modified value of ev-xkey.state. You
mask out the two bits of the state that determine the group. For
compose sequences,
Dear all,
A while ago, I submitted the following patch for xkbcomp, related to
locking and ISOLock:
http://patchwork.freedesktop.org/patch/20376/
It has been reviewed, but not merged yet. Can somebody please merge
this patch?
Apart from fixing incorrect behaviour, this patch brings the
Dear all,
some time ago I submitted the following three patches for libxkbfile:
http://patchwork.freedesktop.org/patch/20377/
http://patchwork.freedesktop.org/patch/20378/
http://patchwork.freedesktop.org/patch/20379/
They have been reviewed, but not merged. The first two add
Dear all,
a while ago, I submitted a few patches which have been reviewed, but not
merged.
These two add missing flags to output:
http://patchwork.freedesktop.org/patch/20380/
http://patchwork.freedesktop.org/patch/20381/
This one disables autorepeat for modifier keys (current
It seems that mailing list x...@listserv.bat.ru doesn't exist anymore.
Right. It moved to Google Groups:
https://groups.google.com/a/listserv.bat.ru/group/xkb
Everything that happens in bugzilla for xkeyboard-config is forwarded to
this list, and little else is going on on this list besides
compose(A)
produces Ă) instead of Ⓐ
With the libX11 compose, I get Ⓐ. With the GTK compose mechanism, I get
Ă) as you observed. So my guess is that you accidentially use GTK's or
some other input method, rather than XIM.
Andreas
___
fwiw, I'm really tempted to fix the translation here. Legacy and veraltet
are two different things. ueberholt would be a more appropriate term, IMO.
überholt is too dismissive, I think. I would translate legacy in
this context as mit toter Tilde...
Andreas
after I upgraded Ubuntu from 13.10 to 14.04 I can't type letters with
a makron on top like for instance 'ā' with the 'AltGr' + 'Shift' + '+'
- shortcut which worked before.
There was a change in xkeyboard-config more than a year ago that made
the tilde in the default German layout non-dead, as
Thank you very much for the help. I tried what you provided but it did't
work for me. I think I need to change other parts of the file.
The second proposal actually should work without further changes, but
maybe you test the layout with an application that does not handle
Control as a level
Is there anyway you could give me similar (complete) instructions for
using the control key?
To get a startfrom.xkb with the right control key as level5 chooser,
run:
setxkbmap -print us -option -option lv3:ralt_switch -option
lv5:rwin_switch_lock | sed -e s/rwin_switch_lock/rctrl_switch/ |
25 matches
Mail list logo
