[Xorg] Clavier en qwerty apres mise a jour noyau linux 3.2..

[Tetsumaki]

Je ne les ai pas blacklisté.
Ça faisait partit d'autres tests.

[tuxce]

J'ai du rater un truc Tu as essayé de blacklister suite au conseil de benjarobin :

Dans /boot/syslinux/syslinux.cfg :

Code : Tout sélectionner

APPEND root=... modprobe.blacklist=hid_logitech,hid_logitech_dj

Dans /etc/modprobe.d/modprobe.conf :

Code : Tout sélectionner

blacklist hid_logitech
blacklist hid_logitech_dj
install hid_logitech /bin/false
install hid_logitech_dj /bin/false

or :

mais de cette façon le clavier ne fonctionne plus du tout :

C'est peut être normal si tu blacklistes hid_logitech

Enfin bref, le truc, c'est que vu la fréquence de mise à jour des noyaux sur Arch, recompiler chaque noyau juste pour supprimer un module, c'est disproportionné surtout que ne pas avoir un noyau == ne pas le charger.
Mais après tout, chacun est administrateur de sa machine

[Tetsumaki]

En fait sur les tests précédents j'ai testé le blacklistage de 3 manières :
- blacklist/désactivation de hid_logitech
- blacklist/désactivation de hid_logitech_dj
- blacklist/désactivation de hid_logitech et hid_logitech_dj

Dans le 1er cas je ne sais plus si le clavier était en anglais ou alors ne marchait pas.
Dans les 2 autres le clavier ne marchait pas.
Avec un dmesg | grep hid je voyais que hid-generic ne prenait pas la main.

Après en avoir eu marre de passer des heures la dessus j'en suis venu à la solution de recompiler le kernel en faisant un paquet.

[benjarobin]

Personnellement j'aurai simplement essayé de blacklister hid_logitech_dj
Et forcer le chargement de hid-generic

[DomS]

J'ai tente avec /etc/udev/rules.d/111-kbd.ru.rules
Mon fichier est comme cela

Code : Tout sélectionner

## via Xorg
ACTION=="add", KERNEL=="event?", SUBSYSTEMS=="usb",ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b",RUN+="/usr/bin/setxkbmap -model pc104 -layout us,ru -variant ,winkeys,winkeys"
ACTION=="remove", KERNEL=="event?", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", RUN+="/usr/bin/setxkbmap -model 102 -layout us_intl"

sachant que lsusb me retourne

Code : Tout sélectionner

$ lsusb
Bus 003 Device 002: ID 046d:c068 Logitech, Inc. G500 Laser Mouse
Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 004 Device 003: ID 046d:c525 Logitech, Inc. MX Revolution Cordless Mouse

Ca ne marche pas chez moi. Je vais essayer de blacklister hid_logitech_dj

[Tetsumaki]

Personnellement j'aurai simplement essayé de blacklister hid_logitech_dj
Et forcer le chargement de hid-generic

De quelle façon exactement ?
Personnellement j'ai essayé comme ceci :

/etc/modprobe.d/modprobe.conf :

Code : Tout sélectionner

blacklist hid_logitech_dj
install hid_logitech_dj /bin/false

/etc/modules-load.d/modules-load.conf :

Code : Tout sélectionner

hid_generic

Mais ça ne marche pas, le clavier ne fonctionne pas.

[DomS]

Meme echec mais en creant un fichier /etc/modprobe.d/hid-generic.conf

[tuxce]

Il faudrait pouvoir faire un diff entre les /proc/config.gz ainsi que les lsmod pour voir ce qui diffère entre les 2 noyaux.

[DomS]

Au cas où ça mettrait quelqu'un sur la voie,lorsque je branche en même temps mon ancien clavier, le K800 est reconnu en azerty

[DomS]

Bonjour.
Gros soucis ce matin, impossible de contrôler quoi que ce soit. Clavier et souris ne fonctionnaient pas. J'ai dû supprimer à l'aide d'une autre distribution les fichiers de blacklist et de chargement forcé de module. Mais maintenant, même branché en même temps que mon ancien clavier, le K800 est en kwerty.

[Rapty]

Bonjour

Pour ceux chez qui le problème (retour en qwerty des claviers logitech unifying avec les derniers noyaux, suite à une évolution du driver) persiste :
il suffit de re-appliquer setxkbmap (à la rigueur setxkbmap fr) au besoin.

Dans le fichier local xinitrc cela n'affectera que la session de l'utilisateur qui vient de se connecter (donc, ce n'est pas assez tôt).
Les gestionnaires de connexions ont eux aussi besoin de cette re-application.

Par exemple, sous LXDM, c'est le fichier /etc/lxdm/LoginReady qui va aplliquer, en root, les dernières commandes avant l'apparition de l'écran de Login.
C'est donc là qu'il faut placer le setxkbmap.

(Ne pas oublier de rendre LoginReady exécutable)

Cela devrait être pareil pour les autres gestionnaires (sauf gdm qui de mémoire, l'applique déjà de lui même sans lui préciser)

[DomS]

Merci pour l'info. Je suis sous slim. Cela signifie qu'il faut que je rajoute :
setxkbmap fr
dans le fichier /etc/slim.conf ?

[Rapty]

je ne connais pas SLIM
mais je ne pense pas... dis comme ça on dirait que slim.conf ne contient que des paramètres... alors que setxkbmap a besoin d'être exécuté.

Il y a pas un scipt prelogin qui est exécuté avec SLIM ?

Quoique ici ils semblent dire qu'on peut utiliser le slim.conf pour faire passer des commandes :
https://wiki.archlinux.org/index.php/SL ... n_Commands

je n'ai pas je ne peux pas essayer...

[DomS]

Je réponds avec du retard mais YES ! ça marche pour moi sous Slim.
Effectivement il suffit de rajouter une ligne

Code : Tout sélectionner

sessionstart_cmd        setxkbmap

à /etc/slim.conf et le tour est joué