(In reply to comment #56)
> (In reply to comment #54)
> > (In reply to comment #51)
> > > For what it's worth, I have an X230, with the 2.06 version of the BIOS
> and the
> > > 1.10 version of the firmware, running a 3.8-rc6 kernel plus ext4
> development
> > > patches (3.8.0-rc6-00041-gf3a1e5d).  i am using Xfce4 (none of that GNOME
> crap
> > > for me :-), and the brightness keys (Fn-F8/Fn-F9) work just _fine_.
> > 
> > Odd, this bios version isn't listed on Lenovo's website. 
> 
> Sure it is:
> http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/g2uj10us.txt
> Latest is 2.51 and:
> 
> 2.06  (G2UJ08US)  2.06       (G2ET86WW)  1.10  (G2HT31WW)    01    2012/11/27

It wasn't listed at whatever page I was looking at :-/

> > It is newer than the
> > x230 bios version that I know to have the bug, so perhaps Lenovo fixed the
> > problem. Care to attach your ACPI tables?
> 
> I do have the problem with 2.51 (latest version available).

Good to know, thanks.

> > It's also possible that it works because you're using a different window
> > manager, so you most likely wouldn't be using gnome-settings-daemon. You
> could
> > check /sys/class/backlight/*/{brightness,actual_brightness} and see how the
> > values are changing in response to the brightness keys.
> 
> I'm using Xfce too, so I'll try to explain how it works to hopefully
> unconfuse
> people.
> 
> On x230 (and all the 2012 Thinkpads, it seems), before 3.7 brightness keys
> work
> just fine independently of any userspace daemon. It works in single user, it
> works in vt, it works in X at login screen, it just works. However, Xfce
> needs
> a bit of tuning in order to indicate xfce4-power-manager it doesn't have to
> handle brightness keys (KEY_BRIGHTNESS{UP,DOWN}) itself (since it's already
> handled, I guess by video.ko) but that's all.
> 
> On 3.7+ and due to the _OSI("Windows 2012") handling, video.ko seems to not
> handle those anymore, but KEY_BRIGHTNESS{UP,DOWN} are still correctly emitted
> (by /dev/input/even4 which is "Video Bus"). So if xfce4-power-manager is
> configured to handle the keys itself (which is the case by default) it'll
> happily do it (however you'll only have 8 or 9 brightness level instead of
> 15,
> it seems).

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.

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

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.

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/