Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
Hi, On Fri, Jul 26, 2013 at 8:24 AM, Jani Nikula jani.nik...@linux.intel.com wrote: On Sat, 20 Jul 2013, Felipe Contreras felipe.contre...@gmail.com wrote: I tried this patch series and it's as I expected, it's the same as acpi_backlight=vendor, and the intel backlight driver doesn't work correctly in this machine. If you are actually serious about the mantra of no user-space regressions, then for this machine at least, you need to use the ACPI backlight with Windows8 OSI disabled, until the intel backlight driver is fixed. My patch does that: http://article.gmane.org/gmane.linux.acpi.devel/60969 Hi Felipe, would you mind trying the following patch on top of -rc2, without your quirk patch? Up front, I'm not sure what all your failure modes are, I'm not claiming this fixes them, and frankly, it didn't do anything on a machine I tried... I just have this hunch it might help with the ACPI hotkeys on some BIOSes. Maybe you're the lucky one! :) I did try this patch and I still see the same issue: when I go to the lowest level (xbacklight -set 0), the backlight is completely off. It seems in -rc2 the intel backlight driver works better, and can be controlled from the keys just fine, but it's still not as good as the acpi one minus win8. I don't notice any difference with your patch. Cheers. -- Felipe Contreras ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote: On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote: On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! So this didn't work, as we had to revert [3/3], but I think we should try to make some progress with this nevertheless. A way forward I'm seeing now could be to (1) Split the ACPI video driver so that it is possible to register the backlight control separately from the event interface. (2) Add a command line option to i915 to make it use the native backlight control (without registering the ACPI one) if set. Make unset the default initially. (3) Fix i915 backlight control issues for all systems known to have them (that may take a while) and flip the defailt for that option to set when we think we're ready. (4) If there still are problem reports, flip the default back to unset and repeat (3). If this converges, everyone will be using the native backlight control by default and the original problem will go away automatically. Thoughts? Rafael Good idea. I have 3-4 laptops with this problem. I can test, but I don't have devices, on which found regressions (in backlight) in previous patch. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.10.3-300.fc19.x86_64 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On 07/31/2013 08:01 AM, Rafael J. Wysocki wrote: On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote: On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! So this didn't work, as we had to revert [3/3], but I think we should try to make some progress with this nevertheless. A way forward I'm seeing now could be to (1) Split the ACPI video driver so that it is possible to register the backlight control separately from the event interface. (2) Add a command line option to i915 to make it use the native backlight control (without registering the ACPI one) if set. Make unset the default initially. (3) Fix i915 backlight control issues for all systems known to have them (that may take a while) and flip the defailt for that option to set when we think we're ready. (4) If there still are problem reports, flip the default back to unset and repeat (3). If this converges, everyone will be using the native backlight control by default and the original problem will go away automatically. Thoughts? Sounds good to me. -Aaron ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote: On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! So this didn't work, as we had to revert [3/3], but I think we should try to make some progress with this nevertheless. A way forward I'm seeing now could be to (1) Split the ACPI video driver so that it is possible to register the backlight control separately from the event interface. (2) Add a command line option to i915 to make it use the native backlight control (without registering the ACPI one) if set. Make unset the default initially. (3) Fix i915 backlight control issues for all systems known to have them (that may take a while) and flip the defailt for that option to set when we think we're ready. (4) If there still are problem reports, flip the default back to unset and repeat (3). If this converges, everyone will be using the native backlight control by default and the original problem will go away automatically. Thoughts? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote: (3) Fix i915 backlight control issues for all systems known to have them (that may take a while) and flip the defailt for that option to set when we think we're ready. Unfortunately I don't have any systems that reproduce problems here, so I think Intel are going to have to take the lead on this one. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Mon, 29 Jul 2013, Felipe Contreras felipe.contre...@gmail.com wrote: I don't notice any difference with your patch. Ok, thanks for trying it out. BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
[distribution massively reduced]
On Sat, 20 Jul 2013, Felipe Contreras felipe.contre...@gmail.com wrote:
I tried this patch series and it's as I expected, it's the same as
acpi_backlight=vendor, and the intel backlight driver doesn't work
correctly in this machine. If you are actually serious about the
mantra of no user-space regressions, then for this machine at least,
you need to use the ACPI backlight with Windows8 OSI disabled, until
the intel backlight driver is fixed. My patch does that:
http://article.gmane.org/gmane.linux.acpi.devel/60969
Hi Felipe, would you mind trying the following patch on top of -rc2,
without your quirk patch? Up front, I'm not sure what all your failure
modes are, I'm not claiming this fixes them, and frankly, it didn't do
anything on a machine I tried... I just have this hunch it might help
with the ACPI hotkeys on some BIOSes. Maybe you're the lucky one! :)
BR,
Jani.
From eb1493a7551dafb4bac3d65e4ed3ecd2e46f7f67 Mon Sep 17 00:00:00 2001
From: Jani Nikula jani.nik...@intel.com
Date: Fri, 7 Dec 2012 15:32:45 +0200
Subject: [PATCH] drm/i915: set the BIOS current backlight reference level
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula jani.nik...@intel.com
This should keep BIOS brightness keys and i915 backlight device better in
sync.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/intel_opregion.c | 20 +++-
drivers/gpu/drm/i915/intel_panel.c|3 +++
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82ea281..5a1cfa3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2059,10 +2059,13 @@ extern int intel_opregion_setup(struct drm_device *dev);
extern void intel_opregion_init(struct drm_device *dev);
extern void intel_opregion_fini(struct drm_device *dev);
extern void intel_opregion_asle_intr(struct drm_device *dev);
+extern void intel_opregion_asle_set_cblv(struct drm_device *dev, u32 level,
u32 max);
#else
static inline void intel_opregion_init(struct drm_device *dev) { return; }
static inline void intel_opregion_fini(struct drm_device *dev) { return; }
static inline void intel_opregion_asle_intr(struct drm_device *dev) { return; }
+}
+static inline void intel_opregion_asle_set_cblv(struct drm_device *dev, u32
level, u32 max) { return; }
#endif
/* intel_acpi.c */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..00fce49 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -158,6 +158,25 @@ struct opregion_asle {
#define ACPI_LVDS_OUTPUT (48)
#ifdef CONFIG_ACPI
+
+/* set backlight brightness reference to level in range [0..max] */
+void intel_opregion_asle_set_cblv(struct drm_device *dev, u32 level, u32 max)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct opregion_asle __iomem *asle = dev_priv-opregion.asle;
+
+ if (!asle)
+ return;
+
+ if (level max)
+ level = max;
+
+ /* scale to 0...100 per opregion spec */
+ level = level * 100 / max;
+
+ iowrite32(level | ASLE_CBLV_VALID, asle-cblv);
+}
+
static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -173,7 +192,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
return ASLE_BACKLIGHT_FAILED;
intel_panel_set_backlight(dev, bclp, 255);
- iowrite32((bclp*0x64)/0xff | ASLE_CBLV_VALID, asle-cblv);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 67e2c1f..a497e20 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -497,6 +497,9 @@ void intel_panel_set_backlight(struct drm_device *dev, u32
level, u32 max)
goto out;
}
+ /* set brightness reference value for bios hotkeys */
+ intel_opregion_asle_set_cblv(dev, level, max);
+
/* scale to hardware */
level = level * freq / max;
--
1.7.9.5
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Wed, Jul 17, 2013 at 7:16 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! I tried this patch series and it's as I expected, it's the same as acpi_backlight=vendor, and the intel backlight driver doesn't work correctly in this machine. If you are actually serious about the mantra of no user-space regressions, then for this machine at least, you need to use the ACPI backlight with Windows8 OSI disabled, until the intel backlight driver is fixed. My patch does that: http://article.gmane.org/gmane.linux.acpi.devel/60969 -- Felipe Contreras ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
