Comment 186 for bug 1098216

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

> 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

I don't think it is working this way.
When user press the Fn+brightness key, usually, the scan code will be sent to user space as an input event; user space apps like g-s-d or acpid will listen for such evens and react accordingly: choosing a level and write it to the sysfs file to change the brightness level. How does the app choose the next level is beyond of my knowledge, and I would very much like to know.

> 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 information, it helped to understand what is happening here.

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

That's possible, it all depends on user space app. AFAIK, g-s-d will prefer to use acpi_video's backlight control file, but I don't know how xfce's power management component works.

> But you say that isn't happening for you, so it makes me wonder what's
> different about Ted's situation.
>
> 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

This might be more complex: current code already handle some broken BIOSes that does not report correct value with _BQC and we would assume the _BQC is retuning an index instead of level value.

> match, and 2) by default disable handling brightness notifications within the
> video driver and letting userspace take care of it.

As I said above, acpi video driver does not handle it automatically. For the normal case, it even doesn't know such a Fn key is pressed; for some other cases, it will get a notification from some EC firmware code and then it will map those notification to standard video brightness Fn keys and send them to user space through an input device it registered, for user space's awareness.

>
> I've got patches (along with a test build for Ubuntu), which I'll link to
> below. Testing is appreciated. One warning though: a colleague of mine had
> his
> machine get bricked while testing an earlier revision of these patches. I
> really don't _think_ there's anything in them which should brick a machine,
> however I can't say for sure as we don't know how his machine got bricked. We
> do know that he had a kernel panic (not where the panic occurred though) and
> that the machine got very hot before he noticed, and either of those could
> also
> be related to the bricking.
>
> That said, here's the link to the patches for those willing to assume the
> risk.
>
>
> http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.12~lp1098216v201302141715/

May I know which patch is included in this kernel?

Thanks.