I assumed that most if not all of these webcam LEDs are wired in series with the power to the camera itself. Which then makes it impossible to disable them. Who designs this LED to be software addressable?

Assuming Hanlon's razor it's a Chesterton's fence situation you just see a LED that indicates the camera is on. Assuming they ask the question at all they think it's just to remind you your still streaming/in a meeting. Then someone asks any of the following questions:

Can we use it to indicate additional information?

Can we make it standard with the other LEDs?

Can we dim it so it's more pleasant to use at night or make it a customisable colour?

I'm sure plenty of other questions take you down the same path and you've just destroyed one of the LEDs most useful functions.

To be fair, from what I can tell ThinkPad X230 is from 2012, which is over a decade ago, and my guess is that this practice was not yet common place.

In series with the power to the camera would be odd. You would be passing the same amount of current through both the camera and the LED. Unless you meant in parallel, which still leaves the other issue that the camera is likely always powered even when not in use, so the LED would always be on.

I'm not an EE by trade, but I personally wouldn't want to put a CCD in series with an LED with god-knows-what Vf tolerances. Then again, I'd bet that nearly all laptop webcams come as off-the-shelf modules with their own internal regulators for the CCD anyway. So maybe it wouldn't matter.

I'll bet it went something like this: As originally specified, the user need was "LED privacy indicator for the webcam." Product management turns that into two requirements:

1) LED next to webcam.

2) LED turns on and off when webcam turns on and off.

Requirement 1 gets handed to the EEs, and requirement 2 gets handed to the firmware engineers. By the time a firmware engineer gets assigned the job of making the LED turn on and off, the hardware designers are already 1 or 2 board spins in. If the firmware engineer suggested that we revise the board to better fit the intention of the user needs, one of two things will happen:

1) They'll get laughed out of the room for suggesting the EEs and manufacturing teams go through another cycle to change something so trivial.

2) They'll get berated by management because it's "not the engineers' place to make decisions about product requirements."

Of course this is all spitballing. I've definitely never been given a requirement that obviously should have been a hardware requirement. I've definitely never brought up concerns about the need to implement certain privacy and security-critical features in hardware, then been criticized for that suggestion. And I've definitely never, ever written code that existed for the sole purpose of papering over bad product-level decision making.

Nope, never. Couldn't be me.

>Who designs this LED to be software addressable?

The very first home made monitoring camera I made with a Raspberry Pi 1 and the camera module you could disable the LED in the config.

So it seems to be an old pattern. Definitely would make the most sense to focus on privacy and make the LED hard wired but here we are.

Does that mean if the LED dies the camera is dead?