Forum Linux.général Multiseat : assigner un port USB à un siège

Posté par Clement33 le 23 novembre 2011 à 14:55.

Étiquettes :

nov.

2011

Bonjour,

Je teste actuellement le mode multi-sièges sur ma Debian Squeeze (2 cartes graphiques nVidia).

J'ai mis en place 2 sièges, un sur chaque carte graphique. Tout est paramétré via xorg.conf et gdm.conf en suivant le Wiki de Debian.

En revanche, j'aimerais maintenant pouvoir assigner tel port USB sur tel siège, dans l'optique de pouvoir assigner un Hub USB complet pour chaque siège.

J'ai un peu cherché sur internet, mais rien trouvé, hormis pour systemd de Fedora...

Savez-vous s'il est possible d'utiliser udev pour assigner un port USB à un siège ?

Merci d'avance,

Clem

# udev, ses rules et les /dev/input

Posté par NeoX le 23 novembre 2011 à 15:07. Évalué à 2.

regarde du coté de /etc/udev/rules.d/ (debian like)

tu y verras des fichiers qui permettent de fixer certains fonctionnement de UDEV.

dans mon cas, j'ai deux fichiers
70-persistent-cd.rules 70-persistent-net.rules

qui fixent le nommage du lecteur de CD/DVD et le nommage de la carte reseau

avec ca tu dois pouvoir faire ton fichier qui va fixer un appareil (le HUB USB, ou le Clavier et la souris) à un /dev/inputXYZ

