Grub-pc usb_keyboard keymap fr

Support Debian
#1

Bonjour,

Il aura fallu du temps pour que grub-pc rende possible la configuration du clavier en français.
Malheureusement, ça ne fonctionne uniquement avec le module at_keyboard.

Pour un clavier usb (pourtant courant), il est tout simplement impossible de configurer le mappage du clavier pour le module usb_keyboard (bug connu).

En m’inspirant de [ Grub2 et azerty ] qui est bien sûr obsolète aujourd’hui, j’ai essayé de trouver quel fichier, quel module de grub pourrait être modifié directement en hexa pour avoir un clavier français aussi pour usb_keyboard.
Rien à faire: même en modifiant keylayouts.mod qui contient l’alphabet de manière explicite, remplacer “a” par “q” n’a strictement aucun effet.

Si quelqu’un d’assez pointu sur grub-pc trouvait une combine, ce serait pas mal.

ps: quand-même gonflant en 2017 d’être encore emmerdé avec ça, alors que grub-legacy ne posait aucun problème de configuration clavier.

Merci

Installation from scratch
#2

Salut
quand je suis sur une utilisation d’un logiciel qui a défini le clavier en qwerty j’utilise la commande

setxkbmap fr

ce qui sur un clavier matériellement azerty s’écrit ainsi

setxkb,qp fr

quand j’interroge ça donne ça

 setxkbmap -query
rules:      evdev
model:      hpdv5
layout:     fr,us,fr
variant:    latin9,,oss
options:    compose:rwin,terminate:ctrl_alt_bksp,eurosign:e
#3

Alors je n’ai pas du être assez clair dans le titre.
=> Je cherche à configurer le clavier pour le terminal de Grub-pc, et non pas celui d’un environnement linux !!

Pour info, je cite: "_Commenting out terminal_input at_keyboard or replacing “at_keyboard” with “usbkeyboard" both restored keyboard functionality, however my keymaps didn’t work and I was forced to type my long passwords slowly in the QWERTY layout. It’s very very incovenient.”

voir bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464#73

#4

ok peut-être :joy: tu es donc sur le prompt >

as tu essaye

> setxkb,qp fr

#5

Pour que je ne reboote pas pour rien, tu es bien sûr que setxkb est une commande de grub-pc ?
Je ne la trouve pas dans la doc: https://www.gnu.org/software/grub/manual/grub/grub.html , ou j’ai mal cherché ?

=>> ne pas confondre la console/terminal de linux, avec celui de grub-pc : rien à voir !!

#6

je vois que tu lis pas
il s’agit de la commande setxkbmap

exprimé sur un clavier azerty que le logiciel comprends comme un clavier qwerty ca devient la suite de touche setxkb,qp

c’est vrai qu’1 boot c’est dramatique :joy:

#7

La commande setxkbmap n’est pas non plus une commande de grub-pc !
Quelle doc de grub-pc utilises-tu exactement ?

La bilble, c’est celle là https://www.gnu.org/software/grub/manual/grub/grub.html , à ma connaissance.

Si une simple commande pouvait résoudre le bug du mappage du module usb_keyboard, je pense que ça se serait su depuis le temps que ce bug est connu !!!

C’est pour ça que j’en appelle à un expert de grub-pc qui aurait réussi à résoudre ce bug en attaquant un module à l’éditeur Hexa.

#8

ça à l’air de se jouer en utilisant les commandes grub-kbdcomp grub-mklayout

#9

Ça pourrait avoir l’air. J’ai déjà regardé tout ça.
Mais si le mappage de l’usb_keyboard ne fonctionne pas, quasiment aucune chance que refaire un core.img ne résolve.
Le mappage clavier n’est prévu que pour at_keyboard; c’est vraiment très ballot, mais c’est comme ça.
Je ne vois aucune chaîne qwerty dans boot.img qui pourrait laisser supposer une solution triviale.
“sediseasy” avait déjà bien creusé le sujet (voir mon premier message).
Mais je ne sais pour quelle raison, c’est devenu plus compliqué de tripoter tout ça directement en Hexa (même pour at_keyboard où on ne trouve plus de chaîne qwerty aussi évidente qu’avant)
Le sujet est pointu, et pas tout-à-fait du “Debian”, mais je me dis que j’ai plus de chance de trouver des gens qui ont creusé ce sujet sur un forum français, que pour des gens à clavier qwerty qui se moquent bien de tout ça (à condition de TRES bien connaître grub-pc et ses faiblesses, et de ne pas confondre console grub-pc, avec console linux…)

