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
Most switcheroo setups attach power management to one of the GPUs. This is
not always the case, so provide a mechanism for handlers to declare that
they can change the power state of GPUs and permit drivers to obtain this
information.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga
We may not know whether the platform supports dynamic PM of GPUs until the
switcheroo handler is registered. Add an enable() callback for clients and
another entry point to switcheroo in order to permit them to set dynamic PM
appropriately.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga
We can switch DDC pins in a way that ought (with luck) to work for LVDS.
This isn't sufficient for eDP, which is addressed in later patches.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/platfor
The GMUX doesn't appear to switch instantly, which can trigger problems in
panel detection and setup. Wait for an interrupt or 200msec, whichever comes
first.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 12
1 file changed, 12 insertions(+)
diff --
Add a command line option in order to allow the user to provide a perferred
GPU at boot time.
Signed-off-by: Matthew Garrett
---
Documentation/kernel-parameters.txt | 5 +
drivers/gpu/vga/vga_switcheroo.c| 29 +
2 files changed, 34 insertions(+)
diff --git
retrigger the driver's output probing.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_switcheroo.c | 10 ++
include/linux/vga_switcheroo.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index dd
The Apple GMUX can cut power to the discrete GPU, so should declare this
to the vga_switcheroo core.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
Registering the handler after both GPUs will trigger a DDC switch for
connector reprobing. This will oops if apple_gmux_data hasn't already been
assigned. Reorder the code to do that.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 10 ++
1 file chang
data in vga_switcheroo where it can be retrieved by the other driver later.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_switcheroo.c | 59
include/linux/vga_switcheroo.h | 12
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu
We need to force the previously active device to reprobe its connectors
when we switch in order to allow it to give up connectors that are no
longer in use.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_switcheroo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/vga
From: Seth Forshee
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM to mux
only the
onality to
GMUX in order to fix things up. This won't actually *work* in its current
form - it needs additional patches to the GPU drivers, which are currently
in a somewhat hacky state.
--
Matthew Garrett | matthew.garrett at nebula.com
On Wed, 2014-06-25 at 00:55 +0200, Bruno Pr?mont wrote:
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
>
Both look good to me.
Acked-by: Matthew Garrett
--
Matthew Garrett
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
#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
___
dri-devel mailing list
dri-devel@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
- something's still
going to have to make the same policy decision as we do right now, and
the kernel isn't really the right place to do that. It does have the
benefit of allowing that policy decision to be made at boot time and
then allow that to be consumed by all later userspace, so there is
*some* benefit, but I think the "make unprivileged userspace possible"
argument is much more compelling.
--
Matthew Garrett
One extreme case - apple_gmux needs to be mapped to both the internal and
discrete gpu. The same may be true for some other platform drivers on multi-gpu
systems.
Matthew Garrett | matthew.garrett at nebula.com
-- next part --
An HTML attachment was scrubbed...
URL
ems like it's
going to be a visible change in behaviour.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Aug 23, 2017 at 09:10:09PM +0530, Varad Gautam wrote:
> Hi Matthew,
>
> On Sat, Aug 19, 2017 at 2:02 PM, Matthew Garrett wrote:
> > On Fri, Aug 18, 2017 at 09:19:11PM +0530, Varad Gautam wrote:
> >> From: Stéphane Marchesin
> >>
> >> initia
Anyone know more about the acpi code?
Not sure what you're asking here - acpi_get_table returns acpi_status,
not a pointer.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
+ */
Won't this break the multiple cards with independent outputs case?
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote:
> On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote:
> > Won't this break the multiple cards with independent outputs case?
>
> Yes, if they don't have a switcheroo handler. I only have experienc
ases - Apple is the only special case I can
see, and that one's a fairly easy workaround.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Aug 21, 2012 at 10:50:35AM -0400, Alex Deucher wrote:
> Any objections from the ACPI folks to this patch going into 3.6 and stable?
Looks good to me.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-de
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
the type field.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Sep 14, 2012 at 03:29:14PM +0100, David Woodhouse wrote:
> On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> > On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
> >
> > > Tested on MacbookPro8,3. Without this patch both the intel_backlight
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
> &
On Thu, Nov 17, 2011 at 09:36:23PM +0100, Mario Kleiner wrote:
> On Nov 17, 2011, at 3:19 AM, Matthew Garrett wrote:
> >Assuming we're sleeping rather than busy-looping, that's certainly ok.
> >My previous experiments with radeon indicated that the scanout irq was
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
___
d
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Add core support for allocating buffer objects that cover the existing
framebuffers at startup.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |4
drivers/gpu/drm/nouveau/nouveau_state.c |9 -
3
We want to be able to guarantee the location of the allocated buffer
object if we're going to be able to reliably allocate the existing
framebuffer at startup. Add an argument to do so and pass that through to
the ttm core.
Signed-off-by: Matthew Garrett
---
drivers/bcma/m
The instmem setup code may allocate from the region that's currently being
scanned out, but we can't allocate a buffer object to cover that until the
generic vram code has been run. Flip the order to make this possible.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouve
he current
framebuffer state on nv50 and avoids graphical glitches appearing during
modesetting.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_reg.h |1 +
drivers/gpu/drm/nouveau/nouveau_state.c |2 ++
drivers/gpu/drm/nouveau/nv50_display
as well. Is this no longer true on the latest?
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 24, 2012 at 11:31:17PM +0100, Alan Cox wrote:
> On Tue, 24 Apr 2012 22:02:18 +0100
> Matthew Garrett wrote:
> > The PowerVR Intels I'd seen had the opregion address in the 0xfc
> > register as well. Is this no longer true on the latest?
>
> PowerVR do
On Wed, Apr 25, 2012 at 11:27:11AM +0100, Alan Cox wrote:
> On Tue, 24 Apr 2012 23:30:22 +0100
> Matthew Garrett wrote:
> > Right now you seem to set opregion unconditionally on PVR, which seems
> > to be equivalent to the 0xfc check that was there before - I can
> > u
n if an i915 is found, but not
> if a GMA500 is found. Ditto the reverse.
No you don't - there's various platforms that will hang if you do that.
It's necessary to make sure that the DIDL fields are set up before
calling any ACPI video functions on opregion hardware.
--
On Wed, Apr 25, 2012 at 01:49:40PM +0100, Alan Cox wrote:
> On Wed, 25 Apr 2012 13:40:18 +0100
> Matthew Garrett wrote:
> > No you don't - there's various platforms that will hang if you do that.
> > It's necessary to make sure that the DIDL fields are set up b
Acked-by: Matthew Garrett
for the set.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
fixed
> already).
Dave has patches.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Anyone have any further thoughts on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote:
> In v3.3, the gma500 drm driver moved from staging to drm group by
> Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
> brightness well and don't need gma500 stub driver anymore.
Looks good to me.
ptop
> machines are expected to bail out before the EDID check then the
> approach I've taken seems reasonable. Otherwise adding a quirk probably
> is a good idea.
I know we've previously had problems with machines with phantom LVDS
hardware, but I'm not sure what the curren
irk for this situation would
be justifiable, rather than doing it for all devices.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
w piece of related hardware to the quirk list.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
e'll always be broken on the hardware
at the point where it ships. Implementing the functionality means we
stand some chance of working out of the box.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-dev
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
___
dri-devel mailing list
dri-dev
g'?
"Do not rely upon 0 being visible".
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
when booted in EFI
> mode. The original patch fixed macbook2,1 systems which were
> r5xx and hence have no UVD. Limit the hack to those systems to
> prevent UVD breakage on newer systems.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=63935
>
> Cc: Matthew Garrett
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/
the vendor drivers under Windows.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
--
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
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
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
___
dri-deve
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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel
if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-deve
;s glint
driver, with the modesetting code cribbed from cirrusfb (hence the
license).
Signed-off-by: Matthew Garrett
Cc: Matt Turner
---
drivers/gpu/drm/Kconfig |8 +
drivers/gpu/drm/Makefile|1 +
drivers/gpu/drm/cirrus/Makefile |6
+
> > + unsigned char tmp;
> > +
> > + switch (encoder->crtc->fb->bits_per_pixel) {
> > + case 8:
> > + tmp = 0x0;
> > + break;
> > + case 16:
> > + /* Enable 16 bit mode */
> > + WRE
On Mon, Apr 18, 2011 at 10:20:13PM +0100, Matthew Garrett wrote:
> On Mon, Apr 18, 2011 at 10:03:06PM +0100, Alan Cox wrote:
> > So has this been benchmarked - intuitively I'd agree and expect that a
> > shadowfb driver ought to give best performance.
>
> No, but it'
if the resolutions don't
match. Systems without a valid internal panel EDID will still use the BIOS
native mode.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ra
ecute the init scripts on Apples when we're using EFI.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon_device.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
ind
The parent of the backlight doesn't let you determine whether it's a
platform or a firmware interface without heuristics. I'd prefer to
explicitly define that.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing
Richard, any feedback on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
1 - 100 of 243 matches
Mail list logo
