Comment 189 for bug 1098216

(In reply to comment #62)
> (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

The acpi video driver can do some things, and backlight control is one of them. I'm talking about backlight control alone here.

> 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.

Right, that is because for your laptop, there will be an acpi notification once the function key is pressed. But this is not the case for all laptops.

>
> (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.

OK, that is debatable :-)