[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Résolu: Résumé et tentative d'explication: Problème avec udevd



Bonjour à tous !

@JMarc

Le 28/12/2019 à 16:01, Jean-Marc a écrit :
Sat, 28 Dec 2019 11:24:15 +0100
Bureau LxVx <debian-user-fr@emailasso.net> écrivait :

Bonjour à tous !
salut Sylvie,
Je reprends l'Inspiron ce matin et

@JMarc : ça marche ! super !
Content d'avoir pu t'aider, Sylvie.
:-D

En fait, j'avais trouvé cette soluce MAIS ...en ajoutant

<ACTION="" >
j'avais "oublié" l'espace qui suivait (pas tech, j'avais dit ...)
Pour quelqu'un de "pas tech", c'est impressionant !
J’espère que ce n'est pas ironique ;-)
Donc ... merci : mon apprentissage continue par votre aide et par mes erreurs.
Avec grand plaisir !

Dernier détail : tu ne mentionnes pas si tu as copié le fichier 97-hid2hci.rules dans le répertoire /etc/udev/rules.d/ avant de le modifier.
J'ai suivi tes conseils "à la lettre"...
  Se faisant, tu évites qu'il ne soit remis dans sa version originale en cas de mise à jour du paquet bluez, paquet qui contient ce fichier.
Compris ! et ça marche  pour l'instant.


Deux questions :
Et, pour info, ce bogue fait l'objet d'un suivi dans le rapport de bogue suivant :
. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901965
J'y ai ajouté quelques infos en espérant relancer les maintainers en vue d'une solution définitive.

Can you, please, advice what is the best solution to, at least, mitigate the risk of being hit by this bug ?  Specifying the ACTION like described in the RH bugreport or using the driver usbhid like in the Тут Root's proposed patch.

And about further investigations, unfortunately, I cannot reproduce the bug and, then, I am not able to investigate further to know if it is really a driver or kernel bug.
Merci : je n'aurais pas su faire.

Librement,

Sylvie
Bonne fin de journée.

Jean-Marc <jean-marc@6jf.be>
https://6jf.be/keys/ED863AD1.txt
Bon réveillon à tous !

Bien librement,

Sylvie
sylinfo84@debian-inspiron:~$ cd /etc/udev/
sylinfo84@debian-inspiron:/etc/udev$ ls
hwdb.d  rules.d  udev.conf
sylinfo84@debian-inspiron:/etc/udev$ cd rules.d/
sylinfo84@debian-inspiron:/etc/udev/rules.d$ ls
59-smfp_samsung.rules  97-hid2hci.rules
sylinfo84@debian-inspiron:/etc/udev/rules.d$ nano 97-hid2hci.rules 
sylinfo84@debian-inspiron:/etc/udev/rules.d$ 

Le résultat (j'ai bien du l'éditer !): 


# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="hid2hci_end"
SUBSYSTEM!="usb*", GOTO="hid2hci_end"

# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162

ACTION=="add", ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATT$
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0"$
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71$
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
# Logitech, Inc. diNovo Edge Keyboard
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c714", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="$
  ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb $

# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --meth$

LABEL="hid2hci_end"

Reply to: