This isn't about the lock screen. You need to convince UX. :-)

The previous time that using ambient light sensors for this was proposed, they didn't get initialized early enough to be used when displaying the boot splash screen. Even if they did, the readings from them are noisy enough that we wouldn't be able to do anything sensible.

And I'll just leave Mike's change here: https://crrev.com/c/1145840

(I'll probably un-cc myself soon since this will likely just get a bunch of "+1" comments. :-P)

My bad: this is about the boot screen coming from frecon, not the lock screen
(which at least on my pixelbook looks ok -- not too bright).

#1: Indeed, frecon seems to initialize dbus [1] after the splash screen is 
shown [2], so this might need deeper changes -- aside from the noisy readings
ofc.


[1] https://cs.corp.google.com/chromeos_public/src/platform/frecon/main.c?dr&g=0&l=494
[2] https://cs.corp.google.com/chromeos_public/src/platform/frecon/main.c?dr&g=0&l=475

this is the bootscreen that is shown on every boot before Chrome comes up, so it's not related to OOBE

Per discussion with Jenn on http://go/cros-splash, I think it's unlikely that we'll change these assets. Let's use issue 785040 to track reducing the brightness that's used while the boot splash screen is displayed.