Ludovic Rousseau's blog (Posts about pcsc-lite)

pcsc-lite backward & forward compatible with itself

Ludovic Rousseau — Wed, 07 Jan 2026 15:55:10 GMT

pcsc-lite 2.4.1 now provides a backward & forward compatible mechanism that supports both the current and previous internal communication protocols.

The communication protocol we are talking about here is the one between the client (libpcsclite) and the server (pcscd) sides. It is an internal-only protocol that is specific to pcsc-lite.

Protocol negotiation

To ensure that the client and server are using the same protocol, they negotiate the procotol they know. If they are different, the server will refuse the connection. In the application (client side), the SCardEstablishContext() function will return the error code SCARD_E_SERVICE_STOPPED.

Up to version 2.4.0, both the server and the client only supported one protocol version (version 4:5).

Sandboxes

Flatpack, Snap, AppImage and other sandbox technologies are now used to distribute applications.

In some/many cases, the server (pcscd daemon) running on the host comes from a different version of pcsc-lite than the client used in the sandbox. If the internal communication protocol differs, the communication is not possible.

I receive requests to solve this problem. See:

Protocol History

pcsc-lite version	Release Date	Protocol version	Compatible with
2.4.1	1 Jan 2026	4:5	4:4 & 4:5
2.4.0	19 Oct 2025	4:5	4:5
2.3.3	2 Apr 2025
2.3.2	26 Mar 2025
2.3.1	24 Dec 2024
2.3.0	3 Aug 2024
2.2.3	26 May 2024	4:4	4:4
...
1.8.24	12 Oct 2018
1.8.23	18 Dec 2017	4:3	4:3
...
1.8.9	16 Oct 2013
1.8.8	16 Jan 2012	4:2	4:2
...
1.6.5	12 Oct 2010

New protocol negotiation

From pcsc-lite 2.4.1 onwards, the protocol negotiation is smarter.

The daemon side will accept the current version and also the previous one. Versions 4:5 and 4:4 are accepted. It is straightforward, as the only change with version 4:5 is the addition of a new command (command CMD_GET_READER_EVENTS introduced in commit 53f57ed700bcd0bc47d970dc674ba3fd5ee5b387). Old clients will simply not use the new command.

The client side will also accept the current version and the previous one. These are versions 4:5 and 4:4. Using a recent client (protocol 4:5) with an old server (protocol 4:4) will have a small side effect. The SCardGetStatusChange() function will not include the number of reader events (see Improved SCardGetStatusChange() for "\\?PnP?\Notification" special reader).

Applications using pcsc-lite 2.4.1 can use a daemon as old as pcsc-lite version 1.8.24, released in October 2018.

A pcscd daemon from pcsc-lite 2.4.1 can handle clients as old as the same pcsc-lite version 1.8.24 from October 2018.

Supporting the (older) protocol version 4:3 may be possible but would require more efforts and be more complex. Contact me if you require this.

Conclusion

This change should help mix PC/SC servers and clients from more different versions.

This should prevent people from using ugly hacks.

New version of pcsc-lite: 2.4.1

Ludovic Rousseau — Wed, 07 Jan 2026 14:33:25 GMT

I have just released a new version of pcsc-lite 2.4.1.

pcsc-lite is a Free Software implementation of the PC/SC (also known as WinSCard) API for Unix systems. It provides an API for using smart cards and smart card readers.

This version offers backwards compatibility for both the client and server components. It should now be easier to mix and match different versions of pcscd and libpcsclite (and using different internal protocol versions).

Changes:

2.4.1: Ludovic Rousseau: 1 January 2026

Add backward version support on the client side
Add backward version support on the server side
hotplug libudev: rescan the USB bus with pcscd --hotplug
fix a value in pcscd.service systemd file
meson: install systemd files even if libsystemd is not used
Some other minor improvements

Outdated and broken PC/SC drivers with pcsc-lite 2.4.0

Ludovic Rousseau — Fri, 31 Oct 2025 16:59:51 GMT

Since pcsc-lite 2.4.0 and the fact that pcscd can now run as a normal user (see pcscd runs as pcscd user), the driver must configure the reader's device access rights. Otherwise, the pcscd process will not be able to use the device.

Unmaintained drivers

Some older, unmaintained drivers will no longer work with pcscd. I have requested their removal from Debian unstable.

They are:

