Does the below patch solve your problem? You can try v3.18 kernel.

commit 35d0565b95547ec12d025dc9b1394f22968d113d
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Mon Dec 1 02:09:18 2014 +0100

    ACPI / video: update condition to check if device is in _DOD list

https://lkml.org/lkml/2014/11/29/158

I will test it and report today.

Created attachment 160031 [details]
ACPI log

Aaron,

So, the result is that your DOD patch works in a sense that it removes acpi backlight control and leaves only intel_backlight.
But it disables brightness buttons completely.

The patch should only affect if acpi_video interface should be created, it shouldn't affect event delivery, and the above commit is meant to restore acpi_video interface, dunno what's going wrong. can you please confirm with my problematic commit, is the event still generated with tool like acpi_listen? Does the intel_backlight work?

BTW, I didn't see what I want. I was expecting output from this line:
 ACPI_DEBUG_PRINT((ACPI_DB_INFO, "dod element[%d] = %d\n", i,
                                   (int)obj->integer.value));

Aaron,

With 3.18 kernel:

1. The event is not generated by Fn+F5 or F6. Other Fns work.
2. Intel_backlight works.

There is no "dod element" in dmesg.

And it is 100% your commit that cause that bug. I noticed it when backported that commit to Ubuntu kernel. Then tested 3.18rc and found that same thing is there.
If I revert it, the problem is gone.

BTW, acpi_video is not created.

In general the idea is good. When both acpi_video and intel_backlight are created, the system does not know which one to use. It can be solved by an option in xorg.conf. But for some reason it has side effects.

(In reply to Dmitry Tunin from comment #6)
> Aaron,
> 
> With 3.18 kernel:
> 
> 1. The event is not generated by Fn+F5 or F6. Other Fns work.
> 2. Intel_backlight works.
> 
> There is no "dod element" in dmesg.

Do you have CONFIG_ACPI_DEBUG=y in your kernel config?

> 
> And it is 100% your commit that cause that bug. I noticed it when backported
> that commit to Ubuntu kernel. Then tested 3.18rc and found that same thing
> is there.
> If I revert it, the problem is gone.

I have no doubt either, I'm trying to understand what is the problem here and then solve it.

I can understand the commit cause acpi_videoX disappear, but have no idea why that commit would make the event disappear...

Oops. I will rebuild with ACPI_DEBUG and post dmesg again.

Created attachment 160041 [details]
Debug log

If you need anything else, I can do.

Created attachment 160051 [details]
Log with acpi_osi=

This time I added acpi_osi=
There are no more errors.

Please attach your acpidump:
# acpidump > acpidump.txt

Created attachment 160161 [details]
acpidump

With the said offending commit, I suppose you have only intel_backlight under /sys/class/backlight directory? And does that interface work? If you run acpi_listen, when you press the hotkey, will there be any output?

Please attach the memory dump:
# dd if=/dev/mem of=gnvs bs=1 count=$((0x33b)) skip=$((0xB936AA98))

And i915_opregion:
/sys/kernel/debug/dri/0/i915_opregion

Created attachment 160211 [details]
memory dump

Created attachment 160221 [details]
i915_opregion

(In reply to Aaron Lu from comment #15)
> With the said offending commit, I suppose you have only intel_backlight
> under /sys/class/backlight directory? And does that interface work? If you
> run acpi_listen, when you press the hotkey, will there be any output?

As I already mentioned in #6, the intel_backlight interface works. Backlight is controlled.
acpi_listen does not react on Fn+F5 or F6.

To make it 100% clear. Before the DOD commit Fn+F5, F6 created events only with acpi_osi= boot parameter. After the commit there is no event with or without acpi_osi=.

What happened after adding acpi_osi= to kernel cmdline is beyond my understanding at the moment. If you do not add that cmdline, the events are always not delivered with or without the DOD commit, is it the case?

(In reply to Aaron Lu from comment #21)
> What happened after adding acpi_osi= to kernel cmdline is beyond my
> understanding at the moment. If you do not add that cmdline, the events are
> always not delivered with or without the DOD commit, is it the case?

Correct.

Besides the backlight hotkey, what other benefits does the acpi_osi= have? Is it a must have for your laptop?

BTW, acpi_osi= is documented. 

http://redsymbol.net/linux-kernel-boot-parameters/

acpi_osi= disables all strings. There must be something in the firmware.
acpi_osi=! may work too.

(In reply to Aaron Lu from comment #23)
> Besides the backlight hotkey, what other benefits does the acpi_osi= have?
> Is it a must have for your laptop?

There is nothing else I could notice. But backlight control is needed anyway.
So it a must have. It could be more convenient for other users, if it is done automatically as a quirk.

But now it is more important to get it working at least some way.

Here is my IMHO, why it may happen.

The UEFI firmware has an OS selection of 2 choices: Win7 or Win8.
I guess that it is supposed that Windows will handle brightness keys.
acpi_osi= disables that.

I do not know where UEFI stores that settings.

It seems that once the acpi_osi= is added, the event is delivered through keyboard instead of a notify to the LCDD video output device. Below is a simplified code from the acpidump:

        Method (_Q0E, 0, NotSerialized)  // _Qxx: EC Query
        {
            If (LGreaterEqual (MSOS (), OSVT))
            {
                If (^^^GFX0.PRST ())
                {
                    If (LNotEqual (^^^GFX0.LCDD._DCS (), 0x1F))
                    {
                        Return (Zero)
                    }

                    ^^^GFX0.DWBL () /* notify LCDD here */
                }
            }
            Else
            {
                If (ATKP)
                {
                    ^^^^ATKD.IANE (Add (LBTN, 0x20))
                }
            }

            Return (Zero)
        }

from the above asl code, for normal case(when acpi_osi= is not in the cmdline option), the event is delivered in the GFX0.DWBL method, but that require the _DCS method returns 0x1f, which is the reason why it doesn't work today. The problem would occur on any laptops as long as the firmware defines more than 8 output video devices due to the current i915 operation region code implementation. The v1 of the operation regions spec defines that at most 8 output devices are supported but obviously things have changed. Jani has a branch to handle such things:
http://cgit.freedesktop.org/~jani/drm/log/?h=didl
Can you please give it a try?

For the acpi_osi= case, the event should be delivered through ATKD.IANE, which is beyond my understanding.

I started building form jani. I need to do some work and will report later.

I tested jani branch. No difference. No events. Is any output of interest how it handles acpi?

BTW, jani drm patches break building of nouveau and radeon modules. I disabled them in .config, but just to let you know.

*** This bug has been marked as a duplicate of bug 70241 ***