Rendering issues in MOSH (was: Working with ttyd but not mosh)

[vanrein]

TWIN works great in ttyd and really adds value there; for TWDM there was a need to add a one-shot option, as a resource is not freed otherwise. See PR #46 for details.

Since both TTYD and MOSH use xterm-256color displays, I expected TWIN to work well with MOSH too. But it does not!

To replicate:

mosh twin.host.with.mosh /path/to/twin_server 2>&1 | tee /tmp/twout

Spelling out the ANSI codes, this logs:

ESC[?1049hESC[?1hESC[?5lESC[1;25rESC[0mESC[HESC[2JESC[KESC[1;1HESC[K ESC[?25lESC[2;1HESC[KESC[2;1HESC[K ESC[3;1HESC[KESC[3;1HESC[K ESC[4;1HESC[KESC[4;1HESC[K 
ESC[5;1HESC[KESC[5;1HESC[K ESC[6;1HESC[KESC[6;1HESC[K ESC[7;1HESC[KESC[7;1HESC[K ESC[8;1HESC[KESC[8;1HESC[K ESC[9;1HESC[KESC[9;1HESC[K ESC[10;1HESC[KESC[10;1H
ESC[K ESC[11;1HESC[KESC[11;1HESC[K ESC[12;1HESC[KESC[12;1HESC[K ESC[13;1HESC[K
ESC[13;1HESC[K ESC[14;1HESC[KESC[14;1HESC[K ESC[15;1HESC[KESC[15;1HESC[K ESC[16;1HESC[KESC[16;1HESC[K ESC[17;1HESC[KESC[17;1HESC[K ESC[18;1HESC[KESC[18;1HESC[K ESC[19;1HESC[KESC[19;1HESC[K ESC[20;1HESC[KESC[20;1HESC[K ESC[21;1HESC[KESC[21;1HESC[K ESC[22;1HESC[KESC[22;1HESC[K ESC[23;1HESC[KESC[23;1HESC[K ESC[24;1HESC[K
ESC[24;1HESC[K ESC[25;1HESC[KESC[1;1HESC[?25hESC[0mESC[?2004lESC[?1003lESC[?1002lESC[?1001lESC[?1000lESC[?1004lESC[?1015lESC[?1006lESC[?1005lESC[?25lESC[2;1Htwin: starting display driver module `hw_tty'...ESC[3;1H      linux_InitVideo() failed: terminal `xterm-256color' is not `linux'.ESC[4;1Htwin: ...module `hw_tty' failed to start.ESC[5;1Htwin: all display drivers failed for `-hw=tty'ESC[7;1Htwin:  ESC[0;1mALL  DISPLAY  DRIVERS  FAILED.  QUITTING.ESC[8;1HESC[?25hESC[0mESC[?1lESC[0mESC[?25hESC[?1003lESC[?1002lESC[?1001lESC[?1000lESC[?1015lESC[?1006lESC[?1005lESC[?1049l
[mosh is exiting.]

in readable terms, that's

twin: starting display driver module `hw_tty'...
      linux_InitVideo() failed: terminal `xterm-256color' is not `linux'
twin: ...module `hw_tty' failed to start
twin: all display drivers failed for `-hw=tty'
twin:  ALL  DISPLAY  DRIVERS  FAILED.  QUITTING.
[mosh is exiting.]

My suspicion is that something makes TWIN think that MOSH is like a Linux environment, in spite of having TERM=xterm-256color set, and then bogs down to refusal because it is not actually TERM=linux compliant.

Note: Fixing this would mean that TWIN can be used virtually anywhere, even on Mac OS X with iTerm.app, which is why I am chasing this. It also seems like MOSH and TWIN are a marriage made in heaven -- just think of train rides with "graphical" interactivity as a big thank you to the textual nature of the display!

[tallship]

Thank you for chasing this down and your diligence in finding a resolution for this issue @vanrein - it is much appreciated. Twin deserves to be relevant as the awesome window manager that it is, and MOSH support is kinda really sorta very important.

[vanrein]

OK, there is one difference.

Both MOSH and TTYD use TERM=xterm-256color and tty prints /dev/pts/123. Both err on linux_InitVideo() failed: terminal "xterm-256color" is not linux but the difference is:

TTYD continues to report GPM_InitMouse() failed: terminal /dev/pts/123 and is not a local linux console and lrawkbd_InitKeyboard() error: tty is not a Linux console: ioctl(KDGKBMOD) failed! and then, surprisingly, concludes twin: ...module "hw_tty" successfully started.

Without the GPM failure, the hw_tty fails more seriously? Does not try an alternative strategy meant for X-terminals? And so does not recognise xterm-256color?

[vanrein]

It would seem that xterm_InitMouse() can work on xterm-256color. Its code in mouse_xterm.h uses !strncmp(term, "xterm", 5) which would match. And that is how TTYD works, as far as I can tell, because hw_tty.c tries xterm_InitMouse(...) right after it failed to do GPM_InitMouse() or skipped it. Since both fail loudly, the missing occurrence of GPM_InitMouse() errors with MOSH suggest it either succeeds or never gets there.

Tried MOSH without GPM running, same output.

Conclusion: Things fail on MOSH before GPM_InitMouse() is tried... so all of vcsa_InitVideo(), linux_InitVideo() [which is shown] and termcap_InitVideo() are either failing or not even tried. And, because it fails loudly, it must not even be tried. That would be subject to undefined CONF_HW_TTY_TERMCAP or the preceding condition TRY_V(termcap) evaluating to 0.

And then the code gets really confusing...

[vanrein]

My include/twconfig.h says #undef CONF_HW_TTY_TERMCAP on the host where I tried MOSH without luck, which explains the problem, because it says #define CONF_HW_TTY_TERMCAP on the host where I tried TTYD with better luck.

The difference was in the install base, not in TWIN.

Reconfigured (which the instructions say should not ever be a problem, ahem) and rebuilt. Now it does not error anymore like it did. (It shows no output, but that might be a local terminal problem.)

Sorry for the uproar -- well, sort of -- the relations were not very clear.

[vanrein]

I got TWIN working in MOSH, but I may be the first, as I'm encountering rendering trouble:

The brown colour is how my terminals normally look in the surrounding terminal. And black is probably the default assumed by TWIN. When I move windows around, with or without shadows, parts are overwritten, when they are thought to have changed; this sounds typical of MOSH.

I could not find a way to ask an xterm for its current colour, and the brown colour I use is 4a3407 -- a custom setting in iTerm.app so it may be required to change this. I am however surprised that the colour is not reset, or otherwise communicated to be dynamic all the way through. (If it is reset, I have a preference, of course.)

This is a rendering bug, but I am not sure where in the chain TWTERM -- TWIN -- MOSH -- ITERM the cause lies. I never encountered it before, however, not with MOSH -- ITERM at least.

[vanrein]

Colour information does seem to be available, according to the xterm documentation, which states

Set Text Parameters. For colors and font, if P t is a "?", the control sequence elicits a response which consists of the control sequence which would set the corresponding value.

The list of parameters for "dynamic" colours does indeed match; the documentation says, among others,

P s = 1 0 → Change VT100 text foreground color to P t 
P s = 1 1 → Change VT100 text background color to P t 
P s = 1 2 → Change text cursor color to P t 

and the iTerm.app colour configuration contains at least these few

I cannot seem to get the query output from the iTerm.app though, not locally, but being able to set these values in TWTERM again could also work. They are currently overridden by a default AFAIK.

[tallship]

I'm looking forward to @cosmos72 (Max) effecting another official release once you get these issues finally ironed out, and then I'll package it up and push it to the package repo so it's available.

There's also (if it's still there) an undocumented, from what I remember, batch file feature called 'twstart'. I'll look around further to see if I can find any docs on it, as I seem to recall that I only came to know of it through the very old documentation years ago in the sourceforge repo.

Maybe I should work on the docs and issue a PR after adding in coverage of that (If it's still there). But that's a completely separate matter.

[vanrein]

Hi Bradley, I've been successful running TWIN over MOSH yesterday, with good results. The only quirks were: * I had to use a black TTY background (a bit less restful, but it saves me from chasing Esc codes) * Editing during connection delays, MOSH replaces lines in the VI window + all to its right * Copy paste does not work * Much longer battery life than under Mac OS X ;-) Copy-paste is really a stumbling block IMHO. It does not work, but outside of MOSH I've seen it work but then it fills lines up with spaces, rather than noticing each end-of-line. I wonder if not working at all relates to MOSH, but since it's all done server-side I imagine not.

Maybe I should work on the docs and issue a PR after adding in coverage of that (If it's still there). But that's a completely separate matter.

I've also been wondering to work on documentation a bit. Still learning, but I've been missing it bigtime. No idea how detach works, and display recurses on itself, so I'm probably missing out on powerful possibilities. There might be an interesting combination between MOSH and TWIN detach too. Been wondering if/how this integrates with screen and tmux, for which TWIN feels like a graphical alternative. Another angle where I feel some interest is to look into TWDM and see if I can subtitute a SASL-based alternative for remote access. There's no mailing list for TWIN, right? That's where this stuff would normally go :-)

…

-Rick

[tallship]

Twin has always worked well for me with tmux, I'll typically ssh into a box and then do a tmux attach in the remote session, although there are little display idiosyncrasies, throughout.

There is a mailing list, yet I haven't received anything from it since 2012:
https://sourceforge.net/p/twin/mailman/twin-develop/?viewmonth=201202

Max's email addy is easy to discern from that page, and I think it's still current, although I haven't had any direct exchanges with him for years.

I do believe that he attempted to explain detaching and setting displays ala X-Windows style to me there, but I was confused too, so haven't been able to take advantage of those additional powerful features. If you don't see it, then I'll look in my own email archives to see if I can't find it, or the website he bundled up for me back then. He does commit bugfixes here occasionally.

I would still be glad to donate a domain and host a site for Twin, but it might be just as well to do the hosting here on GitHub.

I did a write up a few years back, although it's pretty dated at this point:
http://northtech.us/content/20110311/adding-convenient-layers-persistent-abstraction-simplify-remote-administration

Somewhere way back I did a HowTo for Twin on CentOS, not sure if that's even relevant anymore.

And FWIW, there is this kewl PR: #5

[cosmos72]

Hi @tallship, hi @vanrein,
thanks for trying to get twin running inside MOSH!

Let me try and answer your questions and doubts:

• Yes, the mailing list is still https://sourceforge.net/p/twin/mailman/twin-develop/ although it has not seen any use in a long time. You can use it, and I should still be able to receive it.
• Thanks for the offer, but hosting twin on github seems to suffice at the moment
• Twin currently assumes black background, and as you both point out xterm escape sequences contain a way to set the background color, but they seem to lack a way to query it. Maybe it can be worked around by implementing an option to manually specify the background color when twin attaches to a terminal, i.e. something like --hw=tty@bg=...
• Copy-paste can be tricky in some configurations. I should have a look at it inside MOSH - which I admit I never used. In any case, if you copy-paste multiple lines, twin pastes spaces instead of CR or NL after the end of each line - that's a known limitation
• twstart is a simple script that tries to detect an already running twin server and attach to it. If it fails, it starts a new twin server.
• as you probably guessed #define CONF_HW_TTY_TERMCAP i.e. generic termcap/terminfo/ncurses terminal support, is enabled only if the library libtinfo-dev or libncurses-dev is available when running ./configure. Otherwise generic terminal support is disabled, and twin will only support linux terminals (i.e. the Linux console and itself)
• Twin should support xterm-style mouse just fine. As you point out, xterm_InitMouse() does exactly that, and it can work on xterm-256color.

P.S. if you want to contribute, you're welcome! Documentation and fixes are surely appreciated :)