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 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. :-)

(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".

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.

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")?

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.

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.

I can confirm the ssh/vim issue. I have not used less yet.

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).

(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 2009-12-21 12:43:47 UTC

(In reply to comment #10)
> Maybe someone with access to the internal bug tracker

Done.

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.

(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

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.

Nokia N900, Maemo 5 1.2009.42-1

Local vim works as expected when pressing the enter key for me.

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).

Bug still exists in 2.2009.51-1

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.

(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.

(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.

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.

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.

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.

Updating version field as per comment 18.

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.
>

(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.

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.

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.

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 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.

This patch is going into the Community SSU at
http://gitorious.org/community-ssu/vte

Comment 32 Andrew Flegg 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

(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.

(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!

it works for me too. thank you very much community!! :)))

Comment 36 Eero Tamminen 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...