5 ms·

The top answer on SO that I found (https://unix.stackexchange.com/a/344463/91434 https://unix.stackexchange.com/a/344463/91434) also uses this way of determinin

by nyir 5y ago

The top answer on SO that I found (https://unix.stackexchange.com/a/344463/91434 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 5y ago
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 5y ago
  All external observables of my software running devices really should have a way to be observed programmatically.
KMnO4 5y ago
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 5y ago
  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 5y ago
To me, asking the operating system's video abstraction layer seems cleaner than asking the device's binary blob.
- nixpulvis 5y ago
  But will less confidence.
  - nemetroid 5y ago
    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 5y ago
      More points of failure.

by nyir 5y ago

digitalsushi 5y ago

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 5y ago
All external observables of my software running devices really should have a way to be observed programmatically.

KMnO4 5y ago

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 5y ago
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 5y ago

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

nixpulvis 5y ago
But will less confidence.
- nemetroid 5y ago
  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 5y ago
    More points of failure.