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
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 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 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 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 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, 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 Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
> Your i915 does not have a ROM BAR in hardware. If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_RO
t; some shadowed copy of a real underlying hardware ROM, but is
> fundamentally just a RAM image decompressed from some other source and
> then marked read-only.
If only - nvidias used to rewrite their image at runtime.
--
Matthew Garrett | matthew.garr...@coreos.com
__
his is the problem. If runtime PM is enabled on the i915 PCI
device (and the HDMI HDA device), things break. If it's disabled,
everything works fine. I hope that helps narrow it down!
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx
every second or so but fbcon works. If I suspend and resume, things
go back to the working state until the next screen power cycle.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedeskto
splay.
--
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
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
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 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
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
.
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 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
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 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
#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
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
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
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
if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gf
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
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
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 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
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
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
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
___
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
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, 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
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
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:/
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
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
--
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/
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
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
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
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
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
#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
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
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 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
> &
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
> 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
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
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
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
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
> 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
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
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
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
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
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
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
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
___
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
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
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
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
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
switch itself will still generate an event.
I'll send v2 now.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
requesting a display switch before passing that event through
to userspace.
Signed-off-by: Matthew Garrett
Tested-by: Adam Jackson
---
drivers/acpi/video.c |7 ---
drivers/gpu/drm/i915/intel_opregion.c | 15 +++
include/acpi/video.h |2
requesting a display switch before passing that event through
to userspace.
Signed-off-by: Matthew Garrett
Tested-by: Adam Jackson
---
drivers/acpi/video.c |7 ---
drivers/gpu/drm/i915/intel_opregion.c | 15 +++
include/acpi/video.h |2
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:32:40PM +0000, Matthew Garrett wrote:
> > Opregion is one mechanism to provide VBT - it doesn't define it.
>
> Then let me repeat that I haven't seen anything in the VBT tab
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:52:26AM +0000, Matthew Garrett wrote:
> > Now that we've got multiple consumers it's probably not helpful to move
> > the (potentially chip-specific) VBT handling to general
ntially chip-specific) VBT handling to general code. We've got
zero documentation on how GMA500 handles VBT, and not a great deal more
for i915.
> About the naming, as this is Intel-only intel_opregion seems clearer than
> igd-opregion, which sounds like it could be anything.
It&
acking in hardware (and no, this
is not a plea for some gma500)
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
anything sensible.
Signed-off-by: Matthew Garrett
---
drivers/staging/gma500/Kconfig |1 +
drivers/staging/gma500/Makefile |1 -
drivers/staging/gma500/psb_drv.c| 28 --
drivers/staging/gma500/psb_drv.h| 21 +---
drivers
n and
remove the i915 dependency, while simultaneously reworking i915 to make
use of the new driver.
Signed-off-by: Matthew Garrett
---
drivers/acpi/Kconfig |8 +
drivers/acpi/Makefile |1 +
drivers/acpi/acpi_igd_opregion.c |
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
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
+ 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
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
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
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
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
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
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
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
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
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
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
__
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
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
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
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
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
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
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
1 - 100 of 114 matches
Mail list logo
