Re: [Xen-users] xen console dimensions

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-06-24 at 07:28 -0400, Austin S Hemmelgarn wrote:
> On 2014-06-24 07:12, Ian Campbell wrote:
> > On Mon, 2014-06-23 at 14:52 -0400, Phillip Susi wrote:
> >> When I run xl console or xl create -c to connect to the console of the
> >> guest, /dev/hvc0 in the guest has unknown or default 80x25 dimensions
> >> rather than being informed of the dimensions of the terminal I run xl
> >> console from.  Is this something wrong with my configuration, or a
> >> currently unsupported feature of xen and/or the hvc driver?
> > 
> > hvc has essentially the same properties as a serial console (as in rs232
> > etc).
> > 
> > I think it is normal for such things to be unaware of the dimensions of
> > the terminal emulator window on the "host" side.
> > 
> > Ian.
> > 
> > 
> Even in those cases, it is still possible (in theory) to get the window
> dimensions by using ANSI escape sequences to try to set the cursor to
> the position 1000,1000, and then read back the actual position

How exciting! I had no idea...

>  (busybox
> uses this to determine terminal size for the apps that actually care
> about it, like vi and ls), but that trick doesn't seem to work correctly
> on /dev/hvc devices, regardless of what you set TERM to.
> Interestingly, the issues with this that I have only seem to affect
> terminal width, until I go into something screen/frame based like vi, at
> which point it clips the height as well.

The xenconsole binary (which is what xl console shells out to, see
tools/console/client/main.c for the source) is pretty dumb and AFAICT
doesn't speak any ANSI escape codes at all -- it appears to just forward
everything between the pty attached to the guest and it's std* file
descriptors. I suppose it relies on the terminal emulator which it is
running in to interpret them (which I guess makes sense).

You say it doesn't work whatever TERM= you use, does that extend to
setting TERM to whatever the containing terminal is using? It seems like
that should be the one case which ought to always work...

The only thing which xenconsole interprets itself is Control-] (0x1d)
which is used to exit the client. I think this is the same as telnet's
escape code so I suppose it is unlikely that it interferes.

TBH both xenconsle and terminal emulation are things which are mostly a
mystery to me. If someone who understood either (especially terminal
emulation side) wanted to dig in and figure out what is happening then
that would be awesome.

I suppose the other alternative is that the in guest kernel hvc driver
is interfering with escape codes somehow. That doesn't seem very likely
either though.

Ian.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users