# [gdm]clavier qwerty

## DuF

Bonsoir à tous,

Je finalise la réinstallation de ma machine et un truc m'em....de pas mal => GDM se fou royalement de toutes mes tentatives de configuration pour qu'il prenne un clavier français....

En plus ça a un fort goût de "déjà vu" : https://forums.gentoo.org/viewtopic-t-858109-start-0.html

J'ai tenté un peu tous les trucs sioux que j'ai trouvé (fichier /etc/GDM/init/default) et autres joyeusetés....

Pour information le seul fichier dans /etc/X11/xorg.conf.d :

 *Quote:*   

> genduf ~ # cat /etc/X11/xorg.conf.d/09-keyboard_fr.conf 
> 
> Section "InputClass"
> 
> 	Identifier "keyboard FR"
> ...

 

A la base ce fichier n'existait pas et le résultat était le même.

Le log Xorg : 

```
[   208.356] (II) config/udev: Adding input device Power Button (/dev/input/event1)

[   208.356] (**) Power Button: Applying InputClass "evdev keyboard catchall"

[   208.356] (**) Power Button: Applying InputClass "keyboard FR"

[   208.356] (II) LoadModule: "evdev"

[   208.356] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[   208.356] (II) Module evdev: vendor="X.Org Foundation"

[   208.356]    compiled for 1.11.4, module version = 2.6.0

[   208.356]    Module class: X.Org XInput Driver

[   208.356]    ABI class: X.Org XInput driver, version 13.0

[   208.356] (II) Using input driver 'evdev' for 'Power Button'

[   208.356] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[   208.356] (**) Power Button: always reports core events

[   208.356] (**) Power Button: Device: "/dev/input/event1"

[   208.356] (--) Power Button: Found keys

[   208.356] (II) Power Button: Configuring as keyboard

[   208.356] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1"

[   208.356] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6)

[   208.356] (**) Option "xkb_rules" "evdev"

[   208.356] (**) Option "xkb_model" "evdev"

[   208.356] (**) Option "xkb_layout" "fr"

[   208.356] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

[   208.367] (II) config/udev: Adding input device Video Bus (/dev/input/event5)

[   208.367] (**) Video Bus: Applying InputClass "evdev keyboard catchall"

[   208.367] (**) Video Bus: Applying InputClass "keyboard FR"

[   208.367] (II) Using input driver 'evdev' for 'Video Bus'

[   208.367] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[   208.367] (**) Video Bus: always reports core events

[   208.367] (**) Video Bus: Device: "/dev/input/event5"

[   208.367] (--) Video Bus: Found keys

[   208.367] (II) Video Bus: Configuring as keyboard

[   208.367] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5/event5"

[   208.367] (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 7)

[   208.367] (**) Option "xkb_rules" "evdev"

[   208.367] (**) Option "xkb_model" "evdev"

[   208.367] (**) Option "xkb_layout" "fr"

[   208.367] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

[   208.367] (II) config/udev: Adding input device Power Button (/dev/input/event0)

[   208.367] (**) Power Button: Applying InputClass "evdev keyboard catchall"

[   208.367] (**) Power Button: Applying InputClass "keyboard FR"

[   208.367] (II) Using input driver 'evdev' for 'Power Button'

[   208.367] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[   208.367] (**) Power Button: always reports core events

[   208.367] (**) Power Button: Device: "/dev/input/event0"

[   208.367] (--) Power Button: Found keys

[   208.367] (II) Power Button: Configuring as keyboard

[   208.367] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0/event0"

[   208.367] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 8)

[   208.367] (**) Option "xkb_rules" "evdev"

[   208.367] (**) Option "xkb_model" "evdev"

[   208.367] (**) Option "xkb_layout" "fr"

[   208.367] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

[   208.368] (II) config/udev: Adding input device Logitech Unifying Device. Wireless PID:4002 (/dev/input/event2)

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: Applying InputClass "evdev keyboard catchall"

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: Applying InputClass "keyboard FR"

[   208.368] (II) Using input driver 'evdev' for 'Logitech Unifying Device. Wireless PID:4002'

[   208.368] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: always reports core events

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: Device: "/dev/input/event2"

[   208.368] (--) Logitech Unifying Device. Wireless PID:4002: Found 1 mouse buttons

[   208.368] (--) Logitech Unifying Device. Wireless PID:4002: Found scroll wheel(s)

[   208.368] (--) Logitech Unifying Device. Wireless PID:4002: Found relative axes

[   208.368] (--) Logitech Unifying Device. Wireless PID:4002: Found absolute axes

[   208.368] (--) Logitech Unifying Device. Wireless PID:4002: Found keys

[   208.368] (II) Logitech Unifying Device. Wireless PID:4002: Configuring as mouse

[   208.368] (II) Logitech Unifying Device. Wireless PID:4002: Configuring as keyboard

[   208.368] (II) Logitech Unifying Device. Wireless PID:4002: Adding scrollwheel support

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: YAxisMapping: buttons 4 and 5

[   208.368] (**) Logitech Unifying Device. Wireless PID:4002: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200

[   208.368] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.2/0003:046D:C52B.0003/input/input2/event2"

[   208.368] (II) XINPUT: Adding extended input device "Logitech Unifying Device. Wireless PID:4002" (type: KEYBOARD, id 9)

[   208.368] (**) Option "xkb_rules" "evdev"

[   208.368] (**) Option "xkb_model" "evdev"

[   208.368] (**) Option "xkb_layout" "fr"

[   208.368] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

[   208.368] (EE) Logitech Unifying Device. Wireless PID:4002: failed to initialize for relative axes.

```

