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 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
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
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.garrett at coreos.com
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
vga_switcheroo is pretty much the only obstacle to get gpu switching
> to work on MBPs.
My testing suggested that changing the DDC lines didn't change auxch, so
this approach doesn't work for eDP. Have you found otherwise?
--
Matthew Garrett | mjg59 at srcf.ucam.org
rather than ACPI, but yeah. In theory this should work fine if
you're using the EFI entry point. I don't know whether the patches for
linuxefi were ever accepted by grub upstream - if not, pushing those
would make more sense.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
- 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
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
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 --
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
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
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
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
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
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
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
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
The list of machines in the "Use native backlight" table is getting longer
and longer, which is a solid indication that we're doing something wrong.
Disable the ACPI backlight interface if the system claims to be Windows 8
or later.
Signed-off-by: Matthew Garrett
---
Let'
wayland too.
Sure. You should probably take a look at libbacklight, which already has
some amount of support for appropriate heuristics.
--
Matthew Garrett | mjg59 at srcf.ucam.org
that's where
heuristics are probably going to be involved.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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 bug?
--
Matthew Garrett
.
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing list
dri-devel@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
___
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 | mjg59 at srcf.ucam.org
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
have any systems that reproduce problems here, so
I think Intel are going to have to take the lead on this one.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-deve
if (result)
- return;
name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
if (!name)
return;
--
Matthew Garrett | mjg59 at srcf.ucam.org
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 | mjg59 at srcf.ucam.org
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 | mjg59 at 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
been to begin with.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 | mjg59 at 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
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, 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
___
dri-deve
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
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 | mjg59 at srcf.ucam.org
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
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 | mjg59 at srcf.ucam.org
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/
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 +++
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 | mjg59 at srcf.ucam.org
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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/
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 +++
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 Ga
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
g'?
"Do not rely upon 0 being visible".
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
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 | mjg59 at srcf.ucam.org
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
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
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 type field.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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 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
--
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 | mjg59 at srcf.ucam.org
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
ases - Apple is the only special case I can
see, and that one's a fairly easy workaround.
--
Matthew Garrett | mjg59 at srcf.ucam.org
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
+ */
Won't this break the multiple cards with independent outputs case?
--
Matthew Garrett | mjg59 at srcf.ucam.org
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 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
+ */
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
1 - 100 of 243 matches
Mail list logo
