Bug 6009 - (int-145190) "Enter" key sends wrong keycode to console applications
(int-145190)
: "Enter" key sends wrong keycode to console applications
Status: RESOLVED FIXED
Product: Utilities
X Terminal
: 5.0:(20.2010.36-2)
: N900 Maemo
: Low normal with 40 votes (vote)
: 5.0/Community-SSU
Assigned To: unassigned
: osso-xterm-bugs
:
: community-fremantle, patch
:
: int-153696
  Show dependency tree
 
Reported: 2009-11-02 19:50 UTC by Donn Morrison
Modified: 2011-02-04 16:29 UTC (History)
27 users (show)

See Also:


Attachments
isolated patch based on comment 6 and comment 9 (447 bytes, patch)
2010-04-01 16:13 UTC, Thomas Perl
Details
libvte4_0.16.14-0mh9.m5_armel.deb (patched build) (707.79 KB, application/octet-stream)
2010-05-12 12:20 UTC, Thomas Perl
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Donn Morrison (reporter) 2009-11-02 19:50:51 UTC
SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:

1. Open XTerminal (Applications > Others > XTerminal)
2. ssh to a host with screen and vim installed
3. Invoke screen (type "screen")
4. Within screen, invoke vim (type "vim")
5. Enter inster mode (type "i")
6. Press the enter key on the keyboard

EXPECTED OUTCOME:

Carriage return.

ACTUAL OUTCOME:

Carriage return with additional character ("M").

REPRODUCIBILITY:

always

OTHER COMMENTS:

Invoking the console application directly (not under screen) shows the correct
behaviour. Also, the enter key works as expected under the same circumstances
on the N810, leading me to believe something has changed with XTerminal or the
enter keycode on the N900.

I regularly ssh to a machine running mutt and vim under screen and have to use
CTRL-M in place of Enter because mutt and vim does not recognise the keycode.

