[nyir]

The top answer on SO that I found (https://unix.stackexchange.com/a/344463/91434) also uses this way of determining whether the device is being used - is that really the best way, or is there anything to actually query the device? E.g. my webcam has a light already that is only active when images are being captured(?), shouldn't it be possible to query that bit of information directly?

[digitalsushi]

In the Star Trek sense, anything is possible; if the people making the device had desired to expose the state of the LED to software, it would be very easy for us end users (including people writing a little shell script). But there's no reason to expect that just because the LED is active, they made it easy to sample its state.

It's a closed system, like a restaurant kitchen. Determining whether the chef is wearing a hat by examining the plates coming out may be possible with enough plates and time, but the answer sufficiently becomes 'no' for practical purposes.

[nixpulvis]

All external observables of my software running devices really should have a way to be observed programmatically.

[KMnO4]

I would be worried if there was a way to query the webcam LED. Ideally you want it controlled by the hardware: if power is going to the camera, power the light.

If it’s accessible via software, there’s the possibility that it can be controlled with software as well.

[InitialLastName]

Presumably there's a command that drives the common control point.

If there's a pin (or more likely, a USB control transfer controlling a pin) that controls the power state of the webcam (and thus the LED), you need to track the state of the pin anyway.

[nemetroid]

To me, asking the operating system's video abstraction layer seems cleaner than asking the device's binary blob.

[nixpulvis]

But will less confidence.

[nemetroid]

Rather the opposite. Unless you're trying to figure out if the device is capturing video and sending it somewhere else - but even then, a device behaving like that wouldn't be honest about it's status anyway.

[nixpulvis]

More points of failure.