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