/dev/inputXYZ que tu appeleras dans ta config Xorg.
- [^] # Re: udev, ses rules et les /dev/input
  
  Posté par Clement33 le 23 novembre 2011 à 15:27. Évalué à 1.
  
  C'est ce que je pensais faire, mais il y a 2 choses qui me turlupinent :
  
  Comment reconnaître les ports USB ? Je vois pas comment préciser "tel port USB" dans mon 50-usb-seat.rules, je l'assigne à /dev/portusb1
  
  Dans le Xorg, comment je précise que /dev/portusb1 n'appartient à mon seat0 ou mon seat1 ? Dans quelle section ? Car j'ai bien des "Section InputDevice", mais je vois pas quoi en faire hormis préciser que ce sont un clavier ou une souris...
  - [^] # Re: udev, ses rules et les /dev/input
    
    Posté par NeoX le 23 novembre 2011 à 16:59. Évalué à 2.
    
    en THEORIE :
    pour udev
    c'est le USBID qui permet de determiner le peripherique (le HUB, le clavier ou la souris)
    
    tu ne sais pas sur quel port il est et ... tu t'en fous.
    
    avec udev tu vas dire que le periph ayant l'ID 04cb:01c6 (dans l'exemple ci dessous)
    
    :/etc/udev/rules.d$ /sbin/lsusb
    Bus 6 Device 2: ID 04cb:01c6 Fuji Photo Film Co., Ltd
    
    SYSFS{idVendor}=="04cb", SYSFS{idProduct}=="01c6", MODE="660", GROUP="camera"
    
    sera monter dans /dev/inputX
    
    pour xorg, tu va creer une section par clavier, par souris, par ecran (donc pour 2 sieges, deux sections de chaque)
    
    puis tu vas les appeler en Layout, qui incluera un clavier, une souris, un ecran
    
    en PRATIQUE :
    je ne sais pas si Debian inclue deja ce qu'il faut pour faire du multiseat
    il y avait un projet 'MPX' je crois, mais je ne sais ou ils en sont.
    - [^] # Re: udev, ses rules et les /dev/input
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 23 novembre 2011 à 17:54. Évalué à 2.
      
      il y avait un projet 'MPX' je crois, mais je ne sais ou ils en sont.
      
      Ils en sont au point que c'est inclut dans X.Org de base, ça s'appelle XInput 2.
      
      En revanche ça n'a strictement rien à voir avec ce qui nous intéresse ici : XInput 2 ça sert à utiliser plusieurs entrées (pointage et saisie) sur un seul serveur graphique, or là on cherche à utiliser affectées plusieurs entrées à plusieurs serveurs graphiques.
    - [^] # Re: udev, ses rules et les /dev/input
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 23 novembre 2011 à 17:55. Évalué à 2.
      
      c'est le USBID qui permet de determiner le peripherique (le HUB, le clavier ou la souris)
      
      Si c'est la seule façon de faire, c'est ennuyeux parce que lui voulait discriminer par port USB utilisé plutôt que par modèle de périphérique…
      
      L'identifiant USB, ça identifie le fabricant et le modèle. Ce n'est pas un numéro de série…
      - [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Sytoka Modon (site web personnel) le 23 novembre 2011 à 21:57. Évalué à 3.
        
        Ben oui, si je branche une clef USB (formaté en FAT) sur le port A, elle va au bureau A et idem avec le port USB B...
        
        Il faut donc pouvoir assigner un port et non un équipement. A noter que certain équipement d'acquisition s'assigne un port avec LabView (Windows) et qu'il est alors impossible d'utiliser ce matériel sur un autre port ensuite ! Réfléchir a 2 fois avant de brancher ses trucs la sur un PC...
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Clement33 le 24 novembre 2011 à 10:24. Évalué à 1.
        
        Sytoka Modon a tout dit. L'objectif n'est pas d'identifier le fabricant ou n'importe quoi, mais de dire "tel port USB à gauche ira au siège A, et tel port USB sur la droite ira au siège B". Pour cela, je dois identifier les ports USB et pouvoir dire "toi, je t'assigne ce port, il n'y a que toi qui aura accès aux périphériques USB insérés sur ce port".
        
        @NeoX : j'utilise bien les sections de Xorg, et j'ai déjà assigné 2 claviers et 2 souris dans mes sections, ça marche bien. Mais je pense pas pouvoir faire pareil pour les périphériques USB...
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par NeoX le 24 novembre 2011 à 11:55. Évalué à 0.
        
        je ne vois pas ou est le probleme
        sauf si tu echanges souvent des peripheriques entre les deux "bureaux"
        
        logiquement tu as deux clavier, deux souris
        chaque materiel à son identifiant.
        
        si ca se trouve le HUB aussi
        
        as-tu essayé USBID ou lsusb pour savoir si le HUB avait un ID unique
        si oui, udev est ton ami.
        
        udev te permet de lié un ID à un /dev/inputX
        xorg te permet via les sections d'utiliser un /dev/inputX particulier
        
        donc tu peux identifier ton peripherique, et faire en sorte qu'il soit associé à tel ou tel ecran.
        
        sauf, comme dit au debut, si tu echanges ta souris, ton clavier, le gamepad... avec l'autre "siege".
        
        en me relisant, je viens de comprendre que, ce qui marche pour le clavier/souris
        ne marche plus pour les clefs USB, les appareils photos, mais là ce n'est plus la faute à Xorg
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Clement33 le 24 novembre 2011 à 13:14. Évalué à 1.
        
        Bon, via lsusb j'ai réussi à identifier mes 9 ports USB. J'ai leur id du type "1d6b:0002". J'ai des doublons, mais si je compte uniquement les ID en écartant les doublons, j'ai bien 9 ID, donc 9 ports.
        
        Maintenant, je dois créer des règles udev pour assigner un port USB à un /dev/usb1 par exemple. Là, ok, j'ai trouvé comment faire sur internet.
        
        Maintenant, comme tu disais, je peux lier un clavier, une souris, ou encore un gamepad à mon seat via les sections "InputDevice", je l'ai déjà fait. Mais concernant les ports USB, ce n'est pas géré par Xorg il me semble.
        
        Une autre solution consisterait à désactiver l'automount de Nautilus, et de mettre en place un script (via udev) de montage perso qui vérifierait l'ID du port USB et qui le monterait pour le bon utilisateur... Jouable ?
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par NeoX le 24 novembre 2011 à 17:41. Évalué à 2.
        
        Maintenant, comme tu disais, je peux lier un clavier, une souris, ou encore un gamepad à mon seat via les sections "InputDevice", je l'ai déjà fait. Mais concernant les ports USB, ce n'est pas géré par Xorg il me semble.
        
        ben comme dit precedemment, Xorg peut gerer les peripheriques de control (clavier/souris/pad)
        
        mais pas les periph de stockage (ce n'est pas SON travail)
        
        Une autre solution consisterait à désactiver l'automount de Nautilus, et de mettre en place un script (via udev) de montage perso qui vérifierait l'ID du port USB et qui le monterait pour le bon utilisateur... Jouable ?
        
        jouer de la meme maniere, avec les USBID, mais avec les outils de chaque desktop.
        - pour gnome il me semble que c'est gvfs qui fait que ca monte ou pas dans nautilus
        - pour kde il me semble que c'est les Kio
        etc
        
        au risque de voir un utilisateur vouloir utiliser xmonad, lxde ou tout autre gestionnaire de fenetre, et à devoir faire des scripts à chaque fois.
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Clement33 le 25 novembre 2011 à 13:04. Évalué à 0.
        
        Ouais, jouer avec gvfs, ça peut le faire.
        
        Bon, j'ai identité mes périphériques usb comme suit :
        
        J'ai exécuté cette commande :
        
        lsusb -v | grep iSerial
        
        Qui me renvoie ceci les ID usb il me semble :
        
        iSerial 1 0000:00:1d.2 iSerial 1 0000:00:1d.1 iSerial 1 0000:00:1d.0 iSerial 1 0000:00:1a.2 iSerial 1 0000:00:1a.1 iSerial 1 0000:00:1a.0 iSerial 1 0000:00:1d.7 iSerial 1 0000:00:1a.7
        
        Ce qui correspond bien à mes ports USB : 6 derrière, et 2 en facade.
        
        J'ai attaqué ma règle udev :
        
        BUS="usb", ATTR{ ...
        
        J'ai bien trouvé comment prendre en référence le nom de ce qui va être monté (KERNEL="sdh1"), mais je vois pas comment utiliser mes ID usb dans mes règles udev.
        
        Quelqu'un qui en a déjà fait peut-il me renseigner ?
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par NeoX le 25 novembre 2011 à 18:26. Évalué à 2.
        
        si tu as joué avec gvfs,
        regardes s'il peut directement traiter avec l'USBID, ca t'eviterait de passer par udev
        
        sinon, man udev qui doit bien expliquer quelque part comment forcer un peripherique (PCI ou USB) à toujours avoir le meme /dev/xyz
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Sytoka Modon (site web personnel) le 26 novembre 2011 à 19:48. Évalué à 2.
        
        sinon, man udev qui doit bien expliquer quelque part comment forcer un peripherique (PCI ou USB) à toujours avoir le meme
        /dev/xyz
        
        Ca, c'est facile à faire entre ""
        
        Ce qu'il veut faire et qui m'intéresse aussi et d'attribuer à une personne A tout ce qui est branché sur le port A usb et réciproquement, atribué à la personne B ce qui est branché sur le port usb B.
        
        La question, comment relier sur le port USB du PC, l'équipement branché qui peut être un clefs UBS lambda avec un règle utilisateur (ou DISPLAY...) ?
        
        Exemple poussé à fond. Je branche la clef ayant l'UID JHJKYUY sur le port A, elle se monte sur le bureau de la personne A, je la branche maintenant sur le port B alors elle se monte sur le bureau de la personne B. Pourtant c'est la même clef. L'ID de la clef ne sers ici à rien, c'est l'ID du port qui est utile mais qu'en faire et comment l'utiliser pour que la clef JHJKYUY se monte sur le bon bureau ?
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par NeoX le 27 novembre 2011 à 10:21. Évalué à 2.
        
        il dit justement qu'il a trouvé les ID des ports USB (et pas des peripheriques)
        
        il faut donc trouver dans le gestionnaire de bureau (et c'est pour ca que je parle de gvfs, Kio,...) car il a surement un outil qui permette de faire cela.
        
        mais comme il parlait aussi de brancher un hub USB
        il faut peut-etre simplement affecter le HUB via son ID plutot que les ports un par un.
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Clement33 le 28 novembre 2011 à 13:11. Évalué à 1. Dernière modification le 28 novembre 2011 à 13:21.
        
        Voilà ou j'en suis les amis.
        
        J'ai une règle UDEV qui vérifie le périphérique entré (sd*), et qui lance un exécutable :
        
        KERNEL=="sd*", PROGRAM="/usr/bin/who_owns_usb %k"
        
        Ensuite, mon exécutable gère les choses suivantes :
        
        Récupération de l'id usb via "udevadm info -q path -n /dev/sdh1"
        
        Récupération de "quel user est sur quel siège" via la commande "w"
        
        Je compare l'id du port (1-5, 1-6) et je l'assigne à tel siège
        
        Si /media/sdh1 existe, c'est que la clé est branchée, donc je démonte et je vire /media/sdh1
        
        Si /media/sdh1 existe pas, c'est qu'on vient de brancher la clé, donc je créé /media/sdh1, et je monte (via pmount) /dev/sdh1 pour l'utilisateur associé.
        
        Dans la foulée, je lance aussi nautilus pour avoir l'effet "pluganplay".
        
        Qu'en dites-vous ?
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Sytoka Modon (site web personnel) le 29 novembre 2011 à 07:56. Évalué à 2.
        
        Je suis intéressé par le script !
        
        La commande w ne coupe pas les logins s'ils sont trop long ?
        
        Le coup de nautilus, je le ferais que si nautilus tourne déjà. Par exemple, j'ai basculé des utilisateurs sous xfce car gnome, cela devient vraiment très lourd. On doit pouvoir tester ainsi plusieurs explorateur de fichier.
        
        Sinon, au boot, tu n'as pas un problème avec /dev/sda ?
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Clement33 le 29 novembre 2011 à 10:25. Évalué à 0.
        
        Je le partagerai une fois qu'il sera un peu plus "propre" ;) .
        
        Ah en effet, j'ai pas encore testé avec des logins un peu long, comme des logins de domaine... Je vais tester ;) .
        
        Pour Nautilus, je n'ai que des RedHat + Gnome, ou Debian + Gnome, donc ce n'est pas génant pour ma part. Mais tu dois pouvoir faire la même chose avec Thunar par exemple. Tout ce que je fais, c'est un simple "DISPLAY=:0 nautilus /media/sdh1".
        
        Pour /dev/sda, à priori non, car il est monté via fstab. La règle udev ne s'applique qu'aux nouveaux périphériques qui viennent d'être branchés, et comme sda est monté via fstab, cela ne s'applique pas à lui. En tout cas, mon script monte tout dans /media/, je l'aurais vu si j'avais un /media/sda1, /media/sda2, ...
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 novembre 2011 à 11:36. Évalué à 2.
        
        Ben oui, si je branche une clef USB (formaté en FAT) sur le port A, elle va au bureau A et idem avec le port USB B...
        
        Intéressant comme but, ça va plus loin que ce que j'imaginais. Pour ça, si tant est que ce soit possible, tu vas devoir t'amuser non seulement avec udev, mais aussi avec ConsoleKit…
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Sytoka Modon (site web personnel) le 24 novembre 2011 à 19:05. Évalué à 2.
        
        Dans tous les cas, je suis moi intéressé par la solution finale qui si elle est plus générale que GNOME me convient encore plus.
        
        Chez moi, c'est du mono-seat mais F7-> ma copine et F8 moi. Je lui allouerais bien un port pour sa clef et un port pour moi. En pratique, c'est presque le même problème bien car c'est bien une question de DISPLAY qui différencie les deux sessions.
        
        Ne me parlez du changement d'utilisateur, ce truc venant de Windows, ergonomique, lent (et dépendant de l'environnement de bureau). Ctrl+Atl+Fx et on change de session, à l'ancienne et très efficace ;-)
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 novembre 2011 à 20:35. Évalué à 2.
        
        Ne me parlez du changement d'utilisateur, ce truc venant de Windows, ergonomique, lent (et dépendant de l'environnement de bureau). Ctrl+Atl+Fx et on change de session, à l'ancienne et très efficace ;-)
        
        La dernière fois que j'ai utilisé cette fonctionnalité de GNOME, en pratique ce qu'elle faisait c'était précisément ça : lancer un second serveur X avec un nouveau GDM sur une nouvelle console.
        
        [^] # Re: udev, ses rules et les /dev/input
        
        Posté par Sytoka Modon (site web personnel) le 24 novembre 2011 à 21:11. Évalué à 2.
        
        Eh ben moi, j'ai essayé et au bout de 10 jours, j'ai remis gdm2 avec mon ancienne configuration car c'était complètement insupportable... Pourquoi faire compliquer alors que c'était simple. Ainsi, j'ai dès le boot toujours deux bureaux sur F7 et sur F8. Par ailleurs, je suis toujours sous F8 même lorsque je me logue en premier !
# Ca avance

Posté par Clement33 le 02 décembre 2011 à 13:30. Évalué à 1.
Salut,

Je progresse : j'en suis arrivé à utiliser gvfs-mount pour monter mes clés usb, afin que ça puisse être démontable facilement via Nautilus.

Je fais ceci :

su - monuser "gvfs-mount -md /dev/sdh1"

Ce qui est dommage, c'est que ça marche avec un siège, mais pas l'autre.

Explication : dupont et durand ont les mêmes droits, j'ai vérifié via /etc/group.

Pourtant, dupont sur le siège 0 me renvoie cette erreur :
```
Error mounting /dev/sdh1: Not Authorized
```
Alors que durand sur le siège 1, ça fonctionne...
```
Mounted /dev/sdh1 at (null)
```
Y'a t-il moyen de spécifier un utilisateur via gvfs-mount ? Dans le man, aucune trace des droits =/.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.