[PATCH 00/14] Various backlight fixes for Fedora-3.15 kernel

[Hans de Goede]

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

[PATCH 01/14] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540

[Hans de Goede]

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(a)redhat.com&gt;
---
 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,
 		},
 	};
 
-- 
2.0.0

[PATCH 02/14] samsung-laptop: Add broken-acpi-video quirk for NC210/NC110

[Hans de Goede]

Reported (and tested) here:
https://bugzilla.redhat.com/show_bug.cgi?id=861573

Signed-off-by: Hans de Goede <hdegoede(a)redhat.com&gt;
---
 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);
-- 
2.0.0

[PATCH 03/14] ideapad-laptop: Blacklist rfkill control on the Lenovo Yoga 2 11

[Hans de Goede]

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(a)gmail.com&gt;
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com&gt;
---
 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);
-- 
2.0.0

[PATCH 04/14] asus-wmi: Add a no backlight quirk

[Hans de Goede]

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(a)redhat.com&gt;
---
 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
-- 
2.0.0

[PATCH 05/14] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS Motherboard

[Hans de Goede]

https://bugzilla.redhat.com/show_bug.cgi?id=1097436

Signed-off-by: Hans de Goede <hdegoede(a)redhat.com&gt;
---
 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,
+	},
 	{},
 };
 
-- 
2.0.0

[PATCH 06/14] acpi-video: Don't register acpi_video_resume notifier without backlight devices

[Hans de Goede]

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(a)redhat.com&gt;

--

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;
 }
 
-- 
2.0.0

[PATCH 07/14] acpi-video: Add an acpi_video_unregister_backlight function

[Hans de Goede]

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(a)redhat.com&gt;
---
 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)
 {
-- 
2.0.0

[PATCH 08/14] acer-wmi: Switch to acpi_video_unregister_backlight

[Hans de Goede]

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(a)redhat.com&gt;
---
 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)) {
-- 
2.0.0

[PATCH 09/14] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table

[Hans de Goede]

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(a)redhat.com&gt;
---
 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"),
+		},
+	},
 	{}
 };
 
-- 
2.0.0

[PATCH 10/14] nouveau: Don't check acpi_video_backlight_support() before registering backlight

[Hans de Goede]

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(a)redhat.com&gt;
---
 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)
-- 
2.0.0

[PATCH 11/14] backlight: Add backlight device (un)registration notification

[Hans de Goede]

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(a)redhat.com&gt;
---
 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)
 
-- 
2.0.0

[PATCH 12/14] acpi-video: Unregister the backlight device if a raw one shows up later

[Hans de Goede]

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(a)redhat.com&gt;
---
 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);
-- 
2.0.0

[PATCH 13/14] acpi-video: Add use native backlight quirk for the ThinkPad W530

[Hans de Goede]

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(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com&gt;
---
 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"),
-- 
2.0.0

[PATCH 14/14] acpi-video: Add use_native_backlight quirk for HP ProBook 4540s

[Hans de Goede]

As reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1025690
This is yet another model which needs this quirk.

Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com&gt;
---
 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"),
-- 
2.0.0

[Josh Boyer]

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

[Hans de Goede]

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

[Josh Boyer]

On Mon, Jun 2, 2014 at 1:58 PM, Hans de Goede <hdegoede(a)redhat.com&gt; 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

[Hans de Goede]

Hi,

On 06/03/2014 01:05 PM, Josh Boyer wrote:
>  On Mon, Jun 2, 2014 at 1:58 PM, Hans de Goede
> <hdegoede(a)redhat.com&gt; 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

[Josh Boyer]

On Tue, Jun 3, 2014 at 7:09 AM, Hans de Goede <hdegoede(a)redhat.com&gt; 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