On 02/25/2014 07:18 PM, Laszlo Ersek wrote:
> On 02/26/14 01:05, Andrew Fish wrote:
>>
>> On Feb 25, 2014, at 2:04 PM, Laszlo Ersek <ler...@redhat.com
>> <mailto:ler...@redhat.com>> wrote:
>>
>>> The
>>>
>>> CSI Ps ; Ps ; Ps t
>>>
>>> escape sequence serves for window manipulation. We can use the
>>>
>>> CSI 8 ; <rows> ; <columns> t
>>>
>>> sequence to adapt eg. the xterm window size to the selected console mode.
>>>
>>> Reference: <http://rtfm.etla.org/xterm/ctlseq.html>
>>>
>>
>> Laszlo Xterm != PCANSI. So I’m don't think this is safe to do this you
>> have a real PCANSI terminal emulation running.
>>
>> There are a lot of similarities between VT100/PCANSI/VTUTF8 and xterm,
>> but they are not the same. So things can kind of seem like there
>> working, but they are not really 100% functional.
>>
>> From mucking about in the past I seem to remember:
>> 1) xterm (well at least the xterm-256 color, default for the Mac
>> Terminal.app) is UTF-8, For the output stuff you can mostly use VTUTF8Type.
>> 2) It is like VT100, but with differences.
>> INSERT/DELETE/END/PAGE_UP/PAGE_DOWN, and Function Keys,
>> 3) There are some different state machine constructs: ESC [ 1 * ~, ESC [
>> 2 * ~, ESC [ 3 * ~, needed for function keys > F4.
>> 4) You can add a GUIDed device path for the terminal emulation type.
>
> Yes, I figured it would be quite messy to armor this code from all
> sides. That's why I mentioned the PCD -- the default would be to disable
> this behavior, and the PCD could be set where people know for certain
> that PCANSI equals "xterm".
FWIW, SGI has put quite a bit of effort into modifying the Terminal
driver to support common xterm variants (gnome-terminal, konsole, Linux
framebuffer, x11r5 xterm, x11r6 xterm, etc.) As Andrew mentioned, there
are differences from PCANSI in various keyboard escape sequences.
There is also a subtle difference in EOL behavior: the stock Terminal
driver assumes that if the last character on a line is written, the
cursor immediately wraps to the beginning of the next line, scrolling
the screen if necessary. This makes it impossible to write the last
character on the screen: as soon as you write it, the cursor wraps and
the screen scrolls. Actual xterm-style emulators don't wrap the cursor
or scroll the screen until the first character on the new line is
written, avoiding the problem. However, it makes cursor position
tracking within the driver more challenging.
There are a number of cursor movement improvements which can be made as
well. Instead of sending a full X/Y cursor movement code on every
movement request, it's more efficient to send a shorter code when moving
within the same line or column. The most common case, especially when
entering text, is that no movement is necessary at all, since the cursor
is already at the desired location. Making these changes greatly
reduces the amount of escape code clutter sent by the terminal driver,
making the terminal interface more responsive, and more conducive to
logging of output.
I'd be willing to share the xterm support patches we're currently using.
They probably aren't suitable for inclusion in MdePkg as they stand,
but they would give a good starting point. I'd love to get good xterm
support upstream, so we don't need to carry the changes ourselves.
--
Brian Johnson
--------------------------------------------------------------------
"IP over ATM? You mean I can read my email from a cash machine?"
-- David Barr
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
