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
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,
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
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
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
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
On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas bhelg...@google.com 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
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
___
Intel-gfx mailing list
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.freedesktop.org
.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
reasonable thing to do, though.
--
Matthew Garrett matthew.garr...@nebula.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 way for the ACPI interface could
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 bug?
--
Matthew Garrett matthew.garr
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 the GPU interface left and checking win8 doesn't make
and the GPU driver has
* registered a backlight interface, skip registering ACPI video's.
*/
-static bool use_native_backlight = false;
+static bool use_native_backlight = true;
module_param(use_native_backlight, bool, 0644);
static int register_count;
--
1.8.3.2
--
Matthew
not to add such a list, because it almost
inevitably means that we'll never fix this problem properly.
--
Matthew Garrett matthew.garr...@nebula.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
= ACPI_OSI_WIN_8 check in patch 2/2 is the whole
story.
Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code
paths, what guarantees do we have of UEFI+CSM or legacy boots working?
We have no evidence of Windows behaving differently based on the exposed
firmware type.
--
Matthew Garrett
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
On Wed, 11 Sep 2013, Matthew Garrett matthew.garr...@nebula.com 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 have reports [1
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 matthew.garr...@nebula.com
___
Intel-gfx mailing list
Intel-gfx
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote:
On Tue, 10 Sep 2013, Matthew Garrett matthew.garr...@nebula.com 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 the ACPI video driver
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
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
)
- return;
name = kasprintf(GFP_KERNEL, acpi_video%d, count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx
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
been to begin with.
--
Matthew Garrett | mj...@srcf.ucam.org
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 no
way to detect
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.
It's pretty clear we disagree
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 don't
work. The kernel has
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 mailing list
Intel-gfx
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-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 and xorg-x11-drv-intel
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 backlight control or not should
that
drivers know what the firmware's expecting.
Based on a patch by Seth Forshee seth.fors...@canonical.com
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
Cc: Seth Forshee seth.fors...@canonical.com
---
drivers/acpi/acpica/aclocal.h | 13 -
drivers/acpi/acpica/utxface.c | 19
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 matthew.garr...@nebula.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b
://bugzilla.kernel.org/show_bug.cgi?id=35622
v2: Also unregister cooling devices.
Tested-by: Andrzej Krentosz endr...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Carlos Corbacho car...@strangeworlds.co.uk
Cc: Matthew Garrett m
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
, 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://lists.freedesktop.org/mailman/listinfo/intel-gfx
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-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman
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
on intel-gfx@ [1]) to add _DSM support.
One of the first comment is about Calpella, which is exactly the
platform of my laptop (as shown by lshw)
Ignore that - it's entirely harmless.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Tue, Nov 22, 2011 at 06:46:21PM -0200, Eugeni Dodonov wrote:
On Tue, Nov 22, 2011 at 18:15, Matthew Garrett m...@redhat.com wrote:
On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
+ /*
+ * Only enable RC6 if all dma remapping is disabled
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
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 m...@redhat.com
---
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
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 m...@redhat.com
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files changed, 3 insertions(+), 0 deletions
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.
--
Matthew Garrett | mj...@srcf.ucam.org
are disabled and then re-enabled between 1 and 3, what's the
negative outcome?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
better. I'm OK with this solution. Matthew?
I'd still prefer this to come from the firmware in some way, but in the
absence of the awesome let's go with the good.
Acked-by: Matthew Garrett m...@redhat.com
--
Matthew Garrett | mj...@srcf.ucam.org
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 mj...@srcf.ucam.org wrote:
I feel like I'm missing something here. Where's the firmware getting its
initial value from?
My understanding is that normally, the firmware's VBIOS can
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 boot?
--
Matthew Garrett | mj...@srcf.ucam.org
style.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 mailing list
Intel-gfx@lists.freedesktop.org
http
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...@srcf.ucam.org
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
___
Intel-gfx mailing list
Intel-gfx
it again from intel_setup_outputs().
BugLink: http://bugs.launchpad.net/bugs/831542
Signed-off-by: Kamal Mostafa ka...@canonical.com
ACKed-by: Matthew Garrett m...@redhat.com
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel
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?
--
Matthew Garrett | mj
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-gfx@lists.freedesktop.org
http
requesting a display switch before passing that event through
to userspace.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Adam Jackson a...@redhat.com
---
drivers/acpi/video.c |7 ---
drivers/gpu/drm/i915/intel_opregion.c | 15 +++
include/acpi
requesting a display switch before passing that event through
to userspace.
Signed-off-by: Matthew Garrett m...@redhat.com
Tested-by: Adam Jackson a...@redhat.com
---
drivers/acpi/video.c |7 ---
drivers/gpu/drm/i915/intel_opregion.c | 15 +++
include/acpi
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
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
On Tue, Mar 15, 2011 at 01:52:26AM +, 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 code. We've got
zero
vendor-neutral specs that have been pushed and implemented by a
single vendor, I'd rather not make the naming Intel-specific if there's
a chance someone else can end up depending on it.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
anything sensible.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/staging/gma500/Kconfig |1 +
drivers/staging/gma500/Makefile |1 -
drivers/staging/gma500/psb_drv.c| 28 --
drivers/staging/gma500/psb_drv.h| 21
);
+ }
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
? 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
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
the Radeon one. If not, can you drop
that and keep the rest of the set? I'm travelling at the moment and
won't have proper build access until the weekend.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx
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
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 m...@redhat.com
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14 insertions
-by: Matthew Garrett m...@redhat.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/Kconfig |1 +
drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 257 ++-
drivers/gpu/drm/radeon
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.ucam.org
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 m...@redhat.com
---
drivers/acpi/video.c | 15 ++-
1 files changed, 14 insertions
-by: Matthew Garrett m...@redhat.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/Kconfig |1 +
drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 257 ++-
drivers/gpu/drm/radeon
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 m...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 21
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 sent patches to do that
last week.
--
Matthew
On Thu, Sep 09, 2010 at 06:09:40PM +0100, Chris Wilson wrote:
On Wed, 8 Sep 2010 12:32:18 -0400, Matthew Garrett m...@redhat.com wrote:
Not all systems expose a firmware or platform mechanism for changing the
backlight intensity on i915, so add native driver support.
This will conflict
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 m...@redhat.com
Cc: intel-gfx intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_drv.h |3 +
drivers/gpu/drm/i915
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 m...@redhat.com
Cc: Richard Purdie rpur...@rpsys.net
On Tue, May 18, 2010 at 01:12:32PM -0700, Jesse Barnes wrote:
On Tue, 18 May 2010 13:53:16 -0400
Matthew Garrett m...@redhat.com 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 that.
Signed-off
Cc: Matthew Garrett mj...@srcf.ucam.org
Acked-by: Matthew Garrett m...@redhat.com
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
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 m...@redhat.com
---
drivers/gpu/drm/i915/intel_lvds.c | 22 --
1 files changed, 20 insertions(+), 2
87 matches
Mail list logo
