Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

otonvm · 2015-04-28 20:13:30

New info:
http://askubuntu.com/questions/264247/p … 573#613573

hungerfish · 2015-04-28 21:33:39

New info:
http://askubuntu.com/questions/264247/p … 573#613573

If you read the last couple of posts you'll see that its the 'new info' that we've been discussing.
If you happen to have a macbook pro 7.1, please try out what has been posted in the link provided and report back what you find!

otonvm · 2015-04-28 21:39:59

hungerfish wrote:

New info:
http://askubuntu.com/questions/264247/p … 573#613573
If you read the last couple of posts you'll see that its the 'new info' that we've been discussing.
If you happen to have a macbook pro 7.1, please try out what has been posted in the link provided and report back what you find!

Ah sorry, I should have known

Probably tomorrow or the day after that I'll try to install to see what happens.

otonvm · 2015-05-01 08:45:36

Works perfectly!

Here is Ubuntu MATE, nvidia-340 which is the only "blob" that works.
I installed it straight to disk with no other tweaks. It booted into nouveau at first so it was easy to apply the grub settings described.
Now I'm going to try and fix backlight controls.

hungerfish · 2015-05-01 16:23:33

Great! Let us know of any progress!

otonvm · 2015-05-01 16:31:09

hungerfish wrote:

Great! Let us know of any progress!

I managed to get everything (and I mean everything) working with Kubuntu. In MATE screen backlight did not work.
Kubuntu installs all drivers, configures the touchpad in a fairly usable fashion and with a minor tweak backlight also works. So it basically makes this a very good linux laptop.
But... I dislike the new KDE and I don't have the time now to go in and tweak everything. I also don't have the time to install Arch

So for now I'll restore my clonezilla image of osx and maybe work on it again in a while.

hungerfish · 2015-05-01 17:15:34

So for now I'll restore my clonezilla image of osx and maybe work on it again in a while.

Before you do that, mind sharing the 'minor tweaks' you did to get the backlight controls working?

otonvm · 2015-05-01 17:18:46

hungerfish wrote:

So for now I'll restore my clonezilla image of osx and maybe work on it again in a while.
Before you do that, mind sharing the 'minor tweaks' you did to get the backlight controls working?

This:

sudo nano /usr/share/X11/xorg.conf.d/10-nvidia-brightness.conf

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 320M"
    Option         "RegistryDwords" "EnableBrightnessControl=1"
EndSection

hungerfish · 2015-05-01 18:57:35

Could you please provide the output for:

ls -l /sys/class/backlight
ls -l /sys/devices/virtual/backlight
lsmod
ls -l /etc/modprobe.d

I don't understand why the backlight controls don't work for me, ubuntu/kubuntu must be doing something different.

otonvm · 2015-05-01 19:02:17

hungerfish wrote:

Could you please provide the output for:
ls -l /sys/class/backlight
ls -l /sys/devices/virtual/backlight
lsmod
ls -l /etc/modprobe.d
I don't understand why the backlight controls don't work for me, ubuntu/kubuntu must be doing something different.

I can't anymore, sorry. But I remember that in MATE

ls -l /sys/class/backlight

was empty and lsmod had apple_bl among others but blacklisting didn't help. I also installed pommed that didn't help either.
I didn't look in Kubuntu because it worked.

fumfi · 2015-05-02 08:27:17

Hi otonvm

Did wifi work on your machine without the need to close and reopen the lid? Which drivers did you use, b43 or Broadcom STA (bcmwl-kernel-source)?

otonvm · 2015-05-02 09:11:14

fumfi wrote:

Hi otonvm
Did wifi work on your machine without the need to close and reopen the lid? Which drivers did you use, b43 or Broadcom STA (bcmwl-kernel-source)?

I think *buntu installs b43 drivers. But it was automatic so I didn't check. It worked immediately after the drivers were installed.

There was also another driver... Intel micro-something...

fumfi · 2015-05-02 09:20:08

hungerfish wrote:

I don't understand why the backlight controls don't work for me, ubuntu/kubuntu must be doing something different.

So I had a quick glance at the source code of the gsd-backlight-helper which (k)Ubuntu are obviously using for adjusting the display brightness. Looks like it is querying different sysfs places (firmware, platform, raw) for finding the best available brightness interface and then reads/writes from/to that sysfs interface. Also, there is no other method that the tool uses.

So I am making the following assumptions:

