On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote:
> So to fix this we need to make acpi_video_get_backlight_type()
> return native on the Acer Chromebook Spin 713.
Isn't the issue broader than that? Unless the platform is Windows 8 or
later, we'll *always* (outside of some corner ca
On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote:
> That is a valid point, but keep in mind that this is only used on ACPI
> platforms and then only on devices with a builtin LCD panel and then
> only by GPU drivers which actually call acpi_video_get_backlight_type(),
> so e.g. not by
On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote:
> Having the native driver come and then go and be replaced
> with the vendor driver would also be quite inconvenient
> for these planned changes.
I understand that it would be inconvenient, but you've broken existing
working setups.
On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
> drivers/acpi/scan.c:
>
> static acpi_status
> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
> void **return_value)
> {
On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote:
> Ok, so this is a local customization to what is already a custom BIOS
> for a custom motherboard. There is a lot of custom in that sentence and
> TBH at some point things might become too custom for them to be expected
> to work OOTB
On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote:
> In their backlight register paths and this has been present since
> circa 2015.
>
> So both before and after my 6.1 refactor vendor is only preferred
> on devices which don't implement the ACPI video bus control method.
Sorry, yes,
On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
> The *only* behavior which actually is new in 6.1 is the native GPU
> drivers now doing the equivalent of:
>
> if (acpi_video_get_backlight_type() != acpi_backlight_native)
> return;
>
> In their backlight regist
Can you give this patch a try? It's not ready for upstream yet, but
ought to work.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Apr 12, 2010 at 06:19:20PM +0100, Matthew Garrett wrote:
> Can you give this patch a try? It's not ready for upstream yet, but
> ought to work.
It would, of course, be more useful if I included the patch.
commit bd599ffa48a679679434109ead29fcdf108ccc77
Author: Matthew Ga
On Mon, Apr 12, 2010 at 08:45:11PM +0100, Sergio Monteiro Basto wrote:
> On Mon, 2010-04-12 at 18:36 +0100, Matthew Garrett wrote:
> > On Mon, Apr 12, 2010 at 06:19:20PM +0100, Matthew Garrett wrote:
> > > Can you give this patch a try? It's not ready for upstream yet, b
fedora kernel ? or have this patch
> against fedora kernels ?
It's unlikely to end up in any current Fedora releases because it'll
also require userspace changes.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Inte
It seems to be possible to program a new mode without disabling the panel
if the panel fitter setup doesn't change. Add support for that.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/i915/intel_lvds.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
ts that there's something going on which we
don't understand or implement.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
that
drivers know what the firmware's expecting.
Based on a patch by Seth Forshee
Signed-off-by: Matthew Garrett
Cc: Seth Forshee
---
drivers/acpi/acpica/aclocal.h | 13 -
drivers/acpi/acpica/utxface.c | 19 +++
include/acpi/acpixf.h | 22 +++
he OS claims to support
Windows 8. The simplest thing to do appears to be to disable the ACPI
backlight interface on these systems.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/
kernel.org/show_bug.cgi?id=35622
v2: Also unregister cooling devices.
Tested-by: Andrzej Krentosz
Cc: Zhang Rui
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Carlos Corbacho
Cc: Matthew Garrett
Cc: Dmitry Torokhov
Cc: Corentin Chary
Cc: Aaron Lu
Cc: Thomas Renninger
Signed-off-by: Lee, Chun-Yi
--
the vendor drivers under Windows.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ow. The policy as implemented here may not
be correct, but doing better would probably involve Intel letting us
know how their Windows driver behaves.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http:/
lution, all backlight control interfaces stay,
> the priority field is an indication given by kernel to user space.
We shouldn't export interfaces if we don't expect them to work.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gf
On Sat, 2013-06-15 at 09:26 +0800, Aaron Lu wrote:
> On 06/15/2013 01:29 AM, Matthew Garrett wrote:
> > How would that work with existing userspace?
>
> User space tool will need to be updated to use this as stated in the
> gist page, I've patches for gsd-backlight-helper
On Sat, Jun 15, 2013 at 12:14:42PM +0800, Aaron Lu wrote:
> On 06/15/2013 09:38 AM, Matthew Garrett wrote:
> > Well, Windows 8 will only use the ACPI backlight interface if the GPU
> > driver decides to, right? So the logic for deciding whether to remove
> > the ACPI bac
On Sat, Jun 15, 2013 at 08:29:15PM +0800, Aaron Lu wrote:
> On 06/15/2013 12:19 PM, Matthew Garrett wrote:
> > The vendor will presumably have tested that backlight control works - if
> > the GPU driver uses the ACPI interface and backlight control is broken,
> > then th
d should be fixed
> asap. But imo that's not something we should try to (nor do I see any way
> how to) work around in the kernel.
It's only used if there's no backlight property on the display.
--
Matthew Garrett | mj...@srcf.ucam.org
___
t receive keypresses. We could easily tie
certain keycodes into backlight events, but which backlight should they
control? You're really starting to get into the kind of complex policy
decision that's best left to userspace, which is where it should have
be
variable and encourage distributions to flip their behaviour.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > Right, the kernel has special-casing to hook the backlight keys up to
> > the ACPI backlight control. This is an awful thing, because there's n
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > I agree, we should standardise the behaviour. And the only way we can
> > standardise the behaviour is to leave it up to userspace.
> >
&
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote:
> On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> > Which, as we've already established, you don't - Lenovo broke it. Your
> > Thinkpad claims to have 100 available levels, and most of them do
exactly
> like Windows 8 kernel” policy) is indeed a regression.
Your firmware behaves differently depending on whether the OS claims to
be Windows 8 or not. We can't make that invisible.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx
if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gf
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
userspace knows better. This sounds
like a lot of work for something that should really just be handled by
userspace already.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
eems like a
completely reasonable thing to do, though.
--
Matthew Garrett
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#x27;.
Non-standard _ADR values are assigend by the GPU vendor, so Intel should
be able to provide you with the correct interpretations.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ve_backlight, bool, 0644);
>
> static int register_count;
> --
> 1.8.3.2
>
>
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
> have only the GPU interface left and checking win8 doesn't make much
> sense now;
Are we sure that those aren't simply some other b
On Tue, 2014-01-21 at 10:24 +0800, Aaron Lu wrote:
> On 01/20/2014 09:34 PM, Matthew Garrett wrote:
> > On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
> >
> >> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
> >> have only th
On Tue, 2014-01-21 at 13:32 +0800, Aaron Lu wrote:
> On 01/21/2014 11:17 AM, Matthew Garrett wrote:
> > We know that Windows 8 graphics drivers don't use the ACPI interface,
> > and that systems change their behaviour as a result, in some cases with
> > absolutely no
use (as far as we can tell) the Intel drivers
under Windows 8 never use the ACPI backlight set function. Of course, it
would be nice to have that confirmed by Intel.
--
Matthew Garrett
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
#x27;s handled by the ACPI
code then it belongs in the ACPI code. But I have no way of determining
that, whereas you work for a company that produces a Windows 8 video
driver…
--
Matthew Garrett
___
Intel-gfx mailing list
Intel-gfx@lists
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> >
> >> I think the parameter "Does the ACPI backlight interface work or not"
> >> belongs to
ly based on the exposed
firmware type.
--
Matthew Garrett
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Matthew Garrett wrote:
> > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
> >
> >> Before plunging forward, have you observed any difference between the
> >> boot modes? We ha
.
I'd still really prefer not to add such a list, because it almost
inevitably means that we'll never fix this problem properly.
--
Matthew Garrett
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Mar 26, 2013 at 06:10:30PM +0100, Danny Baumann wrote:
> Am 26.03.2013 18:02, schrieb Matthew Garrett:
> >I'm not quite clear what you mean here. The behaviour of "0" isn't well
> >defined for the ACPI backlight driver - it's perfectly reason
d for the ACPI backlight driver - it's perfectly reasonable for it
to turn the backlight off entirely. Anything assuming that "0" is still
visible is broken.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-g
g'?
"Do not rely upon 0 being visible".
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Anyone have any further thoughts on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Afraid it was forgotten -- Matthew, is this patch still useful?
Yup. There's a small set of systems that appear to provide no firmware
control mechanism.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-g
Sigh. Could you provide the output of lspci and acpidump?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Well, that all looks fine. And I also can't see any way that this commit
could cause the backlight not to appear - all it does is set the parent
if it's present. There's no new path that could cause it to return
early. Does reverting this patch really make things work?
--
Matth
has a parent it won't be under /sys/devices/virtual.
Does it appear under /sys/class/backlight ?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
p}_init
> so do not call it again from intel_setup_outputs().
>
> BugLink: http://bugs.launchpad.net/bugs/831542
>
> Signed-off-by: Kamal Mostafa
ACKed-by: Matthew Garrett
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing li
ly any better than the existing error
path - it might make things better for some systems, but it has the
potential to break hardware that expects a different value and no longer
generates an error in that case.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Again, adding arbitrary constants without any explanation for why you're
making this the default really isn't acceptable. We have no way to
determine whether fixing one machine is worth making things worse for
another.
--
Matthew Garrett | mj...@src
I feel like I'm missing something here. Where's the firmware getting its
initial value from?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:
> On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett wrote:
>
> > I feel like I'm missing something here. Where's the firmware getting its
> > initial value from?
>
>
> My understanding is that norma
and use
> the upstream driver instead. However, we still don't have the firmware
> support, which is why we have this patch to provide the missing information.
I'm still not clear on this. There is no video support in the firmware
at all? What happens if the kernel fails to b
s just considered pretty poor style.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
formation
source and allow the existing platform-specific code to hook in would be
conceptually cleaner. But then maybe this is grotesque over-engineering
and we should just hack this case.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx
> in no change to the PWM registers.
> >
> > Signed-off-by: Simon Que
>
> Acked-by: Olof Johansson
>
> Looks much better. I'm OK with this solution. Matthew?
I'd still prefer this to come from the firmware in
The drm core currently waits 5 seconds from userspace dropping a request
for vblanks to vblanks actually being disabled. This appears to be a
workaround for broken hardware, but results in a mostly idle desktop
generating a huge number of wakeups that are entirely unnecessary but which
consume meas
drm_vblank_offdelay is currently a system global, despite the optimal
value being hardware-specific. Move it to the drm_device structure.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/drm_irq.c |6 +++---
drivers/gpu/drm/drm_stub.c |8 +---
include/drm/drmP.h |2
Right now if vblank_offdelay is 0, vblanks won't be disabled after the
last user. Fix that case up.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/drm_irq.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
Sandybridge, at least, seems to manage without any vblank offdelay.
Dropping this reduces the number of wakeups on an otherwise idle system
dramatically.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a
> the counter unreliable. Maybe I'm misremembering though.
If turning it on and off results in the counter value being wrong then
surely that's a hardware problem? I've tested that turning it on and off
between every IRQ still gives valid counter values on sandybridge.
--
Matth
ine, otherwise bad
> things will happen.
> Keeping a way to override the default off delay would be good to
> allow poor scientists to work around potentially broken drivers or
> gpu's in the future. @Matthew: I'm appealing here to your ex-
> Drosophila biologist
On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote:
> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote:
> >I'll admit that I'm struggling to understand the issue here. If the
> >vblank counter is incremented at the time of vblank (which isn't the
> &
ommu || dmar_disabled;
So the user has to choose between 5W of power saving or having dmar? And
we default to giving them dmar? I think that's going to come as a
surprise to people.
--
Matthew Garrett | mj...@srcf.ucam.org
___
I
On Tue, Nov 22, 2011 at 06:46:21PM -0200, Eugeni Dodonov wrote:
> On Tue, Nov 22, 2011 at 18:15, Matthew Garrett wrote:
>
> > On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
> >
> > > + /*
> > > + * Only enable RC6 if
#x27;.
> The whole file was added more than a year ago by commit 723bfd707a97
> (see the relevant thread on intel-gfx@ [1]) to "add _DSM support".
> One of the first comment is about "Calpella", which is exactly the
> platform of m
f we're going to merge this then let's turn off
iommu on SNB by default.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> Cc: Matthew Garrett
Acked-by: Matthew Garrett
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Not all systems expose a firmware or platform mechanism for changing the
backlight intensity on i915, so add native driver support.
Signed-off-by: Matthew Garrett
Cc: intel-gfx
---
drivers/gpu/drm/i915/i915_drv.h |3 +
drivers/gpu/drm/i915/i915_opregion.c | 60 +---
drivers
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-gfx
On Tue, May 18, 2010 at 01:12:32PM -0700, Jesse Barnes wrote:
> On Tue, 18 May 2010 13:53:16 -0400
> Matthew Garrett wrote:
>
> > It seems to be possible to program a new mode without disabling the panel
> > if the panel fitter setup doesn't change. Add support for th
On Thu, Sep 09, 2010 at 06:09:40PM +0100, Chris Wilson wrote:
> On Wed, 8 Sep 2010 12:32:18 -0400, Matthew Garrett wrote:
> > Not all systems expose a firmware or platform mechanism for changing the
> > backlight intensity on i915, so add native driver support.
>
> This
On Fri, Sep 10, 2010 at 02:38:03PM +0100, Chris Wilson wrote:
> Based on an original patch by Matthew Garrett
> Signed-off-by: Chris Wilson
> Cc: Matthew Garrett
ACKed-by: Matthew Garrett
--
Matthew Garrett | mj...@srcf.ucam.org
___
working one and the non-working one.
Having thought about this some more, I don't think this is the right
approach. We should be ensuring that every backlight ahs all the
required methods and then dropping the one that doesn't. This should be
replaced with a native i915 backlight, and I sen
Richard, any feedback on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Not all systems expose a firmware or platform mechanism for changing the
backlight intensity on i915, so add native driver support.
Signed-off-by: Matthew Garrett
Cc: intel-gfx
---
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm/i915/intel_dp.c |7 +++
drivers/gpu
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-gfx
From: Michel Dänzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel Dänzer
Signed-off-by: Matthew Garrett
Cc: dri-de
We may eventually end up with per-connector backlights, especially with
ddcci devices. Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 21
On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> On Fri, 19 Nov 2010 10:53:52 -0500
> Matthew Garrett wrote:
>
> > There may be multiple ways of controlling the backlight on a given machine.
> > Allow drivers to expose the type of interface they are pro
t as a high priority since (in
practice) there's no situations where an ACPI interface will be able to
control more than one backlight.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
eDP it ignores the
firmware and platform interfaces, so you'll fall back to the raw
interface if it can provide support for your connector (presumably via
ddcci, although we don't have this implemented yet)
--
Matthew Garrett | mj...@srcf.ucam.org
__
Not all systems expose a firmware or platform mechanism for changing the
backlight intensity on i915, so add native driver support.
Signed-off-by: Matthew Garrett
Cc: intel-gfx
---
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm/i915/intel_dp.c |7 +++
drivers/gpu
There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.
Signed-off-by: Matthew Garrett
Cc: Richard Purdie
Cc: intel-gfx
We may eventually end up with per-connector backlights, especially with
ddcci devices. Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 24
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions
From: Michel Dänzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel Dänzer
Signed-off-by: Matthew Garrett
Cc: dri-de
On Fri, Jan 14, 2011 at 09:30:19PM +0200, Anca Emanuel wrote:
> Hi Matthew Garrett,
> I have problems with nouveau.
> Do you know ?
Your best bet is to follow the instructions on
http://nouveau.freedesktop.org/wiki/Bugs to report a bug.
--
Matthew Garrett | mj...@srcf
e
> radeon-expose-backlight-class-device-for-legacy-lvds-encoder.patch
> build error.
He applied 2/5, it didn't build, he applied 1/5 and it built? I don't
think that's a patch ordering issue :)
I think Michel's patch should fix the Radeon one. If not, can you drop
that and ke
ise work. I'll send
fixup patches for any I see.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Well, that's odd. I'll look into it this week.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
+ parent = &pdev->dev;
> > + pci_dev_put(pdev);
> > + }
>
> I'm afraid you can't do that or suspend problems will happen.
Ugh. Ok, how can we fix this?
--
Matthew Garrett | mj...@srcf.ucam.org
On Sun, Feb 06, 2011 at 11:41:19PM +0100, Rafael J. Wysocki wrote:
> On Sunday, February 06, 2011, Matthew Garrett wrote:
> > Ugh. Ok, how can we fix this?
>
> Not nicely, I'm afraid.
>
> One possible way is to use device_pm_move_after() to rearrange the devices in
&g
pi-pci glue code? It seems wrong to have acpi devices
resumed before the PCI device they're associated with.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
1 - 100 of 114 matches
Mail list logo
