Hello, after big changes in acpi video/i915 code I cannot change display brightness on my Dell Latitude E6440 with kernel 3.17-rc6. With kernel 3.13 everything worked fine. More information about this problem: For configuring brightness on Dell laptops there are 4 ways: 1) via acpi video driver 2) via dell-laptop driver 3) via i915 drm driver 4) from userspace with special dell SMI call (e.g with program dellLcdBrightness from libsmbios package) Methods 2) and 4) are same, both making special SMI call and Bios handing this request (just 2 is from kernel and 4 from userspace) Method 1) via acpi video driver working, but is not perfect. Driver can be used to change brightness (but only some levels, probably this depends on acpi/DSDT tables), but cannot be used to retrieve current brightness (when BIOS/SMI change brightness acpi driver report old incorrect value). So I prefer dell-laptop driver instead acpi video. Method 3) working even with 3.17-rc6 kernel but because that backlight device exported by i915 is marked as raw, desktop programs prefer to use other devices. Moreover it looks like that methods 1) 2) and 4) just forward request to method 3). So in any cased brightness is changed by i915 drm driver. I'm not sure (correct me if I'm wrong!) but I think that intel i915 drm driver accept changes (file intel_opregion.c) only if acpi function acpi_video_verify_backlight_support() returns true. Function acpi_video_verify_backlight_support() returns true iff: function acpi_video_backlight_support() returns true AND at least one of these functions returns false: acpi_osi_is_win8() acpi_video_use_native_backlight() backlight_device_registered(BACKLIGHT_RAW) On my notebook acpi_osi_is_win8() returns true (as is win8 compliant), backlight_device_registered(BACKLIGHT_RAW) returns true as I'm using intel i915 drm driver with raw backlight device and acpi_video_use_native_backlight() returns true/false depending on "video.use_native_backlight" kernel param. Default is true. So if I want to have working acpi video driver with display brightness support I need to boot kernel with param: "video.use_native_backlight=0". I tested it with kernel 3.17-rc6 and this param really enabled display brightness support via acpi video driver -- which is good. Driver dell-laptop creating backligh device for brightness control only if acpi_video_backlight_support() returns false. There is complicated condition for it and when kernel is booted with "video.use_native_backlight=0" that function returns true. So conclusion is: With current code in kernel 3.17-rc6 it is not possible to control brightness of display with native driver dell-laptop on Dell Latitude E6440 (and probably on others too)!!! And Because laptop is win8 compliant and you create decision to use native driver (instead acpi one) it is not possible to control display brightness without tweeks in kernel cmdline. As I wrote I would rather to use native dell-laptop driver for controlling brightness, but it is not possible. So how to solve this problem? Quick solution would be to set use_native_backlight false for some Dell laptops which means, that acpi video will be used and in this case intel i915 driver will *not* drop backlight change request. Another solution could be to disable check in dell_laptop driver and add use_native_backlight=0 to hooks. But this create two backlight interfaces (which is not good), but only way (for now) how to make dell_laptop working again. Better and maybe only one proper solution would be to teach intel drm i915 driver to not drop backlight change request for Dell laptops (or all??). (This allows to work both acpi video and dell_laptop drivers without any change and with *any* value in param use_native_backlight). I think that problematic code is in function asle_set_backlight() in file intel_opregion.c (but I'm not sure). My idea is that "drop" event function it is caused by this commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not sure). At least something must be done as I think that I'm not only one who has Dell laptop and brightness configuration is really important... Thanks. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
