Le noyau lit sur le port ps/2 ou usb sur lequel le clavier envoie ses codes keymap (en fait sur un portable c'est la même chose, c'est juste que la prise est shuntée)
C'est ce postulat de base qui me dérange. Tout ce qui suit en découle directement, du reste. Je pense que le clavier d'un portable est géré par un hardware propriétaire (puisqu'il est directement accessible, et non pas délocalisé et visible uniquement au travers du port PS/2 et du câble qui y est relié) et qu'à ce titre, la touche « Fn » qui, jusqu'à indication contraire, ne fait pas partie des spécifications PC standard et que l'on ne trouve pas sur un clavier autonome, n'est pas associée à un scancode donné.
Des tests effectués avec mon Toshiba 2410 montrent que ni xev, ni showkey -k, ni showkey -s (en mode console pour les deux derniers) ne renvoient d'événement pour un appui sur « Fn ». Par contre, j'en reçois quand je la combine avec certaines touches seulement, à savoir les modificateurs (Alt, Shift, etc) et les touches auxquelles une fonction spéciale Fn est associée, et seulement si cette fonction consiste à renvoyer un caractère comme, par exemple, le mappage du pavé numérique. Et même dans ce cas précis, je reçois alors le scancode de la touche sur laquelle j'ai appuyé, pas celle du pavé auquel elle est censée appartenir. Et dans tous les cas, aucune mention de la touche « Fn » elle-même.
Chose curieuse, l'utilisation de « Fn » prime sur tout le reste, commande showkey comprise, pour ce qui est de changer le périf vidéo de sortie, parce que c'est critique. Par contre, tout ce qui est réglage de luminosité, etc. est géré en userland, donc jamais par défaut sous Linux.
Autre chose intéressante : « Fn » utilisée avec les touches F10 ou F11 permet de simuler le Num Lock. Pas de scancode pour cette touche, donc, mais deux LED distinctes et mutuellement exclusives. D'autre part, chaque LED fonctionne en mode bascule, en passant du mode normalement allumé au mode normalement éteint et réciproquement sur sollicitation répetée des combinaisons « Fn + F10 » ou « Fn + F11 ». En temps normal, cela fonctionne très bien (et je ne crois pas que ce cas de figure précis soit pris en charge par Linux), mais sous une session showkey, la touche « Fn » fait bien réagir la LED, mais le mode ne change pas, car visiblement le code des touches F10 ou F11 est intercepté, mais pas celui de Fn.
Il fut d'ailleurs un temps où un « cat /proc/toshiba » renvoyait notamment un champ dont l'un des bits nous renseignait sur l'état de Fn, lorsque le module « toshiba » était bien chargé (je dis « il fut un temps » car mon dernier test ne fonctionne plus).
Donc, ce n'est pas simple, et c'est probablement spécifique à chaque constructeur.
[^] # Re: fnfx
Posté par Obsidian . En réponse au message a quel code corresponds la combinaison Fn+Fx(1-12) ?. Évalué à 2.
C'est ce postulat de base qui me dérange. Tout ce qui suit en découle directement, du reste. Je pense que le clavier d'un portable est géré par un hardware propriétaire (puisqu'il est directement accessible, et non pas délocalisé et visible uniquement au travers du port PS/2 et du câble qui y est relié) et qu'à ce titre, la touche « Fn » qui, jusqu'à indication contraire, ne fait pas partie des spécifications PC standard et que l'on ne trouve pas sur un clavier autonome, n'est pas associée à un scancode donné.
Des tests effectués avec mon Toshiba 2410 montrent que ni xev, ni showkey -k, ni showkey -s (en mode console pour les deux derniers) ne renvoient d'événement pour un appui sur « Fn ». Par contre, j'en reçois quand je la combine avec certaines touches seulement, à savoir les modificateurs (Alt, Shift, etc) et les touches auxquelles une fonction spéciale Fn est associée, et seulement si cette fonction consiste à renvoyer un caractère comme, par exemple, le mappage du pavé numérique. Et même dans ce cas précis, je reçois alors le scancode de la touche sur laquelle j'ai appuyé, pas celle du pavé auquel elle est censée appartenir. Et dans tous les cas, aucune mention de la touche « Fn » elle-même.
Chose curieuse, l'utilisation de « Fn » prime sur tout le reste, commande showkey comprise, pour ce qui est de changer le périf vidéo de sortie, parce que c'est critique. Par contre, tout ce qui est réglage de luminosité, etc. est géré en userland, donc jamais par défaut sous Linux.
Autre chose intéressante : « Fn » utilisée avec les touches F10 ou F11 permet de simuler le Num Lock. Pas de scancode pour cette touche, donc, mais deux LED distinctes et mutuellement exclusives. D'autre part, chaque LED fonctionne en mode bascule, en passant du mode normalement allumé au mode normalement éteint et réciproquement sur sollicitation répetée des combinaisons « Fn + F10 » ou « Fn + F11 ». En temps normal, cela fonctionne très bien (et je ne crois pas que ce cas de figure précis soit pris en charge par Linux), mais sous une session showkey, la touche « Fn » fait bien réagir la LED, mais le mode ne change pas, car visiblement le code des touches F10 ou F11 est intercepté, mais pas celui de Fn.
Il fut d'ailleurs un temps où un « cat /proc/toshiba » renvoyait notamment un champ dont l'un des bits nous renseignait sur l'état de Fn, lorsque le module « toshiba » était bien chargé (je dis « il fut un temps » car mon dernier test ne fonctionne plus).
Donc, ce n'est pas simple, et c'est probablement spécifique à chaque constructeur.