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%22%3EKeyboardC...
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(-)
This patch adds new terminal type, LinuxTerm, to TerminalDxe. This terminal type provides a place to add support for various Linux terminals that don't behave like standard VT terminals.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0 --- 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 | 1 + .../Universal/Console/TerminalDxe/TerminalConIn.c | 4 +- .../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 + 19 files changed, 109 insertions(+), 12 deletions(-)
diff --git a/BaseTools/Source/C/Include/Guid/PcAnsi.h b/BaseTools/Source/C/Include/Guid/PcAnsi.h index 9f12ca2..188a9b1 100644 --- a/BaseTools/Source/C/Include/Guid/PcAnsi.h +++ b/BaseTools/Source/C/Include/Guid/PcAnsi.h @@ -38,6 +38,11 @@ 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88 } \ }
+#define EFI_LINUX_TERM_GUID \ + { \ + 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \ + } + #define EFI_UART_DEVICE_PATH_GUID \ { \ 0x37499a9d, 0x542f, 0x4c89, {0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 } \ @@ -52,6 +57,7 @@ extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid; extern EFI_GUID gEfiUartDevicePathGuid; extern EFI_GUID gEfiSasDevicePathGuid;
diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c index 1f184e6..c6852b1 100644 --- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c +++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c @@ -27,8 +27,10 @@ EFI_GUID gEfiPcAnsiGuid = EFI_PC_ANSI_GUID; EFI_GUID gEfiVT100Guid = EFI_VT_100_GUID; EFI_GUID gEfiVT100PlusGuid = EFI_VT_100_PLUS_GUID; EFI_GUID gEfiVTUTF8Guid = EFI_VT_UTF8_GUID; +EFI_GUID gEfiLinuxTermGuid = EFI_LINUX_TERM_GUID;
EFI_GUID_STRING(&gEfiPcAnsiGuid, "Efi", "Efi PC ANSI Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVT100Guid, "Efi", "Efi VT100 Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVT100PlusGuid, "Efi", "Efi VT100Plus Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVTUTF8Guid, "Efi", "Efi VTUTF8 Device Path Vendor GUID") +EFI_GUID_STRING(&gEfiLinuxTermGuid, "Efi", "Efi Linux Terminal Device Path Vendor GUID") diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h index 7181020..9461a35 100644 --- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h +++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h @@ -42,9 +42,15 @@ Abstract: 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88} \ }
+#define EFI_LINUX_TERM_GUID \ + { \ + 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \ + } + extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid;
#endif diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h index 098692f..bfa9b63 100644 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h @@ -1657,7 +1657,7 @@ extern COM_ATTR BaudRateList[19]; extern COM_ATTR DataBitsList[4]; extern COM_ATTR ParityList[5]; extern COM_ATTR StopBitsList[3]; -extern EFI_GUID TerminalTypeGuid[4]; +extern EFI_GUID TerminalTypeGuid[5]; extern STRING_DEPOSITORY *FileOptionStrDepository; extern STRING_DEPOSITORY *ConsoleOptionStrDepository; extern STRING_DEPOSITORY *BootOptionStrDepository; diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c index 0a3ffbc..3f22efa 100644 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c @@ -324,9 +324,10 @@ COM_ATTR StopBitsList[3] = { /// /// Guid for messaging path, used in Serial port setting. /// -EFI_GUID TerminalTypeGuid[4] = { +EFI_GUID TerminalTypeGuid[5] = { DEVICE_PATH_MESSAGING_PC_ANSI, DEVICE_PATH_MESSAGING_VT_100, DEVICE_PATH_MESSAGING_VT_100_PLUS, - DEVICE_PATH_MESSAGING_VT_UTF8 + DEVICE_PATH_MESSAGING_VT_UTF8, + DEVICE_PATH_MESSAGING_LINUX_TERM }; diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c index 966fb79..3371dcc 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c @@ -33,7 +33,8 @@ EFI_GUID *gTerminalType[] = { &gEfiPcAnsiGuid, &gEfiVT100Guid, &gEfiVT100PlusGuid, - &gEfiVTUTF8Guid + &gEfiVTUTF8Guid, + &gEfiLinuxTermGuid };
@@ -152,12 +153,13 @@ TerminalDriverBindingSupported (
} // - // only supports PC ANSI, VT100, VT100+ and VT-UTF8 terminal types + // only supports PC ANSI, VT100, VT100+, VT-UTF8, and Linux terminal types // if (!CompareGuid (&Node->Guid, &gEfiPcAnsiGuid) && !CompareGuid (&Node->Guid, &gEfiVT100Guid) && !CompareGuid (&Node->Guid, &gEfiVT100PlusGuid) && - !CompareGuid (&Node->Guid, &gEfiVTUTF8Guid)) { + !CompareGuid (&Node->Guid, &gEfiVTUTF8Guid) && + !CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) {
return EFI_UNSUPPORTED; } @@ -275,6 +277,10 @@ BuildTerminalDevpath (
TerminalType = VTUTF8TYPE;
+ } else if (CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) { + + TerminalType = LINUXTERMTYPE; + } else { return NULL; } @@ -708,9 +714,9 @@ TerminalDriverBindingStart (
TerminalType = PcdGet8 (PcdDefaultTerminalType); // - // Must be between PCANSITYPE (0) and VTUTF8TYPE (3) + // Must be between PCANSITYPE (0) and LINUXTERMTYPE (4) // - ASSERT (TerminalType <= VTUTF8TYPE); + ASSERT (TerminalType <= LINUXTERMTYPE);
CopyMem (&DefaultNode->Guid, gTerminalType[TerminalType], sizeof (EFI_GUID)); RemainingDevicePath = (EFI_DEVICE_PATH_PROTOCOL *) DefaultNode; @@ -728,6 +734,8 @@ TerminalDriverBindingStart ( TerminalType = VT100PLUSTYPE; } else if (CompareGuid (&Node->Guid, &gEfiVTUTF8Guid)) { TerminalType = VTUTF8TYPE; + } else if (CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) { + TerminalType = LINUXTERMTYPE; } else { goto Error; } @@ -926,6 +934,24 @@ TerminalDriverBindingStart ( );
break; + + case LINUXTERMTYPE: + AddUnicodeString2 ( + "eng", + gTerminalComponentName.SupportedLanguages, + &TerminalDevice->ControllerNameTable, + (CHAR16 *)L"Linux Terminal Serial Console", + TRUE + ); + AddUnicodeString2 ( + "en", + gTerminalComponentName2.SupportedLanguages, + &TerminalDevice->ControllerNameTable, + (CHAR16 *)L"Linux Terminal Serial Console", + FALSE + ); + + break; }
// @@ -1441,7 +1467,7 @@ TerminalUpdateConsoleDevVariable ( // // Append terminal device path onto the variable. // - for (TerminalType = PCANSITYPE; TerminalType <= VTUTF8TYPE; TerminalType++) { + for (TerminalType = PCANSITYPE; TerminalType <= LINUXTERMTYPE; TerminalType++) { SetTerminalDevicePath (TerminalType, ParentDevicePath, &TempDevicePath); NewVariable = AppendDevicePathInstance (Variable, TempDevicePath); ASSERT (NewVariable != NULL); @@ -1554,7 +1580,7 @@ TerminalRemoveConsoleDevVariable ( // Loop through all the terminal types that this driver supports // Match = FALSE; - for (TerminalType = PCANSITYPE; TerminalType <= VTUTF8TYPE; TerminalType++) { + for (TerminalType = PCANSITYPE; TerminalType <= LINUXTERMTYPE; TerminalType++) {
SetTerminalDevicePath (TerminalType, ParentDevicePath, &TempDevicePath);
@@ -1658,6 +1684,10 @@ SetTerminalDevicePath ( CopyGuid (&Node.Guid, &gEfiVTUTF8Guid); break;
+ case LINUXTERMTYPE: + CopyGuid (&Node.Guid, &gEfiLinuxTermGuid); + break; + default: return EFI_UNSUPPORTED; } diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h index d393acb..e0335db 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h @@ -136,6 +136,7 @@ typedef union { #define VT100TYPE 1 #define VT100PLUSTYPE 2 #define VTUTF8TYPE 3 +#define LINUXTERMTYPE 4
#define LEFTOPENBRACKET 0x5b // '[' #define ACAP 0x41 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c index 4a008c9..51492f3 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c @@ -454,6 +454,7 @@ TranslateRawDataToEfiKey ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE: + case LINUXTERMTYPE: AnsiRawDataToUnicode (TerminalDevice); UnicodeToEfiKey (TerminalDevice); break; @@ -1393,7 +1394,8 @@ UnicodeToEfiKey ( if (TerminalDevice->TerminalType == PCANSITYPE || TerminalDevice->TerminalType == VT100TYPE || TerminalDevice->TerminalType == VT100PLUSTYPE || - TerminalDevice->TerminalType == VTUTF8TYPE) { + TerminalDevice->TerminalType == VTUTF8TYPE || + TerminalDevice->TerminalType == LINUXTERMTYPE) { switch (UnicodeChar) { case 'A': Key.ScanCode = SCAN_UP; diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c index affb3ae..868a014 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c @@ -223,6 +223,7 @@ TerminalConOutOutputString ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE: + case LINUXTERMTYPE:
if (!TerminalIsValidTextGraphics (*WString, &GraphicChar, &AsciiChar)) { // @@ -371,6 +372,7 @@ TerminalConOutTestString ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE: + case LINUXTERMTYPE: Status = AnsiTestString (TerminalDevice, WString); break;
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf index 1d86388..7c6e3d3 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf @@ -73,6 +73,7 @@ gEfiVT100Guid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEfiVT100PlusGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path + gEfiLinuxTermGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEdkiiStatusCodeDataTypeVariableGuid ## SOMETIMES_CONSUMES ## GUID
[Protocols] diff --git a/MdePkg/Include/Guid/PcAnsi.h b/MdePkg/Include/Guid/PcAnsi.h index e576fd3..61759f8 100644 --- a/MdePkg/Include/Guid/PcAnsi.h +++ b/MdePkg/Include/Guid/PcAnsi.h @@ -38,6 +38,11 @@ 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88 } \ }
+#define EFI_LINUX_TERM_GUID \ + { \ + 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \ + } + #define DEVICE_PATH_MESSAGING_UART_FLOW_CONTROL \ { \ 0x37499a9d, 0x542f, 0x4c89, {0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 } \ @@ -52,6 +57,7 @@ extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid; extern EFI_GUID gEfiUartDevicePathGuid; extern EFI_GUID gEfiSasDevicePathGuid;
diff --git a/MdePkg/Include/Protocol/DevicePath.h b/MdePkg/Include/Protocol/DevicePath.h index 7cf7113..a718bd4 100644 --- a/MdePkg/Include/Protocol/DevicePath.h +++ b/MdePkg/Include/Protocol/DevicePath.h @@ -706,6 +706,7 @@ typedef VENDOR_DEVICE_PATH VENDOR_DEFINED_DEVICE_PATH; #define DEVICE_PATH_MESSAGING_VT_100 EFI_VT_100_GUID #define DEVICE_PATH_MESSAGING_VT_100_PLUS EFI_VT_100_PLUS_GUID #define DEVICE_PATH_MESSAGING_VT_UTF8 EFI_VT_UTF8_GUID +#define DEVICE_PATH_MESSAGING_LINUX_TERM EFI_LINUX_TERM_GUID
/// /// A new device path node is defined to declare flow control characteristics. diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c index 6ec0a4c..f473b39 100644 --- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c @@ -1545,6 +1545,32 @@ DevPathFromTextVenUtf8 ( }
/** + Converts a text device path node to Vendor defined Linux terminal device + path structure. + + @param TextDeviceNode The input Text device path node. + + @return A pointer to the newly-created Vendor defined Linux terminal + device path structure. + +**/ +EFI_DEVICE_PATH_PROTOCOL * +DevPathFromTextVenLinuxTerm ( + IN CHAR16 *TextDeviceNode + ) +{ + VENDOR_DEVICE_PATH *Vendor; + + Vendor = (VENDOR_DEVICE_PATH *) CreateDeviceNode ( + MESSAGING_DEVICE_PATH, + MSG_VENDOR_DP, + (UINT16) sizeof (VENDOR_DEVICE_PATH)); + CopyGuid (&Vendor->Guid, &gEfiLinuxTermGuid); + + return (EFI_DEVICE_PATH_PROTOCOL *) Vendor; +} + +/** Converts a text device path node to UART Flow Control device path structure.
@param TextDeviceNode The input Text device path node. @@ -3075,6 +3101,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED DEVICE_PATH_FROM_TEXT_TABLE mUefiDevicePathLibDevP {L"VenVt100", DevPathFromTextVenVt100 }, {L"VenVt100Plus", DevPathFromTextVenVt100Plus }, {L"VenUtf8", DevPathFromTextVenUtf8 }, + {L"VenLinuxTerm", DevPathFromTextVenLinuxTerm }, {L"UartFlowCtrl", DevPathFromTextUartFlowCtrl }, {L"SAS", DevPathFromTextSAS }, {L"SasEx", DevPathFromTextSasEx }, diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c index 0300019..f7df807 100644 --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c @@ -194,6 +194,9 @@ DevPathToTextVendor ( } else if (CompareGuid (&Vendor->Guid, &gEfiVTUTF8Guid)) { UefiDevicePathLibCatPrint (Str, L"VenUft8()"); return ; + } else if (CompareGuid (&Vendor->Guid, &gEfiLinuxTermGuid)) { + UefiDevicePathLibCatPrint (Str, L"VenLinuxTerm()"); + return ; } else if (CompareGuid (&Vendor->Guid, &gEfiUartDevicePathGuid)) { FlowControlMap = (((UART_FLOW_CONTROL_DEVICE_PATH *) Vendor)->FlowControlMap); switch (FlowControlMap & 0x00000003) { diff --git a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf index f4ae91f..a1bad14 100644 --- a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf +++ b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf @@ -58,6 +58,8 @@ ## SOMETIMES_CONSUMES ## GUID gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID + gEfiLinuxTermGuid + ## SOMETIMES_CONSUMES ## GUID gEfiUartDevicePathGuid ## SOMETIMES_CONSUMES ## GUID gEfiSasDevicePathGuid diff --git a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf index 943ba2d..b529400 100644 --- a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf +++ b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf @@ -62,6 +62,8 @@ ## SOMETIMES_CONSUMES ## GUID gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID + gEfiLinuxTermGuid + ## SOMETIMES_CONSUMES ## GUID gEfiUartDevicePathGuid ## SOMETIMES_CONSUMES ## GUID gEfiSasDevicePathGuid @@ -78,4 +80,4 @@
[Depex.common.DXE_DRIVER, Depex.common.DXE_RUNTIME_DRIVER, Depex.common.DXE_SAL_DRIVER, Depex.common.DXE_SMM_DRIVER] gEfiDevicePathUtilitiesProtocolGuid - \ No newline at end of file + diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index f9c9d5f..b1b0038 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -269,6 +269,9 @@ gEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0, 0x73, 0xD0, 0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
## Include/Guid/PcAnsi.h + gEfiLinuxTermGuid = { 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 }} + + ## Include/Guid/PcAnsi.h gEfiUartDevicePathGuid = { 0x37499a9d, 0x542f, 0x4c89, { 0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 }}
## Include/Guid/PcAnsi.h diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c index 9a2daa9..9baaed7 100644 --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c @@ -848,6 +848,7 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringList[] = { {STRING_TOKEN(STR_DEVICE_PATH_VT100), &gEfiVT100Guid, NULL}, {STRING_TOKEN(STR_DEVICE_PATH_VT100P), &gEfiVT100PlusGuid, NULL}, {STRING_TOKEN(STR_DEVICE_PATH_VTUTF8), &gEfiVTUTF8Guid, NULL}, + {STRING_TOKEN(STR_DEVICE_PATH_LINUXTERM), &gEfiLinuxTermGuid, NULL}, {STRING_TOKEN(STR_DRIVER_BINDING), &gEfiDriverBindingProtocolGuid, NULL}, {STRING_TOKEN(STR_PLATFORM_OVERRIDE), &gEfiPlatformDriverOverrideProtocolGuid, NULL}, {STRING_TOKEN(STR_BUS_OVERRIDE), &gEfiBusSpecificDriverOverrideProtocolGuid, NULL}, diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf index c95f41b..716dbd7 100644 --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf @@ -181,6 +181,7 @@ gEfiVT100Guid ##UNDEFINED gEfiVT100PlusGuid ##UNDEFINED gEfiVTUTF8Guid ##UNDEFINED + gEfiLinuxTermGuid ##UNDEFINED gEfiStandardErrorDeviceGuid ##UNDEFINED gEfiConsoleInDeviceGuid ##UNDEFINED gEfiConsoleOutDeviceGuid ##UNDEFINED
On 2015-05-13 16:53:58, Roy Franz wrote:
This patch adds new terminal type, LinuxTerm, to TerminalDxe. This terminal type provides a place to add support for various Linux terminals that don't behave like standard VT terminals.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0
BaseTools/Source/C/Include/Guid/PcAnsi.h | 6 +++
I think it best to avoid modifying multiple packages in a single commit.
For one thing, you should provide a subject prefix, and usually this should include the package being updated.
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
Yet, I think updating all PcAnsi.h files in a separate, single commit might be okay here. (Although, it seems like only the MdePkg one is used by this patch, and even that looks like it will need to move since it is not in the spec. So, maybe no PcAnsi.h files will be modified now?)
-Jordan
.../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 | 1 + .../Universal/Console/TerminalDxe/TerminalConIn.c | 4 +- .../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 + 19 files changed, 109 insertions(+), 12 deletions(-)
diff --git a/BaseTools/Source/C/Include/Guid/PcAnsi.h b/BaseTools/Source/C/Include/Guid/PcAnsi.h index 9f12ca2..188a9b1 100644 --- a/BaseTools/Source/C/Include/Guid/PcAnsi.h +++ b/BaseTools/Source/C/Include/Guid/PcAnsi.h @@ -38,6 +38,11 @@ 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88 } \ } +#define EFI_LINUX_TERM_GUID \
- { \
- 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \
- }
#define EFI_UART_DEVICE_PATH_GUID \ { \ 0x37499a9d, 0x542f, 0x4c89, {0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 } \ @@ -52,6 +57,7 @@ extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid; extern EFI_GUID gEfiUartDevicePathGuid; extern EFI_GUID gEfiSasDevicePathGuid; diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c index 1f184e6..c6852b1 100644 --- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c +++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.c @@ -27,8 +27,10 @@ EFI_GUID gEfiPcAnsiGuid = EFI_PC_ANSI_GUID; EFI_GUID gEfiVT100Guid = EFI_VT_100_GUID; EFI_GUID gEfiVT100PlusGuid = EFI_VT_100_PLUS_GUID; EFI_GUID gEfiVTUTF8Guid = EFI_VT_UTF8_GUID; +EFI_GUID gEfiLinuxTermGuid = EFI_LINUX_TERM_GUID; EFI_GUID_STRING(&gEfiPcAnsiGuid, "Efi", "Efi PC ANSI Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVT100Guid, "Efi", "Efi VT100 Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVT100PlusGuid, "Efi", "Efi VT100Plus Device Path Vendor GUID") EFI_GUID_STRING(&gEfiVTUTF8Guid, "Efi", "Efi VTUTF8 Device Path Vendor GUID") +EFI_GUID_STRING(&gEfiLinuxTermGuid, "Efi", "Efi Linux Terminal Device Path Vendor GUID") diff --git a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h index 7181020..9461a35 100644 --- a/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h +++ b/EdkCompatibilityPkg/Foundation/Efi/Guid/PcAnsi/PcAnsi.h @@ -42,9 +42,15 @@ Abstract: 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88} \ } +#define EFI_LINUX_TERM_GUID \
- { \
- 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \
- }
extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid; #endif diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h index 098692f..bfa9b63 100644 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/BootMaint.h @@ -1657,7 +1657,7 @@ extern COM_ATTR BaudRateList[19]; extern COM_ATTR DataBitsList[4]; extern COM_ATTR ParityList[5]; extern COM_ATTR StopBitsList[3]; -extern EFI_GUID TerminalTypeGuid[4]; +extern EFI_GUID TerminalTypeGuid[5]; extern STRING_DEPOSITORY *FileOptionStrDepository; extern STRING_DEPOSITORY *ConsoleOptionStrDepository; extern STRING_DEPOSITORY *BootOptionStrDepository; diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c index 0a3ffbc..3f22efa 100644 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Data.c @@ -324,9 +324,10 @@ COM_ATTR StopBitsList[3] = { /// /// Guid for messaging path, used in Serial port setting. /// -EFI_GUID TerminalTypeGuid[4] = { +EFI_GUID TerminalTypeGuid[5] = { DEVICE_PATH_MESSAGING_PC_ANSI, DEVICE_PATH_MESSAGING_VT_100, DEVICE_PATH_MESSAGING_VT_100_PLUS,
- DEVICE_PATH_MESSAGING_VT_UTF8
- DEVICE_PATH_MESSAGING_VT_UTF8,
- DEVICE_PATH_MESSAGING_LINUX_TERM
}; diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c index 966fb79..3371dcc 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c @@ -33,7 +33,8 @@ EFI_GUID *gTerminalType[] = { &gEfiPcAnsiGuid, &gEfiVT100Guid, &gEfiVT100PlusGuid,
- &gEfiVTUTF8Guid
- &gEfiVTUTF8Guid,
- &gEfiLinuxTermGuid
}; @@ -152,12 +153,13 @@ TerminalDriverBindingSupported ( } //
// only supports PC ANSI, VT100, VT100+ and VT-UTF8 terminal types
// only supports PC ANSI, VT100, VT100+, VT-UTF8, and Linux terminal types // if (!CompareGuid (&Node->Guid, &gEfiPcAnsiGuid) && !CompareGuid (&Node->Guid, &gEfiVT100Guid) && !CompareGuid (&Node->Guid, &gEfiVT100PlusGuid) &&
!CompareGuid (&Node->Guid, &gEfiVTUTF8Guid)) {
!CompareGuid (&Node->Guid, &gEfiVTUTF8Guid) &&!CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) {return EFI_UNSUPPORTED; } @@ -275,6 +277,10 @@ BuildTerminalDevpath ( TerminalType = VTUTF8TYPE;
- } else if (CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) {
- TerminalType = LINUXTERMTYPE;
- } else { return NULL; }
@@ -708,9 +714,9 @@ TerminalDriverBindingStart ( TerminalType = PcdGet8 (PcdDefaultTerminalType); //
// Must be between PCANSITYPE (0) and VTUTF8TYPE (3)
// Must be between PCANSITYPE (0) and LINUXTERMTYPE (4) //
ASSERT (TerminalType <= VTUTF8TYPE);
ASSERT (TerminalType <= LINUXTERMTYPE);CopyMem (&DefaultNode->Guid, gTerminalType[TerminalType], sizeof (EFI_GUID)); RemainingDevicePath = (EFI_DEVICE_PATH_PROTOCOL *) DefaultNode; @@ -728,6 +734,8 @@ TerminalDriverBindingStart ( TerminalType = VT100PLUSTYPE; } else if (CompareGuid (&Node->Guid, &gEfiVTUTF8Guid)) { TerminalType = VTUTF8TYPE;
} else if (CompareGuid (&Node->Guid, &gEfiLinuxTermGuid)) {TerminalType = LINUXTERMTYPE; } else { goto Error; }@@ -926,6 +934,24 @@ TerminalDriverBindingStart ( ); break;
- case LINUXTERMTYPE:
AddUnicodeString2 ("eng",gTerminalComponentName.SupportedLanguages,&TerminalDevice->ControllerNameTable,(CHAR16 *)L"Linux Terminal Serial Console",TRUE);AddUnicodeString2 ("en",gTerminalComponentName2.SupportedLanguages,&TerminalDevice->ControllerNameTable,(CHAR16 *)L"Linux Terminal Serial Console",FALSE);break;// @@ -1441,7 +1467,7 @@ TerminalUpdateConsoleDevVariable ( // // Append terminal device path onto the variable. //
- for (TerminalType = PCANSITYPE; TerminalType <= VTUTF8TYPE; TerminalType++) {
- for (TerminalType = PCANSITYPE; TerminalType <= LINUXTERMTYPE; TerminalType++) { SetTerminalDevicePath (TerminalType, ParentDevicePath, &TempDevicePath); NewVariable = AppendDevicePathInstance (Variable, TempDevicePath); ASSERT (NewVariable != NULL);
@@ -1554,7 +1580,7 @@ TerminalRemoveConsoleDevVariable ( // Loop through all the terminal types that this driver supports // Match = FALSE;
- for (TerminalType = PCANSITYPE; TerminalType <= VTUTF8TYPE; TerminalType++) {
- for (TerminalType = PCANSITYPE; TerminalType <= LINUXTERMTYPE; TerminalType++) {
SetTerminalDevicePath (TerminalType, ParentDevicePath, &TempDevicePath); @@ -1658,6 +1684,10 @@ SetTerminalDevicePath ( CopyGuid (&Node.Guid, &gEfiVTUTF8Guid); break;
- case LINUXTERMTYPE:
- CopyGuid (&Node.Guid, &gEfiLinuxTermGuid);
- break;
- default: return EFI_UNSUPPORTED; }
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h index d393acb..e0335db 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h @@ -136,6 +136,7 @@ typedef union { #define VT100TYPE 1 #define VT100PLUSTYPE 2 #define VTUTF8TYPE 3 +#define LINUXTERMTYPE 4 #define LEFTOPENBRACKET 0x5b // '[' #define ACAP 0x41 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c index 4a008c9..51492f3 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c @@ -454,6 +454,7 @@ TranslateRawDataToEfiKey ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE:
- case LINUXTERMTYPE: AnsiRawDataToUnicode (TerminalDevice); UnicodeToEfiKey (TerminalDevice); break;
@@ -1393,7 +1394,8 @@ UnicodeToEfiKey ( if (TerminalDevice->TerminalType == PCANSITYPE || TerminalDevice->TerminalType == VT100TYPE || TerminalDevice->TerminalType == VT100PLUSTYPE ||
TerminalDevice->TerminalType == VTUTF8TYPE) {
TerminalDevice->TerminalType == VTUTF8TYPE ||TerminalDevice->TerminalType == LINUXTERMTYPE) { switch (UnicodeChar) { case 'A': Key.ScanCode = SCAN_UP;diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c index affb3ae..868a014 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c @@ -223,6 +223,7 @@ TerminalConOutOutputString ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE:
- case LINUXTERMTYPE:
if (!TerminalIsValidTextGraphics (*WString, &GraphicChar, &AsciiChar)) { // @@ -371,6 +372,7 @@ TerminalConOutTestString ( case PCANSITYPE: case VT100TYPE: case VT100PLUSTYPE:
- case LINUXTERMTYPE: Status = AnsiTestString (TerminalDevice, WString); break;
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf index 1d86388..7c6e3d3 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf @@ -73,6 +73,7 @@ gEfiVT100Guid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEfiVT100PlusGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path
- gEfiLinuxTermGuid ## SOMETIMES_CONSUMES ## GUID # used with a Vendor-Defined Messaging Device Path gEdkiiStatusCodeDataTypeVariableGuid ## SOMETIMES_CONSUMES ## GUID
[Protocols] diff --git a/MdePkg/Include/Guid/PcAnsi.h b/MdePkg/Include/Guid/PcAnsi.h index e576fd3..61759f8 100644 --- a/MdePkg/Include/Guid/PcAnsi.h +++ b/MdePkg/Include/Guid/PcAnsi.h @@ -38,6 +38,11 @@ 0xad15a0d6, 0x8bec, 0x4acf, {0xa0, 0x73, 0xd0, 0x1d, 0xe7, 0x7e, 0x2d, 0x88 } \ } +#define EFI_LINUX_TERM_GUID \
- { \
- 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 } \
- }
#define DEVICE_PATH_MESSAGING_UART_FLOW_CONTROL \ { \ 0x37499a9d, 0x542f, 0x4c89, {0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 } \ @@ -52,6 +57,7 @@ extern EFI_GUID gEfiPcAnsiGuid; extern EFI_GUID gEfiVT100Guid; extern EFI_GUID gEfiVT100PlusGuid; extern EFI_GUID gEfiVTUTF8Guid; +extern EFI_GUID gEfiLinuxTermGuid; extern EFI_GUID gEfiUartDevicePathGuid; extern EFI_GUID gEfiSasDevicePathGuid; diff --git a/MdePkg/Include/Protocol/DevicePath.h b/MdePkg/Include/Protocol/DevicePath.h index 7cf7113..a718bd4 100644 --- a/MdePkg/Include/Protocol/DevicePath.h +++ b/MdePkg/Include/Protocol/DevicePath.h @@ -706,6 +706,7 @@ typedef VENDOR_DEVICE_PATH VENDOR_DEFINED_DEVICE_PATH; #define DEVICE_PATH_MESSAGING_VT_100 EFI_VT_100_GUID #define DEVICE_PATH_MESSAGING_VT_100_PLUS EFI_VT_100_PLUS_GUID #define DEVICE_PATH_MESSAGING_VT_UTF8 EFI_VT_UTF8_GUID +#define DEVICE_PATH_MESSAGING_LINUX_TERM EFI_LINUX_TERM_GUID /// /// A new device path node is defined to declare flow control characteristics. diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c index 6ec0a4c..f473b39 100644 --- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c @@ -1545,6 +1545,32 @@ DevPathFromTextVenUtf8 ( } /**
- Converts a text device path node to Vendor defined Linux terminal device
- path structure.
- @param TextDeviceNode The input Text device path node.
- @return A pointer to the newly-created Vendor defined Linux terminal
device path structure.+**/ +EFI_DEVICE_PATH_PROTOCOL * +DevPathFromTextVenLinuxTerm (
- IN CHAR16 *TextDeviceNode
- )
+{
- VENDOR_DEVICE_PATH *Vendor;
- Vendor = (VENDOR_DEVICE_PATH *) CreateDeviceNode (
MESSAGING_DEVICE_PATH,MSG_VENDOR_DP,(UINT16) sizeof (VENDOR_DEVICE_PATH));- CopyGuid (&Vendor->Guid, &gEfiLinuxTermGuid);
- return (EFI_DEVICE_PATH_PROTOCOL *) Vendor;
+}
+/** Converts a text device path node to UART Flow Control device path structure. @param TextDeviceNode The input Text device path node. @@ -3075,6 +3101,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED DEVICE_PATH_FROM_TEXT_TABLE mUefiDevicePathLibDevP {L"VenVt100", DevPathFromTextVenVt100 }, {L"VenVt100Plus", DevPathFromTextVenVt100Plus }, {L"VenUtf8", DevPathFromTextVenUtf8 },
- {L"VenLinuxTerm", DevPathFromTextVenLinuxTerm }, {L"UartFlowCtrl", DevPathFromTextUartFlowCtrl }, {L"SAS", DevPathFromTextSAS }, {L"SasEx", DevPathFromTextSasEx },
diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c index 0300019..f7df807 100644 --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c @@ -194,6 +194,9 @@ DevPathToTextVendor ( } else if (CompareGuid (&Vendor->Guid, &gEfiVTUTF8Guid)) { UefiDevicePathLibCatPrint (Str, L"VenUft8()"); return ;
} else if (CompareGuid (&Vendor->Guid, &gEfiLinuxTermGuid)) {UefiDevicePathLibCatPrint (Str, L"VenLinuxTerm()");return ; } else if (CompareGuid (&Vendor->Guid, &gEfiUartDevicePathGuid)) { FlowControlMap = (((UART_FLOW_CONTROL_DEVICE_PATH *) Vendor)->FlowControlMap); switch (FlowControlMap & 0x00000003) {diff --git a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf index f4ae91f..a1bad14 100644 --- a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf +++ b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf @@ -58,6 +58,8 @@ ## SOMETIMES_CONSUMES ## GUID gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID
- gEfiLinuxTermGuid
- ## SOMETIMES_CONSUMES ## GUID gEfiUartDevicePathGuid ## SOMETIMES_CONSUMES ## GUID gEfiSasDevicePathGuid
diff --git a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf index 943ba2d..b529400 100644 --- a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf +++ b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf @@ -62,6 +62,8 @@ ## SOMETIMES_CONSUMES ## GUID gEfiPcAnsiGuid ## SOMETIMES_CONSUMES ## GUID
- gEfiLinuxTermGuid
- ## SOMETIMES_CONSUMES ## GUID gEfiUartDevicePathGuid ## SOMETIMES_CONSUMES ## GUID gEfiSasDevicePathGuid
@@ -78,4 +80,4 @@ [Depex.common.DXE_DRIVER, Depex.common.DXE_RUNTIME_DRIVER, Depex.common.DXE_SAL_DRIVER, Depex.common.DXE_SMM_DRIVER] gEfiDevicePathUtilitiesProtocolGuid
\ No newline at end of file
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index f9c9d5f..b1b0038 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -269,6 +269,9 @@ gEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0, 0x73, 0xD0, 0x1D, 0xE7, 0x7E, 0x2D, 0x88 }} ## Include/Guid/PcAnsi.h
- gEfiLinuxTermGuid = { 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 }}
- ## Include/Guid/PcAnsi.h gEfiUartDevicePathGuid = { 0x37499a9d, 0x542f, 0x4c89, { 0xa0, 0x26, 0x35, 0xda, 0x14, 0x20, 0x94, 0xe4 }}
## Include/Guid/PcAnsi.h diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c index 9a2daa9..9baaed7 100644 --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c @@ -848,6 +848,7 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringList[] = { {STRING_TOKEN(STR_DEVICE_PATH_VT100), &gEfiVT100Guid, NULL}, {STRING_TOKEN(STR_DEVICE_PATH_VT100P), &gEfiVT100PlusGuid, NULL}, {STRING_TOKEN(STR_DEVICE_PATH_VTUTF8), &gEfiVTUTF8Guid, NULL},
- {STRING_TOKEN(STR_DEVICE_PATH_LINUXTERM), &gEfiLinuxTermGuid, NULL}, {STRING_TOKEN(STR_DRIVER_BINDING), &gEfiDriverBindingProtocolGuid, NULL}, {STRING_TOKEN(STR_PLATFORM_OVERRIDE), &gEfiPlatformDriverOverrideProtocolGuid, NULL}, {STRING_TOKEN(STR_BUS_OVERRIDE), &gEfiBusSpecificDriverOverrideProtocolGuid, NULL},
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf index c95f41b..716dbd7 100644 --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf @@ -181,6 +181,7 @@ gEfiVT100Guid ##UNDEFINED gEfiVT100PlusGuid ##UNDEFINED gEfiVTUTF8Guid ##UNDEFINED
- gEfiLinuxTermGuid ##UNDEFINED gEfiStandardErrorDeviceGuid ##UNDEFINED gEfiConsoleInDeviceGuid ##UNDEFINED gEfiConsoleOutDeviceGuid ##UNDEFINED
-- 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Treat ASCII 0x7F as backspace, rather than delete, for Linux terminals.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0 --- MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
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 (TerminalDevice->TerminalType == LINUXTERMTYPE) { + Key.ScanCode = SCAN_NULL; + Key.UnicodeChar = CHAR_BACKSPACE; + } + else { + Key.ScanCode = SCAN_DELETE; + Key.UnicodeChar = 0; + } } else { Key.ScanCode = SCAN_NULL; Key.UnicodeChar = UnicodeChar;
Accept the VT200 escape code [3~ as backspace for LinuxTerm terminals.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0 --- .../Universal/Console/TerminalDxe/Terminal.h | 1 + .../Universal/Console/TerminalDxe/TerminalConIn.c | 33 ++++++++++++++++++++++ 2 files changed, 34 insertions(+)
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h index e0335db..727cab8 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h @@ -117,6 +117,7 @@ typedef struct { #define INPUT_STATE_LEFTOPENBRACKET 0x04 #define INPUT_STATE_O 0x08 #define INPUT_STATE_2 0x10 +#define INPUT_STATE_LEFTOPENBRACKET_2 0x20
#define RESET_STATE_DEFAULT 0x00 #define RESET_STATE_ESC_R 0x01 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c index 70ec370..b23b012 100644 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c @@ -1397,6 +1397,12 @@ UnicodeToEfiKey ( TerminalDevice->TerminalType == VTUTF8TYPE || TerminalDevice->TerminalType == LINUXTERMTYPE) { switch (UnicodeChar) { + case '3': + if (TerminalDevice->TerminalType == LINUXTERMTYPE) { + TerminalDevice->InputState |= INPUT_STATE_LEFTOPENBRACKET_2; + continue; + } + break; case 'A': Key.ScanCode = SCAN_UP; break; @@ -1527,6 +1533,33 @@ UnicodeToEfiKey ( break;
+ case INPUT_STATE_ESC | INPUT_STATE_LEFTOPENBRACKET | INPUT_STATE_LEFTOPENBRACKET_2: + + Key.ScanCode = SCAN_NULL; + + if (TerminalDevice->TerminalType == LINUXTERMTYPE) { + switch (UnicodeChar) { + case '~': + Key.ScanCode = SCAN_DELETE; + break; + } + } + + TerminalDevice->ResetState = RESET_STATE_DEFAULT; + + if (Key.ScanCode != SCAN_NULL) { + Key.UnicodeChar = 0; + EfiKeyFiFoInsertOneKey (TerminalDevice, &Key); + TerminalDevice->InputState = INPUT_STATE_DEFAULT; + UnicodeToEfiKeyFlushState (TerminalDevice); + continue; + } + + UnicodeToEfiKeyFlushState (TerminalDevice); + + break; + + default: // // Invalid state. This should never happen.
This changes the QEMU terminal type to LinuxTerm, which handles the terminals commonly used to connect to the emulated serial port.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0 --- ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc index 9078c4c..10bee77 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc @@ -131,8 +131,8 @@ gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0
# Use the serial console (ConIn & ConOut) and the Graphic driver (ConOut) - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()" - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()" + gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenLinuxTerm()" + gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenLinuxTerm()" gArmPlatformTokenSpaceGuid.PcdPlatformBootTimeOut|3
#
On 05/14/15 01:54, Roy Franz wrote:
This changes the QEMU terminal type to LinuxTerm, which handles the terminals commonly used to connect to the emulated serial port.
Signed-off-by: Roy Franz roy.franz@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc index 9078c4c..10bee77 100644 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc @@ -131,8 +131,8 @@ gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 # Use the serial console (ConIn & ConOut) and the Graphic driver (ConOut)
- gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
- gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
- gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenLinuxTerm()"
- gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenLinuxTerm()" gArmPlatformTokenSpaceGuid.PcdPlatformBootTimeOut|3
Please make this depend on a new -D build flag (and the default, ie. when the new flag is absent, should not change).
Thanks Laszlo
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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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(-)
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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On May 13, 2015, at 6:15 PM, Yao, Jiewen jiewen.yao@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Andrew,
I agree that PCDs could be used to change behavior.
However, I think a new GUID would be required if there a behavior change in the interpretation of byte streams to/from a terminal emulator.
Mike
-----Original Message----- From: Andrew Fish [mailto:afish@apple.com] Sent: Wednesday, May 13, 2015 6:20 PM To: edk2-devel@lists.sourceforge.net Cc: Kinney, Michael D; linaro-uefi@lists.linaro.org; Tian, Feng Subject: Re: [edk2] [RFC 0/4] New terminal type for Linux
On May 13, 2015, at 6:15 PM, Yao, Jiewen jiewen.yao@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
So, does that mean we will have GUID to decide "major type", and PCD to decide "minor type"? :-) OK. I think it is workable solution.
Thank you Yao Jiewen
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Andrew Fish Sent: Thursday, May 14, 2015 9:20 AM To: edk2-devel@lists.sourceforge.net Cc: Kinney, Michael D; Tian, Feng; linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] [edk2] [RFC 0/4] New terminal type for Linux
On May 13, 2015, at 6:15 PM, Yao, Jiewen jiewen.yao@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboar dConfiguration
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
_______________________________________________ Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On May 13, 2015, at 6:23 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
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,
Sorry I was unclear (writing code in parallel to this mail thread). I think adding a LinuxTerminal GUID is the right way to start. If there are pedantic complaints on how it works the behavior could be tunable via PCD. This seems to be what happens in the real world is folks make minor config tweaks. We may have to start naming the GUID’s after people at some point, if we don’t enabled the PCDs :).
Thanks,
Andrew Fish
Mike
-----Original Message----- From: Yao, Jiewen Sent: Wednesday, May 13, 2015 6:16 PM To: Kinney, Michael D; edk2-devel@lists.sourceforge.net; linaro-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Andrew,
I would hope we would only need to add a new GUID if there is a new type of terminal emulator with a fundamentally different byte stream translation.
Let's see how far we can get without adding PCDs. For example, on the Simple Input Protocol, supporting more than one byte sequence for a single key can be supported without PCDs. It is only when there is a conflict in the interpretation of a byte sequence that we have to consider a new GUID or a PCD.
Mike
-----Original Message----- From: Andrew Fish [mailto:afish@apple.com] Sent: Wednesday, May 13, 2015 6:59 PM To: edk2-devel@lists.sourceforge.net Cc: Yao, Jiewen; linaro-uefi@lists.linaro.org; Tian, Feng; Kinney, Michael D Subject: Re: [edk2] [RFC 0/4] New terminal type for Linux
On May 13, 2015, at 6:23 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
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,
Sorry I was unclear (writing code in parallel to this mail thread). I think adding a LinuxTerminal GUID is the right way to start. If there are pedantic complaints on how it works the behavior could be tunable via PCD. This seems to be what happens in the real world is folks make minor config tweaks. We may have to start naming the GUID’s after people at some point, if we don’t enabled the PCDs :).
Thanks,
Andrew Fish
Mike
-----Original Message----- From: Yao, Jiewen Sent: Wednesday, May 13, 2015 6:16 PM To: Kinney, Michael D; edk2-devel@lists.sourceforge.net; linaro-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
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-uefi@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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Jiewen,
I think most of the terminal emulators being discussed here layer on top of a TTY device.
How about TtyTerm instead?
Mike
-----Original Message----- From: Yao, Jiewen Sent: Wednesday, May 13, 2015 7:13 PM To: Kinney, Michael D; edk2-devel@lists.sourceforge.net; linaro-uefi@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-uefi@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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On Thu, May 14, 2015 at 12:31 PM, Kinney, Michael D michael.d.kinney@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-uefi@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-uefi@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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Roy,
1) New GUID should be defined in MdeModulePkg/MdeModulePkg.dec 2) New include file for new GUID in MdeModulePkg/Include/Guid 3) Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
-----Original Message----- From: Roy Franz [mailto:roy.franz@linaro.org] Sent: Thursday, May 14, 2015 1:44 PM To: Kinney, Michael D Cc: Yao, Jiewen; edk2-devel@lists.sourceforge.net; linaro-uefi@lists.linaro.org; Tian, Feng Subject: Re: [edk2] [RFC 0/4] New terminal type for Linux
On Thu, May 14, 2015 at 12:31 PM, Kinney, Michael D michael.d.kinney@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-uefi@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-uefi@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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
Roy,
- New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
- New include file for new GUID in MdeModulePkg/Include/Guid
- Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
OK, I have made the above changes, and have it working with one hack I'm not sure how to properly resolve.
I now have gEfiTtyTermGuid declared (extern) in MdeModulePkg/Include/Guid/TtyTerm.h, and defined in MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert between a text path to a device path, but I don't see how to include TtyTerm.h in DevicePathFromText.c. Right now I just have added the extern to DevicePathFromText.c to verify functionality. This works, but is obviously not the right solution. How should I go about properly getting gEfiTtyTermGuid declared in DevicePathFromText.c?
Thanks, Roy
On 5 June 2015 at 06:03, Roy Franz roy.franz@linaro.org wrote:
On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
Roy,
- New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
- New include file for new GUID in MdeModulePkg/Include/Guid
- Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
OK, I have made the above changes, and have it working with one hack I'm not sure how to properly resolve.
I now have gEfiTtyTermGuid declared (extern) in MdeModulePkg/Include/Guid/TtyTerm.h, and defined in MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert between a text path to a device path, but I don't see how to include TtyTerm.h in DevicePathFromText.c. Right now I just have added the extern to DevicePathFromText.c to verify functionality. This works, but is obviously not the right solution. How should I go about properly getting gEfiTtyTermGuid declared in DevicePathFromText.c?
You should not define the GUID yourself, you should add it to the appropriate .dec file, If you then depend on that package and guid in a module's .inf, the definition will be emitted implicitly by the build tools.
On Fri, Jun 5, 2015 at 2:31 AM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 5 June 2015 at 06:03, Roy Franz roy.franz@linaro.org wrote:
On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
Roy,
- New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
- New include file for new GUID in MdeModulePkg/Include/Guid
- Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
OK, I have made the above changes, and have it working with one hack I'm not sure how to properly resolve.
I now have gEfiTtyTermGuid declared (extern) in MdeModulePkg/Include/Guid/TtyTerm.h, and defined in MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert between a text path to a device path, but I don't see how to include TtyTerm.h in DevicePathFromText.c. Right now I just have added the extern to DevicePathFromText.c to verify functionality. This works, but is obviously not the right solution. How should I go about properly getting gEfiTtyTermGuid declared in DevicePathFromText.c?
You should not define the GUID yourself, you should add it to the appropriate .dec file, If you then depend on that package and guid in a module's .inf, the definition will be emitted implicitly by the build tools.
Thanks Ard.
OK, got rid of the bogus Tty.c. I already had the GUID (also) defined in the MdeModulePkg.dec, and the gEfiTtyTermGuid in the [Guid] section of the UefiDevicePathLib.inf. What I am missing is the declaring the dependency of UefiDevicePathLib on the MdeModulePackage, and I don't know how to add that. TerminalDxe isn't under the Library directory, and doesn't have a "LIBRARY_CLASS" in its .inf file, and all the examples of dependencies that I have found seem to rely on that. My somewhat vague understanding of the ED2 build system has hit its limit.
Thanks, Roy
-- Ard.
On 06/06/15 00:36, Roy Franz wrote:
On Fri, Jun 5, 2015 at 2:31 AM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 5 June 2015 at 06:03, Roy Franz roy.franz@linaro.org wrote:
On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
Roy,
- New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
- New include file for new GUID in MdeModulePkg/Include/Guid
- Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
OK, I have made the above changes, and have it working with one hack I'm not sure how to properly resolve.
I now have gEfiTtyTermGuid declared (extern) in MdeModulePkg/Include/Guid/TtyTerm.h, and defined in MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert between a text path to a device path, but I don't see how to include TtyTerm.h in DevicePathFromText.c. Right now I just have added the extern to DevicePathFromText.c to verify functionality. This works, but is obviously not the right solution. How should I go about properly getting gEfiTtyTermGuid declared in DevicePathFromText.c?
You should not define the GUID yourself, you should add it to the appropriate .dec file, If you then depend on that package and guid in a module's .inf, the definition will be emitted implicitly by the build tools.
Thanks Ard.
OK, got rid of the bogus Tty.c. I already had the GUID (also) defined in the MdeModulePkg.dec, and the gEfiTtyTermGuid in the [Guid] section of the UefiDevicePathLib.inf. What I am missing is the declaring the dependency of UefiDevicePathLib on the MdeModulePackage, and I don't know how to add that. TerminalDxe isn't under the Library directory, and doesn't have a "LIBRARY_CLASS" in its .inf file, and all the examples of dependencies that I have found seem to rely on that. My somewhat vague understanding of the ED2 build system has hit its limit.
In the INF file of any module (library instance, driver module, application, etc), you have a
[Packages]
section, under which you can list *.dec files, with pathnames relative to the root of the edk2 clone. Once you add a dec file there, you can reference guids, PCDs, and library classes (headers) declared in that DEC file.
Protocol GUIDs and other GUIDs will become available for compilation by including the appropriate include files (from under Library/, Protocol/, and Guid/, usually); these relative include file pathnames are then searched against all modules that you listed under [Packages].
For *linking*, you'll also have to list the protocol guids under [Protocols] and the other guids under [Guids] in the INF file. This will cause the build system to include *definitions* for these GUIDs in the auto-generated C files. This way linking too will succeed.
The [LibraryClasses] section is also there for linking, but it has an extra level of indirection. (For compilation, see Library/ above.) A library class ultimately corresponds to a header file only, and it can have several implementations. [LibraryClasses] therefore lists only the sets of APIs you'd like to link against, but the actual library implementation is resolved in the DSC file that you are building.
The DSC file can resolve a library class to a library instance - globally, for all modules, - for types of modules (eg. DXE_DRIVER vs. PEIM vs. UEFI_APPLICATION), - for individual modules (identified by their INF files).
(The INF file spec describes this in much more detail, and no doubt much more correctly; just google it.)
In addition, library instances (= implementations) can restrict themselves to some module types. The most common example is that libraries that write to static variables cannot be generally linked into PEIMs, because writeable memory becomes available only at some point during PEI; some PEIMs execute in place from flash. (There's only static linking; dynamic linking is covered with PPIs (PEIM-to-PEIM interfaces) and protocols.)
So a library wanting to write to a static variable would in general restrict itself to post-PEI module types. Alternatively, its INF file could list a dependency expression (a depex) on the "gEfiPeiMemoryDiscoveredPpiGuid" PPI, which gets installed when DRAM becomes available during PEI. Such a depex would be inherited by any PEIM that linked against this particular library instance, with the effect that the PEIM would be first dispatched only after DRAM were initialized. (Hence allowing the library built into the module to write to its static variables.)
Anyway, in the current case, the technical solution would be to add MdeModulePkg/MdeModulePkg.dec under the [Packages] section in "MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf".
However, that's no good, because MdePkg contains definitions, libraries etc. for industry standards. For example, the DevicePathLib library instance in question ("UefiDevicePathLib") knows about GUIDs that are listed in the UEFI specification. So you'd either have to introduce a cross-package dependency to MdeModulePkg (which is technically feasible, but purity-wise it would be frowned upon I think, because MdeModulePkg is reference implementation for a standard, not standard per se), *or* you'd have to add gEfiTtyTermGuid to MdePkg's dec file, and the appropriate MdePkg/Include/Guid/... header file). However, the latter would not be accepted until gEfiTtyTermGuid were actually *standard*.
So what can you do, if neither the cross-pkg dependency nor the direct MdePkg modification is appropriate? Two options: - Try to standardize the GUID with the USWG. Good luck! :) - Fork the UefiDevicePathLib library instance to some other (less central) package, and modify it there. This sucks because any updates to the standard location would have to be cross-ported, going forward.
The edk2 build system is actually very flexible, it's just that the terminal stuff has always proven untouchable (to me at least). Note though that forking a library instance (or a module for that matter) is the *norm* for proprietary vendors, which is what edk2 (and the UEFI spec itself) are optimized for. (Eg. the protocols are ABIs, not APIs.)
To summarize: you're facing this problem because the devpath-to-text conversion library instance under MdePkg is tightly coupled with an industry standard (the UEFI spec), whereas the driver modules under MdeModulePkg are just "independent implementations" (that Intel cares about very much though). If you want to add non-standard extensions to the devpath-to-text conversion library, you might have to fork it (or standardize the extension).
Sorry if I misunderstood the situation; hopefully others can correct me then (or anyway).
Thanks Laszlo
On Fri, Jun 5, 2015 at 4:39 PM, Laszlo Ersek lersek@redhat.com wrote:
On 06/06/15 00:36, Roy Franz wrote:
On Fri, Jun 5, 2015 at 2:31 AM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 5 June 2015 at 06:03, Roy Franz roy.franz@linaro.org wrote:
On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D michael.d.kinney@intel.com wrote:
Roy,
- New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
- New include file for new GUID in MdeModulePkg/Include/Guid
- Update TerminalDxe to use this new GUID.
I do not recommend creating a new terminal driver. Please continue as you have which is adding support for this one new terminal type to MdeModulePkg/Universal/Console/TerminalDxe.
Best regards,
Mike
OK, I have made the above changes, and have it working with one hack I'm not sure how to properly resolve.
I now have gEfiTtyTermGuid declared (extern) in MdeModulePkg/Include/Guid/TtyTerm.h, and defined in MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert between a text path to a device path, but I don't see how to include TtyTerm.h in DevicePathFromText.c. Right now I just have added the extern to DevicePathFromText.c to verify functionality. This works, but is obviously not the right solution. How should I go about properly getting gEfiTtyTermGuid declared in DevicePathFromText.c?
You should not define the GUID yourself, you should add it to the appropriate .dec file, If you then depend on that package and guid in a module's .inf, the definition will be emitted implicitly by the build tools.
Thanks Ard.
OK, got rid of the bogus Tty.c. I already had the GUID (also) defined in the MdeModulePkg.dec, and the gEfiTtyTermGuid in the [Guid] section of the UefiDevicePathLib.inf. What I am missing is the declaring the dependency of UefiDevicePathLib on the MdeModulePackage, and I don't know how to add that. TerminalDxe isn't under the Library directory, and doesn't have a "LIBRARY_CLASS" in its .inf file, and all the examples of dependencies that I have found seem to rely on that. My somewhat vague understanding of the ED2 build system has hit its limit.
In the INF file of any module (library instance, driver module, application, etc), you have a
[Packages]
section, under which you can list *.dec files, with pathnames relative to the root of the edk2 clone. Once you add a dec file there, you can reference guids, PCDs, and library classes (headers) declared in that DEC file.
Protocol GUIDs and other GUIDs will become available for compilation by including the appropriate include files (from under Library/, Protocol/, and Guid/, usually); these relative include file pathnames are then searched against all modules that you listed under [Packages].
For *linking*, you'll also have to list the protocol guids under [Protocols] and the other guids under [Guids] in the INF file. This will cause the build system to include *definitions* for these GUIDs in the auto-generated C files. This way linking too will succeed.
The [LibraryClasses] section is also there for linking, but it has an extra level of indirection. (For compilation, see Library/ above.) A library class ultimately corresponds to a header file only, and it can have several implementations. [LibraryClasses] therefore lists only the sets of APIs you'd like to link against, but the actual library implementation is resolved in the DSC file that you are building.
The DSC file can resolve a library class to a library instance
- globally, for all modules,
- for types of modules (eg. DXE_DRIVER vs. PEIM vs. UEFI_APPLICATION),
- for individual modules (identified by their INF files).
(The INF file spec describes this in much more detail, and no doubt much more correctly; just google it.)
In addition, library instances (= implementations) can restrict themselves to some module types. The most common example is that libraries that write to static variables cannot be generally linked into PEIMs, because writeable memory becomes available only at some point during PEI; some PEIMs execute in place from flash. (There's only static linking; dynamic linking is covered with PPIs (PEIM-to-PEIM interfaces) and protocols.)
So a library wanting to write to a static variable would in general restrict itself to post-PEI module types. Alternatively, its INF file could list a dependency expression (a depex) on the "gEfiPeiMemoryDiscoveredPpiGuid" PPI, which gets installed when DRAM becomes available during PEI. Such a depex would be inherited by any PEIM that linked against this particular library instance, with the effect that the PEIM would be first dispatched only after DRAM were initialized. (Hence allowing the library built into the module to write to its static variables.)
Anyway, in the current case, the technical solution would be to add MdeModulePkg/MdeModulePkg.dec under the [Packages] section in "MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf".
However, that's no good, because MdePkg contains definitions, libraries etc. for industry standards. For example, the DevicePathLib library instance in question ("UefiDevicePathLib") knows about GUIDs that are listed in the UEFI specification. So you'd either have to introduce a cross-package dependency to MdeModulePkg (which is technically feasible, but purity-wise it would be frowned upon I think, because MdeModulePkg is reference implementation for a standard, not standard per se), *or* you'd have to add gEfiTtyTermGuid to MdePkg's dec file, and the appropriate MdePkg/Include/Guid/... header file). However, the latter would not be accepted until gEfiTtyTermGuid were actually *standard*.
So what can you do, if neither the cross-pkg dependency nor the direct MdePkg modification is appropriate? Two options:
- Try to standardize the GUID with the USWG. Good luck! :)
- Fork the UefiDevicePathLib library instance to some other (less central) package, and modify it there. This sucks because any updates to the standard location would have to be cross-ported, going forward.
The edk2 build system is actually very flexible, it's just that the terminal stuff has always proven untouchable (to me at least). Note though that forking a library instance (or a module for that matter) is the *norm* for proprietary vendors, which is what edk2 (and the UEFI spec itself) are optimized for. (Eg. the protocols are ABIs, not APIs.)
To summarize: you're facing this problem because the devpath-to-text conversion library instance under MdePkg is tightly coupled with an industry standard (the UEFI spec), whereas the driver modules under MdeModulePkg are just "independent implementations" (that Intel cares about very much though). If you want to add non-standard extensions to the devpath-to-text conversion library, you might have to fork it (or standardize the extension).
Sorry if I misunderstood the situation; hopefully others can correct me then (or anyway).
Thank you - that was very helpful, and I think you do understand the situation. I had some inklings of some of problems you highlighted above, but not the full ramifications.
So, the link problem I am having is in the device path conversion code (DevicePathTo/FromText.c), so is there a way to avoid this by just not supporting nice text device paths? From my (again limited) understanding of device paths, I could do something like: VenHw(D3987D4B-971A-435F-8CAF-4967EB627241) instead of VenTtyTerm(), which would directly encode the GUID, and hence avoid the dependency problems I'm having. It will make for a more ugly .dsc file, but that's what comments are for :) Would this work?
Thanks, Roy
Thanks Laszlo
On 06/06/15 01:57, Roy Franz wrote:
So, the link problem I am having is in the device path conversion code (DevicePathTo/FromText.c), so is there a way to avoid this by just not supporting nice text device paths? From my (again limited) understanding of device paths, I could do something like: VenHw(D3987D4B-971A-435F-8CAF-4967EB627241) instead of VenTtyTerm(), which would directly encode the GUID, and hence avoid the dependency problems I'm having. It will make for a more ugly .dsc file, but that's what comments are for :) Would this work?
Absolutely. It should not be VenHw(), but VenMsg() -- grep the MdePkg/Library/UefiDevicePathLib/ directory for "VenVt100", and check the contexts of the hits --, but that's it. Therefore, simply don't touch MdePkg/Library/UefiDevicePathLib/.
Thanks Laszlo
On Jun 5, 2015, at 5:13 PM, Laszlo Ersek lersek@redhat.com wrote:
On 06/06/15 01:57, Roy Franz wrote:
So, the link problem I am having is in the device path conversion code (DevicePathTo/FromText.c), so is there a way to avoid this by just not supporting nice text device paths? From my (again limited) understanding of device paths, I could do something like: VenHw(D3987D4B-971A-435F-8CAF-4967EB627241) instead of VenTtyTerm(), which would directly encode the GUID, and hence avoid the dependency problems I'm having. It will make for a more ugly .dsc file, but that's what comments are for :) Would this work?
Absolutely. It should not be VenHw(), but VenMsg() -- grep the MdePkg/Library/UefiDevicePathLib/ directory for "VenVt100", and check the contexts of the hits --, but that's it. Therefore, simply don't touch MdePkg/Library/UefiDevicePathLib/.
The emulators have a similar issue, they have non standard GUID’ed device paths.
The way to solve this is to have a Extension Lib that UefiDevicePathLib depends on. The MdePkg could have the NULL version of this lib, and then a given platform could publish an extension lib that knows about the extra GUIDs.
Thanks,
Andrew Fish
On 06/05/2015 07:19 PM, Andrew Fish wrote:
On Jun 5, 2015, at 5:13 PM, Laszlo Ersek lersek@redhat.com wrote:
On 06/06/15 01:57, Roy Franz wrote:
So, the link problem I am having is in the device path conversion code (DevicePathTo/FromText.c), so is there a way to avoid this by just not supporting nice text device paths? From my (again limited) understanding of device paths, I could do something like: VenHw(D3987D4B-971A-435F-8CAF-4967EB627241) instead of VenTtyTerm(), which would directly encode the GUID, and hence avoid the dependency problems I'm having. It will make for a more ugly .dsc file, but that's what comments are for :) Would this work?
Absolutely. It should not be VenHw(), but VenMsg() -- grep the MdePkg/Library/UefiDevicePathLib/ directory for "VenVt100", and check the contexts of the hits --, but that's it. Therefore, simply don't touch MdePkg/Library/UefiDevicePathLib/.
The emulators have a similar issue, they have non standard GUID’ed device paths.
The way to solve this is to have a Extension Lib that UefiDevicePathLib depends on. The MdePkg could have the NULL version of this lib, and then a given platform could publish an extension lib that knows about the extra GUIDs.
That would be helpful. We've had to resort to modifying MdePkg locally.
Good suggestion, Mike. I believe "Tty" is much better than "Linux".
-----Original Message----- From: Kinney, Michael D Sent: Friday, May 15, 2015 3:31 AM To: Yao, Jiewen; edk2-devel@lists.sourceforge.net; linaro-uefi@lists.linaro.org; Tian, Feng; Kinney, Michael D; roy.franz@linaro.org Subject: RE: [edk2] [RFC 0/4] New terminal type for Linux
Jiewen,
I think most of the terminal emulators being discussed here layer on top of a TTY device.
How about TtyTerm instead?
Mike
-----Original Message----- From: Yao, Jiewen Sent: Wednesday, May 13, 2015 7:13 PM To: Kinney, Michael D; edk2-devel@lists.sourceforge.net; linaro-uefi@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-uefi@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-uefi@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-uefi@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-uefi@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.kinney@intel.com] Sent: Thursday, May 14, 2015 8:44 AM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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.franz@linaro.org] Sent: Wednesday, May 13, 2015 4:54 PM To: edk2-devel@lists.sourceforge.net; linaro-uefi@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%22%3EKeyboardC...
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%3B117567292%3By _______________________________________________ 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%3B117567292%3By _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
-
Andrew Fish -
Ard Biesheuvel -
Brian J. Johnson -
Jordan Justen -
Kinney, Michael D -
Laszlo Ersek -
Roy Franz -
Yao, Jiewen