Comment 184 for bug 1098216

(In reply to comment #57)
> To clarify, video.ko does still handle the keys (whether or not it should be
> doing so is debatable). What happens is that it receives a brightness up/down
> notification, reads the current brightness via _BQC, selects the next
> higher/lower brightness level, and writes it via the _BCM. The adjacent
> levels
> do not change the brightness though, not even the internal value of the
> brightness returned by _BQC. So the next time the brightness up/down key is
> pressed it reads the exact same value as the first time. So no matter how
> many
> times you hit the hotkeys you'll never see any change in brightness.

Thanks for the clarification.
>
> > So in case it's still confusing, I think it's better to test either in a vt
> or
> > in X with nothing else running (just running X from vt for example).
>
> That would take X and the desktop out of the picture. What I thought might be
> different about xfce is that it could be responding to the notifications by
> changing the brightness via the GPU's backlight device instead of
> acpi_video's.
> But you say that isn't happening for you, so it makes me wonder what's
> different about Ted's situation.

I think that Ted might not have changed anything to xfce4-power-manager default setup, so maybe 3.7 actually improved his experience, due to shortcomings in xfpm.
>
> Also I should probably give an update. The short version is that the
> maintainers have requested that I fix the issue by gradually changing the
> brightness instead of using a quirk. Going that route doesn't fix the problem
> I
> just described with the hotkeys, so the approach I've taken is to 1) read
> back
> the brightness after writing and disable use of _BQC if the value doesn't
> match, and 2) by default disable handling brightness notifications within the
> video driver and letting userspace take care of it.

Hmh, that looks like a huge change to me. On a personal note, I prefer this kind of things to be handled in the kernel, so it works just fine wether you're in X, on a vte, with the screen locked or not etc. I know some daemon don't handle this really fine (at least xfpm is a bit confused since it doesn't really detect automatically if he should hands off the brightness), but at least that means a daemon is *not* needed to handle something as close to metal as the brightness handling is.

> That said, here's the link to the patches for those willing to assume the
> risk.

I'll try to test them tomorrow on X230 and report back.