> On May 13, 2015, at 6:15 PM, Yao, Jiewen <jiewen....@intel.com> wrote: > > 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? >
Maybe we can add some PCDs to configure preferences. Thanks, Andrew Fish > 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 ------------------------------------------------------------------------------ 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
