Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Desktop

Question regarding disappearing keystrokes...

 

 

Gentoo desktop RSS feed   Index | Next | Previous | View Threaded


mcfletch at rogers

Sep 25, 2004, 11:18 AM

Post #1 of 2 (591 views)
Permalink
Question regarding disappearing keystrokes...

This is probably going to seem trivial, but it is driving me a little
buggy. I'm a programmer, so I spend almost my whole day editing code,
including a large amount of cutting, copying and pasting. So I do a lot
of key-sequences where I'm holding down shift(+ctrl)+arrows to select,
then depressing control to start a ctrl+c or a ctrl+x sequence.

What's driving me nuts is that while I'm editing, the various KDE-based
editors (Eric, Kwrite, Kate) are all displaying behaviour where if I
hold down shift and move the cursor to select, then depress ctrl before
I release shift, my next keystroke (normally ctrl+c or ctrl+x) is
ignored. Given that probably 80% of the time I'm doing shift+ctrl+arrow
to select "words", this makes for a very frustrating situation where I
have to pause, explicitly release the control, release the shift, then
re-depress the control key (and when I do it wrong I wind up having to
go from where I was trying to paste back to where I copied).

Similarly, if I hold down shift before depressing control to start
selecting, the first arrow-keypress is ignored for moving about in
words, so I wind up having to constantly check to see if I've really
selected the thing I'm trying to select (which slows me down). To be
clear shift, then control, then arrow ignores the first arrow-keypress,
whereas control, then shift, then arrow pays attention to the first
arrow-keypress.

I'm seeing a similar effect in Mozilla Thunderbird and Mozilla Firefox
(form text-entry), where if I use shift-ctrl-arrow to select words and
let the ctrl key up last, the editor consumes two keystrokes before
returning to normal editing. I'm gathering that it's entering some sort
of "chording" key-entry mode, where it's expecting me to enter an
accented character sequence or the like, but I can't find anywhere to
*disable* that. That's supported by the fact that if the two characters
are "co", a copyright symbol is inserted, and ss inserts a German
character (note, that this chording entry also occurs in the KDE-based
editors, but only for the case where I select with just shift+arrows,
then depress control before releasing shift (first case outlined above)).

The effect from the KDE editors wrt shift then control then arrow
ignoring the arrow-press while the keys are down does *not* occur in
Mozilla (that is, the word is selected normally, but the next key-stroke
after releasing everything is ignored, and will produce extended
characters if for example co or ss are the next two characters).

Just pressing shift, then ctrl, releasing, then typing the two-character
sequence produces the chording effect as well.

I've disabled KDE keyboard layouts and checked that there aren't any
hotkeys with just ctrl in them. Locale is set to US English. The
keyboard is a Microsoft Natural Pro (USB). Running xorg-x11 (same
effect on 6.7 and 6.8) and kde 3.2.2, 3.2.3 and 3.3.0 (all show the same
effect) on AMD64. I'm guessing this is:

* a bug in the keyboard driver
o that could explain the KDE problems, if the driver was
mis-reporting the sequence of releasing shift and control
o wouldn't explain the chording-key mode, or the ignoring the
first arrow with both modifier keys down
* possibly a problem with the xorg configuration, but I can't see
what it would be, I just tell it that it's a "microsoft" keyboard
with "us" layout
* possibly two entirely different "features"/bugs that just happen
to be related to the same keys

I'd really appreciate any guidance people have about how to disable
these effects, or how to go about tracking down where the setup for such
"features" would be located so I can terminate them with extreme
prejudice :) (I'm getting tired of screaming at the computer :) ).

Thanks,
Mike

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com


--
gentoo-desktop [at] gentoo mailing list


mcfletch at rogers

Sep 25, 2004, 9:02 PM

Post #2 of 2 (570 views)
Permalink
Re: Question regarding disappearing keystrokes... [In reply to]

Okay, have been playing with this problem (ctrl+shift consumes
characters) for the last three hours or so (it's been driving me crazy),
and I now have a solution. Posting here in case others run into the
problem and need to know how to disable this little mis-feature.

Problem summary:

The microsoft(natural) keyboard mapping, by default, maps shift+ctrl
to "Multi_key", which is a "chording" composition mechanism that
allows for entering extended character codes via a set of defined
mappings. For instance type shift+ctrl, then 'co' produces a
copyright symbol. This particular choice of keys, however, means
that simple editing operations involving shift and control can wind
up entering the chording-key mode.

Problem source:

Turns out that this is an XWindows "feature" which was enabled by
the (AFAIK automatically generated) configuration options in my
xorg.conf keyboard section:

Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbModel" "microsoftpro"
Option "XkbLayout" "us"
Option "XkbVariant" "winkeys"
EndSection

winkeys doesn't actually appear to be defined anywhere, which leaves
the definition as the "normal" microsoftpro layout (leaving out
winkeys, or defining any other unrecognised variant has the same
effect, effectively selecting "basic").

Solution 1:

Switch the XkbVariant setting to "nodeadkeys". This eliminates all
of the undesirable features of the mapping, but also eliminates a
number of the commonly useful key-mappings such as the Windows keys,
the "Menu" key, etceteras.

Solution 2:

Leave XkbVariant setting as "basic" (or "winkeys" if you prefer).
Create a file like this in your home directory:

8<_____ .xmodmap.rc ___________

keycode 115 = Super_L Multi_key
keycode 116 = Super_R Multi_key
keycode 109 = Control_R

and add the following line to your .xinitrc file (you may not have a
.xinitrc file yet, if not, read up on what to put in it, at the very
least you'll want a call to startkde in it, read this *before*
editing the file, as a messed up .xinitrc can prevent you from
logging in (annoying if you're using xdm for your login manager)):

xmodmap .xmodmaprc

This file maps the "compose key" (multi-key) mode to
shift+WindowsKey (either one), and eliminates the control-with-shift
as a multi-key mapping.

If someone has a better approach, that would be cool to know about too.
Adding the xmodmap call to .xinitrc means that the whole system operates
as-desired wrt this feature, but if I'm reading correctly xmodmap is not
the "proper" way to do this kind of thing any more.

Enjoy yourselves,
Mike

Mike C. Fletcher wrote:

> This is probably going to seem trivial, but it is driving me a little
> buggy. I'm a programmer, so I spend almost my whole day editing code,
> including a large amount of cutting, copying and pasting. So I do a
> lot of key-sequences where I'm holding down shift(+ctrl)+arrows to
> select, then depressing control to start a ctrl+c or a ctrl+x sequence.
>
... <snip>
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com


--
gentoo-desktop [at] gentoo mailing list

Gentoo desktop RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.