Fix keyboard layouts other than us
Hi there,
I've been trying to set up my grub for my Dvorak keyboard. It seems
that everywhere I look points to something like:
insmod keylayouts
keymap /boot/grub/bepo.gkb
In practice however, this does NOT work at all.
After some debugging, here's what I've found:
- grub-core/commands/keylayouts.c has grub_term_map_key() which does
the actual mapping.
- This function is only referred by
- grub-core/term/at_keyboard.c (via ps2.c)
- grub-core/term/usb_keyboard.c
In my case, at GRUB command prompt, terminal_input tells:
- Current terminal is console.
- Neither at_keyboard nor usb_keyboard are available.
So no wonder the keymap does not work...
I drafted the attached patch to grub-core/term/efi/console.c and
grub-core/i386/pc/console.c, which should make use of
grub_term_map_key() and fix the problem. I unfortunately can't test it
because of this Ubuntu build issue
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1914953/comments/7
... separate issue though.
Anyhow, any advice on whether this patch would / would not work?
It seems reasonable to me that keyboard mapping should happen at
grub-core/kern/term.c at grub_getkey_noblock() instead though, as
fixing it there (immediately after term->getkey (term) call), in
theory, would fix things for all cases.
WDYT?
Thanks.
Fabio Pugliese Ornellas
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 715994872..e24603c32 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -205,6 +205,7 @@ kernel = {
efi = kern/efi/init.c;
efi = kern/efi/mm.c;
efi = term/efi/console.c;
+ efi = commands/keylayouts.c;
efi = kern/acpi.c;
efi = kern/efi/acpi.c;
efi = kern/efi/sb.c;
@@ -269,6 +270,7 @@ kernel = {
i386_pc = kern/i386/pc/init.c;
i386_pc = kern/i386/pc/mmap.c;
i386_pc = term/i386/pc/console.c;
+ i386_pc = commands/keylayouts.c;
i386_qemu = bus/pci.c;
i386_qemu = kern/vga_init.c;
diff --git a/grub-core/term/efi/console.c b/grub-core/term/efi/console.c
index a3622e4fe..37d5a971b 100644
--- a/grub-core/term/efi/console.c
+++ b/grub-core/term/efi/console.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
typedef enum {
GRUB_TEXT_MODE_UNDEFINED = -1,
@@ -374,13 +375,25 @@ grub_efi_console_input_init (struct grub_term_input *term)
static int
grub_console_getkey (struct grub_term_input *term)
{
+ int key;
+ int status = 0;
+
if (grub_efi_is_finished)
return 0;
if (term->data)
-return grub_console_getkey_ex(term);
+key = grub_console_getkey_ex(term);
else
-return grub_console_getkey_con(term);
+key = grub_console_getkey_con(term);
+
+ if (key & GRUB_TERM_SHIFT)
+status |= GRUB_TERM_STATUS_RSHIFT;
+ if (key & GRUB_TERM_ALT)
+status |= GRUB_TERM_STATUS_RALT;
+ if (key & GRUB_TERM_CTRL)
+status |= GRUB_TERM_STATUS_RCTRL
+
+ return grub_term_map_key(key & GRUB_TERM_KEY_MASK, status);
}
static struct grub_term_coordinate
diff --git a/grub-core/term/i386/pc/console.c b/grub-core/term/i386/pc/console.c
index 9403390f1..b7b3bfc12 100644
--- a/grub-core/term/i386/pc/console.c
+++ b/grub-core/term/i386/pc/console.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
static grub_uint8_t grub_console_cur_color = 0x7;
@@ -183,6 +184,21 @@ grub_console_setcursor (struct grub_term_output *term __attribute__ ((unused)),
grub_bios_interrupt (0x10, ®s);
}
+static int
+map_key (int key)
+{
+ int status = 0;
+
+ if (key & GRUB_TERM_SHIFT)
+status |= GRUB_TERM_STATUS_RSHIFT;
+ if (key & GRUB_TERM_ALT)
+status |= GRUB_TERM_STATUS_RALT;
+ if (key & GRUB_TERM_CTRL)
+status |= GRUB_TERM_STATUS_RCTRL;
+
+ return grub_term_map_key(key & GRUB_TERM_KEY_MASK, status);
+}
+
/*
* if there is a character pending, return it; otherwise return -1
* BIOS call "INT 16H Function 01H" to check whether a character is pending
@@ -226,16 +242,16 @@ grub_console_getkey (struct grub_term_input *term __attribute__ ((unused)))
regs.flags = GRUB_CPU_INT_FLAGS_DEFAULT;
grub_bios_interrupt (0x16, ®s);
if (!(regs.eax & 0xff))
-return ((regs.eax >> 8) & 0xff) | GRUB_TERM_EXTENDED;
+return map_key (((regs.eax >> 8) & 0xff) | GRUB_TERM_EXTENDED);
if ((regs.eax & 0xff) >= ' ')
-return regs.eax & 0xff;
+return map_key (regs.eax & 0xff);
for (i = 0; i < ARRAY_SIZE (bypass_table); i++)
if (bypass_table[i] == (regs.eax & 0x))
- return regs.eax & 0xff;
+ return map_key (regs.eax & 0xff);
- return (regs.eax & 0xff) + (('a' - 1) | GRUB_TERM_CTRL);
+ return map_key ((regs.eax & 0xff) + (('a' - 1) | GRUB_TERM_CTRL));
}
static int
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fix keyboard layouts other than us
Le dim. 31 juil. 2022, 12:41, Fabio Pugliese Ornellas < fabio.ornel...@gmail.com> a écrit : > Hi there, > > I've been trying to set up my grub for my Dvorak keyboard. It seems > that everywhere I look points to something like: > > insmod keylayouts > keymap /boot/grub/bepo.gkb > > In practice however, this does NOT work at all. > > After some debugging, here's what I've found: > > - grub-core/commands/keylayouts.c has grub_term_map_key() which does > the actual mapping. > - This function is only referred by > - grub-core/term/at_keyboard.c (via ps2.c) > - grub-core/term/usb_keyboard.c > > In my case, at GRUB command prompt, terminal_input tells: > > - Current terminal is console. > - Neither at_keyboard nor usb_keyboard are available. > > So no wonder the keymap does not work... > > I drafted the attached patch to grub-core/term/efi/console.c and > grub-core/i386/pc/console.c, which should make use of > grub_term_map_key() and fix the problem. I unfortunately can't test it > because of this Ubuntu build issue > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1914953/comments/7 > ... separate issue though. > > Anyhow, any advice on whether this patch would / would not work? > > It seems reasonable to me that keyboard mapping should happen at > grub-core/kern/term.c at grub_getkey_noblock() instead though, as > fixing it there (immediately after term->getkey (term) call), in > theory, would fix things for all cases. > > WDYT? > Mostly doesn't work. Firmware services and (even more) serial terminal lack information like Right Alt press and 102nd key. Without them many layouts are unusable > > Thanks. > > Fabio Pugliese Ornellas > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v6 1/1] plainmount: Support plain encryption mode
From 683357e227467c05272facc7da534a82becc9d8a Mon Sep 17 00:00:00 2001
From: Maxim Fomin
Date: Sun, 31 Jul 2022 14:06:42 +0100
Subject: [PATCH v6 1/1] plainmount: Support plain encryption mode
This patch adds support for plain encryption mode (plain dm-crypt) via
new module/command named 'plainmount'.
Signed-off-by: Maxim Fomin
---
docs/grub.texi | 80 +++
grub-core/Makefile.core.def | 5 +
grub-core/disk/plainmount.c | 450
3 files changed, 535 insertions(+)
create mode 100644 grub-core/disk/plainmount.c
diff --git a/docs/grub.texi b/docs/grub.texi
index af119dea3..22c73580c 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4265,6 +4265,7 @@ you forget a command, you can run the command
@command{help}
* parttool::Modify partition table entries
* password::Set a clear-text password
* password_pbkdf2:: Set a hashed password
+* plainmount:: Open device encrypted in plain mode
* play::Play a tune
* probe:: Retrieve device info
* rdmsr:: Read values from model-specific registers
@@ -4552,6 +4553,14 @@ function is supported, as Argon2 is not yet supported.
Also, note that, unlike filesystem UUIDs, UUIDs for encrypted devices must be
specified without dash separators.
+
+Successfully decrypted disks are named as (cryptoX) and have increasing
numeration
+suffix for each new decrypted disk. If the encrypted disk hosts some higher
level
+of abstraction (like LVM2 or MDRAID) it will be created under a separate device
+namespace in addition to the cryptodisk namespace.
+
+Support for plain encryption mode (plain dm-crypt) is provided via separate
+@command{@pxref{plainmount}} command.
@end deffn
@node cutmem
@@ -5060,6 +5069,77 @@ to generate password hashes. @xref{Security}.
@end deffn
+@node plainmount
+@subsection plainmount
+
+@deffn Command plainmount device @option{-c} cipher @option{-s} key size
[@option{-h} hash]
+[@option{-S} sector size] [@option{-p} password] [@option{-u} uuid]
+[[@option{-d} keyfile] [@option{-O} keyfile offset]]
+
+
+Setup access to the encrypted device in plain mode. Offset of the encrypted
+data at the device is specified in terms of 512 byte sectors with the blocklist
+syntax and loopback device. The following example shows how to specify 1MiB
+offset:
+
+@example
+loopback node (hd0,gpt1)2048+
+plainmount node
+@end example
+
+The @command{plainmount} command can be used to open LUKS encrypted volume
+if its master key and parameters (key size, cipher, offset, etc) are known.
+
+There are two ways to specify password: a keyfile and a secret passphrase.
+Keyfile path parameter has higher priority than secret passphrase and is
+specified with the option @option{-d}. Password data obtained from keyfiles
+is not hashed and is used directly as a cipher key. Optional offset of password
+data in the keyfile can be specified with the option @option{-O} or directly
+with the option @option{-d} and GRUB blocklist syntax. The following example
+shows both methods to specify password data in the keyfile at offset 1MiB:
+
+@example
+plainmount -d (hd0,gpt1)2048+
+plainmount -d (hd0,gpt1) -O 1048576
+@end example
+
+If no keyfile is specified then the password is set to data specified by
+option @option{-p} or is requested interactively from the console. In both
+cases the provided password is hashed with the algorithm specified by the
+option @option{-h}. This option is mandatory if no keyfile is specified, but
+it can be set to @code{plain} which means that no hashing is done and such
+password is used directly as a key.
+
+Cipher @option{-c} and keysize @option{-s} options specify the cipher
+algorithm and the key size respectively and are mandatory options. Cipher
+must be specified with the mode separated by a dash (for example,
+'aes-xts-plain64'). Key size option @option{-s} is the key size of the cipher,
+not to be confused with the offset of the key data in a keyfile specified with
+the @option{-O} option. It must not exceed 128 bytes and must be specified in
+bits (so a 32 byte key would be specified as 256 bits).
+
+The optional parameter @option{-S} specifies encrypted device sector size. It
+must be at least 512 bytes long (default value) and a power of 2.
@footnote{Current
+implementation of cryptsetup supports only 512/1024/2048/4096 byte sectors}.
+Disk sector size is configured when creating the encrypted volume. Attempting
+to decrypt volumes with a different sector size than it was created with will
+not result in an error, but will decrypt to random bytes and thus prevent
+accessing the volume (in some cases filesystem driver can detect the filesystem
+presense, but nevertheless will refuse to mount it).
+
+By default new plainmount devices will be given a UUID starting with
+'109fea84-a6b7-34a8-4bd1-1c506305a401' where the last digits are incremented
+by o
Re: [PATCH v5 2/9] Add LoongArch definitions
在 2022-07-29星期五的 15:31 +0800，WANG Xuerui写道： > On 2022/7/29 15:11, Xiaotian Wu wrote: > > Signed-off-by: Xiaotian Wu > > Signed-off-by: Zhou Yang > > --- > > include/grub/elf.h | 23 +++ > > 1 file changed, 23 insertions(+) > > > > diff --git a/include/grub/elf.h b/include/grub/elf.h > > index c478933ee..1c8d4f5d5 100644 > > --- a/include/grub/elf.h > > +++ b/include/grub/elf.h > > @@ -248,6 +248,7 @@ typedef struct > > #define EM_NUM95 > > #define EM_AARCH64183 /* ARM 64-bit architecture > > */ > > #define EM_RISCV 243 /* RISC-V */ > > +#define EM_LOONGARCH 258 /* LoongArch */ > > > > /* If it is necessary to assign new unofficial EM_* values, > > please > > pick large random numbers (0x8523, 0xa7f2, etc.) to minimize > > the > > @@ -2531,6 +2532,28 @@ typedef Elf32_Addr Elf32_Conflict; > > #define R_RISCV_SET32 56 > > #define R_RISCV_32_PCREL 57 > > > > +/* LoongArch relocations */ > > +#define R_LARCH_NONE 0 > > +#define R_LARCH_64 2 > > +#define R_LARCH_MARK_LA 20 > > +#define R_LARCH_SOP_PUSH_PCREL 22 > > +#define R_LARCH_SOP_PUSH_ABSOLUTE 23 > > +#define R_LARCH_SOP_PUSH_PLT_PCREL 29 > > +#define R_LARCH_SOP_SUB 32 > > +#define R_LARCH_SOP_SL 33 > > +#define R_LARCH_SOP_SR 34 > > +#define R_LARCH_SOP_ADD 35 > > +#define R_LARCH_SOP_AND 36 > > +#define R_LARCH_SOP_IF_ELSE 37 > > +#define R_LARCH_SOP_POP_32_S_10_5 38 > > +#define R_LARCH_SOP_POP_32_U_10_12 39 > > +#define R_LARCH_SOP_POP_32_S_10_12 40 > > +#define R_LARCH_SOP_POP_32_S_10_16 41 > > +#define R_LARCH_SOP_POP_32_S_10_16_S2 42 > > +#define R_LARCH_SOP_POP_32_S_5_20 43 > > +#define R_LARCH_SOP_POP_32_S_0_5_10_16_S2 44 > > +#define R_LARCH_SOP_POP_32_S_0_10_10_16_S2 45 > > + > > Welp. This almost certainly needs some additional work, now that the > new-style relocs [1][2] are upstreamed, and bound to be generated > with > the combo of binutils 2.40 trunk and gcc 13.0 trunk. So we'll need to > support both flavors in order to stay compatible with both older and > newer toolchains. > > Do you think this part could be finished relatively quickly so as to > not > miss the next grub release? Yes, the new style relocation patch is done and visible on github[1], needs more testing and will be sent to the mailing list for review. [1] https://github.com/loongarch64/grub/pull/5 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
