Re: [Xen-users] xen console dimensions

[Austin S Hemmelgarn <ahferroin7@xxxxxxxxx>]

On 2014-06-24 07:42, Ian Campbell wrote:
> 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...
Even when I set TERM to match what the terminal emulator sets itself,
things don't work.  However, other things that depend on ANSI escape
sequences working correctly (like colors and frames) work correctly
under this case.
> 
> 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.
This should only be interpreted on input though, and only if the actual
input is made using the control key and ].  This is particularly
important because a lot of programs use the escape key (which in the
ASCII character set is represented by 0x1d), and the standard control
sequence initiator is Control-] followed by ].
> 
> 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.
Based on the fact that control sequences work correctly, I think that
the guest side is probably limiting the terminal width by default.  I
hadn't thought to test this before, but I wonder if the command 'resize'
works correctly?  IIRC the hvc devices are treated just like VT's under
Linux and NetBSD, and on both platforms the default when they can't get
information about the attached device is to set the terminal width to 80
columns.  I'll look into this and report back.
> 
> Ian.
> 
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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