libasedrive-serial & libasedrive-usb from asedriveiiie (see bug #1119077)
libgempc410 & libgempc430 from ifd-gempc (see bug #1119078)

I am the Debian maintainer of these packages, so it is my responsibility to open tickets to remove the packages.

I also filed a release critical bug #1119081 on libgcr410 so that this driver will not be included in the next version of Debian (unless the issue is fixed).

Old hardware

These drivers are intended for very old serial smart card readers (who still has a serial port on their computer?) or USB readers from the last century.

The advantage of Free Software is that if someone still has such a device, they can obtain the source code of the driver (still available online), adapt it and use it.

Old software

There has been no new version of the asedriveiiie software since September 2010. The source code is no longer available from the publisher (a commecial company).

The ifd-gempc software is maintained upstream by me. The latest major version dates from April 2012 and was mostly compiler warnings fixes. The source code is still available at https://ifd-gempc.apdu.fr/.

The libgcr410 software was also written by me. I wrote it before ifd-gempc and I am surprised to see it packaged in Debian, as it should be replaced by ifd-gempc. The Debian package has been abandonned by its Debian maintainer since March 2008. More recent Debian versions have been produced by the Debian Quality Assurance (QA) team.

Popularity

I have already published an article on the popularity of Debian packages for smart cards in 2020 in Smart card Usage in Debian: pcscd and drivers.

With updated graphics, we now have:

asedriveiiie

ifd-gempc

libgcr410

Very few people still have these packages installed. And even fewer use them.

Changes required

I also filed the bug #39 "Set group to pcscd in the udev rules file" on the upstream acsccid driver.

This driver is a fork of my CCID driver and is still actively maintained. The problem should therefore be resolved in a new version.

Conclusion

I don't have enough free time to maintain software that is no longer in use.

I haven't used these drivers for at least 10 years. And I don't plan on using them in the future, because I discovered that I no longer have the smart card readers.

New version of pcsc-lite: 2.4.0

Ludovic Rousseau — Sun, 19 Oct 2025 13:25:09 GMT

I just released a new version of pcsc-lite 2.4.0.

pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

The major change in this release is that the pcscd daemon process now runs as a normal user instead of root (when systemd is used).

You must use drivers that configure the reader device access rights so that a user in the pcscd group can access it for reading and writing. That is the case for libccid 1.7.0. See New version of libccid: 1.7.0.

Changes:

2.4.0: Ludovic Rousseau: 19 October 2025

Run pcscd under a pcscd user instead of root when using systemd
Set PIDFile in systemd service file
Protect contextMapList modifications using a mutex
meson:
- Fix libpcsclite.pc file
- respect builtin meson default_library option
- build and install spy lib & tool only when needed
UnitaryTests/*.py: fix pylint warnings
Improve Doxygen documentation

New version of pcsc-lite: 2.3.3

Ludovic Rousseau — Wed, 02 Apr 2025 15:54:28 GMT

I just released a new version of pcsc-lite 2.3.3.

pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Polkit rules was broken. So it was no more possible to give access to remote users for example. See pcsc-lite and polkit.

Thanks to Mike Kazantsev for the very nice bug report in PrivateUsers=yes in systemd sandboxing options prevents polkit rules from getting user/group info.

Changes:

2.3.3: Ludovic Rousseau: 2 April 2025

Make polkit rules work again (bug introduced in 2.3.2)

Ignore readers using PCSCLITE_IGNORE udev property

Ludovic Rousseau — Wed, 02 Apr 2025 12:00:29 GMT

Version 2.3.2 of pcsc-lite (New version of pcsc-lite: 2.3.2) introduced a new way to ignore a smart card reader.

The patch included in pcsc-lite is from Valtteri Vuorikoski and I will quote his git commit message in this article.

Use case

"This is similar to the existing filtering support provided by PCSCLITE_FILTER_IGNORE_READER_NAMES (Remove and/or customize PC/SC reader names), but allows using the full range of udev rules to match specific devices. For example, if you have several Yubikeys and one is attached to a specific USB port that is being forwarded to a virtual machine (viz. it should not be touched by programs on the host machine), this facility allows setting a rule to keep pcscd away from that Yubikey. Yubikeys attached to other ports keep working normally."

udev

By default pcsc-lite uses libudev to detect readers events (plug or unplug of a USB reader). The idea is to use a flag set by udev to tell pcsc-lite to ignore a reader.

Example rule that targets a Yubikey attached to a specific USB port and causes pcscd to ignore that device:

ACTION!="remove|unbind", SUBSYSTEM=="usb", ATTR{idVendor}=="1050",
ATTR{idProduct}=="0406", KERNEL=="1-2.3", ENV{PCSCLITE_IGNORE}="1"

The KERNEL match targets a USB device attached to port 3 of a hub on port 2 of USB bus 1, and rule sets property PCSCLITE_IGNORE to cause the device to be ignored.

The reader with idVendor=0x1050 and idProduct=0x0406 is the YubiKey FIDO+CCID from Yubico.

Or if you want to ignore any reader connected to USB port 1-3:

ACTION!="remove|unbind", SUBSYSTEM=="usb", KERNEL=="1-3", ENV{PCSCLITE_IGNORE}="1"

You put the above rule is a file /etc/udev/rules.d/foobar.rules and voila.

Config

To know what value for KERNEL= to use you can run udevadm monitor and connect a USB reader. You will get something like:

$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[2022.067560] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
KERNEL[2022.069016] change   /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
KERNEL[2022.069332] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[2022.069416] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
UDEV  [2022.690370] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
UDEV  [2022.695881] change   /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
UDEV  [2022.700310] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
UDEV  [2022.728691] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)

You can see the "1-3" information to use in the .rules file.

Debug

To debug your configuration and check the new field PCSCLITE_IGNORE is correctly set you can use udevadm monitor --property and you get something like:

$ udevadm monitor --property
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[2265.405075] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/001/015
DEVTYPE=usb_device
PRODUCT=8e6/3437/100
TYPE=0/0/0
BUSNUM=001
DEVNUM=015
SEQNUM=4692
MAJOR=189
MINOR=14

[...]

UDEV  [2266.066186] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
ACTION=bind
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/001/015
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=8e6/3437/100
TYPE=0/0/0
BUSNUM=001
DEVNUM=015
SEQNUM=4695
USEC_INITIALIZED=2265405122
ID_BUS=usb
ID_MODEL=USB_SmartCard_Reader
ID_MODEL_ENC=USB\x20SmartCard\x20Reader
ID_MODEL_ID=3437
ID_SERIAL=Gemplus_USB_SmartCard_Reader
ID_VENDOR=Gemplus
ID_VENDOR_ENC=Gemplus
ID_VENDOR_ID=08e6
ID_REVISION=0100
ID_USB_MODEL=USB_SmartCard_Reader
ID_USB_MODEL_ENC=USB\x20SmartCard\x20Reader
ID_USB_MODEL_ID=3437
ID_USB_SERIAL=Gemplus_USB_SmartCard_Reader
ID_USB_VENDOR=Gemplus
ID_USB_VENDOR_ENC=Gemplus
ID_USB_VENDOR_ID=08e6
ID_USB_REVISION=0100
ID_USB_INTERFACES=:0b0000:
ID_VENDOR_FROM_DATABASE=Gemalto (was Gemplus)
ID_MODEL_FROM_DATABASE=GemPC Twin SmartCard Reader
ID_PATH_WITH_USB_REVISION=pci-0000:00:14.0-usbv2-0:3
ID_PATH=pci-0000:00:14.0-usb-0:3
ID_PATH_TAG=pci-0000_00_14_0-usb-0_3
ID_SMARTCARD_READER=1
ID_FOR_SEAT=usb-pci-0000_00_14_0-usb-0_3
SYSTEMD_WANTS=smartcard.target
SYSTEMD_USER_WANTS=smartcard.target
PCSCLITE_IGNORE=1
MAJOR=189
MINOR=14
TAGS=:uaccess:security-device:seat:systemd:
CURRENT_TAGS=:uaccess:security-device:seat:systemd:

In pcscd logs I get:

04337722 [140613033731776] ../src/hotplug_libudev.c:656:HPEstablishUSBNotifications() USB Device add
00000411 [140613033731776] ../src/hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x08E6, PID: 0x3437, path: /dev/bus/usb/001/016
00000303 [140613033731776] ../src/hotplug_libudev.c:417:HPAddDevice() Device Gemalto PC Twin Reader at /dev/bus/usb/001/016 (1-3:1.0) has PCSCLITE_IGNORE set: ignored

And I do not see the PC/SC reader with pcsc_scan command:

$ pcsc_scan -r
No reader found.

Conclusion

I am sure you will find other use cases for this new feature.

Thanks to Valtteri Vuorikoski for the patch. If you have ideas of changes or improvements for pcsc-lite do not hesitate to submit them.

New version of pcsc-lite: 2.3.2

Ludovic Rousseau — Wed, 26 Mar 2025 15:26:20 GMT

I just released a new version of pcsc-lite 2.3.2.

pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:

2.3.2: Ludovic Rousseau: 26 March 2025

Hardening systemd pcscd.service file
pcscd.service: add missing Requires=polkit.service
pcsc-spy: add missing PCSCv2_PART10_PROPERTY_* definitions
Support udev PCSCLITE_IGNORE property to filter readers
debuglog: force use of colors when --color is used
Some other minor improvements

Static library libpcsclite.a

Ludovic Rousseau — Tue, 24 Dec 2024 15:20:37 GMT

With pcsc-lite 2.3.1 (New version of pcsc-lite: 2.3.1) a static library libpcsclite.a is also generated by default.

Using the static library libpcsclite.a instead of the dynamic one libpcsclite.so.1 has pros and cons.

Pros

The application binary does not depend on an external library. It is then easier to use on a minimal system that works on "any" x86_64 GNU/Linux distribution.

This request comes from a user of Alpine Linux. See github issue #216.

Cons

The mechanism to log pcsc-lite calls can't be used (PCSC API spy using LIBPCSCLITE_DELEGATE). It will also not be possible to use the mechanism to redirect calls for RDP (How to use LIBPCSCLITE_DELEGATE?).

If the library libpcsclite.a uses a protocol version that is different from the protocol version used by the installed pcscd server then client/server communication will fail. It will not "run everywhere". (See Accessing smart cards from inside a flatpak sandbox).

Conclusion

The Debian package does NOT provide the static version of the library because of the cons listed above.

But it may make sens for Alpine Linux or another specialized distribution to provide a static version of the library.

New version of pcsc-lite: 2.3.1

Ludovic Rousseau — Tue, 24 Dec 2024 15:12:24 GMT

I just released a new version of pcsc-lite 2.3.1.

pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:

2.3.1: Ludovic Rousseau: 24 December 2024

Install a default /etc/default/pcscd file
auth.c: implement polkit support for FreeBSD
meson:
- also build static version of libpcsclite
- add options to disable polkit and libsystemd
- add "filter_names" in features when needed
Doxygen: document dwCurrentState use for "\\?PnP?\Notification"
Some other minor improvements

Improved SCardGetStatusChange() for "\\?PnP?\Notification" special reader

Ludovic Rousseau — Sun, 04 Aug 2024 11:07:07 GMT

SCardGetStatusChange() works fine to detect a change in one of the listed readers. It is also possible to detect when a reader has been added or removed using the special reader name "\\?PnP?\Notification". See How to use SCardGetStatusChange()?.

One old problem is:

how to detect that a reader has been added between two calls to SCardGetStatusChange()?

Even if you call SCardGetStatusChange() just after the previous SCardGetStatusChange() returned you may still suffer from a race condition and miss a reader event.

In pcsc-lite version 2.3.0 I implemented a solution for that use case.

SCardGetStatusChange() will now use the high word (high 16-bits) of the .dwEventState field for the special reader "\\?PnP?\Notification" to store the number of reader events (since the start of the pcscd daemon).

Pseudo code algorithm

The suggested way to fix the problem is to use something like that:

initial call to SCardGetStatusChange()
get the initial value from .dwEventState
copy this value in .dwCurrentState
second call to SCardGetStatusChange()

If a reader has been added before the second SCardGetStatusChange() call then SCardGetStatusChange() will return immediately.

Sample code

File sample.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>

#include <winscard.h>

#define CHECK(f, rv, panic) \
 printf(f "(): 0x%08lX, %s\n", rv, pcsc_stringify_error(rv)); \
 if ((SCARD_S_SUCCESS != rv) && panic) \
 { \
  return -1; \
 }

#define PANIC true
#define DONT_PANIC false

#define MAX_READERS 16

int main(void)
{
    LONG rv;
    SCARDCONTEXT hContext;
    LPTSTR mszReaders;
    DWORD dwReaders = 0;
    char *ptr, *readers[MAX_READERS] = {};
    int nb_readers;
    SCARD_READERSTATE rgReaderStates[MAX_READERS];

    rv = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    CHECK("SCardEstablishContext", rv, PANIC)

    rv = SCardListReaders(hContext, NULL, NULL, &dwReaders);
    CHECK("SCardListReaders", rv, DONT_PANIC)

    mszReaders = calloc(dwReaders, sizeof(char));
    rv = SCardListReaders(hContext, NULL, mszReaders, &dwReaders);
    CHECK("SCardListReaders", rv, DONT_PANIC)
    printf("Found readers:\n");
    nb_readers = 0;
    for (ptr=mszReaders; *ptr; ptr += strlen(ptr) +1)
    {
        printf(" %s\n", ptr);
        readers[nb_readers++] = ptr;
    }
    printf("Found %d readers\n", nb_readers);

    /* add the special reader */
    readers[nb_readers++] = "\\\\?PnP?\\Notification";

    /* get the initial states */
    for (int i=0; i<nb_readers; i++)
    {
        rgReaderStates[i].szReader = readers[i];
        rgReaderStates[i].dwCurrentState = SCARD_STATE_UNAWARE;
    }
    rv = SCardGetStatusChange(hContext, 0, rgReaderStates, nb_readers);
    CHECK("SCardGetStatusChange", rv, DONT_PANIC)

    /* set the current state */
    for (int i=0; i<nb_readers; i++)
    {
        rgReaderStates[i].dwCurrentState = rgReaderStates[i].dwEventState;
        printf("reader: %s, events #: %d\n",
            readers[i], rgReaderStates[i].dwEventState >> 16);
        printf("reader: %s, events state 0x%04X\n",
            readers[i], rgReaderStates[i].dwEventState & 0xFFFF);
    }

    /* wait for a change */
    rv = SCardGetStatusChange(hContext, INFINITE, rgReaderStates, nb_readers);
    CHECK("SCardGetStatusChange", rv, PANIC)

    /* new state */
    for (int i=0; i<nb_readers; i++)
    {
        printf("reader: %s, events #: %d\n",
            readers[i], rgReaderStates[i].dwEventState >> 16);
        printf("reader: %s, events state 0x%04X\n",
            readers[i], rgReaderStates[i].dwEventState & 0xFFFF);
    }

    free(mszReaders);

    rv = SCardReleaseContext(hContext);
    CHECK("SCardReleaseContext", rv, PANIC)

    return 0;
}

File Makefile:

# Linux
PCSC_CFLAGS := $(shell pkg-config --cflags libpcsclite)
LDLIBS := $(shell pkg-config --libs libpcsclite)

CFLAGS = $(PCSC_CFLAGS) -g

sample: sample.c

clean:
    rm -f sample

Connect a reader

We start the sample code with no reader connected:

 SCardEstablishContext(): 0x00000000, Command successful.
 SCardListReaders(): 0x8010002E, Cannot find a smart card reader.
 SCardListReaders(): 0x8010002E, Cannot find a smart card reader.
 Found readers:
 Found 0 readers
 SCardGetStatusChange(): 0x8010000A, Command timeout.
 reader: \\?PnP?\Notification, events #: 33
 reader: \\?PnP?\Notification, events state 0x0000

 >>> connection of a new reader here

 SCardGetStatusChange(): 0x00000000, Command successful.
 reader: \\?PnP?\Notification, events #: 34
 reader: \\?PnP?\Notification, events state 0x0002
 SCardReleaseContext(): 0x00000000, Command successful.

State value 0x0002 is SCARD_STATE_CHANGED.

The first SCardGetStatusChange() returns a reader events of 33. After I connect a reader the number goes to 34.

Disconnect a reader

We restart the sample code with the reader connected:

 SCardEstablishContext(): 0x00000000, Command successful.
 SCardListReaders(): 0x00000000, Command successful.
 SCardListReaders(): 0x00000000, Command successful.
 Found readers:
  Gemalto PC Twin Reader 00 00
 Found 1 readers
 SCardGetStatusChange(): 0x00000000, Command successful.
 reader: Gemalto PC Twin Reader 00 00, events #: 0
 reader: Gemalto PC Twin Reader 00 00, events state 0x0012
 reader: \\?PnP?\Notification, events #: 34
 reader: \\?PnP?\Notification, events state 0x0000

 >>> removal of the reader here

 SCardGetStatusChange(): 0x00000000, Command successful.
 reader: Gemalto PC Twin Reader 00 00, events #: 0
 reader: Gemalto PC Twin Reader 00 00, events state 0x000E
 reader: \\?PnP?\Notification, events #: 35
 reader: \\?PnP?\Notification, events state 0x0002
 SCardReleaseContext(): 0x00000000, Command successful.

The reader "Gemalto PC Twin Reader 00 00" has been removed. Its state value 0x000E contains the bits:

SCARD_STATE_UNKNOWN
SCARD_STATE_UNAVAILABLE
SCARD_STATE_CHANGED

Connect a second reader

We restart the sample code with the reader connected:

 SCardEstablishContext(): 0x00000000, Command successful.
 SCardListReaders(): 0x00000000, Command successful.
 SCardListReaders(): 0x00000000, Command successful.
 Found readers:
  Gemalto PC Twin Reader 00 00
 Found 1 readers
 SCardGetStatusChange(): 0x00000000, Command successful.
 reader: Gemalto PC Twin Reader 00 00, events #: 0
 reader: Gemalto PC Twin Reader 00 00, events state 0x0012
 reader: \\?PnP?\Notification, events #: 36
 reader: \\?PnP?\Notification, events state 0x0000

 >>> connection of a second reader

 SCardGetStatusChange(): 0x00000000, Command successful.
 reader: Gemalto PC Twin Reader 00 00, events #: 0
 reader: Gemalto PC Twin Reader 00 00, events state 0x0010
 reader: \\?PnP?\Notification, events #: 37
 reader: \\?PnP?\Notification, events state 0x0002
 SCardReleaseContext(): 0x00000000, Command successful.

The Gemalto reader event state is 0x0010 = SCARD_STATE_EMPTY because it does not contains a smart card. It does not have the bit SCARD_STATE_CHANGED set because it's state has not changed.

The PnP reader state is 0x0002 = SCARD_STATE_CHANGED because a new reader was connected.

Remarks

Timeout

It is important to use a timeout of 0 (parameter dwTimeout) in the first call to SCardGetStatusChange() to make the function returns immediately.

Unitary Test

If you want to know if your implementation of PC/SC includes the fix or not (or test on Windows or macOS) you can use the program CardGetStatusChange_PnP_Events.py included in pcsc-lite UnitaryTests/SCardGetStatusChange/ directory.

Windows

Microsoft implemented a similar mechanism. But instead of using the number of reader events it uses the number of connected readers.

So between the 2 calls to SCardGetStatusChange() if one reader is added and one reader is removed you may not be notified.

macOS

Apple does not support the special reader "\\?PnP?\Notification". See OS X El Capitan missing feature: SCardGetStatusChange() and "\\?PnP?\Notification".

So there is no way it supports the mechanism presented here.

Backward compatibility

To not break existing codes the new SCardGetStatusChange() beahavior is enabled only if the number of reader events in .dwCurrentState is not zero.

That is also one reason why you should use a dwTimeout value of 0 for the first call.

`.dwEventState` for normal readers

The high 16-bits of .dwEventState for the normal readers is also used. It contains the number of card events for this particular reader.

This is an old behavior that is documented in the API documentation:

dwEventState also contains a number of events in the upper 16 bits (dwEventState & 0xFFFF0000). This number of events is incremented for each card insertion or removal in the specified reader. This can be used to detect a card removal/insertion between two calls to SCardGetStatusChange()

Conclusion

I was aware of this race issue with SCardGetStatusChange() since a long time (at least 2018. Thanks Maksim). But I got a new motivation boost after an issue was reported SCardGetStatusChange: Race condition when attaching multiple readers at the same time.

It is now the job of applications programmers to use this new feature in their codes.

If you find a regression in your application because of this change please open an issue.

Ludovic Rousseau's blog (Posts about pcsc-lite)

pcsc-lite backward & forward compatible with itself

Protocol negotiation

Sandboxes

Protocol History

New protocol negotiation

Conclusion

New version of pcsc-lite: 2.4.1

Changes:

Outdated and broken PC/SC drivers with pcsc-lite 2.4.0

Unmaintained drivers

Old hardware

Old software

Popularity

Changes required

Conclusion

New version of pcsc-lite: 2.4.0

Changes:

New version of pcsc-lite: 2.3.3

Changes:

Ignore readers using PCSCLITE_IGNORE udev property

Use case

udev

Config

Debug

Conclusion

New version of pcsc-lite: 2.3.2

Changes:

Static library libpcsclite.a

Pros

Cons

Conclusion

New version of pcsc-lite: 2.3.1

Changes:

Improved SCardGetStatusChange() for "\\?PnP?\Notification" special reader

Pseudo code algorithm

Sample code

Connect a reader

Disconnect a reader

Connect a second reader

Remarks

Timeout

Unitary Test

Windows

macOS

Backward compatibility

.dwEventState for normal readers

Conclusion

`.dwEventState` for normal readers