Bonjour à tous !
@JMarc
Le 28/12/2019 à 16:01, Jean-Marc a écrit :
> Sat, 28 Dec 2019 11:24:15 +0100
> Bureau LxVx <[email protected]> é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=="add", >
>> 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 :
* quel est le sens de cet ajout "<ACTION=="add", >"
* pour quelles raisons ne faut-il pas éditer ce fichier ? cf PJ
> 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 <[email protected]>
> 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"
