Comment 188 for bug 1098216

(In reply to comment #60)
> (In reply to comment #57)
> > To clarify, video.ko does still handle the keys (whether or not it should
> be
>
> Indeed, but it handles the key only when requested, i.e. a user space program
> did a sysfs write to the brightness file, then acpi video driver will update
> the backlight level accordingly; not that it handles the key automatically.
> So
> if there is no app reacting to the key, acpi video driver will do nothing.

Well, I'm not sure how generic this comment is, but I kind-of disagree. I can't test without video.ko since nowadays i915 needs it and KMS needs i915, but on my x201s and my x230 pre 3.7 or 3.7+ with acpi_osi="!Windows 2012" I don't need any userspace daemon to handle brightness keys.

(In reply to comment #61)
> Hi Seth,
>
> I'm sorry I think I missed some code in video.c...
>
> Apparently, for the notification case, the driver indeed changed the
> brightness
> level. I don't think this is correct, since it will also report this event to
> user space, like the no notification case. So we should definitely set
> brightness_switch_enabled to 0 by default, to give user space a consistent
> behaviour.

If that means brightness keys won't work anymore if no userspace is running (or if the screen is locked, or noone is logged in, or anything userspace related), I again think this is a bad idea.