xkb custom map and xterm - Shift+U & Shift+I
Chris Jones
with (among other things), the ‘navigation keypad’ mapped to
Mod3+[UIOPHJKL] so that I can easily access PageUp, PageDown, Home, End,
and the ‘arrow keys’ without moving my fingers away from the home row.
My custom map loads OK and the new navigation keys function as expected
in my web browser, but rather mysteriously, the Shifted ‘U’ and ’I’ keys
no longer work in XTerm. In fact, the cursor stays put and it's as if
XTerm never sees the keypresses.
As far as I can understand its output, ‘xev’ sees them alright and
associates them with the correct keysyms:
‘u’ -> ‘u’
‘u’ with Shift key depressed -> ‘U’
‘u’ with Mod3 key depressed -> ‘Prior’
‘i’ -> ‘i’
‘i’ with Shift key depressed -> ‘I’
‘i’ with Mod3 key depressed -> ‘Next’
All other keys with a third-level mapping to a navigation action, such
as Home, End, etc. work fine. Only the ‘U/Prior’ and ‘I/Next’ keys are
affected.
Among a number of things I tried to help narrow down this issue and
figure out where to report it is that I fired up rxvt and I was unable
to reproduce the problem.
Another thing I noticed is that if I move the mappings to the fourth
column, which results in Prior being mapped to Mod3+Shift+U etc.. the
problem goes away! Not very useful since pressing more than two keys
concurrently is not something I would want to do on a regular basis.
In case it matters, here's the relevant part of my custom symbols map:
------------------------------------------------------------------------
// Custom US layout
// 2011-01-11 Chris Jones
//
// Bizarre problem where the Prior/Next (or Page_Up/Page_Down) on
// AD07/AD08 - 3rd column cause Shift-U/Shift-I to no longer produce
// upper-case U and I in an xterm...! This does not happen with rxvt...
partial alphanumeric_keys
xkb_symbols "cjns" {
include "us(basic)"
name[Group1]= "USA - cjns";
// Alphanumeric section
...
key <AD06> { [ y, Y, Nosymbol, NoSymbol ] };
key <AD07> { [ u, U, Prior, NoSymbol ] };
key <AD08> { [ i, I, Next, NoSymbol ] };
key <AD09> { [ o, O, Home, NoSymbol ] };
key <AD10> { [ p, P, End, NoSymbol ] };
...
key <AC01> { [ a, A, aacute, Greek_alpha ] };
key <AC02> { [ s, S, ssharp, Greek_SIGMA ] };
key <AC03> { [ d, D, Greek_delta, Greek_DELTA ] };
key <AC04> { [ f, F, caret, period ] };
key <AC05> { [ g, G, Greek_gamma, Greek_GAMMA ] };
key <AC06> { [ h, H, Left, leftarrow ] };
key <AC07> { [ j, J, Down, downarrow ] };
key <AC08> { [ k, K, Up, uparrow ] };
key <AC09> { [ l, L, Right, rightarrow ] };
...
include "level3(win_switch)"
include "compose(menu)"
};
------------------------------------------------------------------------
Tests were run on debian stable with a recent xterm(253) downloaded as
a tarball.
Is anyone aware of anything that might make XTerm treat Prior/PageUp
and Next/PageDown any different than the other (navigation) keys?
Thanks,
cj
Lucas Levrel
> All other keys with a third-level mapping to a navigation action, such
> as Home, End, etc. work fine. Only the ‘U/Prior’ and ‘I/Next’ keys are
> affected.
What if you map Prior/Next to other keys?
Maybe also check what showkey gives?
--
LL
Chris Jones
> Le 10 janvier 2011, Chris Jones a écrit :
>> All other keys with a third-level mapping to a navigation action, such
>> as Home, End, etc. work fine. Only the ‘U/Prior’ and ‘I/Next’ keys are
>> affected.
>
> What if you map Prior/Next to other keys?
Same.
> Maybe also check what showkey gives?
Hm. I was under the impression showkey was the linux console equivalent
of xev, so I'm not sure it's relevant.
cj
Lucas Levrel
>> Maybe also check what showkey gives?
>
> Hm. I was under the impression showkey was the linux console equivalent
> of xev, so I'm not sure it's relevant.
Right, but I found some terminals don't honor all X settings (Xfce's
Terminal e.g. still uses Alt as Meta although I've set Win keys to produce
Meta in X), hence the suggestion. Nevermind.
--
LL
Lucas Levrel
> Among a number of things I tried to help narrow down this issue and
> figure out where to report it is that I fired up rxvt and I was unable
> to reproduce the problem.
Same with Xfce's Terminal, new layout honored.
> Another thing I noticed is that if I move the mappings to the fourth
> column, which results in Prior being mapped to Mod3+Shift+U etc.. the
> problem goes away! Not very useful since pressing more than two keys
> concurrently is not something I would want to do on a regular basis.
I had set
key <AD07> { [ u, U, Prior, Ucircumflex ] };
Neither U nor Ucircumflex work in xterm.
> Tests were run on debian stable with a recent xterm(253) downloaded as
> a tarball.
openSUSE here with xterm -v: X.Org 6.8.99.903(242). So at least the bug
isn't specific to your computer or distribution.
--
LL
Chris Jones
No problem.
In case something trivial in xterm's terminfo might be causing this,
I even tested with ‘xterm -tn rxvt’ and still was unable to get Shift+U
and Shift+I to do anything. It would make better sense if all the
navigation remappings (Right, Left.. Home.. End..) caused problems, but
it's only those two particular keyboard actions.
It's rather odd that the remappings themselves work as expected, but
they appear to clobber the mapping ‘just below’.. so-to-speak.
If at least they caused the shifted U/I to be forced to the unshifted
mapping (u/i), this would hint at the bit that stands for the Shift
modifier being ‘accidentally’ reset.. but here, it's as if they had been
remapped to ’nosymbol’.
I tried hitting the Mod3+U/I combos and then hitting another key..
thinking.. maybe they are remapped to dead keys :-) .. but even after
trying half a dozen keys chosen randomly, I still didn't see anything.
At this point, I have no idea what I can do to investigate further. I'm
not sure running XTerm under a debugger would help since Shift+U/I are
not even echoed back to the screen (i.e. without hitting enter): it
looks as if XTerm does not even see the keypresses.
I don't have Xfce set up, so I'll try to reproduce under
gnome-terminal.. Have a feeling I'm looking at this from the wrong
perspective.
Also, if you know of any usenet group, mailing list or forum where
I could report this to folks who are xkb-savvy.. that might help.
This feels more like an Xorg/xkb bug that causes problems to XTerm
rather than an XTerm bug proper, and somehow rxvt is not affected.
Thanks,
cj
Lucas Levrel
> At this point, I have no idea what I can do to investigate further.
One more test idea: assigning Prior/Next to fourth level rather than
third.
(With xmodmap I had to put mod3 and shift-mod3 symbols in the fifth and
sixth places in "keycode X = ..." lines. Perhaps a glitch in my config,
though.)
Also, did you inspect xev's output in full detail (state, keysym)?
> This feels more like an Xorg/xkb bug that causes problems to XTerm
> rather than an XTerm bug proper, and somehow rxvt is not affected.
Yet, all other X apps work... What about text apps in xterm? What does C-v
S-u give?
--
LL
Lucas Levrel
> At this point, I have no idea what I can do to investigate further. I'm
> not sure running XTerm under a debugger would help since Shift+U/I are
> not even echoed back to the screen (i.e. without hitting enter): it
> looks as if XTerm does not even see the keypresses.
Just occurred to me there are also KP_Prior/KP_Next you could try...
--
LL
Chris Jones
> Le 12 janvier 2011, Chris Jones a écrit :
>> At this point, I have no idea what I can do to investigate further.
>
> One more test idea: assigning Prior/Next to fourth level rather than
> third.
From my initial post:
‘Another thing I noticed is that if I move the mappings to the fourth
column, which results in Prior being mapped to Mod3+Shift+U etc.. the
problem goes away! Not very useful since pressing more than two keys
concurrently is not something I would want to do on a regular basis.’
No harm done... I am so ignorant of what goes on behind the scenes that
it's really a challenge to come up with a well-organized description of
the symptoms. :/
> (With xmodmap I had to put mod3 and shift-mod3 symbols in the fifth and
> sixth places in "keycode X = ..." lines. Perhaps a glitch in my config,
> though.)
This is something else I don't understand: When I do an ‘xmodmap -pk’,
I end up with six mappings per key instead of four, with basically the
fifth and sixth column reproducing column three and four. This
apparently is not supported by the newer xkb symbols maps.
Not relevant to the current issue, but I for one wouldn't mind being
able to define a single keymap with 3*2=6 different keysyms per key.
> Also, did you inspect xev's output in full detail (state, keysym)?
The symbolic name of the keysym is the only thing I somewhat understand.
>
>> This feels more like an Xorg/xkb bug that causes problems to XTerm
>> rather than an XTerm bug proper, and somehow rxvt is not affected.
>
> Yet, all other X apps work...
Aha.. !
I just tried ‘xman’ with my custom layout. I open ‘Manual Page’ then
click on ‘Search’ in the ‘Options’ menu. This gives you an input field
where you can type the name of a man page.
With my custom layout, all the keys that are mapped to navigation keys
totally stop functioning: I can hit the ‘YUIOPHJKL’ keys both shifted
and unshifted and none of them causes the corresponding ‘YUIOPHJKL‘or
‘yuiophjkl' to materialize in the little input field. If I hit other
keys, say ‘asdf’, the corresponding characters are displayed, but then
something even more bizarre happens: the un-shifted forms of some of the
‘UYIOPHJKL’ keys actually cause the cursor to jump to the beginning or
the end of the text-entry field.. Of course, after I switch back to the
standard ‘us’ layout, these keys work normally.
As you must have realized by now, I know next to nothing about X.. but
I would consider ‘xman’ to be a ‘true’ X application, so doesn't this
suggest that threre are some areas where X and xkb do not understand
each other?
> What about text apps in xterm? What does C-v S-u give?
Yes, I tried this as well.
More to the point is CTRL+V Shift+U followed by CTRL+V Shift+I: nothing
happens until I hit CTRL+V a second time, behaving the same as if I had
typed CTRL+V CTRL+V.. demonstrating that Shift+U did not generate an
event.
At this point, I think I need to locate the xkb maintainer for
assistance.
cj
Chris Jones
I tried those as well.. IIRC, Shift+U was working but Shift+I did not.
Chris Jones
Or personal customization.. :-)
One thing I haven't tried and that may be worth taking a look at would
be to use xmodmap rather than xkb for these mappings (as you suggested
some place else in this thread, I believe) and see what happens.
Thanks,
cj
Marc D. Williams
>
> Or personal customization.. :-)
>
> One thing I haven't tried and that may be worth taking a look at would
> be to use xmodmap rather than xkb for these mappings (as you suggested
> some place else in this thread, I believe) and see what happens.
>
> Thanks,
>
> cj
Yeah, xmodmap might be worth trying.
Although it's an old program I wonder if xkeycaps might be helpful.
It's a visual keyboard remapper that generates custom xmodmap files.
Not sure if it can handle all the things you need.
Old and no longer maintained pure X11 app.
--
==ANIME SENSHI==
Marc D. Williams
http://www.oldskool.org/guides/tvdog/ -- DOS Internet & Tandy 1000
http://www.digisensei.info/win3/ -- Win3.x Makeover
Chris Jones
> On 13.Jan.11 9:22 AM, Chris Jones wrote:
[..]
> Yeah, xmodmap might be worth trying. Although it's an old program
> I wonder if xkeycaps might be helpful. It's a visual keyboard remapper
> that generates custom xmodmap files. Not sure if it can handle all the
> things you need. Old and no longer maintained pure X11 app.
Yes, that's a thought.. I haven't used xkeycaps in a while and I mostly
remember the dire warning.. ’you'll be sorry son..’ or something to that
effect.. that pops up every time you attempt to make any changes to your
setup. :-)
But in any event, I'm not really looking for a work around.. everything
else works and I don't need PgUp and PgDn that bad.. mostly to switch
tabs in browsers via the CTRL modifier.. otherwise I'm used to scrolling
by keeping the Up/Down keys depressed.
I'm mostly trying to figure out who I should report this peculiar
behavior to.. not holding my breath that they will care.
Thanks,
cj
Lucas Levrel
> One thing I haven't tried and that may be worth taking a look at would
> be to use xmodmap rather than xkb for these mappings (as you suggested
> some place else in this thread, I believe) and see what happens.
Tried it, doesn't work.
--
LL
Lucas Levrel
> On Thu, 13 Jan 2011 10:48:31 +0100, Lucas Levrel <lucas....@u-pec.fr> wrote:
>> One more test idea: assigning Prior/Next to fourth level rather than
>> third.
>
> From my initial post:
>
> ‘Another thing I noticed is that if I move the mappings to the fourth
> column, which results in Prior being mapped to Mod3+Shift+U etc.. the
> problem goes away! Not very useful since pressing more than two keys
> concurrently is not something I would want to do on a regular basis.’
>
> No harm done... I am so ignorant of what goes on behind the scenes that
> it's really a challenge to come up with a well-organized description of
> the symptoms. :/
I'm so more ignorant that I messed up words. I had in mind "using mod4".
In fact I have no precise idea of what modX means. But I know there's a
way to get eight levels per key by defining another modifier key. Then you
could try putting Prior in one of levels 5-8 (5 probably since you don't
want to press several modifiers).
> This is something else I don't understand: When I do an ‘xmodmap -pk’,
> I end up with six mappings per key instead of four, with basically the
> fifth and sixth column reproducing column three and four.
Yes, I realized that after posting. I never understood xmodmap well,
always used trial and error...
> As you must have realized by now, I know next to nothing about X.. but
> I would consider ‘xman’ to be a ‘true’ X application, so doesn't this
> suggest that threre are some areas where X and xkb do not understand
> each other?
Yes, but I would also have considered xkb to be part of X. Plus, using
xmodmap instead of setxkbmap yields the same problems.
--
LL
Lucas Levrel
Hey! I just tested and they both work! (I mean, all levels of the
redefined key do work.)
Also, I found that with your original setup (u U Prior x), Shift+u in
xterm has the effect of Shift+Prior, that is scroll up. Might be
interesting to mention to the maintainers, if you find them.
--
LL
Chris Jones
> Le 13 janvier 2011, Chris Jones a écrit :
>
>> On Thu, 13 Jan 2011 16:38:19 +0100, Lucas Levrel <lucas....@u-pec.fr> wrote:
>>
>>> Just occurred to me there are also KP_Prior/KP_Next you could try...
>>
>> I tried those as well.. IIRC, Shift+U was working but Shift+I did not.
>
> Hey! I just tested and they both work! (I mean, all levels of the
> redefined key do work.)
Sometimes too many cooks spoil the broth.. and sometimes it's nice to
have another pair of eyes look at the problem..
I guess I was getting really frustrated when I tried KP+Prior/Next and
I must have missed something.
Works now..!
> Also, I found that with your original setup (u U Prior x), Shift+u in
> xterm has the effect of Shift+Prior, that is scroll up. Might be
> interesting to mention to the maintainers, if you find them.
I haven't sent in my debian report as yet, so I will definitely mention
your findings & workaround...
I would assume the debian package maintainer knows where he can find the
upstream.. it would be nice if it were the same person.
If I had known where to look, it would probably have been more effective
to check the source, and possibly come up with a patch.
Thanks much for cracking this one.
cj
Chris Jones
Here's the bug report:
Not sure if you can update it, in case I forgot something.
cj
Lucas Levrel
> Here's the bug report:
>
> http://bugs.debian.org/610263
>
> Not sure if you can update it, in case I forgot something.
(Didn't try to update myself.)
In the second paragraph you forgot to mention the problem happens in
xterm, not seamonkey.
1) mod3+u/i (Prior/Next) work everywhere
2) Shift+u/i (U/I) work in many places except xterm, xman...
--
LL
Chris Jones
Ah yes, you're right.. lost some stuff while trying to make the original
report a little less confusing... ;-)
Erratum sent.
cj