Entre nous je trouve certains messages choquants si je peux me permettre l'expression. Configurer power button et video bus comme "keyboard" c'est un peu....

Sinon sous les consoles TTY je suis bien en fr et sous gnome je suis aussi en fr.

Les locales du systèmes :  *Quote:*   

> genduf ~ # locale
> 
> LANG=fr_FR.utf8
> 
> LC_CTYPE="fr_FR.utf8"
> ...

 

J'ai essayé en positionnant LC_ALL en désespoir de cause mais pas mieux et mon user a les mêmes locales.

Ne me dites pas qu'il faille que je remette HAL ?  :Smile: 

Mes paquets installés : 

```
genduf ~ # emerge -pv xorg-server xf86-input-evdev

[ebuild   R    ] x11-base/xorg-server-1.11.4-r1  USE="ipv6 kdrive nptl udev xorg -dmx -doc -minimal (-selinux) -static-libs -tslib -xnest -xvfb" 0 kB

[ebuild   R    ] x11-drivers/xf86-input-evdev-2.6.0  0 kB

```

Je viens de passer 2 heures sur cette bêtise (j'aime pas quand des détails trainent et vu que j'en ai un autre concernant pulseaudio, gnome etc.... je voulais au moins rêgler celui là  :Smile:  ).

Donc voilà j'en appelle à vos idées, moi j'ai épuisé les miennes.

Globalement les documentations que j'ai suivi et pour lesquels les configurations sont proches : 

- http://www.gentoo.org/doc/en/xorg-config.xml

- http://www.gentoo.org/doc/fr/utf-8.xml

- /usr/share/X11/xorg.conf.d/10-evdev.conf

N'hésitez pas, je prends toute suggestion, même celles qui vous paraissent idiotes, sans doutes que je les ai déjà essayées  :Wink: 

----------

## boozo

'alute

je ne vias pas t'aider beaucoup mais j'ai eu exactement le même désagrément avec kdm il y a quelques mois suite à une migration d'architecture... je n'ai jamais pu identifier exactement la cause du pb ni sa solution   :Crying or Very sad: 

Ni rien du contexte ni des fichiers de conf ne voulaient rien savoir au login _uniquement et sous X seulement_ ensuite tout roulait en fr_utf8 (tty, WM, applis).

J'ai donc supposé un pb d'initialisation de variables au démarrage (mode de démarrage des services en parallèle i.e. ou de runlevel boot vs default) mais sans jamais arriver à le prouver malgré mes tests.

Il me semble avoir aussi tout essayé à l'époque : de la suppression des fichiers de conf y compris ceux locaux du user, à la vérification de tous les paramètres i.e. Xsession, kdmrc, ... jusqu'à les refaire from scratch via les outils de configuration du DM en root... mais rien... 

Sous toutes réserves, il me semble de mémoire que le pb s'est réglé de lui-même soit en lancant un -e world en désespoir de cause à ce moment, soit avec une màj des packages xdm/kdm/kde-l10n ou d'un lot dans ce goût-là...

Navré de ne pouvoir ni t'aider ni t'en dire plus mais je compatis sincèrement à ta frustration   :Sad: 

----------

## DuF

En fait ton message m'aide pas mal car je pense à la même chose, c'est donc toujours bon de ne pas être seul à penser une chose  :Smile:  Et j'avoue que j'ai passé un peu beaucoup de temps sur ce sujet qui amha n'en mérite pas autant  :Smile: 

En effet, dans les 2 trucs irritants que je traine sur ma nouvelle installation il y a ce problème de clavier sous GDM et le problème de "master audio" sous gnome qui fait qu'aslamixer est opérationnel mais le volume manager de gnome n'a aucun effet (j'aurai tendance à mettre ça sur le dos de pulseaudio juste par principe   :Very Happy:  ). Et hier soir j'ai commencé par faire un emerge -ve system car j'ai eu un problème de date lors de l'installation et certains paquets ont été installés avec une date dans le futur. Les guides d'installation disent de le faire mais de ne pas se limiter à system, de le faire pour world donc je pense le refaire ce soir.

A mon avis pour GDM c'est un problème lié à xorg (à ne pas confondre avec un problème d'xorg), gnome permettant de passer en français cela limite le problème à GDM. Et comme toi j'ai à peu près essayé toutes les techniques connues (sauf remettre hal  :Smile:  ).

