Maybe due to you have two graphics card and acpi_video0 corresponds to the discrete one and since the backlight is actually controlled by the integrated one, so acpi_video0 doesn't work.

Please attach your dmesg.

As far as I know, there is no discrete graphic card present in this laptop.
I add the aoutput of dmesg and lshw. 
lshw shows two displays, but I have not connected an external display to the laptop.

Created attachment 187031 [details]
Output of dmesg

Created attachment 187041 [details]
Output of lshw

Hmm, not two graphics controller but one controller has two video output devices that claim to be capable of adjusting backlight.
Tough, not easy to decide which one is the right one.

What exactly does "video output device" mean? Does this refer only to a physical monitor connected to the graphic controller (graphic card?) or can this be a virtual output, too?

Is there a way to identify which of these two video output devices is used for the actual video output (internal monitor panel of the laptop). Maybe this can be used to decide which device shall be exposed by the kernel.

At the moment I have no idea where the second output device is coming from. xrandr and gnome only list one monitor.

It's a word used in the ACPI spec, see "Appendix B Video Extensions" of the ACPI spec if you are interested.

The video output device means the connected monitors, like LCD, CRT, etc and these devices may be connected through different ports like VGA, HDMI, etc.

There is information about which kind of device it is(LCD or CRT or), and your ACPI table defines two:
                Device (DD03)
                {
                    Name (_ADR, 0x0320)  // _ADR: Address
                    Name (_DCS, 0x1F)  // _DCS: Display Current Status
                    Name (_DGS, Zero)  // _DGS: Display Graphics State
                    Method (_BCM, 1, NotSerialized)  // _BCM: Brightness Control Method
                    {
                        Divide (Arg0, 0x0A, Local0, Local1)
                        If ((Local0 == 0x00))
                        {
                            BRTW (Arg0)
                        }
                    }
current kernel doesn't 
                }

                Device (DD04)
                {
                    Name (_ADR, 0x0410)  // _ADR: Address
                    Name (_DCS, 0x1F)  // _DCS: Display Current Status
                    Name (_DGS, Zero)  // _DGS: Display Graphics State
                    Method (_BCM, 1, NotSerialized)  // _BCM: Brightness Control Method
                    {
                        If (^^^LPCB.H_EC.ECON)
                        {
                            If (^^^LPCB.H_EC.ECLS)
                            {
                                BRIB = Arg0
                                ^^^LPCB.H_EC.MBX2 = Arg0
                                ^^^LPCB.H_EC.MBX1 = 0x10
                            }
                        }
                    }
                }

According to the spec, device DD04, whose _ADR is 0x0410 is the internal digital panel while the device DD03, whose _ADR is 0x0320 is an external digital monitor(DVI monitor?).

The acpi video module, who is responsible for the acpi_videoX interface, doesn't have the knowledge of which output device is currently connected, the graphics driver does.

OTOH, it doesn't seem possible for the backlight of the external monitor being controlled by the ACPI interface, Jani and Hans, do you have any information on this? 

I was thinking not creating acpi_videoX interface for video output devices that is not the type of internal digital panel to avoid the trouble since the majority of the people may not expect to control the backlight of the external monitor through laptop I guess and even if they want to do that, I wonder how that can work? Is there a standard protocol that all monitors support that the OS can use to do the backlight control?

Is there any missing information I can provide to help solving the issue?

No more information required, I just don't know how to fix it.

Hi,