#10

Bonsoir

Peut-être par là : https://wiki.archlinux.org/index.php/Talk:GRUB#Custom_keyboard_layout

#11

Déjà vu tout ça !

GRUB_TERMINAL_INPUT=at_keyboard

Aucun souci avec at_keyboard…
Le sujet est bien usb_keyboard !
Il est même bien précisé:
" If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout…"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464

ps: Si je cherche une solution bazouka directement dans mon premier message, c’est que grub-pc est éternellement en version beta depuis au moins 5 ans, et que ce bug d’usb_keyboard a toute chance d’encore exister dans 10 ans, vu la vitesse de progression.

#12

Bon, petit point sur le sujet mappage usb_keyboard, qui intéressera peu de monde, mais sûrement au moins ceux qui utilisent grub-pc pas uniquement pour booter un système installé.

D’abord, j’ai recompilé grub-pc à partir de git pour en faire un grub autonome totalement indépendant du système, et placer boot.img et core.img dans le MBR d’un disque externe, pour y voir plus clair.

git clone git://git.savannah.gnu.org/grub.git

Ensuite, j’ai trouvé des choses très intéressantes dans les fichiers sources:

git/grub/grub-core/term/usb_keyboard.c

#include <grub/keyboard_layouts.h>

=> intéressant à décommenter
et
git/grub/include/grub/keyboard_layouts.h

typedef enum grub_keyboard_key
  {
    GRUB_KEYBOARD_KEY_A = 0x04,
    GRUB_KEYBOARD_KEY_B = 0x05,
    GRUB_KEYBOARD_KEY_C = 0x06,
    GRUB_KEYBOARD_KEY_D = 0x07,
    ...
}

Je n’ai pas été jusqu’au bout pour réussir à avoir usb_keyboard compatible avec un clavier azerty, mais si un courageux s’intéresse au sujet, 80/90% de l’investigation est faite.

#13

Si c’était juste pour ça, alors recompiler GRUB était totalement inutile : c’est parfaitement possible avec la commande grub-install de la distribution.

La boot image d’accord, mais certainement pas la core image : elle est bien trop volumineuse pour contenir dans un secteur, et de tout façon le MBR est déjà occupé par la boot image.

En langage C, le # ne signale pas un commentaire mais une commande du préprocesseur comme la commande #include.

#14

Grub-install peut bien sûr être utilisé en standard, mais je ne fais justement pas une opération “standard” mais cherche à modifier le mappage clavier directement dans core.img.
J’ai donc préféré repartir à partir de quelque-chose de propre et vierge et totalement indépendant du système, à partir de git.
C’est un choix personnel, car je voulais aussi voir les sources … pour voir les fichiers intéressants.

Il n’y a pas pour le moment de solution identifiée pour modifier le mappage clavier de usb_keyboard sans compilation => voir l’objet du sujet.

!! le fichier core.img de l’OS est déjà fabriqué pour indiquer au boot sur quelle partition se trouvent les fichiers de /boot/grub du système installé !! / donc pas directement utilisable.

Le boot.img est situé entre 0 et 446 du MBR.
Ensuite, tu as la table de partition.
Ensuite, à partir de 512, core.img qui doit être de taille inférieure à 32Ko (celui que j’ai fabriqué fait 29Ko).
Si tu regardes la taille du fichier /boot/grub/i386-pc/core.img de ta Debian, tu verras qu’il fait environ 25Ko.
Donc strictement aucune anomalie sur la taille de core.img.

Et ensuite, tu arrives au premier secteur de boot de la première partition => c’est pour ça que core.img doit être inférieur à 32Ko.
Pour faire le parallèle avec grub-legacy, boot.img est le stage 1, et core.img le stage 2, si tu connais grub-legacy.

Maintenant, si tu sais comment continuer avec les fichiers sources pour que le mappage clavier de usb_keyboard soit en azerty dès l’initialisation de core.img, you’re welcome !!
La solution ne doit pas être bien loin.

#15

Ce fichier est regénéré à chaque exécution de grub-install, en fonction des options fournies.[quote=“Verner, post:14, topic:74865”]
Ensuite, à partir de 512, core.img
[/quote]
Non, pas forcément. Il y a d’autres emplacements possibles.

Non, pas forcément.

Regarde où se trouve ce secteur sur un disque partitionné il n’y a pas trop longtemps : la position standard est 2048, donc 1 Mio.

Il n’y a pas de parallèle possible car les rôles sont différents, mais par sa position core.img correspondrait plutôt au stage 1.5.

#16