Je sens que ce soir le tout nouveau corei7 va chauffer 4-5h avec un emerge -e world  (2h hier pour les 300 paquets de system, je peux espérer 4h pour les 700 de world)  :Laughing: 

----------

## bivittatus

'lut!

J'ai eu ce problème avec GDM à une époque et j'y ai aussi passé pas mal de temps...sans jamais pouvoir trouver la solution!

Ca ne t'aidera pas, loin de là, mais au cas où ça arriverait à d'autres, une "solution" est de composer son mot de passe avec des lettres qui se situent au même endroit sur les QWERTY et AZERTY...

Soit:

E R T Y U I O P S D F G H J K L X C V B N

Donc éviter les:

A Z Q W M

Après, j'avoue ne plus m'être soucié du problème du coup...

Ok, je sors, mais c'est une astuce comme une autre qui a fonctionné pour moi!   :Wink: 

----------

## DuF

Toutes les astuces sont bonnes à prendre  :Smile: 

Pour le coup je vais tenter (quand j'aurai un peu de temps) d'autres versions voir une montée de version de gnome.

----------

## Tetsumaki

Bonsoir à tous.

Je relance ce vieux sujet car le problème persiste toujours.

Ça vient des périphériques Unifying de Logitech et de udev.

Quelqu’un aurait une solution propre à apporter pour que le clavier soit bien reconnu en français depuis le temps ?

Merci d'avance.

----------

## USTruck

Bonsoir,

Il semble bien que le driver unify du kernel pause problème, vu le nombre de personne qui sont touché ....

Dans kernel config, il y a une option dans la partie HID->Special HID

```
 CONFIG_HID_LOGITECH_DJ:                                                                                                        

  │                                                                                                                                                            

  │ Say Y if you want support for Logitech Unifying receivers and devices.                                        

  │ Unifying receivers are capable of pairing up to 6 Logitech compliant                                               

  │ devices to the same receiver. Without this driver it will be handled by                                             

  │ generic USB_HID driver and all incomming events will be multiplexed                                             

  │ into a single mouse and a single keyboard device.

```

Si actif et qu'il y a le problème, il faut le déactiver et laisser usb_hid s'en occupé, en perdant donc quelque options,comme seul deux périphériques, une souris et un clavier.

----------

## Tetsumaki

Je tente ta solution de suite, je compile ça risque d'être long.

EDIT : Ça marche.

Voici le bout du fichier de config du kernel concerné :

Avant (avec le bug) :

```
CONFIG_HID_LOGITECH_DJ=m
```

Après :

```
# CONFIG_HID_LOGITECH_DJ is not set
```

----------

## xaviermiller

Hello,

En quoi un pilote du noyau influence la disposition du clavier sous X ?

Y a-t-il bien un fichier de configuration dans /etc/X11/xorg.conf qui spécifie le "keyboard layout" ?

http://www.gentoo.org/doc/en/xorg-config.xml#doc_chap3

 *Quote:*   

> nano -w /etc/X11/xorg.conf.d/30-keyboard.conf
> 
> Section "InputClass"
> 
>         Identifier "keyboard-all"
> ...

 

----------

## USTruck

Bonjour Xavier

 *XavierMiller wrote:*   

> Hello,
> 
> En quoi un pilote du noyau influence la disposition du clavier sous X ?
> 
> Y a-t-il bien un fichier de configuration dans /etc/X11/xorg.conf qui spécifie le "keyboard layout" ?
> ...

 

Si on regarde bien le premier post, Xorg detecte bien et assigne bien le clavier 'fr' mais reste en mode qwerty !!!!

Pourquoi j'ai dis problème du pilote noyau:

Avec usb_hid le périphérique est bien détecté et le fonctionnement de Xorg est comme attendu, information trouvée sur d'autre forum (merci google)

Donc le soucis vient de pilote kernel, udev, le driver evdev d'Xorg ?

Je n'ai pas ce matériel, j'ai le temps de faire du debug et chercher mais ceux qui demande ?

Donc ici, si ils ont le temps, il faudrait pouvoir re-faire un kernel avec le logitech, ne pas lancer xdm et voir dans dmesg les messages d'init du périphérique peut-être un soucis a ce niveau

Essayer d'ajouter un rules a udev pour setup du clavier (pris du post https://forums.gentoo.org/viewtopic-t-931660-start-0.html)

```
/etc/udev/rules.d/111-kbd.ru.rules:

## via Xorg

ACTION=="add", KERNEL=="event?", SUBSYSTEMS=="usb",ATTRS{idVendor}=="ffff", ATTRS{idProduct}=="8081",RUN+="/usr/bin/setxkbmap -model pc104 -layout us,ru -variant ,winkeys,winkeys"

ACTION=="remove", KERNEL=="event?", SUBSYSTEMS=="usb", ATTRS{idVendor}=="ffff", ATTRS{idProduct}=="8081", RUN+="/usr/bin/setxkbmap -model 102 -layout fr"
```

Faudra qu'il change le idproduct et idvendor  par celui du logitech

Désoler si ma solution n'est pas 'propre', dans le sens trouver une réelle solution y compris la possibilité de report de bug si nécessaire.

Edit : voir aussi a quel event est associé le clavier (/dev/input/eventx) et le forcer dans /etc/X11/xorg.conf.d/ en ajoutant :  MatchDevicePath        "/dev/input/eventX" ; X etant l'event correspondant au clavier

ls -l /dev/input/by-id

Chercher l'identifiant du clavier ....

Edit 2 : en relisant le premier post, je vois que dans le fichier conf il avait utiliser "event*" ... peut-être bien que le soucis venait de là.

----------

## Tetsumaki

Au moins on trouve beaucoup de possibilités pour contourner le problème lié aux périphériques Logitech Unifying sur ce thread.

Prochain update du kernel au lieu de prendre 1h à le compiler pour supprimer le driver hid-logitech-dj je le blacklisterais simplement en l'ajoutant dans modprobe.conf : blacklist hid-logitech-dj

EDIT : pour info en blacklistant mon clavier ne fonctionne plus.

----------

## jaypeche

Salut,

Il y a qq temps, suite à une montée de version de Xorg, j'ai également rencontré ce problème avec GDM !

Comme ça je ne me souviens plus très bien ce qui m' avait permis de solutionner le problème.

Avant il suffisait de configurer correctement dans /etc/X11/xorg.conf et le tour était joué. Dorénavant Xorg utilise des fichiers de configuration annexes dans /etc/X11/xorg.conf.d/, c'est ce que tu précises dans ton premier post DUF : :Wink: 

J'ai utilisé evdev comme driver dans la section "Input Device" pour mon clavier filaire en PS2, je te post ma configuration :

Fichier /etc/X11/xorg.conf :

```
Section "ServerLayout"

   Identifier     "X.org Configured"

   Screen      0  "Screen0" 0 0

   InputDevice    "Mouse0" "CorePointer"

   InputDevice    "Keyboard0" "CoreKeyboard"

EndSection

Section "Files"

   ModulePath   "/usr/lib/xorg/modules"

   FontPath     "/usr/share/fonts/misc/"

   FontPath     "/usr/share/fonts/TTF/"

   FontPath     "/usr/share/fonts/OTF"

   FontPath     "/usr/share/fonts/Type1/"

   FontPath     "/usr/share/fonts/100dpi/"

   FontPath     "/usr/share/fonts/75dpi/"

EndSection

Section "Module"

   Load  "record"

   Load  "glx"

   Load  "dbe"

   Load  "extmod"

EndSection

Section "InputDevice"

   Identifier  "Keyboard0"

   Driver      "evdev"

   Option "XkbModel" "pc105"

   Option "XkbLayout" "fr"

   Option "XkbVariant" "latin9"

EndSection

Section "InputDevice"

   Identifier  "Mouse0"

   Driver      "mouse"

   Option       "Protocol" "auto"

   Option       "Device" "/dev/input/mice"

   Option       "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"

   Identifier   "Monitor0"

   VendorName   "Monitor Vendor"

   ModelName    "Monitor Model"

   Option      "PreferredMode" "1280x1024"

EndSection

Section "Device"

   Identifier  "Card0"

   Driver      "nvidia"

   VendorName  "nVidia Corporation"

   BoardName   "NV44A [GeForce 6200]"

   BusID       "PCI:1:0:0"

   Option         "NoLogo"      "true"

   Option         "TripleBuffer"       "true"

   Option         "AddARGBGLXVisuals"  "true" 

   Option         "RenderAccel"        "true"  

   Option     "Coolbits"    "1" # Overclocking active

EndSection

Section "Extensions"

  Option "Composite" "Enable"

EndSection

Section "Screen"

   Identifier "Screen0"

   Device     "Card0"

   Monitor    "Monitor0"

   SubSection "Display"

      Viewport   0 0

      Depth     1

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

   SubSection "Display"

      Viewport   0 0

      Depth     4

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

   SubSection "Display"

      Viewport   0 0

      Depth     8

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

   SubSection "Display"

      Viewport   0 0

      Depth     15

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

   SubSection "Display"

      Viewport   0 0

      Depth     16

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

   SubSection "Display"

      Viewport   0 0

      Depth     24

      Modes      "1280x1024"   "1024x768"   "800x600"   "720x400"   "640x480"   "640x400"

   EndSubSection

EndSection
```

Je n'ai pas tout compris au fonctionnement interne de Xorg avec ses fichiers de conf mais il m'a fallut ajouté ceçi dans /etc/X11/xorg.conf.d et là mon problème avec GDM était résolu. Peut être qq de plus compétent pourra t'apporter davantage de précisions...

Fichier /etc/X11/xorg.conf.d/30-keyboard.conf :

```
Section "InputClass"

        Identifier "Keyboard0"

        Driver "evdev"

        Option "XkbLayout" "fr"

        Option "XkbModel" "pc105"

        Option "XkbRules" "xorg"

        Option "XkbVariant" "latin9"

        MatchIsKeyboard "on"

EndSection
```

En espérant aider un peu...   :Idea: 

----------

## USTruck

Bonjour a tous,

jaypeche : tout grand merci mais si tu relis bien tu verras que xorg détecte bien le clavier, l'initialise correctement mais malheureusement il reste en mode qwerty .... dès que l'on n'utilise plus le hid logitech, car ici le soucis vient de là, cela fonctionnne !!!!

Tetsumaki : J'ai mis un peux de temps a avoir une idée, si on regarde bien le menu du kernel, le module hid-logitech-dj dépend du module hid-logitech ... 

L'idée c'est : le module hid-logitech est chargé ... a besoin, car détecte, du module hid-logitech-dj ... du coup il ne charge pas celui-ci car blacklist et usb_hid ne prend pas la main puisque hid-logitech l'a ....

En espérant qu'il soit en module, blackliste aussi hid-logitech

----------

## Tetsumaki

 *USTruck wrote:*   

> Tetsumaki : J'ai mis un peux de temps a avoir une idée, si on regarde bien le menu du kernel, le module hid-logitech-dj dépend du module hid-logitech ... 
> 
> L'idée c'est : le module hid-logitech est chargé ... a besoin, car détecte, du module hid-logitech-dj ... du coup il ne charge pas celui-ci car blacklist et usb_hid ne prend pas la main puisque hid-logitech l'a ....
> 
> En espérant qu'il soit en module, blackliste aussi hid-logitech

 

J'avais justement essayé de cette façon en blacklistant et désactivant hid_logitech et hid_logitech_dj mais vu que j'avais besoin de mon serveur j'en suis revenu à ma solution précédente à savoir recompiler le kernel.

Je me demande pourquoi hid-generic n'a pas prit la relève étant donné que hid-logitech et hid-logitech-dj était blacklisté et désactivé.

Voici un dmesg | grep hid avec mon kernel custom sans hid-logitech ni hid-logitech-dj :

```
[    1.708965] usbcore: registered new interface driver usbhid

[    1.708969] usbhid: USB HID core driver

[   10.677049] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:1d.0-2/input0

[   10.678063] hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-2/input1

[   10.682104] hid-generic 0003:046D:C52B.0003: hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-2/input2
```

Ça me laisse une trace pour comparer quand je referais des tests, si vous avez une idée entre temps je veux bien  :Smile: 

J'aimerais éviter d'avoir à faire une règle udev.

----------

## USTruck

Bonjour

Via google, je vois qu'il faut d'abord faire un 'pairing' des périphériques que l'on désire utiliser avec le logitech unify receiver .... as-tu pu le faire ?

Non -> https://github.com/treeder/logitech_unifier ou http://th0th.me/log/pairing-logitech-unifying-devices-on-gnulinux/

Il en existe d'autre : google -> setup logitech unifying receiver

Attention, dans le(s) scripts a complier, dans la partie #define ils harcode l'id du périphérique, a toi de voir s'il correspond

----------

## Tetsumaki

Le périphérique reçu est toujours associé au dongle reçu.

Il faut faire un appareillage seulement dans le cas ou on veut associer son périphérique à un autre dongle.

Par exemple dans le cas ou j'ai un clavier+dongle et une souris+dongle et que je veux appareiller le clavier+souris sur le même dongle.

----------

## kopp

J'avais eu le même problème passé un temps, mais ce n'est plus le cas. Je ne sais plus ce qui a résolu le problème. 

J'utilise le dongle logitech avec logitech_dj (en dur dans le noyau).

J'avais peut-être du masker certains paquets de type polkit ou autre, mais je n'ai plus rien dans package.mask. Peut-être que c'était accountsservice, mais je ne suis pas sûr.

Tu es en arch ou ~arch ?

----------

## Tetsumaki

 *kopp wrote:*   

> J'avais eu le même problème passé un temps, mais ce n'est plus le cas. Je ne sais plus ce qui a résolu le problème. 
> 
> J'utilise le dongle logitech avec logitech_dj (en dur dans le noyau).
> 
> J'avais peut-être du masker certains paquets de type polkit ou autre, mais je n'ai plus rien dans package.mask. Peut-être que c'était accountsservice, mais je ne suis pas sûr.
> ...

 

Archlinux x86_64

----------

## kopp

Ok, pas Gentoo donc, ça n'aide pas pour les versions  des logiciels.

Du coup, je me souviens d'un truc : en fait, je susi sur mon portable, et mon clavier logitech était en qwerty tant que je ne touchais pas au clavier intégré du portable. Une simple touche (même Shift ou autre) faisait basculer mon Logitech en azerty comme il se doit.

Bon, ça n'avance pas grand chose... mais c'est résolu maintenant.

----------

## Tetsumaki

 *kopp wrote:*   

> Ok, pas Gentoo donc, ça n'aide pas pour les versions  des logiciels.
> 
> Du coup, je me souviens d'un truc : en fait, je susi sur mon portable, et mon clavier logitech était en qwerty tant que je ne touchais pas au clavier intégré du portable. Une simple touche (même Shift ou autre) faisait basculer mon Logitech en azerty comme il se doit.
> 
> Bon, ça n'avance pas grand chose... mais c'est résolu maintenant.

 

Oui j'ai constaté la même chose en branchant un clavier usb ça switchait tout en fr.

----------

## xaviermiller

Oui mais bon... Gentoo et Arch ne suivent pas les mêms versions de paquets... à quoi bon venir ici demander de l'aide ?

Parce qu'on est gentils ?

----------

## Tetsumaki

Parcque ce n'est pas un problème de distrib mais un problème générique.

----------

## HazeC5

Salut.

Je rencontre le même problème depuis que j'ai installé cette gentoo en 64 bit. Dès l'installation ce problème est apparu.

Que ce soit avec GDM ou Esla (lorsque celui-ci était disponible) le clavier est en qwerty, alors que tout mon système est en français...Il n'y a que pour le login manager qu'il persiste à rester en qwerty et ce quoi que je tente, je n'ai toujours pas trouvé la solution, j'ai aussi un clavier logitech. Mon mot de passe ne comporte pas de  A Z W ou Q par contre mon login oui....

J'ai lu les posts ci-dessus, une chose que je en comprends pas c'est que vous mentionnez  *Quote:*   

> /etc/X11/xorg.d/

  or je n'ai pas de dossier, je n'ai que le xorg.conf et ceci: *Quote:*   

> # ls /etc/X11
> 
> chooser.sh  gdm       startDM.sh  xorg.conf
> 
> dm          Sessions  xinit       XvMCConfig

 

Je me souviens avoir eu ce dossier sur mon ancienne gentoo en 32 bit, mais sur celle-ci je n'ai jamais eu à faire à lui !

Dans le kernel j'ai ceci: *Quote:*   

> 
> 
> CONFIG_HID_LOGITECH=y
> 
> # CONFIG_HID_LOGITECH_DJ is not set
> ...

 

J'ai tenté aussi:  *Quote:*   

> 
> 
> GDM_LANG="fr_FR.utf8"

 

Sans succès...Je me souviens que sur 1 autre machine ça avait fonctionné, par contre ne me souviens plus si le problème était identique à celui qui nous préoccupe présentement.

Par avance merci pour votre aide   :Exclamation: 

Bonne soirée/journée  :Exclamation:   :Wink: 

----------

## PabOu

J'ai un clavier Microsoft et je rencontre le même soucis mais je n'ai jamais vraiment cherché à résoudre le problème... Je sais qu'une fois toutes les 2 semaines, je dois taper mon mot de passe en qwerty puis voilà, ça ne me dérange pas. J'ai réinstallé la machine il y a quelques semaines mais le problème persiste depuis des mois.

J'ai également rencontré ceci très récemment sur un autre ordinateur avec ubuntu sur lequel j'ai viré le login manager existant pour mettre gdm, et ce avec un clavier bluetooth Logitech + un clavier ps/2 Logitech mais à nouveau, je n'ai pas cherché à le résoudre.

----------

## HazeC5

Salut ! 

 Oui ça ne me dérange pas plus que cela non plus étant donné que je reboot rarement le PC.

Par contre j'aime avoir un système qui fonctionne sans erreurs aucune donc si je pouvais/l'on pouvait trouver la solution cela me conviendrait parfaitement.

----------

## xaviermiller

Hello,

Avez-vous essayé sans passer par GDM ?

- via startx

- via un autre login manager ?

Si ça peut vous aider, mon keyboard.conf est le suivant :

```
Section "InputClass"

        Identifier "keyboard-all"

        Driver "evdev"

        Option "XkbLayout" "be"

        Option "XkbRules" "xorg"

        MatchIsKeyboard "on"

EndSection
```

Pour le reste, je ne peux pas trop aider : j'ai un clavier Cherry (mais eu un Dell), et utilise slim et razorqt, le tout en "instable".

----------

## boozo

'alute

il me reste une vieille hypothèse  ou 2 que je n'ai jamais pu tester à l'époque faute de les avoir trouvé avant de passer par slim

Sait-on jamais   :Wink: 

----------

## HazeC5

Re .

Merci pour réactivité, c'est très apprécié.   :Wink: 

 *Quote:*   

> Avez-vous essayé sans passer par GDM ?
> 
> - via startx
> 
> - via un autre login manager ?
> ...

 

Alors oui j'ai testé avec d'autre login manager, le problème y est aussi présent! Avec startx non je n'ai jamais essayé car je ne connais pas cet outil, ou du moins je n'ai jamais réussi à le faire fonctionner.

Cependant startx n'est pas 1 LM, ou si ? Car si ce n'en est pas un le problème n'y sera pas, car c'est uniquement avec le LM que le clavier est en Qwerty, tout le reste de mon système est bien en français.

J'aimerai bien testé la solution du:

```
/etc/X11/xorg.conf.d/10-keyboard.conf
```

Mais depuis je ne sais quelle version de xorg, je n'ai plus ce dossier, ni même la présence de "evdev" ou de "fr" dans mon xorg.conf.

Alors comment puis-je procéder pour tester cette éventuelle solution ? Svp !

Par avance merci.   :Wink: 

----------

## GentooUser@Clubic

Je vient de me rendre compte que j'ai le même problème avec GDM et peut-être ibus qui restent en qwerty, pareil ma config clavier est bien prise en compte  :

```

[   227.621] (II) XINPUT: Adding extended input device "Genius 2.4G Wireless Mouse and Keyboard" (type: KEYBOARD, id 8)

[   227.621] (**) Option "xkb_rules" "evdev"

[   227.621] (**) Option "xkb_model" "latin9"

[   227.621] (**) Option "xkb_layout" "fr"

[   227.621] (**) Option "xkb_variant" "compose:menu"

```

Par contre j'ai aussi ce message :

```

[   227.593] (EE) Error loading keymap /var/lib/xkb/server-0.xkm

[   227.593] (EE) XKB: Failed to load keymap. Loading default keymap instead.

```

Peut-être un bug de xkb qui ne compile pas la keymap ?

----------

## xaviermiller

Ah, voilà du concret ! on va pouvoir avancer  :Smile: 

----------

## HazeC5

Salut

Bien de mon côté je viens juste de résoudre le soucis et GDM est enfin en Azerty.

C'est le post de GentooUser@Clubic qui m'a mis sur la piste. En effet après avoir vu son erreur xkb, j'ai donc tapé la commande:

```
grep xkb /var/log/Xorg.0.log
```

dans laquelle j'ai pu trouver ceci: *Quote:*   

> 
> 
> [  2838.385] (**) Option "xkb_rules" "evdev"
> 
> [  2838.385] (**) Option "xkb_model" "evdev"
> ...

 

Du coup j'ai donc crée le dossier 

```
/etc/X11/xorg.conf.d/
```

 et éditer 1 fichier que j'ai nommé:

 *Quote:*   

> 10-evdev.conf

 

 et dans lequel j'y ai mis:

```
Section "InputClass"

   Identifier "keyboard0"      

   MatchIsKeyboard "on"

#       MatchDevicePath "/dev/input/event*"

        Driver "evdev"

        Option "XkbLayout" "fr" 

        Option "XkbVariant" "latin9" 

        Option "XkbOptions" "terminate:ctrl_alt_bksp" 

EndSection
```

Et voilà que GDM est en français.

Je dois dire que c'est aussi 1 peu de ma faute car il y a de nombreux mois de cela il m'avait semblé que les fichiers relatifs à la config du clavier et de la souris étaient devenus obsolètes.... Grossière erreur visiblement.

----------

## xaviermiller

En effet, tout est obsolète à condition d'accepter les valeurs par défaut  :Laughing: 

- clavier US

- pilote X plutôt que Y

- ...

----------

## GentooUser@Clubic

Ça remarche aussi chez moi, mes options Xkb était en vrac (pourtant j'ai pas touché ce fichier depuis la disparition de hal, et avant ça marchait oO)

Mon nouveau fichier de config :

```
% cat /etc/X11/xorg.conf.d/80-keyboard-all.conf 

Section "InputClass"

   Identifier "evdev keyboard catchall"

   MatchIsKeyboard "on"

   MatchDevicePath "/dev/input/event*"

   Driver "evdev"

   Option "XkbLayout" "fr"

   Option "XkbVariant" "latin9"

   Option "XkbOptions" "compose:menu"

EndSection

```

Par contre ibus reste sur un backend qwerty :/ j’essaierai de voir si c'est un problème avec ibus ou son intégration dans Gnome.

----------

## DuF

Là tout de suite j'ai cassé mon ordi (noyau, udev, tout ça) mais j'ai hâte de tester pour corriger ce problème...

----------

## HazeC5

Re-Salut.

Bon je suis super satisfait d'avoir pu résoudre ce soucis. Par contre je me suis rendu compte d'une chose.

si j'utilise le layout latin9 avec l'option Option "XkbOptions" "terminate:ctrl_alt_bksp cette commande permet effectivement de relancer X.

Par contre avec le layout oss cette commande ne fonctionne plus...

Mais en même temps j'ai rajouté ceci:

```
Option "XkbOptions" "terminate:ctrl_alt_bksp,compose:menu"
```

Serait-ce à cause du compose:menu que cela ne fonctionne plus ?

Je pose la question, car j'ai pas mal de taf et je devais utiliser le PC , je ne peux donc me permettre de relancer X toutes les 2mns, sinon j'avance pas dans mon travail...

Je me rends compte que je ne sais pas trop à quoi sert finalement ce compose:menu, m'est-il nécessaire, et à quoi sert-il s'il vous plait ? 

Merci d'avance   :Exclamation: 

----------

## GentooUser@Clubic

compose:menu sert à utiliser la touche menu comme touche morte pour taper certains caractères : <compose> + <a> + <`> =  à, mais je vient de me rendre que ça ne marche pas chez moi, donc XkbOptions ne dois pas être le bon endroit pour le mettre, donc c'est probablement ça qui empêche de fonctionner ton terminate:ctrl_alt_bksp

----------

## HazeC5

Je viens juste de tester,avant de voir ton post  GentooUser@Clubic en supprimant compose:menu que le ctrl+alt+bcksp ne fonctionnait pas non plus!

Je suis d'avis que cela viendrai donc de la Variante utilisée, je testerai demain, là il se fait tard.

Quand au compose:menu je ne vois déjà pas où est la touche compose... Puis je pense pas que j'en aurai l'utilité puisque jusqu'ici j'ai toujours pu me servir du clavier et taper tout e que je désirai avec... Saus si maintenant on vient à m'expliquer et me démontrer son utilité, j'y reflechirai certainement.

Pour tuer la session par contre, ça avait fonctionné juste après mon 1er login avec GDM en azerty, et j'avais la variante latin-9 activée à ce moment.

Bonne soirée. Et Merci @ vous  :Exclamation:   :Wink:  

----------

## christophe_y2k

 *GentooUser@Clubic wrote:*   

> Ça remarche aussi chez moi, mes options Xkb était en vrac (pourtant j'ai pas touché ce fichier depuis la disparition de hal, et avant ça marchait oO)
> 
> Mon nouveau fichier de config :
> 
> ```
> ...

 

Pour moi ça fonctionne pas avec gnome-base/gdm-2.20.11-r1

impossible d'obtenir un clavier en AZERTY

avec ou sans fichier xorg.conf.d

----------

## Tetsumaki

HazeC5 même avec un clavier bien configuré en fr dans /etc/X11/xorg.conf.d/10-keyboard.conf ça ne suffit pas si le driver HID_LOGITECH_DJ est compilé avec le kernel, le clavier sera toujours en us.

Pour ma part il est toujours nécessaire d'avoir 10-keyboard.conf bien configuré + un kernel compilé avec l'option # CONFIG_HID_LOGITECH_DJ is not set.

----------

## DuF

 *Tetsumaki wrote:*   

> HazeC5 même avec un clavier bien configuré en fr dans /etc/X11/xorg.conf.d/10-keyboard.conf ça ne suffit pas si le driver HID_LOGITECH_DJ est compilé avec le kernel, le clavier sera toujours en us.
> 
> Pour ma part il est toujours nécessaire d'avoir 10-keyboard.conf bien configuré + un kernel compilé avec l'option # CONFIG_HID_LOGITECH_DJ is not set.

 

Merci car je suis dans le même cas et je tournais en rond, j'avais bien mis la configuration qui allait bien mais c'était toujours inopérant... Personnellement je n'aurai pas pensé à cette histoire d'option du noyau pour les périphériques type "Logitech Unifying receivers". A priori j'ai lu que ça fonctionne bien même sans cet élément du noyau, est-ce le cas quand on a 2 périphériques sur le même récepteur ?

----------

## Tetsumaki

 *DuF wrote:*   

>  *Tetsumaki wrote:*   HazeC5 même avec un clavier bien configuré en fr dans /etc/X11/xorg.conf.d/10-keyboard.conf ça ne suffit pas si le driver HID_LOGITECH_DJ est compilé avec le kernel, le clavier sera toujours en us.
> 
> Pour ma part il est toujours nécessaire d'avoir 10-keyboard.conf bien configuré + un kernel compilé avec l'option # CONFIG_HID_LOGITECH_DJ is not set. 
> 
> Merci car je suis dans le même cas et je tournais en rond, j'avais bien mis la configuration qui allait bien mais c'était toujours inopérant... Personnellement je n'aurai pas pensé à cette histoire d'option du noyau pour les périphériques type "Logitech Unifying receivers". A priori j'ai lu que ça fonctionne bien même sans cet élément du noyau, est-ce le cas quand on a 2 périphériques sur le même récepteur ?

 

Je n'ai pas eu l'occasion de tester avec 2 périphériques, à tester donc, à vu de nez je dirais que ça fonctionne mais je ne peux pas le promettre.

----------

## DuF

 *Tetsumaki wrote:*   

> 
> 
> Je n'ai pas eu l'occasion de tester avec 2 périphériques, à tester donc, à vu de nez je dirais que ça fonctionne mais je ne peux pas le promettre.

 

Ca fonctionne mais il faut utiliser un petit outil pour appairer les 2 éléments sur le même récepteur ce qui des fois occasionnent des problèmes de configuration (il choisit le mauvais hidrawX). Au final je vais garder les 2 récepteurs car ça fonctionne tout le temps, sans se mélanger les pinceaux.

----------

