Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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,

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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) >

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

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

Re: [PATCH 06/14] drm/cirrus: Use 32bpp by default

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 <mj...@srcf.ucam.org> wrote: > > On Fri, Aug 18, 2017 at 09:19:11PM +0530, Varad Gautam wrote: > >> From: Stéphane Marchesin <marc...@

Re: [PATCH 06/14] drm/cirrus: Use 32bpp by default

; 1280x1024x24 fits in 4MB, 1280x1024x32 doesn't. That seems 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

git pull] drm for v4.1-rc1

adowed 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

git pull] drm for v4.1-rc1

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

[PATCH 00/11] Enable gpu switching on the MacBook Pro

> 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

[PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed

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

[PATCH RFC 4/4] drm: link connectors to backlight devices

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

[PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices

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

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

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

[PATCH 11/11] apple_gmux: Wait for switch completion

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 --git

[PATCH 10/11] apple-gmux: Indicate that driver supports changing of GPU power states

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

[PATCH 09/11] apple-gmux: Assign apple_gmux_data before registering

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 changed, 6

[PATCH 08/11] apple-gmux: Add support for the switch_ddc callback

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/platform/x86

[PATCH 07/11] vga_switcheroo: Reprobe old device on switching

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

[PATCH 06/11] vga_switcheroo: Add enable() call to clients and permit deferral of dynamic PM

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

[PATCH 05/11] vga_switcheroo: Allow handlers to indicate that they can handle PM

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

[PATCH 04/11] vga_switcheroo: Allow stashing of panel data

that 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

[PATCH 03/11] vga_switcheroo: Add command line option

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

[PATCH 02/11] vga_switcheroo: Add support for reprobing connectors

to 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 dd1d587

[PATCH 01/11] vga_switcheroo: Add support for switching only the DDC

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()

Improve Apple GMUX support on switcheroo

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

[PATCH] [ACPI] Default to using the native backlight control on Windows 8 systems

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's at

Fixing the kernels backlight API

oo. 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

Fixing the kernels backlight API

that's where heuristics are probably going to be involved. -- Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH v3] ACPI / video: Add systems that should favor native backlight interface

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 f

[PATCH v3] ACPI / video: Add systems that should favor native backlight interface

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

[PATCH v3] ACPI / video: Add systems that should favor native backlight interface

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

[PATCH v5 0/4] Fix Win8 backlight issue

ll really prefer not to add such a list, because it almost inevitably means that we'll never fix this problem properly. -- Matthew Garrett

Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

= 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

Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

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

Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

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 ___ dri-devel mailing list dri-devel

Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

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

Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

never use the ACPI backlight set function. Of course, it would be nice to have that confirmed by Intel. -- Matthew Garrett matthew.garr...@nebula.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo

Backlight control only in the kernel?

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

Re: Backlight control only in the kernel?

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

[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

[Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

f (result) - return; name = kasprintf(GFP_KERNEL, "acpi_video%d", count); if (!name) return; -- Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

ly > 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

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

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 >

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

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. > > &

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

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 &g

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

variable and encourage distributions to flip their behaviour. -- Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

esses. 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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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 mailing list dri-devel

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

ed > 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

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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 A

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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 the vendor would fix it. I

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

. 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 ___ dri-devel mailing list dri-devel

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

mented 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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

, 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://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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/i915/i915_dma.c

[PATCH 2/3] ACPICA: Add interface for getting latest OS version requested via _OSI

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 ++ 3

[PATCH 1/3] acpi: video: add function to support unregister backlight interface

22 https://bugzilla.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 Si

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

drivers under Windows. -- Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH 2/3] ACPICA: Add interface for getting latest OS version requested via _OSI

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

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

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

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

[PATCH 1/3] acpi: video: add function to support unregister backlight interface

://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

[PATCH] drm/radeon: narrow scope of Apple re-POST hack

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

Re: [PATCH] drm/radeon: narrow scope of Apple re-POST hack

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 mj...@srcf.ucam.org Acked

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

;Do not rely upon 0 being visible". -- Matthew Garrett | mjg59 at srcf.ucam.org

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

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

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

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 reasonable for it >

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

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

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

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 reasonable for it to turn the backlight off entirely

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

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-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman

[PATCH] i915: Quirk out disconnected backlight

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

[PATCH] i915: Quirk out disconnected backlight

ype field. -- Matthew Garrett | mjg59 at srcf.ucam.org

Re: [PATCH] i915: Quirk out disconnected backlight

. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Quirk out disconnected backlight

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 and gmux_backlight devices get

Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size

-- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size

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

[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size

-- Matthew Garrett | mjg59 at srcf.ucam.org

Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size

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-devel

[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

the only special case I can see, and that one's a fairly easy workaround. -- Matthew Garrett | mjg59 at srcf.ucam.org

[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

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 experience > wit

[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

Won't this break the multiple cards with independent outputs case? -- Matthew Garrett | mjg59 at srcf.ucam.org

Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

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 experience with one such machine, which

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

ne know more about the acpi code? Not sure what you're asking here - acpi_get_table returns acpi_status, not a pointer. -- Matthew Garrett | mjg59 at srcf.ucam.org

Re: [PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

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

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

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 | mjg59 at srcf.ucam.org

  1   2   3   >