linux-kernel - Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 25 Oct 2015 17:58:45 +0100
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Darren Hart <dvhart@...radead.org>
Cc:	platform-driver-x86@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Petri Hodju <petrihodju@...oo.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME
 backlight control on Macbook Pro mid-2015 11,5

Hi Darren,

Looks like the Apple issue with backlight working on hidden Intel IGP
(doing IO on VGA addresses) while graphics are running on visible
discrete GPU (Radeon this time instead of usual nvidia).


I should have offered a solution quite some time ago but it seem time
was running very fast.
The best solution I can think of is denying any vga_arb on Apple EFI
systems (and not trying to choose the right one which is not possible
when one of both GPUs is hidden).


The lines of interest in dmesg are:
[    0.210225] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=none,locks=none
[    0.210227] vgaarb: loaded
[    0.210228] vgaarb: setting as boot device: PCI:0000:01:00.0
[    0.210229] vgaarb: bridge control possible 0000:01:00.0
[    0.385583] fb0: EFI VGA frame buffer device
[    7.738507] apple_gmux: Found gmux version 4.0.20 [indexed]
[    7.738514] apple_gmux: locked IO for PCI:0000:01:00.0
[    7.792805] fb: switching to radeondrmfb from EFI VGA

Not loading apple_gmux might or might not affect ability to control
backlight depending on what backlight devices go registered
(radeon backlight device probably does not affect screen, at best an
ACPI backlight device might work)

Interesting part to check is how things work when both GPU are visible
to OS.

Thanks,
Bruno

On Thu, 22 Oct 2015 11:36:52 Darren Hart wrote:
> Bruno, can you please have a look at the following regression attributed to:
> 
> 4eebd5a apple-gmux: lock iGP IO to protect from vgaarb changes
>  2015-03-18 (7 months ago), Bruno Prémont <bonbons@...ux-vserver.org>
> 
> 
> On Thu, Oct 15, 2015 at 04:47:13AM +0000, bugzilla-daemon@...zilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=105051
> > 
> > Felipe Ortiz <fortizc@...il.com> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |fortizc@...il.com
> > 
> > --- Comment #14 from Felipe Ortiz <fortizc@...il.com> ---
> > I can confirm the problem with 4eebd5a4e72697aac25a8a57d3f888a9d5f80370. I have
> > a MPB 11,5 with AMD/Intel graphics. I recompile the module (a previous version
> > of 4eebd5a4e72697aac25a8a57d3f888a9d5f80370) and brightness adjusts is working
> > again.
> > 
> > I see two problems: 
> > 
> > 1) If someone uses gpu-switch (https://github.com/0xbb/gpu-switch) with this
> > bug screen seem not work, after severals reboots (with different kernels) I can
> > access a terminal and execute gpu-switch -d and then screen seems work again.
> > 
> > 2) If you use a Intel card (swiched with gpu-switch) the OSD (activated with
> > functions keys) is so slow and chromium have the same problem (temporary fix is
> > deactivate chromium hw acceleration) is this a intel driver bug?
> > 
> > -- 
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> > 
> 
> Thanks,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/