I would be quite happy with a simple work around.
Comment 1 Lucas Maneos 2009-11-02 21:49:07 UTC
Confirming, and not just under screen.  For example, searching in less has the
same problem.  Not-so-elegant temporary workaround: press ctrl-J instead.
Comment 2 Andre Klapper maemo.org 2009-11-03 13:42:10 UTC
(In reply to comment #0)
> Invoking the console application directly (not under screen) shows the correct
> behaviour.

(In reply to comment #1)
> Confirming, and not just under screen.

Somehow this is a contradiction to me, but maybe somebody could clarify. :-)
Comment 3 Donn Morrison (reporter) 2009-11-03 14:31:12 UTC
(In reply to comment #2)
> Somehow this is a contradiction to me, but maybe somebody could clarify. :-)

Lucas is correct. Even though vim shows correct behaviour when not running
under screen, less does not. So we can factor screen out of the problem.

Comparing XTerminal on Diablo 4.2008.30-2 and 1.2009.41-10, it is easy to
verify that there is a difference. Do the following from both (i.e. N810 and
N900):

1. Open XTerminal
2. ssh to a host with less installed
3. Run "less somelongtextfile"
4. Attempt to search: Type "/" followed by a search term, followed by Enter

On Diablo pressing Enter (Step 4) executes the search. On Fremantle, pressing
Enter appends the text "ESCOM" to the search term instead of executing the
search. To properly execute the search, one must press CTRL-M.

Both Diablo and Fremantle set the TERM environment variable to "xterm" and this
is reflected on the host that is ssh'd to by typing "echo $TERM".
Comment 4 Lucas Maneos 2009-11-03 16:39:40 UTC
Note (just to rule out any ssh, remote terminfo etc interactions) that less is
also available to run locally (from the tools repository) and exhibits the same
problem.

I haven't managed to find the difference between the N810 & N900 yet.  The
"Enter" key generates KP_Enter on both devices (as reported by xev), and their
respective /usr/share/terminfo/x/xterm are identical.
Comment 5 Patrick Smears 2009-12-09 18:17:01 UTC
Some points that may be helpful:

(0) A workaround is to press Ctrl+M or Ctrl+J instead of Enter.

(1) This behaviour (enter not working) can be enabled/disabled at will, by
sending the escape codes to enable/disable "application mode". Try starting a
new xterm window, then:

To start having problems:    echo -e '\033='

(after this, the enter key won't work in the shell - use the workaround above
to be able to enter commands)

To stop having problems:    echo -e '\033>'

So it looks like it's something to do with the handling of Application Mode.
(The behaviour may even be technically "correct", it's just very annoying!)

(2) I don't have my N810 here so can't try it on that. But that might be a
useful data point.

(3) For standard xterm, the configuration file allows arbitrary key mappings.
Has the key mapping for Enter changed (e.g. from "normal enter" to "keypad
enter")?
Comment 6 Santtu Lakkala 2009-12-09 18:36:37 UTC
The reason why it worked in diablo is likely due to the tweak I put in vte back
when Nokia wasn't handling osso-xterm. The second chunk in
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/vte/trunk/debian/patches/maybe-rel/90-maemo-changes.patch?revision=191&root=osso-xterm&view=markup

Apparently this patch did not make it into the fremantle version of vte, nor
was it implemented in osso-xterm. I never got around to finding the real
culprit so the hack made it all the way to official diablo versions.
Comment 7 Jukka N. 2009-12-10 01:18:39 UTC
Using Irssi through SSH (X terminal, SSH to other comp, screen -rU  opening my
normal Irssi session) is very annoying with this bug. No matter what you do
relating to those echo things on comment #5, "enter" key just doesn't work. You
have to use ^J or ^M which is very annoying. I hope this bug gets fixed fast.
Comment 8 David Ward 2009-12-16 00:10:16 UTC
I can confirm the ssh/vim issue. I have not used less yet.
Comment 9 Pierre Amadio 2009-12-20 18:40:19 UTC
I confirm applying chunk 2 of the patch mentionned in comment 6 fix the
problem.

I applyed it after apt-get sourcing libvte 0.16.14-0mh9.m5 , rebuilded the
package and installed the new libvte4_0.16.14-0mh9.m6_armel.deb
libvte-common_0.16.14-0mh9.m6_all.deb on the n900. Enter key worked ok on a
screen session in vi and mutt (whereas it did not before updating the package).
Comment 10 Thomas Perl 2009-12-21 01:07:24 UTC
(In reply to comment #9)
> I confirm applying chunk 2 of the patch mentionned in comment 6 fix the
> problem.

Great! Can we get this to the person who maintains the X Terminal builds for
the "official" Nokia images and have it merged? Maybe someone with access to
the internal bug tracker can add this information to "int-145190"?
Comment 11 Andre Klapper maemo.org 2009-12-21 12:43:47 UTC
(In reply to comment #10)
> Maybe someone with access to the internal bug tracker

Done.
Comment 12 awwaiid 2009-12-23 00:03:42 UTC
Another workaround is to tweak your .screenrc a bit to turn the app-mode keypad
enter button into a ^M

  # Fix n900 keyboard
  bindkey -a -k fe stuff ^M

I don't really understand why it is sending KP_Enter instead of just Return at
all, actually, let alone why we are going into app-mode.
Comment 13 David Ward 2009-12-23 02:22:42 UTC
(In reply to comment #12)
> Another workaround is to tweak your .screenrc a bit to turn the app-mode keypad
> enter button into a ^M
> 
>   # Fix n900 keyboard
>   bindkey -a -k fe stuff ^M
> 
> I don't really understand why it is sending KP_Enter instead of just Return at
> all, actually, let alone why we are going into app-mode.
> 

Thanks for that. Can confirm it works well. Not sure how it impacts an ENTER
press from a normal keyboard in the same screen session.

Juat a note, the creation of the up arrow and M is like so:

CTRL+v then ENTER

ENTER on N900 is CTRL+M
ENTER on normal kb is ENTER key.

HTH
Comment 14 Edheldil 2009-12-30 15:19:02 UTC
Nokia N900, Maemo 5 1.2009.42-11
ukeyboard: 2.1-0

The same problem with Enter is with locally installed vim (from Maemo repo),
but not with vi (default)

1) start X Terminal, start vim, pres 'i' to get to insert mode, press Enter: M
inserted before the cursor, new line after it

2) start X Terminal, start vi, press 'i', press Enter: new line correctly
inserted before the cursor

Both hardware and software keyboard exhibit the same behaviour.
Comment 15 David Ward 2009-12-30 15:28:20 UTC
Nokia N900, Maemo 5 1.2009.42-1

Local vim works as expected when pressing the enter key for me.
Comment 16 Vincent Lefevre 2010-01-16 02:18:50 UTC
I think the problem is that the <RTRN> key is defined in the rx-51 file as
KP_Enter (the observed behavior is correct with KP_Enter) instead of the usual
Return. I've tried to replace KP_Enter by Return, but this doesn't work: the
key is completely ignored.

Note: I think that the real fix would be to accept Return, otherwise this bug
could reappear in other terminals (e.g. compiled by users).
Comment 17 Marat Radchenko 2010-01-17 11:40:31 UTC
Bug still exists in 2.2009.51-1
Comment 18 Patrick Feliciano 2010-02-25 00:27:18 UTC
I can confirm that the bug still exists in 3.2010.02-8.002.

Also my xterm switches between 2 modes in which I experience one of 2 separate
problems.

1. The bug is as described here and "Enter" returns M in vim (or doesn't enter
at command lines in nested screen sessions ).

2. The enter works fine and the arrow keys fail to work in vim.

The 2 states are mutually exclusive and I can't determine what triggers the
change.

I'd like to bump the priority on this since I upgraded from the n810 to use
this as a tool for remote linux sysadmin work and reliable terminal access is
essential to that work.

I'll be comparing the rx-44 from my n810 and the rx-51 from the n900 to see if
I can glean anything.
Comment 19 Vincent Lefevre 2010-02-25 03:52:19 UTC
(In reply to comment #18)
> Also my xterm switches between 2 modes in which I experience one of 2 separate
> problems.

This is the notion of keyboard_transmit mode, a.k.a. "application mode" or
"application keypad mode".

> 1. The bug is as described here and "Enter" returns M in vim (or doesn't enter
> at command lines in nested screen sessions ).
> 
> 2. The enter works fine and the arrow keys fail to work in vim.

Yes, the Enter sends the wrong keycode only in application mode. And vim (like
most curses applications) probably expects application mode (which has the
effect to change some keycodes, in particular the arrow keys).

> The 2 states are mutually exclusive and I can't determine what triggers the
> change.

Vim probably switches to application mode with smkx (and disables it with rmkx
before exiting). But it may have an option to disable these sequences.

> I'd like to bump the priority on this since I upgraded from the n810 to use
> this as a tool for remote linux sysadmin work and reliable terminal access is
> essential to that work.

Yes, I find this bug very annoying too, and this is definitely not a minor bug.

> I'll be comparing the rx-44 from my n810 and the rx-51 from the n900 to see if
> I can glean anything.

Both have KP_Enter for the RTRN key.

I wonder whether a workaround is possible with a GDK/GTK related config file.
Comment 20 Lucas Maneos 2010-02-25 11:16:48 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > I'd like to bump the priority on this
> 
> Yes, I find this bug very annoying too, and this is definitely not a minor bug.

Agreed, according to the severity definitions ("easy workaround is NOT
present").

Also adding patch keyword according to comment 6 & comment 9.
Comment 21 Thomas Perl 2010-04-01 16:11:03 UTC
What's the status of this bug? It can be fixed by applying the patch as per
comment #9. Also, is "Utilities / X Terminal" the correct assignment, or is
there a better assignment for vte bugs? If so, please change the assignment.

I've also notified Gabriel Schulhof (worked on vte in 2009 as per
debian/changelog), Aapo Kojo (last entry in debian/changelog) and Santtu
Lakkala (maintainer in debian/control) with a link to this bug report.
Comment 22 Thomas Perl 2010-04-01 16:13:03 UTC
Created an attachment (id=2562) [details]
isolated patch based on comment 6 and comment 9

Here's the second chunk of the patch mentioned in comment 6, ready to be
applied to libvte. I've tested this patch on my device by applying the patch,
rebuilding the package and copying libvte4 over to my device - enter in screen
sessions work now for me.
Comment 23 Thomas Perl 2010-05-12 12:20:52 UTC
Created an attachment (id=2705) [details]
libvte4_0.16.14-0mh9.m5_armel.deb (patched build)

Binary package for libvte, created using these commands in Scratchbox (with
attachment 2562 [details]):

> apt-get source vte
> patch -p0 < /path/to/attachment2562 [details]
> cd vte-0.16.14/
> fakeroot apt-get build-dep vte
> dpkg-buildpackage -rfakeroot -b

The version number has not been changed so that an update to the real vte will
automatically overwrite this custom build.

I've ran this patched vte on my device now for several weeks without problems
(nearly daily usage of X Terminal), so I can't think of a reason why it
shouldn't be merged.
Comment 24 Thomas Perl 2010-05-12 12:26:36 UTC
Updating version field as per comment 18.
Comment 25 Jason Morawski 2010-08-21 04:13:55 UTC
I am unable to install the package. I get an error:

Unable to update 'libvte4'.
Incompatible application package.

(In reply to comment #23)
> Created an attachment (id=2705) [details] [details]
> libvte4_0.16.14-0mh9.m5_armel.deb (patched build)
> 
> Binary package for libvte, created using these commands in Scratchbox (with
> attachment 2562 [details] [details]):
> 
> > apt-get source vte
> > patch -p0 < /path/to/attachment2562 [details] [details]
> > cd vte-0.16.14/
> > fakeroot apt-get build-dep vte
> > dpkg-buildpackage -rfakeroot -b
> 
> The version number has not been changed so that an update to the real vte will
> automatically overwrite this custom build.
> 
> I've ran this patched vte on my device now for several weeks without problems
> (nearly daily usage of X Terminal), so I can't think of a reason why it
> shouldn't be merged.
>
Comment 26 Thomas Perl 2010-08-23 10:49:15 UTC
(In reply to comment #25)
> I am unable to install the package. I get an error:
> 
> Unable to update 'libvte4'.
> Incompatible application package.

You need to install it via the command line:

  sudo gainroot
  dpkg -i /path/to/libvte4*.deb

You cannot install such packages using H-A-M, as their section does not start
with 'user/'. Maybe in red pill mode, if you have to use the GUI.
Comment 27 Juergen Lock 2010-10-01 02:08:49 UTC
Just for the record, here is the workaround I came up with before I found this
ticket, maybe it's useful for someone:

xterm-n900,
        rmkx@, smkx@, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
use=xterm,

run that snippet thru "tic -o ~/.terminfo" (tic(1) is part of ncurses-base, I
did it on debian and copied ~/.terminfo/x/xterm-n900 over to the device but
maybe ncurses-base is in extras-devel too) - and then use TERM=xterm-n900 .  If
you are like me and sometimes ssh out from the device too then the target boxen
need that definition too of course, and if you have a box that ignores
~/.terminfo like some(?) BSDs do (and don't want to install a global definition
on there) then you can also set

TERMCAP='xterm-n900|N900
xterm:ks@:ke@:kl=\E[D:kd=\E[B:kr=\E[C:ku=\E[A:tc=xterm:'

- the only downside of that is screen(1) skips TERMCAP when setting up its
environment and thus it won't know xterm-n900 (probably because it sets its own
TERMCAP for its childs), so for that you'll need a special .screenrc with this
instead:

termcapinfo xterm ks@:ke@:kl=\E[D:kd=\E[B:kr=\E[C:ku=\E[A

..and set TERM back to xterm when starting screen.
Comment 28 Chris Nadovich 2010-10-17 21:28:21 UTC
I can also confirm the patched libvte from comment 25 seems to fix this bug and
otherwise works fine. Pity that the process for officially rolling out updates
for critical bugs like this seems to be buggy itself. Maybe the update is ready
to be published,,, if they only could figure out how to type ENTER.
Comment 29 Thomas Perl 2010-11-01 13:36:31 UTC
Still an issue in PR1.3 (updating version field).

The patch (attachment 2562 [details]) still applies, as vte hasn't changed in PR1.3.

CC'ing Gabriel (from the last non-automated entry in debian/changelog).

Gabriel: Do you know who can apply/integrate that patch into the "official" vte
package?
Comment 30 Andre Klapper maemo.org 2010-11-09 18:04:38 UTC
(In reply to comment #29)
> Gabriel: Do you know who can apply/integrate that patch into the "official" vte
> package?

CC'ing Mohammad.
Comment 31 Thomas Perl 2011-01-11 14:15:47 UTC
This patch is going into the Community SSU at
http://gitorious.org/community-ssu/vte
Comment 32 Andrew Flegg maemo.org 2011-01-29 23:51:41 UTC
Should this now be RESOLVED (and even VERIFIED, if possible) as the fix is
included in the Community SSU, as thp notes?

Suggested bug lifecycle:
  http://talk.maemo.org/showpost.php?p=923088&postcount=47

Commit:
 
http://gitorious.org/community-ssu/vte/commit/785b4b02d294b7ec165673d52db562d2ae0bbda3
Comment 33 Thomas Perl 2011-01-30 11:51:49 UTC
(In reply to comment #32)
> Should this now be RESOLVED (and even VERIFIED, if possible) as the fix is
> included in the Community SSU, as thp notes?
> 
> Suggested bug lifecycle:
>   http://talk.maemo.org/showpost.php?p=923088&postcount=47
> 
> Commit:
>  
> http://gitorious.org/community-ssu/vte/commit/785b4b02d294b7ec165673d52db562d2ae0bbda3

I'm marking this as RESOLVED/FIXED for now, as I just tested this with the
Community SSU installed from http://wiki.maemo.org/Community_SSU ("Testing"
link). Please feel free to update the status to VERIFIED.

Tested using X Terminal and a SSH connection to a remote screen session. Tested
with both "mutt" and "vim" inside screen - using the Enter key works as
expected, whereas before the update, only Ctrl+M worked as a workaround.
Comment 34 gregor herrmann 2011-01-30 19:10:41 UTC
(In reply to comment #33)
> I'm marking this as RESOLVED/FIXED for now, as I just tested this with the
> Community SSU installed from http://wiki.maemo.org/Community_SSU ("Testing"
> link). Please feel free to update the status to VERIFIED.

The version in community-ssu works for me, too; thanks!
Comment 35 ben 2011-01-31 15:52:00 UTC
it works for me too. thank you very much community!! :)))
Comment 36 Eero Tamminen nokia 2011-02-04 16:29:00 UTC
> I don't really understand why it is sending KP_Enter instead of just Return

At least in earlier Maemo versions virtual keyboards acted differently on
KP_Enter and on Return and that's why HW keyboard Enter might be mapped to
KP_Enter. It's not necessarily something XTerm is itself doing...