Hi James,
On 04/16/2018 03:02 PM, James Hogan wrote:
On Mon, Apr 16, 2018 at 01:07:50PM +0200, Hans de Goede wrote:
On 16-04-18 00:54, James Hogan wrote:
On Sun, Apr 15, 2018 at 02:04:26PM +0200, Hans de Goede wrote:
When you say quirk do you mean you add something to the kernel commandline to work around this?
No, it was automatic, in the source. I don't know this code well enough to know how they got it working.
Weird, if my only_lcd changes impact you then acpi_osi_is_win8() returns true for you
It rings a bell that this laptop claims win8 support.
you should get the intel backlight interface by default, but maybe the i915 driver somehow detects that that is not appropriate on your device ... ?
Before I can start working on a quirk to fix this I've some questions:
- With recent kernels without the 965736ee654d commit, what is the output of "ls /sys/class/backlight" ?
$ ls -l /sys/class/backlight total 0 lrwxrwxrwx 1 root root 0 Apr 16 13:57 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
- What is the output of "ls /sys/class/backlight" after commit 965736ee654d ?
no devices show up there.
- Can you start a kernel with commit 965736ee654d in there and "video.only_lcd=0" on the kernel commandline and verify that this fixes backlight control for you ?
Confirmed, acpi_video0 shows up and backlight control works as expected.
Ok, so rather then DMI quirk our way out of this I've come up with a more generic solution.
I've just send out a "[RFC] ACPI / video: Only default only_lcd to true on Win8-ready _desktops_" patch which should fix this.
Can you give this patch a quick spin (on top of the troublesome commit) and let me know if it fixes things (without needing the kernel cmdline option).
Regards,
Hans