[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)



On May 21, 2016, at 3:05 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:

>> First observation is that the way I normally do installations on this machine (I keep it around for exactly this kind of testing, so I do a fair number of installations on it) is to run screen as a terminal emulator on a desktop machine that is connected to the Plug via a USB serial connection.  If I did that for this experiment, I’d wind up with screen running on the Plug inside of screen running on the Desktop and the thought of keeping track of all the levels of ctl-A gave me nightmares.
> 
> Indeed. It will be messed up if running screen inside screen.
> If you have any suggestion to avoid this, just let me know.
> 
>> So, I changed to using “cu” to run the USB serial connection.  That worked well enough.

This, or some other workaround, will have to be described in the documentation for the feature.  I suggest that it go in the release notes for the first official release to contain the feature.  A wiki page is probably also appropriate.


>> 
>> The installation proceeded smoothly while I experimented with the ctl-A <1-4> options.  It would have been nice to have the option of a more spacious work-area — larger than 24x80 — but that’s a minor issue.
> 
> I find this size of screen limitation, too.
> But I think this limitation is not introduced by GNU/screen, it exists before.

The kernel assumes that the default size of a serial console should be 24x80.  This probably goes back to the early days of video terminals with UNIX in the 1980s.

It is possible to change the assumed size of a serial console using the “stty” command with its “rows” and “columns” options.  Unfortunately doing so doesn’t inform “screen” of the new size — you have to do that yourself by resizing the terminal window it’s running in.

I can’t think of any way to automate that rather complicated process, so I guess the only sensible approach is to accept 24x80 as a given limitation and just live with it.  After all, who are we to argue with 30 years of history!  (-:

Enjoy!
Rick


Reply to: