in terms of some modes not being
available on battery, I'd prefer to leave the ac/battery decision up to
userspace. Having it be default behaviour at the kernel level is
plausibly confusing.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing
On Mon, May 24, 2010 at 06:53:51AM -0700, Randy Dunlap wrote:
On 05/24/10 05:56, Matthew Garrett wrote:
Won't this result in a behavioural difference? The desirable outcome is
It could, yes.
that that configuration be impossible, not for that configuration to
build but be buggy
, evergreen_hwmon_attrgroup);
They should be under the hwmon device.
--
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
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 m...@redhat.com
Cc: intel-gfx intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm
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
-by: Matthew Garrett m...@redhat.com
Cc: dri-devel@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, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
On Fri, 19 Nov 2010 10:53:52 -0500
Matthew Garrett m...@redhat.com wrote:
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
and platform interfaces, so you'll fall back to the raw
interface if it can provide support for your connector (presumably via
ddcci, although we don't have this implemented yet)
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel
hardware working,
upstream-suitable or otherwise, then there's not much point in worrying
about it.
--
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 m...@redhat.com
Cc: intel-gfx intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm
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
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 | 24
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-devel@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
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
___
dri-devel mailing list
dri-devel
fixup patches for any I see.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Well, that's odd. I'll look into it this week.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
);
+ }
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Sun, Feb 06, 2011 at 11:41:19PM +0100, Rafael J. Wysocki wrote:
On Sunday, February 06, 2011, Matthew Garrett wrote:
Ugh. Ok, how can we fix this?
Not nicely, I'm afraid.
One possible way is to use device_pm_move_after() to rearrange the devices in
the PM core's suspend list
? It seems wrong to have acpi devices
resumed before the PCI device they're associated with.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ineligible for driver binding. In other words, it sounds like part
of the problem is that we have two drivers binding to what's really
a single piece of hardware.
Part of the problem is that ACPI video devices aren't inherently PCI
devices.
--
Matthew Garrett | mj...@srcf.ucam.org
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
___
dri-devel mailing list
dri
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
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote:
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
Opregion is one mechanism to provide VBT - it doesn't define it.
Then let me repeat that I haven't seen anything in the VBT tables of
the gma500-using netbook I
, with the modesetting code cribbed from cirrusfb (hence the
license).
Signed-off-by: Matthew Garrett m...@redhat.com
Cc: Matt Turner matts...@gmail.com
---
drivers/gpu/drm/Kconfig |8 +
drivers/gpu/drm/Makefile|1 +
drivers/gpu/drm/cirrus/Makefile |6
);
If you switch back from 16 does this not need clearing ?
Nope. qemu just looks at this to distinguish between 15 and 16 bit, and
I've no intention of supporting 15 bit...
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel
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's noticably nicer to use under virt
. Systems without a valid internal panel EDID will still use the BIOS
native mode.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon
the init scripts on Apples when we're using EFI.
Signed-off-by: Matthew Garrett m...@redhat.com
---
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
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
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 m...@redhat.com
---
drivers/gpu/drm/drm_irq.c |6 +++---
drivers/gpu/drm/drm_stub.c |8 +---
include/drm/drmP.h
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
case for radeon, it seems, but as far as I
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
certainly not entirely reliable
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
___
dri-devel mailing list
dri-devel@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
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
___
dri-devel mailing list
dri
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 m...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |4
drivers/gpu/drm/nouveau/nouveau_state.c
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 m...@redhat.com
---
drivers/bcma/main.c
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 m...@redhat.com
---
drivers/gpu/drm/nouveau
framebuffer state on nv50 and avoids graphical glitches appearing during
modesetting.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_reg.h |1 +
drivers/gpu/drm/nouveau/nouveau_state.c |2 ++
drivers/gpu/drm/nouveau/nv50_display.c | 30
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 mj...@srcf.ucam.org 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 does - i740 never did
On Wed, Apr 25, 2012 at 11:27:11AM +0100, Alan Cox wrote:
On Tue, 24 Apr 2012 23:30:22 +0100
Matthew Garrett mj...@srcf.ucam.org 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
understand
, 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.
--
Matthew Garrett | mj...@srcf.ucam.org
On Wed, Apr 25, 2012 at 01:49:40PM +0100, Alan Cox wrote:
On Wed, 25 Apr 2012 13:40:18 +0100
Matthew Garrett mj...@srcf.ucam.org 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 before
calling any
Acked-by: Matthew Garrett m...@redhat.com
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
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.
--
Matthew Garrett
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 current state of affairs is.
--
Matthew Garrett | mj
, 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
list.
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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-devel@lists.freedesktop.org
http://lists.freedesktop.org
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
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
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
--
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 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
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
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
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 mj...@srcf.ucam.org
Acked
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
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
://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
, 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
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
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
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 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
. 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
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
___
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 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
___
dri-devel mailing list
dri-devel
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
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
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
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
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
= 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
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
> 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
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
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
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
1 - 100 of 220 matches
Mail list logo
