On Thu, May 14, 2015 at 12:31 PM, Kinney, Michael D
<michael.d.kin...@intel.com> wrote:
> Jiewen,
>
> I think most of the terminal emulators being discussed here layer on top of a
> TTY device.
>
> How about TtyTerm instead?
I think this is a more appropriate name.
Michael - I'll also try to address feedback on the new GUID going in
the wrong place, as the patchset
did grow larger than I expected it to be. If I understand correctly
the new GUID should just be present
in the TerminalDxe module.
I do want to try to keep the size of this change in check, as fixing backspace
for the problematic cases can be done with the following patch. Fixing delete
is slightly bigger, but if I create a completely separate terminal module it
will be 95+% directly copied from TerminalDxe. I have no further plans
beyond backspace/delete, so unless others want to extend this new terminal
I don't foresee more being done.
Thanks,
Roy
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
index 51492f3..70ec370 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
@@ -1561,8 +1561,14 @@ UnicodeToEfiKey (
}
if (UnicodeChar == DEL) {
- Key.ScanCode = SCAN_DELETE;
- Key.UnicodeChar = 0;
+ if (PcgGetBool(TerminalTreatAsciiDelAsBackspace) {^M
+ Key.ScanCode = SCAN_NULL;^M
+ Key.UnicodeChar = CHAR_BACKSPACE;^M
+ }^M
+ else {^M
+ Key.ScanCode = SCAN_DELETE;^M
+ Key.UnicodeChar = 0;^M
+ }^M
>
> Mike
>
> -----Original Message-----
> From: Yao, Jiewen
> Sent: Wednesday, May 13, 2015 7:13 PM
> To: Kinney, Michael D; edk2-devel@lists.sourceforge.net;
> linaro-u...@lists.linaro.org; Tian, Feng
> Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
>
> Definitely, I fully agree we should add new capability for terminal type to
> support more OS. It is question of "how", not "if". :-)
>
> Back to naming, I feel a little strange to use "Linux". Does it also work for
> other *nix system?
> I suggest we had better give a name for terminal type, instead of OS type.
>
> Mike or Andrew
> Do you have better suggestion on naming?
>
> Thank you
> Yao Jiewen
>
> -----Original Message-----
> From: Kinney, Michael D
> Sent: Thursday, May 14, 2015 9:23 AM
> To: Yao, Jiewen; edk2-devel@lists.sourceforge.net;
> linaro-u...@lists.linaro.org; Tian, Feng; Kinney, Michael D
> Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
>
> Jiewen,
>
> Adding more GUIDs is possible if there is no agreement between different
> terminal emulators. I recommend we allow the patch to be reviewed and
> encourage expanding the capabilities of this new terminal type as required to
> maximize compatibility.
>
> Mike
>
> -----Original Message-----
> From: Yao, Jiewen
> Sent: Wednesday, May 13, 2015 6:16 PM
> To: Kinney, Michael D; edk2-devel@lists.sourceforge.net;
> linaro-u...@lists.linaro.org; Tian, Feng
> Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
>
> OK. I also have interest to know how to handle below case mentioned by patch
> submitter :
> "I do not think that all Linux distributions agree on all the details, so my
> goal is to have a terminal defition that mostly works in many configurations."
>
> If one distribution think it should do A, other distribution think it should
> do B. Should we just keep adding new GUID type?
>
> Thank you
> Yao Jiewen
>
> -----Original Message-----
> From: Kinney, Michael D
> Sent: Thursday, May 14, 2015 9:12 AM
> To: Yao, Jiewen; edk2-devel@lists.sourceforge.net;
> linaro-u...@lists.linaro.org; Tian, Feng; Kinney, Michael D
> Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
>
> Jiewen,
>
> If there is a size concern, we can add Feature Flag PCDs to enable/disable
> support for different terminal types in the TerminalDxe driver.
>
> Since this new terminal type is very close to another terminal type that is
> already supported by TerminalDxe, the size impact of adding this new terminal
> type should be very small. Especially since the TerminalDxe driver is
> usually compressed.
>
> Thanks,
>
> Mike
>
> -----Original Message-----
> From: Yao, Jiewen
> Sent: Wednesday, May 13, 2015 5:59 PM
> To: edk2-devel@lists.sourceforge.net; linaro-u...@lists.linaro.org; Tian,
> Feng; Kinney, Michael D
> Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
>
> Or can we provide a standalone LinuxTerminalDxe driver?
>
> The original TerminalDxe handle the default types defined in UEFI spec.
> The new LinuxTerminalDxe can support the extension like this.
>
> That can also made code size small, if a platform BIOS decides to only
> support a subset of terminal types.
>
> Thank you
> Yao Jiewen
>
>
> -----Original Message-----
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, May 14, 2015 8:44 AM
> To: edk2-devel@lists.sourceforge.net; linaro-u...@lists.linaro.org; Tian,
> Feng; Kinney, Michael D
> Subject: Re: [edk2] [RFC 0/4] New terminal type for Linux
>
> Roy,
>
> The new GUID for this terminal type should not be defined in the MdePkg. The
> MdePkg is intended to only contain content from industry standard
> specifications.
>
> I recommend you add the GUID for this new terminal type to the MdeModulePkg
> so it is in the same package that contains the terminal driver that uses it.
>
> I think this means you should not modify PcAnsi.h in BaseTools or the
> EdkCompatibilityPkg.
>
> It also means that the UEFI Device Path Libs in the MdePkg cannot know about
> this GUID and will show the VenMedia() node with a GUID value.
>
> Hopefully with these changes, the patch set will be much smaller.
>
> Thanks,
>
> Mike
>
> -----Original Message-----
> From: Roy Franz [mailto:roy.fr...@linaro.org]
> Sent: Wednesday, May 13, 2015 4:54 PM
> To: edk2-devel@lists.sourceforge.net; linaro-u...@lists.linaro.org; Tian, Feng
> Subject: [edk2] [RFC 0/4] New terminal type for Linux
>
> This patchset is a follow on to my previous backspace patchse, and adds a new
> terminal type "LinuxTerm"
> (for lack of a better name) that better handles the typical Linux terminal
> (xterm/rxvt/gnome terminal/etc.) These often treat backspace/delete
> differently than the existing EDK2 terminal types expect, particularly in
> emulated environments where the emulated serial port is connected to a
> graphical terminal rather than a serial console.
> For a description of how Debian has dealt with the terminal
> backspace/delete/^H mess, see the "Keyboard configuration"
> section of:
>
> https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.8";>KeyboardConfiguration
>
> I do not think that all Linux distributions agree on all the details, so my
> goal is to have a terminal defition that mostly works in many configurations.
>
> Backspace being broken in these environments is the primary motivation for
> this, but this terminal type could be exentend to better support the typical
> graphical terminal now in use.
> This terminal type may be of use in BSD environments as well, so I'm open to
> more generic name suggestions. I deliberately avoided calling it "xterm", as
> my intention is to try to work with multiple terminal types to the degree
> possible.
>
>
>
> Roy Franz (4):
> Add "LinuxTerm" terminal type to TerminalDxe
> Treat ASCII 0x7F as backspace for LinuxTerm terminal
> accept [3~ as delete for LinuxTerm terminals
> Change QEMU terminal type to LinuxTerm
>
> .../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 4 +-
> BaseTools/Source/C/Include/Guid/PcAnsi.h | 6 +++
> .../Foundation/Efi/Guid/PcAnsi/PcAnsi.c | 2 +
> .../Foundation/Efi/Guid/PcAnsi/PcAnsi.h | 6 +++
> .../Universal/BdsDxe/BootMaint/BootMaint.h | 2 +-
> .../Universal/BdsDxe/BootMaint/Data.c | 5 ++-
> .../Universal/Console/TerminalDxe/Terminal.c | 44 ++++++++++++++++----
> .../Universal/Console/TerminalDxe/Terminal.h | 2 +
> .../Universal/Console/TerminalDxe/TerminalConIn.c | 47
> ++++++++++++++++++++-- .../Universal/Console/TerminalDxe/TerminalConOut.c |
> 2 + .../Universal/Console/TerminalDxe/TerminalDxe.inf | 1 +
> MdePkg/Include/Guid/PcAnsi.h | 6 +++
> MdePkg/Include/Protocol/DevicePath.h | 1 +
> .../Library/UefiDevicePathLib/DevicePathFromText.c | 27 +++++++++++++
> .../Library/UefiDevicePathLib/DevicePathToText.c | 3 ++
> .../UefiDevicePathLib/UefiDevicePathLib.inf | 2 +
> ...UefiDevicePathLibOptionalDevicePathProtocol.inf | 4 +-
> MdePkg/MdePkg.dec | 3 ++
> .../UefiHandleParsingLib/UefiHandleParsingLib.c | 1 +
> .../UefiHandleParsingLib/UefiHandleParsingLib.inf | 1 +
> 20 files changed, 153 insertions(+), 16 deletions(-)
>
> --
> 1.9.1
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications Performance
> metrics, stats and reports that give you Actionable Insights Deep dive
> visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications Performance
> metrics, stats and reports that give you Actionable Insights Deep dive
> visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
