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.

#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.

#18

La question du changement de langue de clavier avec usb_keyboard étant relancée dans un autre sujet, il est temps de donner la solution, rien n’ayant changé depuis 2017.
Il n’est officiellement toujours pas possible de changer la mapping clavier d’usb_keyboard. Mais, en fouillant l’historique de bugs grub-pc de 2017, on trouve en fait une solution de contournement.

[bug #51129] Keyboard not working using GRUB_TERMINAL_INPUT=« at_keyboard » for changing keyboar layout

at_keyboard only works if you have AT controller.
If your keyboard is connected through USB, you need to use nativedisk together with usb_keyboard.

Formulation un peu laconique qui demande un peu plus d’explications.
Parmi les 275 modules (!!) potentiellement appelés par grub, il y en a deux très spéciaux: biosdisk et nativedisk
L’un ou l’autre est impérativement le premier module dont a besoin grub pour démarrer, par défaut biosdisk.

  • biosdisk utilise les informations fournies par le BIOS pour identifier le matériel;
  • nativedisk fait abstraction du BIOS, et a son propre mécanisme d’identification du matériel.

Probablement pour des raisons de performance de vitesse de démarrage, nativedisk n’est pas utilisé par défaut.
Pour remplacer biosdisk par nativedisk, l’option --disk-module= doit être utilisée

# grub-install --disk-module=nativedisk <....>

Rappel pour faire le fichier fr.gkb de configuration clavier fr, qui nécessite l’installation du paquet xkb-data.

ls /usr/share/X11/xkb/symbols/fr

# ckbcomp fr |grub-mklayout -v -o /boot/grub/layouts/fr.gkb
ou
# grub-kbdcomp -o /boot/grub/layouts/fr.gkb fr

Configuration grub.cfg:

insmod keylayout
keymap /boot/grub/layouts/fr.gkb
# ou keymap fr 
terminal_input usb_keyboard
# ou terminal_input at_keyboard

Solution non précisée en 2017, car peu d’intérêt général pour ce forum, mais mieux vaut tard que jamais.

#19

Pour le grub.cfg, mieux vaut utiliser le fichier /etc/grub.d/40_custom pour y inclure les lignes (ce qui permet d’être sur que l’utilisation de update-grub n’écrasera pas les modifications.

#21

Comme quoi déterer des sujet vieux de 7 ans est une mauvaise idée (d’ailleurs il me semblait que c’était une mauvaise pratique).
Il aurait mieux valut que tu mettes ton messages dans le sujet que tu cites; sujet mis de coté du fait de la panne d’accès au site.
Mais le nativedisk est lui intéressant.

Et ca reste une mauvaise pratique d’aller modifier directement le grub.cfg qui se fera écraser au premier update-grub venu.
La méthode est aussi importante si on veut que des débutants puisse s’y retrouver.

#23

Évite les attaques personnelles dans un fil, ça fait aussi perdre du temps, voir plus.
Peux-tu clôturer @Clochette s’il te plaît? je t’en remercie.

#24