ctrl-x / ctrl-c may not work under GRUB2 with EFI

ctrl-x / ctrl-c may not work under GRUB2 with EFI

[Pawel Wojtalczyk]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

Hello,

I run GRUB2 as 64-bit EFI application and I use gfxterm and serial as 
output.

I would like to edit commands before boot by type 'e' command. Then I 
would like to boot by press ctrl-x, but unfortunately the boot does not 
appears.

The reason is that in AMI and Phoenix BIOSes when ctrl key is pressed 
then EFI_SIMPLE_TEXT_INPUT_PROTOCOL protocol returns VT100 style 
encoding of pressed unicode character ( 
http://www.vt100.net/docs/vt100-ug/table3-5.html).

I tried to use EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL to get the pressed key 
modifier (ctrl, alt, etc), but in case when serial console redirection 
enabled in Phoenix BIOS, none characters are received via serial with 
EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL(with AMI BIOS characters are received 
in VT100 encoding style).

So maybe we can do another way. Maybe we can explicitly set key modifier 
(as in grub_terminfo_getkey() with 
http://wiki.phoenix.com/wiki/index.php/Unicode_Control_Characters 
restrictions) as following:

--- grub.orig/grub-core/term/efi/console.c      2013-07-31 
07:50:52.000000000 +0200
+++ grub/grub-core/term/efi/console.c   2013-08-06 10:28:26.117499386 +0200
@@ -125,7 +125,12 @@
      return GRUB_TERM_NO_KEY;

    if (key.scan_code == 0)
-    return key.unicode_char;
+#if defined (__i386__) || defined (__x86_64__)
+    if (key.unicode_char < 0x20 && key.unicode_char != 0 && 
key.unicode_char != '\t' && key.unicode_char != '\b' && key.unicode_char 
!= '\n' && key.unicode_char != '\r')
+      return GRUB_TERM_CTRL | (key.unicode_char - 1 + 'a');
+    else
+#endif /* defined (__i386__) || defined (__x86_64__) */
+      return key.unicode_char;
    else if (key.scan_code < ARRAY_SIZE (efi_codes))
      return efi_codes[key.scan_code];

In some remote systems EFI serial redirection must be enabled and thus 
we cannot use serial (as termianl_input) module in GRUB2 and in such 
case it would be good to allow add support for ctrl-x/ctrl-c under GRUB2 
via serial console redirection enabled in EFI and attached USB keyboard.

Regrads
Pawel Wojtalczyk

[-- Attachment #2: Type: text/html, Size: 2956 bytes --]

Re: ctrl-x / ctrl-c may not work under GRUB2 with EFI

[Andrey Borzenkov]

В Tue, 06 Aug 2013 10:35:30 +0200
Pawel Wojtalczyk <eyak@wp.pl> пишет:

> Hello,
> 
> I run GRUB2 as 64-bit EFI application and I use gfxterm and serial as 
> output.
> 
> I would like to edit commands before boot by type 'e' command. Then I 
> would like to boot by press ctrl-x, but unfortunately the boot does not 
> appears.
> 

Does F10 work?

> The reason is that in AMI and Phoenix BIOSes when ctrl key is pressed 
> then EFI_SIMPLE_TEXT_INPUT_PROTOCOL protocol returns VT100 style 
> encoding of pressed unicode character ( 
> http://www.vt100.net/docs/vt100-ug/table3-5.html).
> 
> I tried to use EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL to get the pressed key 
> modifier (ctrl, alt, etc), but in case when serial console redirection 
> enabled in Phoenix BIOS, none characters are received via serial with 
> EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL(with AMI BIOS characters are received 
> in VT100 encoding style).
> 
> So maybe we can do another way. Maybe we can explicitly set key modifier 
> (as in grub_terminfo_getkey() with 
> http://wiki.phoenix.com/wiki/index.php/Unicode_Control_Characters 
> restrictions) as following:
> 
> --- grub.orig/grub-core/term/efi/console.c      2013-07-31 
> 07:50:52.000000000 +0200
> +++ grub/grub-core/term/efi/console.c   2013-08-06 10:28:26.117499386 +0200
> @@ -125,7 +125,12 @@
>       return GRUB_TERM_NO_KEY;
> 
>     if (key.scan_code == 0)
> -    return key.unicode_char;
> +#if defined (__i386__) || defined (__x86_64__)
> +    if (key.unicode_char < 0x20 && key.unicode_char != 0 && 
> key.unicode_char != '\t' && key.unicode_char != '\b' && key.unicode_char 
> != '\n' && key.unicode_char != '\r')
> +      return GRUB_TERM_CTRL | (key.unicode_char - 1 + 'a');
> +    else
> +#endif /* defined (__i386__) || defined (__x86_64__) */
> +      return key.unicode_char;
>     else if (key.scan_code < ARRAY_SIZE (efi_codes))
>       return efi_codes[key.scan_code];
> 
> In some remote systems EFI serial redirection must be enabled and thus 
> we cannot use serial (as termianl_input) module in GRUB2 and in such 
> case it would be good to allow add support for ctrl-x/ctrl-c under GRUB2 
> via serial console redirection enabled in EFI and attached USB keyboard.
> 
> Regrads
> Pawel Wojtalczyk

Re: ctrl-x / ctrl-c may not work under GRUB2 with EFI

[Pawel Wojtalczyk]

Hello,

F10 works only for USB keyboard directly attached to the target, but not 
on the redirected console (enabled in EFI) to the serial which I am 
using for remote access the board.

Regards
Pawel

On 06.08.2013 18:32, Andrey Borzenkov wrote:
> В Tue, 06 Aug 2013 10:35:30 +0200
> Pawel Wojtalczyk <eyak@wp.pl> пишет:
>
>> Hello,
>>
>> I run GRUB2 as 64-bit EFI application and I use gfxterm and serial as
>> output.
>>
>> I would like to edit commands before boot by type 'e' command. Then I
>> would like to boot by press ctrl-x, but unfortunately the boot does not
>> appears.
>>
> Does F10 work?
>
>> The reason is that in AMI and Phoenix BIOSes when ctrl key is pressed
>> then EFI_SIMPLE_TEXT_INPUT_PROTOCOL protocol returns VT100 style
>> encoding of pressed unicode character (
>> http://www.vt100.net/docs/vt100-ug/table3-5.html).
>>
>> I tried to use EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL to get the pressed key
>> modifier (ctrl, alt, etc), but in case when serial console redirection
>> enabled in Phoenix BIOS, none characters are received via serial with
>> EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL(with AMI BIOS characters are received
>> in VT100 encoding style).
>>
>> So maybe we can do another way. Maybe we can explicitly set key modifier
>> (as in grub_terminfo_getkey() with
>> http://wiki.phoenix.com/wiki/index.php/Unicode_Control_Characters
>> restrictions) as following:
>>
>> --- grub.orig/grub-core/term/efi/console.c      2013-07-31
>> 07:50:52.000000000 +0200
>> +++ grub/grub-core/term/efi/console.c   2013-08-06 10:28:26.117499386 +0200
>> @@ -125,7 +125,12 @@
>>        return GRUB_TERM_NO_KEY;
>>
>>      if (key.scan_code == 0)
>> -    return key.unicode_char;
>> +#if defined (__i386__) || defined (__x86_64__)
>> +    if (key.unicode_char < 0x20 && key.unicode_char != 0 &&
>> key.unicode_char != '\t' && key.unicode_char != '\b' && key.unicode_char
>> != '\n' && key.unicode_char != '\r')
>> +      return GRUB_TERM_CTRL | (key.unicode_char - 1 + 'a');
>> +    else
>> +#endif /* defined (__i386__) || defined (__x86_64__) */
>> +      return key.unicode_char;
>>      else if (key.scan_code < ARRAY_SIZE (efi_codes))
>>        return efi_codes[key.scan_code];
>>
>> In some remote systems EFI serial redirection must be enabled and thus
>> we cannot use serial (as termianl_input) module in GRUB2 and in such
>> case it would be good to allow add support for ctrl-x/ctrl-c under GRUB2
>> via serial console redirection enabled in EFI and attached USB keyboard.
>>
>> Regrads
>> Pawel Wojtalczyk
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: ctrl-x / ctrl-c may not work under GRUB2 with EFI

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.08.2013 10:35, Pawel Wojtalczyk wrote:
> +#if defined (__i386__) || defined (__x86_64__)
> +    if (key.unicode_char < 0x20 && key.unicode_char != 0 &&
> key.unicode_char != '\t' && key.unicode_char != '\b' && key.unicode_char
> != '\n' && key.unicode_char != '\r')
> +      return GRUB_TERM_CTRL | (key.unicode_char - 1 + 'a');
> +    else
> +#endif /* defined (__i386__) || defined (__x86_64__) */
> +      return key.unicode_char;
>     else if (key.scan_code < ARRAY_SIZE (efi_codes))
This results in an ambigous else which should be avoided. Also I see no 
reason to restrict this to x86 as other platforms are likely to have the 
same bug. Also it requires a comment as to why this workaround is 
necessarry. Please supply a ChangeLog entry.