Forum Linux.débutant Driver et plug and play sur toutes types de périphériques

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
14
août
2021

Bonjour,

J'ai acheté un clavier ergonomique Contour et je me suis posée la question suivante: en tant que périphérique, un clavier nécessite t-il qu'on installe un driver? Par la suite, je me suis aperçue que ce clavier était en plug and play, donc normalement devrait être reconnu par le système préalablement installé sur l'ordinateur. Je me suis encore posée la question: y-a t-il des périphériques en plus and play qui nécessitent des drivers? Le plug and play est-il un moyen de contournement d'installation d'un driver?

Pourriez-vous m'orienter vers de la doc simple, étant débutante pour comprendre tout cela, car c'est un peu confus pour moi?

Je vous remercie d'avance:)

  • # traduire plug-n-play

    Posté par  . Évalué à 2.

    "plug and play" => brancher et jouer

    comprendre "brancher et utiliser"
    donc je dirais qu'il n'y a pas besoin de driver pour ces périphériques,
    ou que le systeme doit pouvoir les trouver tout seul

    apres il peut arriver qu'un fabricant fasse du "plug'n play" mais pour certains OS mainstream, linux restant un marché de niche, il peut alors etre nécessaire d'installer soit meme des bouts de logiciels non fourni par defaut dans la distribution pour faire fonctionner un périphérique.

    j'ai pour exemple certains touchpads certes plug'n play, ils auront par defaut le minimum nécessaire : 1 toucher/glisser, 1 bouton droit, 1 bouton gauche
    mais avec le pilote du constructeur tu auras le multitouch, les gestures (glisser à 2 ou 3 droits, le pincer/zoomer, etc

    • [^] # Re: traduire plug-n-play

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      comprendre "brancher et utiliser"

      Plutôt « juste connecter et utiliser (.i.e "ça marche") »

      donc je dirais qu'il n'y a pas besoin de driver pour ces périphériques,
      ou que le systeme doit pouvoir les trouver tout seul

      Un périphérique garanti p-n-p (par le fabriquant –il n'y a pas certification) est juste un périphérique qui respecte certaines normes et par conséquent doit pouvoir s'utiliser sur quasiment tous les systèmes (bien que cette appellation soit apparue avec µ$ W95) et surtout sans pilote dédié.
      Il y a d'abord le versant matériel où on doit pouvoir connecter et déconnecter à chaud (donc plutôt USB que PCI) et ça on le faisait depuis un petit bout de temps (certains périphériques sur certaines consoles par exemple) Toujours côté matériel, il n'y a pas de configuration requis par les usagers (les personnes ayant déplacé joué avec les IRQ manuellement comprendrons) et ça se faisait aussi (je pense à iSCSI et à l'ADB par exemple) Le système compatible PnP doit donc savoir gérer l'ajout et retrait de ces périphériques.
      Il y ensuite le versant logiciel car il y a toujours un pilote chargé par le système…

      Quand un périphérique USB est connecté, il doit obéir au protocole du même nom pour pouvoir échanger des données. Ce même protocole prévoit un certain nombre de codes émis par le système et auquel le périphérique doit répondre pour permettre sa configuration automatique : dire quelle est sa nature/catégorie (clavier, pointage, stockage, impression, etc.), sa sous-catégorie (déjà avec ça on peut charger un pilote générique), son code constructeur et son code produit (ici on peut charger un pilote spécifique si disponible) Sous Linux, un coup de lsusb donne l'aperçu de ces ces périphériques connectés avec leur niveau de connexion (quel port quoi) et les codes d'identification.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # docs pnp

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Il y a http://jp.barralis.com/howto/linux/Plug-and-Play-HOWTO/Plug-and-Play-HOWTO-3.php : bien que ça n'entre pas dans les détails, je ne sais pas si c'est simple dns le sens que tu voulais car ça parle de bus auquel on est moins confronté de nos jours (ISA et PCI), et montre l'avance de Linux sur d'autres systèmes fermés.

    Dans une autre réponse j'avais évoqué la commande pour lister les périphériques sur le bus le courant : https://debian-facile.org/doc:systeme:lsusb
    Et disait qu'il y a un code pour les constructeurs : https://usb-ids.gowdy.us/read/UD/
    et pour les classes (types et sous-types) de matériel : https://usb-ids.gowdy.us/read/UC/
    On peut avoir les mêmes informations d'autres façons : https://wiki.debian.org/fr/HowToIdentifyADevice/USB
    Le process que j'ai décrit dans cette autre réponse peut être retrouvé détaillé sur https://sysplay.github.io/books/LinuxDrivers/book/Content/Part11.html : mais je ne sais pas si ça répond à la simplicité voulue vu qu'on glisse rapidement dans la programmation des pilotes (mais c'est en deux parties et la première partie explique le fonctionnement avec des schémas en sus, la seconde partie introduit plutôt à https://www.kernel.org/doc/html/latest/driver-api/usb/writing_usb_driver.html que je trouve pas mal)
    À noter que Linux s'appuie essentiellement sur OHCI et EHCI : voir https://www.hcc-embedded.com/products/usb-overview/host-controllers/ohci-controller pour un diagramme de la pile

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

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