[Pcsclite-muscle] Multiple identical USB card readers

[Douglas E Engert]

lsusb


On 6/6/2025 3:10 PM, it at mrtv.lt wrote:
> Thanks for the explanation,
>
> 2025-06-05 22:57, Ludovic Rousseau rašė:
>> Le jeu. 5 juin 2025 à 16:41, it at mrtv.lt <it at mrtv.lt> a écrit :
>>> Hello,
>> Hello,
>>
>>> thank you for your reply. As far as I understand, the proposed solutions
>>> allow to identify which reader is which after the system has booted.
>>> However, reader identification is not my goal. The aim is to make sure
>>> that the reader numbers do not swap, so that a reader inserted in the
>>> appropriate slot is always identified, e.g. as “Reader 0”. These readers
>>> do not have serial numbers. But they could be “bound” using other unique
>>> attributes visible in the udevadm info (I noticed that the USB
>>> controller number changes, but the USB port number stays the same, which
>>> allows to build a udev rule). However, I don't know how to link these
>>> attributes to the reader enumeration mechanism used by pcscd.
>> The hotplug mechanism uses libudev (by default).
> What does this hotplug mechanism actually do with USB readers? If we swap the USB readers and then run pcscd
> --hotplug, we did not notice any effect. However, restarting pcscd
> changes the enumeration of the readers.
>  Is this hotplug mechanism applicable for USB readers? I found in the descriptions that it is for serial devices. How is it actually?
>>
>> The best I can propose is to provide a layer of indirection between a
>> stable name using the USB bus and port (retrieved using
>> SCARD_ATTR_CHANNEL_ID) and the PC/SC name.
>> For example "Reader 1 5" would be the reader connected on USB bus 1 and port 5.
> Perhaps that would solve my problem. Where and how to use this attribute?
> Could you point out an example?
>>
>> Bye
>>
>> -- 
>>   Dr. Ludovic Rousseau
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

-- 

  Douglas E. Engert  <DEEngert at gmail.com>