@PascalHambourg
Je ne sais pas du tout où tu veux en venir.
Je n’ai strictement aucun problème de gestion de boot loaders, qui fonctionnent parfaitement, même avec un core.img écrit à la suite de la table de partition (ce que fait d’ailleurs grub-install…) et tes “non pas forcément”, je pourrais répondre, "oui évidemment, mais et alors ? ".
Evidemment qu’il n’y a jamais de solution unique, et plein de possibilités, et tu choisis celle qui te convient le mieux pour ton utilisation personnelle.

Le sujet n’est vraiment pas là, mais pas du tout !!!

Rappel du sujet: comment mapper un clavier usb en azerty, avec donc utilisation du module usb_keyboard. => c’est ça la question.

Je serai ravi de développer toutes les solutions et possibilités de loaders, j’en connais pas mal pour les pratiquer, mais ce n’est franchement pas le sujet ici !!
Merci.

#17

Petit point sur le sujet, au cas où un utilisateur de Debian s’y intéresse un jour au jour.
Il n’y a en fait pas un problème, mais deux.

1 - Après modification consciencieuse du fichier /include/grub/keyboard_layouts.h pour l’adapter à l’azerty, le fichier /util/grub_mklayout-grub-mklayout.o se plaint de cette modification

In file included from util/grub-mklayout.c:24:0:
./include/grub/keyboard_layouts.h:81:5: error: redeclaration of enumerator ‘GRUB_KEYBOARD_KEY_LBRACKET’
     GRUB_KEYBOARD_KEY_LBRACKET = 0x2f,
./include/grub/keyboard_layouts.h:68:5: note: previous definition of ‘GRUB_KEYBOARD_KEY_LBRACKET’ was here
     GRUB_KEYBOARD_KEY_LBRACKET = 0x22,
./include/grub/keyboard_layouts.h:82:5: error: redeclaration of enumerator ‘GRUB_KEYBOARD_KEY_RBRACKET’
     GRUB_KEYBOARD_KEY_RBRACKET = 0x30,
./include/grub/keyboard_layouts.h:79:5: note: previous definition of ‘GRUB_KEYBOARD_KEY_RBRACKET’ was here
     GRUB_KEYBOARD_KEY_RBRACKET = 0x2d,
./include/grub/keyboard_layouts.h:84:5: error: redeclaration of enumerator ‘GRUB_KEYBOARD_KEY_COMMA’
     GRUB_KEYBOARD_KEY_COMMA = 0x33,
         ./include/grub/keyboard_layouts.h:50:5: note: previous definition of ‘GRUB_KEYBOARD_KEY_COMMA’ was here
     GRUB_KEYBOARD_KEY_COMMA = 0x10,
         util/grub-mklayout.c:219:14: error: ‘GRUB_KEYBOARD_KEY_5’ undeclared here (not in a function)
   /* 0x06 */ GRUB_KEYBOARD_KEY_5,           GRUB_KEYBOARD_KEY_6,
       util/grub-mklayout.c:222:14: error: ‘GRUB_KEYBOARD_KEY_DASH’ undeclared here (not in a function)
   /* 0x0c */ GRUB_KEYBOARD_KEY_DASH,        GRUB_KEYBOARD_KEY_EQUAL,
       util/grub-mklayout.c:235:45: error: ‘GRUB_KEYBOARD_KEY_SEMICOLON’ undeclared here (not in a function)
   /* 0x26 */ GRUB_KEYBOARD_KEY_L,           GRUB_KEYBOARD_KEY_SEMICOLON,
   
Makefile:8944 : la recette pour la cible « util/grub_mklayout-grub-mklayout.o » a échoué

… alors que la modification n’est pas une “erreur”, mais l’objectif recherché !!
J’atteinds là les limites du bricolage.

2 - autre problème plus vicieux:
Avec un clavier USB et avec le module usb_keyboard correctement chargé, et “terminal_input usb_keyboard” bien excecuté, après vérification, on s’aperçoit que terminal_input rejette usb_leyboard, et reprend la valeur “console” par défaut.

En résumé, ce n’est pas uniquement au module usb_keyboard qu’il faut s’intéresser lors de la recompilation, mais au mappage clavier du module générique “console”.

Il est évident qu’il y a bien un russe ou un chinois ou un japonais ou indien qui a déjà recompilé grub pour corriger ce problème de mappage clavier, mais à part l’anglais, je suis une quiche en russe ou chinois.

Si quelqu’un multi-langues pouvait regarder ce qui se dit sur la solution de ce problème, ça pourrait être intéressant.