(In reply to Aaron Lu from comment #9)
> No more information required, I just don't know how to fix it.

In comment 7 you wrote: "I was thinking not creating acpi_videoX interface for video output devices that is not the type of internal digital panel", how about doing that, maybe combined with a quirk to only enable this behavior on some devices to avoid regressions ?

Regards,

Hans

I can try that, but I have a feeling it may cause regressions for other systems...

(In reply to Aaron Lu from comment #11)
> I can try that, but I have a feeling it may cause regressions for other
> systems...

Right, which is why I suggested enabling it via a quirk, and for now only setting that quirk (based on dmi matching) for the Esprimo Mobile 9410...

Not pretty, but it seems like something which may be useful on a hand of other models, so it is probably good to add support for this extra check, and by only enabling the extra check via quirk (and kernelcmdline option for testing) we avoid regressions.

Created attachment 188991 [details]
Only register backlight for LCD type video output device

Worth a try :-)

(In reply to Hans de Goede from comment #12)
> (In reply to Aaron Lu from comment #11)
> > I can try that, but I have a feeling it may cause regressions for other
> > systems...
> 
> Right, which is why I suggested enabling it via a quirk, and for now only
> setting that quirk (based on dmi matching) for the Esprimo Mobile 9410...

Oh, I didn't notice the latter part of comment #10.

> 
> Not pretty, but it seems like something which may be useful on a hand of
> other models, so it is probably good to add support for this extra check,
> and by only enabling the extra check via quirk (and kernelcmdline option for
> testing) we avoid regressions.

What about we just do it for all, and if people have problems then we add the quirk?
On another thought, it feels very likely to trigger regressions, so yes, I'll add the quirk(the patch in comment #13 didn't yet).

Created attachment 189061 [details]
Only register backlight for LCD type video output device

As suggested by Hans, I've used the quirk now. Please test this patch, thanks.

I have applied the patch from comment #15 on top of linux 4.3-rc3.
Booting this kernel, there are still two acpi_video* folders in /sys/class/backlight.
The behavior is the same as before. acpi_video1 can change the backlight, changes to acpi_video0 have no effect.

This is my first patched kernel. Is there a way to check if I applied the patch correctly?
(I checked that the source file contain the modification and I checked that the newly built kernel is loaded with uname -r)

Hi,

(In reply to Christian Scharl from comment #16)
> I have applied the patch from comment #15 on top of linux 4.3-rc3.
> Booting this kernel, there are still two acpi_video* folders in
> /sys/class/backlight.
> The behavior is the same as before. acpi_video1 can change the backlight,
> changes to acpi_video0 have no effect.
> 
> This is my first patched kernel. Is there a way to check if I applied the
> patch correctly?
> (I checked that the source file contain the modification and I checked that
> the newly built kernel is loaded with uname -r)

Maybe the dmi mathcing for the quirk is not working, can you try adding video.only_lcd=1 to your kernel commandline ?

Regards,

Hans

Thanks for the tip. When adding video.only_lcd=1 to the kernel command line there is no directory under /sys/class/backlight/.

Hi,

(In reply to Christian Scharl from comment #18)
> Thanks for the tip. When adding video.only_lcd=1 to the kernel command line
> there is no directory under /sys/class/backlight/.

You mean no directory at all, not only one as we want, right ?

Aaron, it looks like your patch needs some work then ...

Regards,

Hans

Exactly. The directory is empty and no acpi_video* directory is present.

Best regards
Christian

Thanks for the input and sorry for the delay, it's National holiday here in China. I'll take a look at the patches now.

                Name (_DOD, Package (0x04)  // _DOD: Display Output Devices
                {
                    0x00010410,
                    0x00010100,
                    0x00010320,
                    0x00010240
                })

I just noticed the above number doesn't have bit 31 set, which means if we can explain the other bits according to ACPI spec; if it's not set, it means it doesn't follow the format specified by the ACPI spec, so the code doesn't set LCD flag for the device...

Created attachment 189701 [details]
Only register backlight for LCD type video output device, also quirk device_id_scheme

Please try this patch, and since last patch doesn't correctly handle DMI entry, please also attach the output of dmidecode. To skip the DMI issue, you can also add video.only_lcd=true video.device_id_scheme=true to your kernel cmdline.

I added a debug print for device_id_scheme, so if you see it in dmesg, it means you have patched the kernel well.

Changes since last version:
I also did a quirk for the device_id_scheme in this patch, I don't find anything better to deal with it but if you have any ideas, please let me know, thanks.

Any news?

Sorry for the delay. I tested the patch end of last week with 4.3-rc3, but the kernel was crashing at startup (with and without the provided cmdline parameters). Unfortunately I had no time to check if the crash happens without the patch, too.
I'll come back as soon as I could test without the patch.

Regards
Christian

Created attachment 190421 [details]
Output of dmidecode

Please find attached the output of dmidecode.

Regards
Christian

Created attachment 190431 [details]
Screen output of crash

I tested again with an unmodified version of 4.3-rc4 and with the applied patch.
The unmodified version boots without problems. With the applied patch and adding no parameter, I get the attached output on the screen and the system freezes (no new output after some minutes).
With the cmdline parameters the behavior is similar.

Please let me know if more information are needed or if I can test something.

Regards
Christian

I can't tell what happened there with the screenshot, it missed the starting part of the oops...
I tried to reproduce it locally but failed(using a different system so may not mean anything).

Possible to get the full trace of the oops? Not sure if USB-serial can help here, that depends on if USB driver is loaded earlier than i915. Net console may also worth a try.

Thanks for the tip. The docking port has a native serial port, so I will try to catch the oops over the serial port. Currently I am missing the correct cable, but I will get it on the weekend.

I'll report back, when I get the output working.

Regards
Christian

When trying to get the kernel output over the serial port, it is starting without this crash.
I added the following parameters to the cmdline:
console=tty console=ttyS0,19200

When I add console=tty only, I get the crash. With the second parameter it does not happen. But I only get a console output and the window manager is not starting.

When booting with the second option, I checked the content of /sys/class/backlight and the directory is empty.
Is the second parameter preventing that the intel driver is loaded?

At the moment I do not know how to debug the problem further. If you have any idea, please let me know.

Please can you tell me with which kernel version you did the test? I want to try what results I get with this version.

Regards
Christian

(In reply to Christian Scharl from comment #30)
> When trying to get the kernel output over the serial port, it is starting
> without this crash.
> I added the following parameters to the cmdline:
> console=tty console=ttyS0,19200

Did you get any serial log with console=ttyS0,19200?

> 
> When I add console=tty only, I get the crash. With the second parameter it
> does not happen. But I only get a console output and the window manager is
> not starting.
> 
> When booting with the second option, I checked the content of
> /sys/class/backlight and the directory is empty.
> Is the second parameter preventing that the intel driver is loaded?

No, it shouldn't.

> 
> At the moment I do not know how to debug the problem further. If you have
> any idea, please let me know.

dmesg with console=ttyS0,19200 please.

> 
> Please can you tell me with which kernel version you did the test? I want to
> try what results I get with this version.

It should be v4.3-rc5 when I did the test, but I don't think it matters much.

Thanks for the test.

Created attachment 191181 [details]
dmesg output with console=ttyS0,19200

This is the dmesg output when booting with console=ttyS0,19200.

Created attachment 191191 [details]
dmesg output with console=ttyS0,19200 video.only_lcd=true video.device_id_scheme=true

This is the dmesg output with console=ttyS0,19200 video.only_lcd=true video.device_id_scheme=true

In the dmesg and on the console there are a lot of messages of this type (repeating every few seconds):
video: `true' invalid for parameter `only_lcd'

Could it be that I have not applied the patch correctly?

Regards
Christian

Created attachment 191211 [details]
Only register backlight for LCD type video output device

Sorry, my mistake.
The debug print I added in last patch didn't check for NULL pointer that caused the problem.
And the param needs to be set as:
video.only_lcd=1 instead of true.

Please use this patch, and test both with and without the "video.only_lcd=1 video.device_id_scheme=1" kernel cmdline options to see the effect, thanks.

Dear Aaron,

thanks a lot for your work. The last patch works perfectly. I applied the patch on top of 4.3.0-rc7.

With and without the command line parameters, /sys/class/backlight contains only one folder and it is now possible to change the backlight level with the gnome shell slider and the hotkeys.

Do you need any additional information?

Thanks
Christian

No more info needed, I'll add your reported-and-tested-by tag to the patch and submit it later, thanks a lot for the test.

Patch sent out:
https://patchwork.kernel.org/patch/7507631/

commit e50b9be14ab0ed10b0b3cd4112ff4bed0abf7b6f
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Wed Oct 28 15:09:23 2015 +0800

    ACPI / video: only register backlight for LCD device

as v4.4-rc1 material.