nvidia driver module registers a brightness-capable device somewhere in the sysfs tree but doesn't create a proper symlink in /sys/class/backlight
gsd-backlight-helper queries the sysfs using udev and finds that brightness interface based on its type attributes, regardless of the presence of the symlink. Hence, it can change the brightness on Ubuntu while other distros maybe fail because they require the presence of that symlink.

To be verified, e.g. by (could only give this an exemplary try on a Lenovo machine running Mint 17)

~ # find /sys | grep bright
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/brightness
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/max_brightness
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/actual_brightness
~ # ls -la /sys/class/backlight/
insgesamt 0
drwxr-xr-x  2 root root 0 Mai  2 11:07 .
drwxr-xr-x 55 root root 0 Mai  2 11:07 ..
lrwxrwxrwx  1 root root 0 Mai  2 11:07 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight

hungerfish · 2015-05-02 09:24:06

But it was automatic so I didn't check. It worked immediately after the drivers were installed.

So you went through the 'install additional drivers gui' and installed all that were available? If so, you would have been using the proprietary wifi-drivers afterwards.
The other driver is for updating the microcode on intel cpus. I read somewhere that ubuntu includes a new driver with the 15.04 release.

EDIT:

nvidia driver module registers a brightness-capable device somewhere in the sysfs tree but doesn't create a proper symlink in /sys/class/backlight

I've basically gone through the whole /sys tree and I'm 100% sure that this doesn't happen on my system when in efi mode.

I've determined that /sys/bus/acpi/devices/APP0002:00 is available in both efi and csm mode.
But there's a difference in /sys/bus/acpi/devices/APP0002:00/uevent:

DRIVER=Apple backlight
MODALIAS=acpi:APP0002:BACKLIGHT:

This is in csm-mode, when in efi mode, the 'DRIVER' line is missing hence (I guess) no actual binding to the apple_bl driver takes place. The question remains, why?

Last edited by hungerfish (2015-05-02 10:10:57)

fumfi · 2015-05-02 10:21:08

hungerfish wrote:

I've determined that /sys/bus/acpi/devices/APP0002:00 is available in both efi and csm mode.
But there's a difference in /sys/bus/acpi/devices/APP0002:00/uevent:
DRIVER=Apple backlight
MODALIAS=acpi:APP0002:BACKLIGHT:
This is in csm-mode, when in efi mode, the 'DRIVER' line is missing hence (I guess) no actual binding to the apple_bl driver takes place. The question remains, why?

Okay I'll compare it with the output on my machine tomorrow evening. In the meantime, can you tell whether kernel parameter "acpi_backlight=vendor" makes a difference? And what's the output of above mentioned find command?

hungerfish · 2015-05-02 11:33:05

Looking forward to that output
I've fiddled some more, and found that manually binding/unbinding the 'Apple backlight' driver also doesn't work.
So in csm-mod:

echo -n "APP0002:00" > /sys/bus/drivers/Apple\ backlight/unbind
echo -n "APP0002:00" > /sys/bus/drivers/Apple\ backlight/bind

work as expected. Once unbound, the /sys/class/backlight/apple_backlight link disappears and the backlight can no longer be controlled. Rebinding the driver restores functionality.
In efi-mode however, both unbinding and binding do not work,

no such device

is the error message.
For 'find /sys | grep bright', the diff between csm- and efi-mode

*csm-mode*
/sys/devices/virtual/backlight/apple_backlight/brightness
/sys/devices/virtual/backlight/apple_backlight/max_brightness
/sys/devices/virtual/backlight/apple_backlight/actual_brightness

The rest of the output concerning b43-phy0 and kbd-backlight is identical.

fumfi · 2015-05-03 21:28:36

Bad news is I have the same output on the sysfs tree as you have.

BUT: Eventually, I could deep dive into this issue and I think, after having studied the relevant parts of the GNOME power source code, I have found an explanation for Ubuntu being able to control backlight brightness without the sysfs backlight interface. Without going too far into details, it seems to be as simple as this... Ubuntu Unity and recent versions of GNOME fall back to using XRandR for backlight control if there is no backlight interface exposed on sysfs! I assume that by setting the RegistryDwords either way (kernel module parameter or xorg.conf Option), the Nvidia driver registers the appropriate XRandR backlight extension but KDE and other desktop environments don't make use of this... Try the following (after having enabled the Nvidia RegistryDwords before):

~$ xrandr --current --verbose | grep -i backlight
	Backlight: 90

Install the xbacklight tool (which manipulates backlight brightness using only XRandR API) from Arch repos and play a little with its -inc/-dec/-get/-set switches. If the brightness changes, you can verify that the new brightness is correctly reflected in the output of above xrandr command. Finally, you'll have to bind XF86MonBrightnessDown and XF86MonBrightnessUp keys using xmodmap or a GUI alternative to appropriate xbacklight calls.

Last edited by fumfi (2015-05-03 21:40:10)

hungerfish · 2015-05-04 09:29:20

I assume that by setting the RegistryDwords either way (kernel module parameter or xorg.conf Option), the Nvidia driver registers the appropriate XRandR backlight extension

You are correct. Using Xrandr I can control the backlight! Hurray!!!
I'd forgotten about 'that route' entirely...thanks for doing the digging!

However, I still don't understand why running Ubuntu gnome/unity falls back to this, and under Arch it does not. (I've tried with stock Gnome3). But at least we have a working solution!

Any more findings concerning the wifi-oddness ?

fumfi · 2015-05-04 14:05:04

hungerfish wrote:

However, I still don't understand why running Ubuntu gnome/unity falls back to this, and under Arch it does not. (I've tried with stock Gnome3). But at least we have a working solution!

Answer is simple: because of its implementation in gnome-settings-daemon/plugins/power/gpm-common.c. GNOME 3.16.1 explicitly #undefs the usage of XBacklight API and instead tries to call its polkit helpers using sysfs/udev:

gboolean
backlight_set_percentage (GnomeRRScreen *rr_screen,
                          gint *value,
                          GError **error)
{
        gboolean ret = FALSE;
        gint max;
        guint discrete;
#ifndef __linux__
        GnomeRROutput *output;
        output = get_primary_output (rr_screen);
        if (output != NULL) {
                if (!gnome_rr_output_set_backlight (output, *value, error))
                        return ret;
                *value = gnome_rr_output_get_backlight (output);
                ret = TRUE;
        }
        return ret;
#else
        max = backlight_helper_get_value ("get-max-brightness", error);
        if (max < 0)
                return ret;
        discrete = PERCENTAGE_TO_ABS (0, max, *value);
        ret = backlight_helper_set_value ("set-brightness",
                                          discrete,
                                          error);
        if (ret)
                *value = ABS_TO_PERCENTAGE (0, max, discrete);

        return ret;
#endif
}

The same function in Unity (forked from GNOME) prefers XBacklight over the sysfs helpers:

gboolean
backlight_set_percentage (GsdRRScreen *rr_screen,
                          guint value,
                          GError **error)
{
        GsdRROutput *output;
        gboolean ret = FALSE;
        gint min = 0;
        gint max;
        guint discrete;

        /* prefer xbacklight */
        output = get_primary_output (rr_screen);
        if (output != NULL) {
                min = gsd_rr_output_get_backlight_min (output);
                max = gsd_rr_output_get_backlight_max (output);
                if (min < 0 || max < 0) {
                        g_warning ("no xrandr backlight capability");
                        return ret;
                }
                discrete = PERCENTAGE_TO_ABS (min, max, value);
                ret = gsd_rr_output_set_backlight (output,
                                                     discrete,
                                                     error);
                return ret;
        }

        /* fall back to the polkit helper */
        max = backlight_helper_get_value ("get-max-brightness", error);
        if (max < 0)
                return ret;
        discrete = PERCENTAGE_TO_ABS (min, max, value);
        ret = backlight_helper_set_value ("set-brightness",
                                          discrete,
                                          error);

        return ret;
}

Needless to say that there are also laptops that have a buggy RandR backlight implementation where Unity might fail using above outlined approach...

Any more findings concerning the wifi-oddness ?

Actually, while experimenting with softdep's (man modprobe.d) between nvidia and efifb kernel module, in order to get the tty console stable, I encountered one situation where wifi was working without having to suspend. Doesn't seem to have any causal relation at all but I suspect there is a timing issue upon initialization of the wl module and its dependencies (cfg80211 maybe). I'll give that a few more tries. Other proposed solutions involving kernel parameter intremap=off or trying different acpi_osi variants did not make a difference.

hungerfish · 2015-05-04 15:09:13

Oh, ok, I didn't realize that they actually differ on this kind of level(gnome3/unity fork). I wonder about their rational behind the change, if they have statistics or the like, or just in general how common non-working backlight controls via sysfs are these days. I was under the assumption of this problem being quite 'esoteric' seeing that we're a) using the nvidia blob and b) using it in a non-supported(by nvidia) way and c) using a mac

Also, keep up the good work It would be great to get this machine fully working in efimode!

Last edited by hungerfish (2015-05-04 15:10:31)

fumfi · 2015-05-05 09:56:29

hungerfish wrote:

Oh, ok, I didn't realize that they actually differ on this kind of level(gnome3/unity fork). I wonder about their rational behind the change, if they have statistics or the like, or just in general how common non-working backlight controls via sysfs are these days.

This change has only been introduced very recently in order to unify the Wayland and X11 code bases of GNOME: https://mail.gnome.org/archives/commits … 05027.html
Obviously the reviewers do not own a Macbook or if they do, then just boot in csm mode.

hungerfish · 2015-05-05 13:57:11

Oh so it's a regression, oh well...

BUT:
Please try and upgrade your kernel. I've only done some initial testing, but it seems that the upgrade to 4.0.1-1-ARCH solved the weirdness with the wifi in efi-mode.
Take a look at these change notes, there's been some changes!
You'll obviously need to switch back to the b43 driver, but for me wifi works right off the bat after boot!

fumfi · 2015-05-07 20:20:30

hungerfish wrote:

Please try and upgrade your kernel. I've only done some initial testing, but it seems that the upgrade to 4.0.1-1-ARCH solved the weirdness with the wifi in efi-mode.
Take a look at these change notes, there's been some changes!
You'll obviously need to switch back to the b43 driver, but for me wifi works right off the bat after boot!

Confirmed here as well. Using b43 driver on Kernel 4.0 from Ubuntu mainline kernel ppa, wireless works immediately after booting. Didn't get to test thoroughly (because Ubuntu's nvidia DKMS module doesn't compile with that kernel, hence no wm). But at least, 5 GHz also works more stable with that new b43 module which is a big difference to Ubuntu's current kernel 3.19. So there is still hope... Now waiting for a new LTS hardware stack or a backport of that module into current kernel. Or maybe give Arch a try?

Last edited by fumfi (2015-05-07 20:21:15)

hungerfish · 2015-05-08 10:36:31

Great news!
Maybe in 2015 we can finally use our 2010 hardware 'properly'!
Could you perhaps keep an eye on the mbp's temperatures while testing, maybe comparing between csm-mode/efi-mode?
While I never looked at the numbers, I subjectively 'feel' that it gets hotter more quickly in efi-mode while watching hd-youtube for example. This is running it at stock settings, which I guess means 'let the firmware decide when to rev up the exhaust', but I'm not sure as I've always 'felt' it to be slightly hotter with linux (nopun!) compared to using osx.

Or maybe give Arch a try?

I can only full heartedly recommend that you do so, Sir!

boterock · 2015-07-20 02:25:52

Hello, hope you are still here.

A little time ago (like a month) I started using arch with gnome, after using ubuntu (and hating unity) for like 3 months.
I thought trying arch would be a great way to learn about arch (and it surely has been).

Your guide (hungerfish and fumfi) has been a great help and I also have my macbook with arch with nvidia drivers. Thank you very much for that
The only issue I have left is the wireless, requiring to close and open the lid to work.

I think this also has others issues behind, because the wireless is very unstable, today I was trying to get steam home streaming to work, and even setting it in the lowest bitrate did not work, jumping between 3mbit and 200kbit every 20 seconds or so..

you say that the 4.0.1-ARCH kernel seems to work, but I have 4.1.2-2-ARCH and it does not work. I don't know what could be happening.

I installed the b43 driver following the instructions here https://wiki.archlinux.org/index.php/Broadcom_wireless, installing AUR: b43-firmware, is that the one you are using too?
I don't know what else it could be, any help would be appreciated.

Thank you again for your help

Arch Linux

#51 2015-04-28 20:13:30

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#52 2015-04-28 21:33:39

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#53 2015-04-28 21:39:59

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#54 2015-05-01 08:45:36

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#55 2015-05-01 16:23:33

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#56 2015-05-01 16:31:09

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#57 2015-05-01 17:15:34

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#58 2015-05-01 17:18:46

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#59 2015-05-01 18:57:35

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#60 2015-05-01 19:02:17

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#61 2015-05-02 08:27:17

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#62 2015-05-02 09:11:14

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#63 2015-05-02 09:20:08

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#64 2015-05-02 09:24:06

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#65 2015-05-02 10:21:08

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#66 2015-05-02 11:33:05

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#67 2015-05-03 21:28:36

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#68 2015-05-04 09:29:20

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#69 2015-05-04 14:05:04

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#70 2015-05-04 15:09:13

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#71 2015-05-05 09:56:29

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#72 2015-05-05 13:57:11

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#73 2015-05-07 20:20:30

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#74 2015-05-08 10:36:31

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#75 2015-07-20 02:25:52

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

Board footer