Hi All,
I've a bunch of backlight handling fixes which for various reasons did not make it upstream for 3.15, which I would like to carry in the Fedora kernel package for now.
[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on -Not a backlight fix, but a simple input fix, fixing some keys not working on the latest thinkpads. Reviewed and acked upstream, waiting on the upstream drivers/platform/x86 maintainer.
[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for -https://bugzilla.redhat.com/show_bug.cgi?id=861573 -Not send upstream yet, waiting for the reporter to get back to me that it actually fixes things, already in the Fedora 3.14 kernels
[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo -Created and tested myself on a laptop of a friend -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 04/14] asus-wmi: Add a no backlight quirk [PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS -https://bugzilla.redhat.com/show_bug.cgi?id=1097436 -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier [PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight [PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight [PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table -https://bugzilla.kernel.org/show_bug.cgi?id=35622 -https://bugzilla.redhat.com/show_bug.cgi?id=1012674 -Queued upstream for addition to 3.16, likely fixes a bunch of other Acer models too
[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() [PATCH 11/14] backlight: Add backlight device (un)registration [PATCH 12/14] acpi-video: Unregister the backlight device if a raw device shows up [PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530 -https://bugzilla.redhat.com/show_bug.cgi?id=1093171 -Slightly adventurous, but only comes into play when using video.use_native_backlight=1 on the commandline, or for models which do so by a dmi quirk -Likely this set + video.use_native_backlight=1 will be needed on a whole bunch of recent laptops with nvidia or ati gfx. Already got confirmation on the upstream list that this is also needed for some ati equipped laptops too. -Queued upstream for addition to 3.16
[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s -https://bugzilla.redhat.com/show_bug.cgi?id=1025690 -Want to add to Fedora kernels and ask the user to test before sending upstream -Nothing special really, just another laptop needing video.use_native_backlight=1
Please let me know if there are any objections against me adding this set the Fedora 3.15 kernel pkg. If you don't object an ack would be nice too :)
If no objections are received I'llbe adding this set to the Fedora kernels in a day or two.
Regards,
Hans
The T440s user guide says that when Fn-lock is not active, the *40s' F9 - F12 keys should be mapped to: control-panel, search, show-all-windows and Computer.
These keys generate the sofar unused 28 - 31 hotkey scancodes.
For the first 2 this nicely matches the icons on the keys, for the latter 2 the icons are somewhat creative, which is why I ended up looking them up in the user manual.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/thinkpad_acpi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 15e61c1..d82f196 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -3171,8 +3171,10 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_MICMUTE, /* 0x1a: Mic mute (since ?400 or so) */
/* (assignments unknown, please report if found) */ - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, + + /* Extra keys in use since the X240 / T440 / T540 */ + KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_COMPUTER, }, };
Reported (and tested) here: https://bugzilla.redhat.com/show_bug.cgi?id=861573
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/samsung-laptop.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/samsung-laptop.c b/drivers/platform/x86/samsung-laptop.c index d1f03005..98f61f6 100644 --- a/drivers/platform/x86/samsung-laptop.c +++ b/drivers/platform/x86/samsung-laptop.c @@ -1534,6 +1534,16 @@ static struct dmi_system_id __initdata samsung_dmi_table[] = { }, .driver_data = &samsung_broken_acpi_video, }, + { + .callback = samsung_dmi_matched, + .ident = "NC210", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), + DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"), + DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"), + }, + .driver_data = &samsung_broken_acpi_video, + }, { }, }; MODULE_DEVICE_TABLE(dmi, samsung_dmi_table);
The Lenovo Yoga 2 11 always reports everything as blocked, causing userspace to not even try to use the wlan / bluetooth even though they work fine.
Note this patch also removes the "else priv->rfk[i] = NULL;" bit of the rfkill initialization, it is not necessary as the priv struct is allocated with kzalloc.
Reported-and-tested-by: Vincent Gerris vgerris@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/ideapad-laptop.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c index 6dd060a..219eb28 100644 --- a/drivers/platform/x86/ideapad-laptop.c +++ b/drivers/platform/x86/ideapad-laptop.c @@ -36,6 +36,7 @@ #include <linux/debugfs.h> #include <linux/seq_file.h> #include <linux/i8042.h> +#include <linux/dmi.h>
#define IDEAPAD_RFKILL_DEV_NUM (3)
@@ -819,6 +820,19 @@ static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data) } }
+/* Blacklist for devices where the ideapad rfkill interface does not work */ +static struct dmi_system_id rfkill_blacklist[] = { + /* The Lenovo Yoga 2 11 always reports everything as blocked */ + { + .ident = "Lenovo Yoga 2 11", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Yoga 2 11"), + }, + }, + {} +}; + static int ideapad_acpi_add(struct platform_device *pdev) { int ret, i; @@ -854,11 +868,10 @@ static int ideapad_acpi_add(struct platform_device *pdev) if (ret) goto input_failed;
- for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++) { - if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg)) - ideapad_register_rfkill(priv, i); - else - priv->rfk[i] = NULL; + if (!dmi_check_system(rfkill_blacklist)) { + for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++) + if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg)) + ideapad_register_rfkill(priv, i); } ideapad_sync_rfk_state(priv); ideapad_sync_touchpad_state(priv);
Some Asus motherboards for desktop PC-s export an acpi-video and an asus-wmi interface advertising backlight support. Add a quirk to allow to blacklist these so that desktop environments such as gnome don't start showing nonsense brightness controls.
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/asus-wmi.c | 8 ++++++-- drivers/platform/x86/asus-wmi.h | 1 + 2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index c5e082f..6f73dc5 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -1272,6 +1272,9 @@ static int asus_wmi_backlight_init(struct asus_wmi *asus) int max; int power;
+ if (asus->driver->quirks->no_backlight) + return -ENODEV; + max = read_brightness_max(asus);
if (max == -ENODEV) @@ -1370,7 +1373,7 @@ static void asus_wmi_notify(u32 value, void *context) code = ASUS_WMI_BRN_DOWN;
if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) { - if (!acpi_video_backlight_support()) { + if (asus->backlight_device) { asus_wmi_backlight_notify(asus, orig_code); goto exit; } @@ -1773,7 +1776,8 @@ static int asus_wmi_add(struct platform_device *pdev) if (err) goto fail_rfkill;
- if (asus->driver->quirks->wmi_backlight_power) + if (asus->driver->quirks->wmi_backlight_power || + asus->driver->quirks->no_backlight) acpi_video_dmi_promote_vendor(); if (!acpi_video_backlight_support()) { pr_info("Disabling ACPI video driver\n"); diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h index 4da4c8b..cc47efe 100644 --- a/drivers/platform/x86/asus-wmi.h +++ b/drivers/platform/x86/asus-wmi.h @@ -42,6 +42,7 @@ struct quirk_entry { bool scalar_panel_brightness; bool store_backlight_power; bool wmi_backlight_power; + bool no_backlight; int wapf; /* * For machines with AMD graphic chips, it will send out WMI event
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/eeepc-wmi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index 6112933..a7286bb 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -114,6 +114,10 @@ static struct quirk_entry quirk_asus_x101ch = { .wmi_backlight_power = true, };
+static struct quirk_entry quirk_asus_no_backlight = { + .no_backlight = true, +}; + static struct quirk_entry *quirks;
static void et2012_quirks(void) @@ -182,6 +186,15 @@ static struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_x101ch, }, + { + .callback = dmi_matched, + .ident = "ASUSTeK Computer INC. H87I-PLUS", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_BOARD_NAME, "H87I-PLUS"), + }, + .driver_data = &quirk_asus_no_backlight, + }, {}, };
If we're not going to be registering any backlight devices then acpi_video_resume is always nop, so don't register it in that case.
Signed-off-by: Hans de Goede hdegoede@redhat.com
--
Note to reviewers the changes to acpi_video_dev_register_backlight() only remove the "if (!acpi_video_verify_backlight_support()) {" which surrounded the entire body of the function, as that is checked earlier now. --- drivers/acpi/video.c | 139 +++++++++++++++++++++++++++------------------------ 1 file changed, 74 insertions(+), 65 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 286c376..d20ffcb 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -150,6 +150,7 @@ struct acpi_video_enumerated_device {
struct acpi_video_bus { struct acpi_device *device; + bool backlight_registered; u8 dos_setting; struct acpi_video_enumerated_device *attached_array; u8 attached_count; @@ -1690,88 +1691,89 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void *context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device) { - if (acpi_video_verify_backlight_support()) { - struct backlight_properties props; - struct pci_dev *pdev; - acpi_handle acpi_parent; - struct device *parent = NULL; - int result; - static int count; - char *name; - - result = acpi_video_init_brightness(device); - if (result) - return; - name = kasprintf(GFP_KERNEL, "acpi_video%d", count); - if (!name) - return; - count++; + struct backlight_properties props; + struct pci_dev *pdev; + acpi_handle acpi_parent; + struct device *parent = NULL; + int result; + static int count; + char *name;
- acpi_get_parent(device->dev->handle, &acpi_parent); + result = acpi_video_init_brightness(device); + if (result) + return; + name = kasprintf(GFP_KERNEL, "acpi_video%d", count); + if (!name) + return; + count++;
- pdev = acpi_get_pci_dev(acpi_parent); - if (pdev) { - parent = &pdev->dev; - pci_dev_put(pdev); - } + acpi_get_parent(device->dev->handle, &acpi_parent);
- memset(&props, 0, sizeof(struct backlight_properties)); - props.type = BACKLIGHT_FIRMWARE; - props.max_brightness = device->brightness->count - 3; - device->backlight = backlight_device_register(name, - parent, - device, - &acpi_backlight_ops, - &props); - kfree(name); - if (IS_ERR(device->backlight)) - return; + pdev = acpi_get_pci_dev(acpi_parent); + if (pdev) { + parent = &pdev->dev; + pci_dev_put(pdev); + }
- /* - * Save current brightness level in case we have to restore it - * before acpi_video_device_lcd_set_level() is called next time. - */ - device->backlight->props.brightness = - acpi_video_get_brightness(device->backlight); + memset(&props, 0, sizeof(struct backlight_properties)); + props.type = BACKLIGHT_FIRMWARE; + props.max_brightness = device->brightness->count - 3; + device->backlight = backlight_device_register(name, + parent, + device, + &acpi_backlight_ops, + &props); + kfree(name); + if (IS_ERR(device->backlight)) + return;
- device->cooling_dev = thermal_cooling_device_register("LCD", - device->dev, &video_cooling_ops); - if (IS_ERR(device->cooling_dev)) { - /* - * Set cooling_dev to NULL so we don't crash trying to - * free it. - * Also, why the hell we are returning early and - * not attempt to register video output if cooling - * device registration failed? - * -- dtor - */ - device->cooling_dev = NULL; - return; - } + /* + * Save current brightness level in case we have to restore it + * before acpi_video_device_lcd_set_level() is called next time. + */ + device->backlight->props.brightness = + acpi_video_get_brightness(device->backlight);
- dev_info(&device->dev->dev, "registered as cooling_device%d\n", - device->cooling_dev->id); - result = sysfs_create_link(&device->dev->dev.kobj, - &device->cooling_dev->device.kobj, - "thermal_cooling"); - if (result) - printk(KERN_ERR PREFIX "Create sysfs link\n"); - result = sysfs_create_link(&device->cooling_dev->device.kobj, - &device->dev->dev.kobj, "device"); - if (result) - printk(KERN_ERR PREFIX "Create sysfs link\n"); + device->cooling_dev = thermal_cooling_device_register("LCD", + device->dev, &video_cooling_ops); + if (IS_ERR(device->cooling_dev)) { + /* + * Set cooling_dev to NULL so we don't crash trying to free it. + * Also, why the hell we are returning early and not attempt to + * register video output if cooling device registration failed? + * -- dtor + */ + device->cooling_dev = NULL; + return; } + + dev_info(&device->dev->dev, "registered as cooling_device%d\n", + device->cooling_dev->id); + result = sysfs_create_link(&device->dev->dev.kobj, + &device->cooling_dev->device.kobj, + "thermal_cooling"); + if (result) + printk(KERN_ERR PREFIX "Create sysfs link\n"); + result = sysfs_create_link(&device->cooling_dev->device.kobj, + &device->dev->dev.kobj, "device"); + if (result) + printk(KERN_ERR PREFIX "Create sysfs link\n"); }
static int acpi_video_bus_register_backlight(struct acpi_video_bus *video) { struct acpi_video_device *dev;
+ if (!acpi_video_verify_backlight_support()) + return 0; + mutex_lock(&video->device_list_lock); list_for_each_entry(dev, &video->video_device_list, entry) acpi_video_dev_register_backlight(dev); mutex_unlock(&video->device_list_lock);
+ video->backlight_registered = true; + video->pm_nb.notifier_call = acpi_video_resume; video->pm_nb.priority = 0; return register_pm_notifier(&video->pm_nb); @@ -1799,13 +1801,20 @@ static void acpi_video_dev_unregister_backlight(struct acpi_video_device *device static int acpi_video_bus_unregister_backlight(struct acpi_video_bus *video) { struct acpi_video_device *dev; - int error = unregister_pm_notifier(&video->pm_nb); + int error; + + if (!video->backlight_registered) + return 0; + + error = unregister_pm_notifier(&video->pm_nb);
mutex_lock(&video->device_list_lock); list_for_each_entry(dev, &video->video_device_list, entry) acpi_video_dev_unregister_backlight(dev); mutex_unlock(&video->device_list_lock);
+ video->backlight_registered = false; + return error; }
Add an acpi_video_unregister_backlight function, which only unregisters the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor driver need this as they don't want the acpi_video# backlight device, but do need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor(); acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register() gets called. As acpi_video_register() will get called on acpi-video load time on non intel gfx machines, while it gets called on i915 load time on intel gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx: 1) acpi-video module gets loaded (as it is a dependency of acpi_vendor and i915) 2) acpi-video does NOT call acpi_video_register() 3) acpi_vendor loads (lets assume it loads before i915), calls acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR 4) calls acpi_video_unregister -> not registered, nop 5) i915 loads, calls acpi_video_register 6) acpi_video_register registers the acpi_notifier for the hotkeys, does NOT register a backlight device because of ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx 1) acpi-video module gets loaded (as it is a dependency acpi_vendor) 2) acpi-video calls acpi_video_register() 3) acpi_video_register registers the acpi_notifier for the hotkeys, and a backlight device 4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor() 5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls, but with different results, in one cases acpi-video does handle hotkeys, in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads before the vendor_acpi module, so we also have different behavior depending on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really always want the behavior of a), hence this patch adds a new acpi_video_unregister_backlight() which gives the behavior of a) independent of module loading order.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/acpi/video.c | 14 ++++++++++++++ include/acpi/video.h | 2 ++ 2 files changed, 16 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index d20ffcb..c2a5797 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -2102,6 +2102,20 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister);
+void acpi_video_unregister_backlight(void) +{ + struct acpi_video_bus *video; + + if (!register_count) + return; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_unregister_backlight); + /* * This is kind of nasty. Hardware using Intel chipsets may require * the video opregion code to be run first in order to initialise diff --git a/include/acpi/video.h b/include/acpi/video.h index 61109f2..ea4c7bb 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -19,11 +19,13 @@ struct acpi_device; #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_unregister_backlight(void); extern int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid); #else static inline int acpi_video_register(void) { return 0; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_unregister_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) {
Switch from acpi_video_unregister(), to acpi_video_unregister_backlight(), so that the hotkeys handler registered by acpi-video stays in place.
Since there are no mappings for the atkbd raw codes for the brightness keys used by newer Acer models in /lib/udev/hwdb.d/60-keyboard.hwdb, and since we map the wmi events with a code of KE_IGNORE, we rely on acpi-video to do the hotkey handling for us.
For laptops such as the Acer Aspire 5750 which uses intel gfx this works despite us calling acpi_video_unregister() because the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi and i915) 2) acpi-video does NOT call acpi_video_register() 3) acer-wmi loads (assume it loads before i915), calls acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR 4) calls acpi_video_unregister -> not registered, nop 5) i915 loads, calls acpi_video_register 6) acpi_video_register registers the acpi_notifier for the hotkeys, does NOT register a backlight device because of ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
But on the Acer Aspire 5750G, which uses nvidia graphics the following happens: 1) acpi-video module gets loaded (as it is a dependency of acer-wmi) 2) acpi-video calls acpi_video_register() 3) acpi_video_register registers the acpi_notifier for the hotkeys, and a backlight device 4) acer-wmi loads, calls acpi_video_dmi_promote_vendor() 5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for the hotkeys AND the backlight device
And we end up without any handler for the brightness hotkeys. This patch fixes this by switching over to acpi_video_unregister_backlight() which keeps the hotkey handler in place.
https://bugzilla.kernel.org/show_bug.cgi?id=35622
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/acer-wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index c91f69b3..3a74699 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -2228,7 +2228,7 @@ static int __init acer_wmi_init(void) pr_info("Brightness must be controlled by acpi video driver\n"); } else { pr_info("Disabling ACPI video driver\n"); - acpi_video_unregister(); + acpi_video_unregister_backlight(); }
if (wmi_has_guid(WMID_GUID3)) {
The Aspire 5741 has broken acpi-video backlight control, so add it to the quirk table.
https://bugzilla.redhat.com/show_bug.cgi?id=1012674
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/platform/x86/acer-wmi.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index 3a74699..bbf78b2 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -570,6 +570,14 @@ static const struct dmi_system_id video_vendor_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), }, }, + { + .callback = video_set_backlight_video_vendor, + .ident = "Acer Aspire 5741", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), + }, + }, {} };
acpi_video_backlight_support() is supposed to be called by other (vendor specific) firmware backlight controls, not by native / raw backlight controls like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so if acpi_video backlight support is present it will use that even if nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline (or enabled through a dmi based quirk). As the name indicates the goal here is to make only the raw interface available to userspace so that it will use that (it only does this when it sees a win8 compliant bios).
This is done by: 1) Not registering any acpi_video# backlight devices; and 2) Making acpi_video_backlight_support() return true so that other firmware drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support() returns true, it does not register itself, resulting in no backlight control at all.
This is esp. going to be a problem with 3.16 which will default to video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios will get no backlight control at all.
This also likely explains why the previous attempt to make video.use_native_backlight=1 the default was not a success, as without this patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 630f6e8..2c1e4aa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -31,7 +31,6 @@ */
#include <linux/backlight.h> -#include <linux/acpi.h>
#include "nouveau_drm.h" #include "nouveau_reg.h" @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev) struct nouveau_device *device = nv_device(drm->device); struct drm_connector *connector;
-#ifdef CONFIG_ACPI - if (acpi_video_backlight_support()) { - NV_INFO(drm, "ACPI backlight interface available, " - "not registering our own\n"); - return 0; - } -#endif - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS && connector->connector_type != DRM_MODE_CONNECTOR_eDP)
Some firmware drivers, ie acpi-video want to get themselves out of the way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain that the backlight_device_registered(BACKLIGHT_RAW) it does for this is the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++ include/linux/backlight.h | 7 +++++++ 2 files changed, 47 insertions(+)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index bd2172c..4280890 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -23,6 +23,7 @@
static struct list_head backlight_dev_list; static struct mutex backlight_dev_list_mutex; +static struct blocking_notifier_head backlight_notifier;
static const char *const backlight_types[] = { [BACKLIGHT_RAW] = "raw", @@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const char *name, list_add(&new_bd->entry, &backlight_dev_list); mutex_unlock(&backlight_dev_list_mutex);
+ blocking_notifier_call_chain(&backlight_notifier, + BACKLIGHT_REGISTERED, new_bd); + return new_bd; } EXPORT_SYMBOL(backlight_device_register); @@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device *bd) pmac_backlight = NULL; mutex_unlock(&pmac_backlight_mutex); #endif + + blocking_notifier_call_chain(&backlight_notifier, + BACKLIGHT_UNREGISTERED, bd); + mutex_lock(&bd->ops_lock); bd->ops = NULL; mutex_unlock(&bd->ops_lock); @@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, void *res, }
/** + * backlight_register_notifier - get notified of backlight (un)registration + * @nb: notifier block with the notifier to call on backlight (un)registration + * + * @return 0 on success, otherwise a negative error code + * + * Register a notifier to get notified when backlight devices get registered + * or unregistered. + */ +int backlight_register_notifier(struct notifier_block *nb) +{ + return blocking_notifier_chain_register(&backlight_notifier, nb); +} +EXPORT_SYMBOL(backlight_register_notifier); + +/** + * backlight_unregister_notifier - unregister a backlight notifier + * @nb: notifier block to unregister + * + * @return 0 on success, otherwise a negative error code + * + * Register a notifier to get notified when backlight devices get registered + * or unregistered. + */ +int backlight_unregister_notifier(struct notifier_block *nb) +{ + return blocking_notifier_chain_unregister(&backlight_notifier, nb); +} +EXPORT_SYMBOL(backlight_unregister_notifier); + +/** * devm_backlight_device_register - resource managed backlight_device_register() * @dev: the device to register * @name: the name of the device @@ -544,6 +582,8 @@ static int __init backlight_class_init(void) backlight_class->pm = &backlight_class_dev_pm_ops; INIT_LIST_HEAD(&backlight_dev_list); mutex_init(&backlight_dev_list_mutex); + BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier); + return 0; }
diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 7264742..adb14a8 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -40,6 +40,11 @@ enum backlight_type { BACKLIGHT_TYPE_MAX, };
+enum backlight_notification { + BACKLIGHT_REGISTERED, + BACKLIGHT_UNREGISTERED, +}; + struct backlight_device; struct fb_info;
@@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device *dev, extern void backlight_force_update(struct backlight_device *bd, enum backlight_update_reason reason); extern bool backlight_device_registered(enum backlight_type type); +extern int backlight_register_notifier(struct notifier_block *nb); +extern int backlight_unregister_notifier(struct notifier_block *nb);
#define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
When video.use_native_backlight=1 and non intel gfx are in use, the raw backlight device of the gfx driver will show up after acpi-video has done its acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by adding a backlight notifier and when a raw backlight is registered or unregistered re-doing the acpi_video_verify_backlight_support() check.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/acpi/video.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index c2a5797..64a3d6c 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -151,6 +151,7 @@ struct acpi_video_enumerated_device { struct acpi_video_bus { struct acpi_device *device; bool backlight_registered; + bool backlight_notifier_registered; u8 dos_setting; struct acpi_video_enumerated_device *attached_array; u8 attached_count; @@ -162,6 +163,7 @@ struct acpi_video_bus { struct input_dev *input; char phys[32]; /* for input device */ struct notifier_block pm_nb; + struct notifier_block backlight_nb; };
struct acpi_video_device_flags { @@ -1764,6 +1766,9 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video) { struct acpi_video_device *dev;
+ if (video->backlight_registered) + return 0; + if (!acpi_video_verify_backlight_support()) return 0;
@@ -1908,6 +1913,56 @@ static void acpi_video_bus_remove_notify_handler(struct acpi_video_bus *video) video->input = NULL; }
+static int acpi_video_backlight_notify(struct notifier_block *nb, + unsigned long val, void *bd) +{ + struct backlight_device *backlight = bd; + struct acpi_video_bus *video; + + /* acpi_video_verify_backlight_support only cares about raw devices */ + if (backlight->props.type != BACKLIGHT_RAW) + return NOTIFY_DONE; + + video = container_of(nb, struct acpi_video_bus, backlight_nb); + + switch (val) { + case BACKLIGHT_REGISTERED: + if (!acpi_video_verify_backlight_support()) + acpi_video_bus_unregister_backlight(video); + break; + case BACKLIGHT_UNREGISTERED: + acpi_video_bus_register_backlight(video); + break; + } + + return NOTIFY_OK; +} + +static int acpi_video_bus_add_backlight_notify_handler( + struct acpi_video_bus *video) +{ + int error; + + video->backlight_nb.notifier_call = acpi_video_backlight_notify; + video->backlight_nb.priority = 0; + error = backlight_register_notifier(&video->backlight_nb); + if (error == 0) + video->backlight_notifier_registered = true; + + return error; +} + +static int acpi_video_bus_remove_backlight_notify_handler( + struct acpi_video_bus *video) +{ + if (!video->backlight_notifier_registered) + return 0; + + video->backlight_notifier_registered = false; + + return backlight_unregister_notifier(&video->backlight_nb); +} + static int acpi_video_bus_put_devices(struct acpi_video_bus *video) { struct acpi_video_device *dev, *next; @@ -1989,6 +2044,7 @@ static int acpi_video_bus_add(struct acpi_device *device)
acpi_video_bus_register_backlight(video); acpi_video_bus_add_notify_handler(video); + acpi_video_bus_add_backlight_notify_handler(video);
return 0;
@@ -2012,6 +2068,7 @@ static int acpi_video_bus_remove(struct acpi_device *device)
video = acpi_driver_data(device);
+ acpi_video_bus_remove_backlight_notify_handler(video); acpi_video_bus_remove_notify_handler(video); acpi_video_bus_unregister_backlight(video); acpi_video_bus_put_devices(video);
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video backlight control. Note in order for this to actually fix things on the ThinkPad W530 the commit titled: "nouveau: Don't check acpi_video_backlight_support() before registering backlight" is also needed.
https://bugzilla.redhat.com/show_bug.cgi?id=1093171
Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/acpi/video.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 64a3d6c..7165cbc 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -468,6 +468,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { }, { .callback = video_set_use_native_backlight, + .ident = "ThinkPad W530", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"), + }, + }, + { + .callback = video_set_use_native_backlight, .ident = "ThinkPad X230", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
As reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1025690 This is yet another model which needs this quirk.
Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/acpi/video.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 7165cbc..fa361bf 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -572,6 +572,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { }, { .callback = video_set_use_native_backlight, + .ident = "HP ProBook 4540s", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_VERSION, "HP ProBook 4540s"), + }, + }, + { + .callback = video_set_use_native_backlight, .ident = "HP ProBook 2013 models", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
On Mon, Jun 02, 2014 at 05:40:57PM +0200, Hans de Goede wrote:
Hi All,
I've a bunch of backlight handling fixes which for various reasons did not make it upstream for 3.15, which I would like to carry in the Fedora kernel package for now.
[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on -Not a backlight fix, but a simple input fix, fixing some keys not working on the latest thinkpads. Reviewed and acked upstream, waiting on the upstream drivers/platform/x86 maintainer.
[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for -https://bugzilla.redhat.com/show_bug.cgi?id=861573 -Not send upstream yet, waiting for the reporter to get back to me that it actually fixes things, already in the Fedora 3.14 kernels
[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo -Created and tested myself on a laptop of a friend -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 04/14] asus-wmi: Add a no backlight quirk [PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS -https://bugzilla.redhat.com/show_bug.cgi?id=1097436 -Waiting on the upstream drivers/platform/x86 maintainer
Matthew?
[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier [PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight [PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight [PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table -https://bugzilla.kernel.org/show_bug.cgi?id=35622 -https://bugzilla.redhat.com/show_bug.cgi?id=1012674 -Queued upstream for addition to 3.16, likely fixes a bunch of other Acer models too
[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() [PATCH 11/14] backlight: Add backlight device (un)registration [PATCH 12/14] acpi-video: Unregister the backlight device if a raw device shows up [PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530 -https://bugzilla.redhat.com/show_bug.cgi?id=1093171 -Slightly adventurous, but only comes into play when using video.use_native_backlight=1 on the commandline, or for models which do so by a dmi quirk -Likely this set + video.use_native_backlight=1 will be needed on a whole bunch of recent laptops with nvidia or ati gfx. Already got confirmation on the upstream list that this is also needed for some ati equipped laptops too. -Queued upstream for addition to 3.16
[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s -https://bugzilla.redhat.com/show_bug.cgi?id=1025690 -Want to add to Fedora kernels and ask the user to test before sending upstream -Nothing special really, just another laptop needing video.use_native_backlight=1
Please let me know if there are any objections against me adding this set the Fedora 3.15 kernel pkg. If you don't object an ack would be nice too :)
OK, I have a question on the backlight ones.
3.16 has some backlight rework in the ACPI layer to deal with the Windows2012 issue, which I believe fixes several models of laptops. You got a number of quirk patches into 3.15 already that won't be in 3.16 because of that rework (if I understood the situation correctly).
So are these backlight patches additional quirks that were simply developed too late to get into 3.15, or are they backports of stuff in queued for 3.16? If the latter, wouldn't they depend on that aforementioned rework? If not, are you going to attempt to get them into 3.15 stable?
josh
Hi,
On 06/02/2014 06:53 PM, Josh Boyer wrote:
On Mon, Jun 02, 2014 at 05:40:57PM +0200, Hans de Goede wrote:
Hi All,
I've a bunch of backlight handling fixes which for various reasons did not make it upstream for 3.15, which I would like to carry in the Fedora kernel package for now.
[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on -Not a backlight fix, but a simple input fix, fixing some keys not working on the latest thinkpads. Reviewed and acked upstream, waiting on the upstream drivers/platform/x86 maintainer.
[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for -https://bugzilla.redhat.com/show_bug.cgi?id=861573 -Not send upstream yet, waiting for the reporter to get back to me that it actually fixes things, already in the Fedora 3.14 kernels
[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo -Created and tested myself on a laptop of a friend -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 04/14] asus-wmi: Add a no backlight quirk [PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS -https://bugzilla.redhat.com/show_bug.cgi?id=1097436 -Waiting on the upstream drivers/platform/x86 maintainer
Matthew?
Yes, Matthew. I've already send him a ping on these (2 pings for the thinkpad keys binding one).
[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier [PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight [PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight [PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table -https://bugzilla.kernel.org/show_bug.cgi?id=35622 -https://bugzilla.redhat.com/show_bug.cgi?id=1012674 -Queued upstream for addition to 3.16, likely fixes a bunch of other Acer models too
[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() [PATCH 11/14] backlight: Add backlight device (un)registration [PATCH 12/14] acpi-video: Unregister the backlight device if a raw device shows up [PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530 -https://bugzilla.redhat.com/show_bug.cgi?id=1093171 -Slightly adventurous, but only comes into play when using video.use_native_backlight=1 on the commandline, or for models which do so by a dmi quirk -Likely this set + video.use_native_backlight=1 will be needed on a whole bunch of recent laptops with nvidia or ati gfx. Already got confirmation on the upstream list that this is also needed for some ati equipped laptops too. -Queued upstream for addition to 3.16
[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s -https://bugzilla.redhat.com/show_bug.cgi?id=1025690 -Want to add to Fedora kernels and ask the user to test before sending upstream -Nothing special really, just another laptop needing video.use_native_backlight=1
Please let me know if there are any objections against me adding this set the Fedora 3.15 kernel pkg. If you don't object an ack would be nice too :)
OK, I have a question on the backlight ones.
3.16 has some backlight rework in the ACPI layer to deal with the Windows2012 issue, which I believe fixes several models of laptops.
Correct, basically 3.16 is going to flip the video.use_native_backlight default from 0 to 1.
You got a number of quirk patches into 3.15 already that won't be in 3.16 because of that rework (if I understood the situation correctly).
No, I've discussed this with upstream and it is unsure of the flipping of that default will stick, or if it will cause too much regressions (it is almost inevitable that it will break some models, and we will need reverse quirks).
So it was decided to keep the quirk list and keep updating it for now, even though the quirks will become no-ops for 3.16. And then we will remove the quirk list in the future if the new default sticks.
So are these backlight patches additional quirks that were simply developed too late to get into 3.15, or are they backports of stuff in queued for 3.16?
Patches 6-9 are for an unrelated / orthogonal backlight problem seen on Acer laptops with nvidia graphics. This is mostly a load / initialization ordering problem, which does not show up with intel graphics because these are actually handled in a special way in acpi/video.c . As such they do introduce a new acpi_video_unregister_backlight function, which is also used in patches 10-13, since these deal with a very similar ordering problem when using use_native_backlight in combination with either ati or nouveau. To answer your quirks or backports question, these 4 are more quirk patches then a backport.
Patches 10-13 deal with and initialization ordering issues, fixing use_native_backlight sofar being a no-op when used with ati or nouveau. These 4 are more in the backport territory, but they are quirk-ish too, in the sence that the new code does not come into play unless a laptop model has the use_native_backlight quirk. In 3.16 as such they will become much more important since their use_native_backlight=1 will be the default.
Patch 14 adds one more use_native_backlight quirk.
If the latter, wouldn't they depend on that aforementioned rework?
There is no real rework, just the flipping of the default, although patches 10-13 are important for making the flipping of the default actually work on ati / nouveau using laptops.
If not, are you going to attempt to get them into 3.15 stable?
The patches which only add a use_native_backlight quirk all have are Cc: stable.
The two 4-patch patch-sets do not have a Cc: stable. I consider the chances of these two sets causing regressions small, but not 0, hence no Cc: stable. This is also why I'm suggesting adding them to 3.15 and not to 3.14, so that they can sit through the Fedora 3.15 stabilization phase.
The benefit of adding these 2 patch-sets now, is that they do fix real world problems reported by Fedora users, in the case of the Acer patch-set I already have confirmation from 2 different Fedora users, using 2 different models, that this helps them. In the case of the second set I've one Fedora user confirming it helps him + one person on the linux-acpi list.
Regards,
Hans
On Mon, Jun 2, 2014 at 1:58 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 06/02/2014 06:53 PM, Josh Boyer wrote:
On Mon, Jun 02, 2014 at 05:40:57PM +0200, Hans de Goede wrote:
Hi All,
I've a bunch of backlight handling fixes which for various reasons did not make it upstream for 3.15, which I would like to carry in the Fedora kernel package for now.
[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on -Not a backlight fix, but a simple input fix, fixing some keys not working on the latest thinkpads. Reviewed and acked upstream, waiting on the upstream drivers/platform/x86 maintainer.
[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for -https://bugzilla.redhat.com/show_bug.cgi?id=861573 -Not send upstream yet, waiting for the reporter to get back to me that it actually fixes things, already in the Fedora 3.14 kernels
[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo -Created and tested myself on a laptop of a friend -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 04/14] asus-wmi: Add a no backlight quirk [PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS -https://bugzilla.redhat.com/show_bug.cgi?id=1097436 -Waiting on the upstream drivers/platform/x86 maintainer
Matthew?
Yes, Matthew. I've already send him a ping on these (2 pings for the thinkpad keys binding one).
[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier [PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight [PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight [PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table -https://bugzilla.kernel.org/show_bug.cgi?id=35622 -https://bugzilla.redhat.com/show_bug.cgi?id=1012674 -Queued upstream for addition to 3.16, likely fixes a bunch of other Acer models too
[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() [PATCH 11/14] backlight: Add backlight device (un)registration [PATCH 12/14] acpi-video: Unregister the backlight device if a raw device shows up [PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530 -https://bugzilla.redhat.com/show_bug.cgi?id=1093171 -Slightly adventurous, but only comes into play when using video.use_native_backlight=1 on the commandline, or for models which do so by a dmi quirk -Likely this set + video.use_native_backlight=1 will be needed on a whole bunch of recent laptops with nvidia or ati gfx. Already got confirmation on the upstream list that this is also needed for some ati equipped laptops too. -Queued upstream for addition to 3.16
[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s -https://bugzilla.redhat.com/show_bug.cgi?id=1025690 -Want to add to Fedora kernels and ask the user to test before sending upstream -Nothing special really, just another laptop needing video.use_native_backlight=1
Please let me know if there are any objections against me adding this set the Fedora 3.15 kernel pkg. If you don't object an ack would be nice too :)
OK, I have a question on the backlight ones.
3.16 has some backlight rework in the ACPI layer to deal with the Windows2012 issue, which I believe fixes several models of laptops.
Correct, basically 3.16 is going to flip the video.use_native_backlight default from 0 to 1.
You got a number of quirk patches into 3.15 already that won't be in 3.16 because of that rework (if I understood the situation correctly).
No, I've discussed this with upstream and it is unsure of the flipping of that default will stick, or if it will cause too much regressions (it is almost inevitable that it will break some models, and we will need reverse quirks).
So it was decided to keep the quirk list and keep updating it for now, even though the quirks will become no-ops for 3.16. And then we will remove the quirk list in the future if the new default sticks.
So are these backlight patches additional quirks that were simply developed too late to get into 3.15, or are they backports of stuff in queued for 3.16?
Patches 6-9 are for an unrelated / orthogonal backlight problem seen on Acer laptops with nvidia graphics. This is mostly a load / initialization ordering problem, which does not show up with intel graphics because these are actually handled in a special way in acpi/video.c . As such they do introduce a new acpi_video_unregister_backlight function, which is also used in patches 10-13, since these deal with a very similar ordering problem when using use_native_backlight in combination with either ati or nouveau. To answer your quirks or backports question, these 4 are more quirk patches then a backport.
Patches 10-13 deal with and initialization ordering issues, fixing use_native_backlight sofar being a no-op when used with ati or nouveau. These 4 are more in the backport territory, but they are quirk-ish too, in the sence that the new code does not come into play unless a laptop model has the use_native_backlight quirk. In 3.16 as such they will become much more important since their use_native_backlight=1 will be the default.
Patch 14 adds one more use_native_backlight quirk.
If the latter, wouldn't they depend on that aforementioned rework?
There is no real rework, just the flipping of the default, although patches 10-13 are important for making the flipping of the default actually work on ati / nouveau using laptops.
If not, are you going to attempt to get them into 3.15 stable?
The patches which only add a use_native_backlight quirk all have are Cc: stable.
The two 4-patch patch-sets do not have a Cc: stable. I consider the chances of these two sets causing regressions small, but not 0, hence no Cc: stable. This is also why I'm suggesting adding them to 3.15 and not to 3.14, so that they can sit through the Fedora 3.15 stabilization phase.
The benefit of adding these 2 patch-sets now, is that they do fix real world problems reported by Fedora users, in the case of the Acer patch-set I already have confirmation from 2 different Fedora users, using 2 different models, that this helps them. In the case of the second set I've one Fedora user confirming it helps him + one person on the linux-acpi list.
OK. Thanks for the further background info. I don't see any reason to keep these out of rawhide. If they introduce regressions, they'll probably be in a similar state upstream.
I can add these later today, or you can add them if you'd like. If you do, please take a second and add the Bugzilla: and Upstream-status: fields we've been keeping at the tops of the patches.
josh
Hi,
On 06/03/2014 01:05 PM, Josh Boyer wrote:
On Mon, Jun 2, 2014 at 1:58 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 06/02/2014 06:53 PM, Josh Boyer wrote:
On Mon, Jun 02, 2014 at 05:40:57PM +0200, Hans de Goede wrote:
Hi All,
I've a bunch of backlight handling fixes which for various reasons did not make it upstream for 3.15, which I would like to carry in the Fedora kernel package for now.
[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on -Not a backlight fix, but a simple input fix, fixing some keys not working on the latest thinkpads. Reviewed and acked upstream, waiting on the upstream drivers/platform/x86 maintainer.
[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for -https://bugzilla.redhat.com/show_bug.cgi?id=861573 -Not send upstream yet, waiting for the reporter to get back to me that it actually fixes things, already in the Fedora 3.14 kernels
[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo -Created and tested myself on a laptop of a friend -Waiting on the upstream drivers/platform/x86 maintainer
[PATCH 04/14] asus-wmi: Add a no backlight quirk [PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS -https://bugzilla.redhat.com/show_bug.cgi?id=1097436 -Waiting on the upstream drivers/platform/x86 maintainer
Matthew?
Yes, Matthew. I've already send him a ping on these (2 pings for the thinkpad keys binding one).
[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier [PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight [PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight [PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table -https://bugzilla.kernel.org/show_bug.cgi?id=35622 -https://bugzilla.redhat.com/show_bug.cgi?id=1012674 -Queued upstream for addition to 3.16, likely fixes a bunch of other Acer models too
[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() [PATCH 11/14] backlight: Add backlight device (un)registration [PATCH 12/14] acpi-video: Unregister the backlight device if a raw device shows up [PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530 -https://bugzilla.redhat.com/show_bug.cgi?id=1093171 -Slightly adventurous, but only comes into play when using video.use_native_backlight=1 on the commandline, or for models which do so by a dmi quirk -Likely this set + video.use_native_backlight=1 will be needed on a whole bunch of recent laptops with nvidia or ati gfx. Already got confirmation on the upstream list that this is also needed for some ati equipped laptops too. -Queued upstream for addition to 3.16
[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s -https://bugzilla.redhat.com/show_bug.cgi?id=1025690 -Want to add to Fedora kernels and ask the user to test before sending upstream -Nothing special really, just another laptop needing video.use_native_backlight=1
Please let me know if there are any objections against me adding this set the Fedora 3.15 kernel pkg. If you don't object an ack would be nice too :)
OK, I have a question on the backlight ones.
3.16 has some backlight rework in the ACPI layer to deal with the Windows2012 issue, which I believe fixes several models of laptops.
Correct, basically 3.16 is going to flip the video.use_native_backlight default from 0 to 1.
You got a number of quirk patches into 3.15 already that won't be in 3.16 because of that rework (if I understood the situation correctly).
No, I've discussed this with upstream and it is unsure of the flipping of that default will stick, or if it will cause too much regressions (it is almost inevitable that it will break some models, and we will need reverse quirks).
So it was decided to keep the quirk list and keep updating it for now, even though the quirks will become no-ops for 3.16. And then we will remove the quirk list in the future if the new default sticks.
So are these backlight patches additional quirks that were simply developed too late to get into 3.15, or are they backports of stuff in queued for 3.16?
Patches 6-9 are for an unrelated / orthogonal backlight problem seen on Acer laptops with nvidia graphics. This is mostly a load / initialization ordering problem, which does not show up with intel graphics because these are actually handled in a special way in acpi/video.c . As such they do introduce a new acpi_video_unregister_backlight function, which is also used in patches 10-13, since these deal with a very similar ordering problem when using use_native_backlight in combination with either ati or nouveau. To answer your quirks or backports question, these 4 are more quirk patches then a backport.
Patches 10-13 deal with and initialization ordering issues, fixing use_native_backlight sofar being a no-op when used with ati or nouveau. These 4 are more in the backport territory, but they are quirk-ish too, in the sence that the new code does not come into play unless a laptop model has the use_native_backlight quirk. In 3.16 as such they will become much more important since their use_native_backlight=1 will be the default.
Patch 14 adds one more use_native_backlight quirk.
If the latter, wouldn't they depend on that aforementioned rework?
There is no real rework, just the flipping of the default, although patches 10-13 are important for making the flipping of the default actually work on ati / nouveau using laptops.
If not, are you going to attempt to get them into 3.15 stable?
The patches which only add a use_native_backlight quirk all have are Cc: stable.
The two 4-patch patch-sets do not have a Cc: stable. I consider the chances of these two sets causing regressions small, but not 0, hence no Cc: stable. This is also why I'm suggesting adding them to 3.15 and not to 3.14, so that they can sit through the Fedora 3.15 stabilization phase.
The benefit of adding these 2 patch-sets now, is that they do fix real world problems reported by Fedora users, in the case of the Acer patch-set I already have confirmation from 2 different Fedora users, using 2 different models, that this helps them. In the case of the second set I've one Fedora user confirming it helps him + one person on the linux-acpi list.
OK. Thanks for the further background info. I don't see any reason to keep these out of rawhide. If they introduce regressions, they'll probably be in a similar state upstream.
I'm a bit swamped at the moment, so if you could add them that would be great.
Thanks,
Hans
On Tue, Jun 3, 2014 at 7:09 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 06/03/2014 01:05 PM, Josh Boyer wrote:
OK. Thanks for the further background info. I don't see any reason to keep these out of rawhide. If they introduce regressions, they'll probably be in a similar state upstream.
I'm a bit swamped at the moment, so if you could add them that would be great.
OK. Will do later today.
josh
kernel@lists.fedoraproject.org
-
Hans de Goede -
Josh Boyer