https://wiki.archlinux.org/api.php?action=feedcontributions&user=Thelongdivider&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:07:30ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Qnix_QX2710&diff=513015Talk:Qnix QX27102018-03-08T14:31:29Z<p>Thelongdivider: Created page with "To the writer of this page, your link is dead. It would be really nice to have this edid file, as I still like/use this monitor but currently need to force it with a modeline..."</p>
<hr />
<div>To the writer of this page, your link is dead. It would be really nice to have this edid file, as I still like/use this monitor but currently need to force it with a modeline xorg configuration.</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=User_talk:Thelongdivider&diff=411342User talk:Thelongdivider2015-12-09T18:06:46Z<p>Thelongdivider: Created page with "Hi, The link to the specified EDID file does not exist. I have been having problems finding it across the internet as well..."</p>
<hr />
<div>Hi,<br />
<br />
The link to the specified EDID file does not exist. I have been having problems finding it across the internet as well...</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=MacBookPro7,1&diff=371037MacBookPro7,12015-04-24T21:58:31Z<p>Thelongdivider: /* Network */</p>
<hr />
<div>[[Category:Apple]]<br />
{{Related articles start}}<br />
{{Related|MacBook}}<br />
{{Related|MacBookPro7,1}}<br />
{{Related|MacBookPro8,1/8,2/8,3 (2011)}}<br />
{{Related|MacBookPro9,2 (Mid-2012)}}<br />
{{Related articles end}}<br />
{{Poor writing|}}<br />
<br />
== Installation ==<br />
To install an x86_64 system, follow the [[MacBook]] EFI installation instructions.<br />
It is recommended to read the [[Unified Extensible Firmware Interface|UEFI]], [[GUID Partition Table|GPT]] and [[UEFI Bootloaders]] pages before trying any of this on your machine.<br />
Also of note, [https://gist.github.com/Apsu/4108795 GIST].<br />
<br />
See notes on '''video support''' before attempting installation!<br />
<br />
''The following assumes that you have somehow managed to install archlinux to a single partition on your drive, and that you still have your osx installation on a different partition.''<br />
=== Dual Boot ===<br />
If you want to dualboot osx and linux, the easiest way to do so is to use [[rEFInd]].<br />
rEFInd is a updated and maintained fork of [http://refit.sourceforge.net/ rEFIt] and should be used in its place.<br />
<br />
I've found it easiest to install rEFInd from osx. Depending on your setup, you'll either install it to your osx partition, or to the ESP partition (install.sh --esp). See [http://www.rodsbooks.com/refind/installing.html#installsh here] for instructions.<br />
Installing to the ESP partition can cause some '''startup delay''', which can be overcome by simply renaming rEFInd's installation folder to "BOOT" and the executable to "bootx64.efi"[http://www.rodsbooks.com/refind/installing.html#sluggish]<br />
<br />
Assuming that rEFInd was installed to the ESP, I've found it convenient to later mount the ESP as my "/boot" directory.<br />
That way, by setting<br />
scan_all_linux_kernels<br />
in your refind.conf, rEFInd will automatically pickup the kernel. All you need to add is a "refind_linux.conf" file to the root of the ESP, containing your boot args. I use:<br />
"Boot with defaults" "root=/dev/sda3 rootfstype=xfs ro add_efi_memmap"<br />
Note that my root partion is sda3 and that I use the xfs filesystem on it, yours may differ!<br />
So my ESP partition looks like this when mounted under "/boot":<br />
EFI/<br />
APPLE/<br />
BOOT/<br />
bootx64.efi<br />
drivers/<br />
icons/<br />
keys/<br />
refind.conf<br />
initramfs-linux-fallback.img<br />
initramfs-linux.img<br />
refind_linux.conf<br />
syslinux/ *** My bootloader of choice, see below ***<br />
vmlinuz-linux<br />
Note that the EFI/BOOT directory is normally named EFI/REFIND and that the bootx64.efi is normally named refind_x64.efi.<br />
==== EFI-Mode ====<br />
You should now be able to boot your mac in efi-mode via the kernel's efistub feature. rEFInd should present you with an option to do so.<br />
See [http://www.rodsbooks.com/refind/linux.html here] for more general information on the topic.<br />
This however has some drawbacks, as mentioned in the '''Video''' section below. <br />
==== CSM-Mode ====<br />
Booting your mac in csm- or legacy-mode provides a solution. To do so, we need a '''hybrid mbr''', with at least one 'active/bootable' partition. See [http://www.rodsbooks.com/gdisk/hybrid.html here] for more general information on how to setup a hybrid mbr.<br />
Simply boot in '''efi-mode''', then assuming you have three partitions, the ESP partition, an osx and a linux partition you'll need to use gdisk to set things up.<br />
gdisk /dev/sda<br />
Press 'p' to print your partition table, which should look somewhat like mine:<br />
Number Start (sector) End (sector) Size Code Name<br />
1 40 409639 200.0 MiB 0700 EFI System Partition<br />
2 409640 393186215 187.3 GiB AF00 OSX<br />
3 393186216 625142414 110.6 GiB 8300 Linux filesystem<br />
Press 'r' to enter recovery and transformation mode.<br />
<br />
Now press 'o' to print your mbr. It should only list a single partition covering the entire disk. Or depending on with which tools you used to partition your disk maybe some other entries.<br />
<br />
Press 'h' to create a new hybrid mbr. You'll be prompted for some input:<br />
Type from one to three GPT partition numbers, separated by spaces, to be<br />
added to the hybrid MBR, in sequence:<br />
I chose to mirror my gpt, so I entered '1 2 3', but it should be enough to just use one partition here. In my example, this would need to be the ESP partition, so '1', but in case you don't want to use the ESP to store your kernels, this could also be the linux partition, so '3'. You decide :) <br />
<br />
Another and maybe more secure way to mirror the gpt is only to enter '1' for the first and only partition, the EFI or boot partition. This prevents the strange behaviour of MacOS. It can happen that MacOS or its bootsystem can't find his partition and will end up in a rather long loop. Then proceed as written below.<br />
<br />
Make sure to say 'Yes' to the next promt:<br />
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): y<br />
Then set at least one partition as active/bootable:<br />
Creating entry for GPT partition #1 (MBR partition #2)<br />
Enter an MBR hex code (default 07): <br />
Set the bootable flag? (Y/N): y<br />
Note the MBR hex code depends on the partition type, press 'l' in gdisk's main menu to list them.<br />
<br />
Press 'o' ('''make sure you're still in the recovery menu!!!''') again to see your new hybrid mbr, in my case:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0x07<br />
3 409640 393186215 primary 0xAF<br />
4 393186216 625142414 primary 0x83<br />
<br />
Or if you choose to only mirror the first one, it can also look like this:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0xEF<br />
<br />
Even if the mbr table looks like this (''note that in the second table only the last two lines are missing''), the bootloader will know what to boot.<br />
You can compare start and end sectors between the two tables if you wish.<br />
<br />
Press 'w' to write the table to disk and reboot.<br />
=== Bootloader ===<br />
The next important thing is the bootloader, which acts as the bridge from refind to your kernel.<br />
Based on the Mode you use to install arch, either '''EFI''' or '''CSM''', you can choose a bootloader of your choice.<br />
But for now, We provide you with information about '''Syslinux''' and '''Gummiboot''', because these are the two we tested successfully for now.<br />
<br />
In both cases I assume that you managed to mount the EFI partition mentioned above to ''/boot/'' already.<br />
<br />
Grub is the one bootloader, which can handle both the EFI and the CSM mode. But because it's mighty, it also can be complex and the configuration are far-reaching. I recommending you, unless you want to configure the smallest detail in the bootloader for an '''un'''forgetting adventure during a booting, to use gummiboot (EFI-only) or syslinux (CSM-only), because both are really easy to setup.<br />
<br />
==== EFI-Mode ====<br />
If you do not need the power and its powersaving feature of the nvidia driver, then you should install [[gummiboot]] or [[Grub]], because these bootloaders are the one which actually works fine with EFI.<br />
<br />
Here, let's do it with gummiboot:<br />
# pacman -S gummiboot<br />
After installing the package, it needs to be configured, so run the installer of gummiboot:<br />
# gummiboot install<br />
<br />
Then you need to create a config file for gummiboot and add an entry for the arch booting. The '''sdaX''' means that you have to replace it with your root partition, in this case it may be '''/dev/sda3'''.<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
As usual, for more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
==== CSM-Mode or BIOS-compatibility ====<br />
Otherwise, if you don't want to miss out the advantages of the nvidia driver, I suggest you to install [[syslinux]] or also [[Grub]] for the CSM-Mode.<br />
We'll use syslinux because it's the simplest to setup, but others should also work. Install it via pacman, and then just execute<br />
syslinux-install_update -i -a -m<br />
It should detect your hybrid mbr and install itself automatically. Refer to [[Syslinux]] for more details.<br />
<br />
Make sure to configure the bootloader's menu entries correctly: (syslinux)<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
APPEND root=/dev/sda3 ro vga=865<br />
INITRD ../initramfs-linux.img<br />
Note that 'sda3' refers to the '''gpt mapping''', 'vga=865' means 1280x800 framebuffer resolution, nicer when using the nvidia driver.<br />
<br />
===== Can't find root device =====<br />
If booting fails, first try to use the initramfs-linux-fallback.img, as it includes more modules than your 'auto-detected' initramfs, and should allow the kernel to actually find your root partition.<br />
You'll then need to rebuild your regular initramfs. Rebuild it with<br />
mkinitcpio -p linux<br />
If you're lucky, the whole booting process with the regular initramfs-linux will end up successfully, if not, then try to add the following configuration and rebuild the initramfs again.<br />
I needed to include modules in the initramfs file. In /etc/mkinitcpio.conf:<br />
MODULES="ata_generic libata xfs"<br />
Note, that you'll only need xfs if your root partition is actually formatted with it, exchange it with the appropriate module for the file-system you use.<br />
<br />
<br />
Once you reboot, rEFInd should now present you with three options, two linux entries and one for osx. One linux entry will boot the kernel via efistub in '''efi-mode''', the other will call syslinux(or your chosen bootloader) which then should boot the system in '''csm-mode'''. Do the latter from now on!<br />
<br />
The easiest way to see if you were successful, is to install the [[Nvidia]] driver and start X.<br />
<br />
== Network ==<br />
[[Wireless_Setup|Wireless Setup]] provides instructions on how to identify your card, but if your MacBook Pro 7,1 is like mine then you'll head to [[Broadcom_wireless|Broadcom Wireless]] and use this command.<br />
<br />
$ lspci -vnn -d 14e4:<br />
<br />
If from this you discover that your full PCI-ID is {{ic|[14e4:432b]}}, then the following advice applies to you: Don't waste time on the {{ic|b43}} driver. I've been fiddling with it for weeks, and switching to {{ic|broadcom-wl}} made all the problems go away. {{ic|broadcom-wl}} might make your device names funky, but that's easily fixed with the udev rule documented on [[Broadcom_wireless|Broadcom Wireless]].<br />
<br />
I also recommend {{ic|netctl}}.<br />
<br />
<br />
{{Note| Alternative solution for using b43:<br />
As of kernel version 3.17.1-2, Broadcom Wireless driver most likely won't work (ERROR @wl_cfg80211_scan :WLC_SCAN error (-22)). The only option seems to be loading the b43 driver in [http://en.wikipedia.org/wiki/Programmed_input/output PIO] mode. To enable PIO mode, install driver by following the guide at [http://wireless.kernel.org/en/users/Drivers/b43 wireless.kernel.org], then load the b43 kernel module with <nowiki>pio=1 and qos=0</nowiki> parameters. To make this happen at boot, create {{ic|b43-firmware.conf}} file in {{ic|/etc/modprobe.d/}} and add the following lines:<br />
<br />
{{hc|b43-firmware.conf|<br />
<nowiki>options b43 pio=1 qos=0</nowiki><br />
<br />
blacklist wl<br />
blacklist brcmsmac<br />
blacklist brcmfmac<br />
blacklist b43legacy<br />
blacklist bcm43xx<br />
blacklist brcm80211<br />
}} <br />
<del>Although using PIO should be much slower than using [http://en.wikipedia.org/wiki/Direct_memory_access DMA], I haven't noticed any performance drop.</del> Further testing showed repetitive occurrences of noticable performance drops. Mostly expressed as rapid decrease of transfer speed, sometimes even dropped connections. It also seems that b43 driver has issues operating at 5Ghz.<br />
<br />
Some later kernels are giving me more success (without PIO), but still some wifi drops have occurred.<br />
<br />
}}<br />
<br />
== Video ==<br />
According to the [http://wiki.debian.org/MacBookPro Debian Wiki] the MacBook Pro 7,1 has an [http://www.geforce.com/hardware/desktop-gpus/geforce-GT-320-OEM NVIDIA GeForce GT 320M] in it.<br />
=== Nouveau ===<br />
Works out of the box, performance however is not that great and your system will get quite ''hot'' when running nouveau.<br />
=== Nvidia === <br />
The drivers work, but so far only when booting the mac in csm- or legacy-mode.<br />
See [https://bbs.archlinux.org/viewtopic.php?id=162289 here] for some discussion on the topic.<br />
<br />
In short, booting in '''efi-mode''', will crash the nvidia module when X starts, resulting in a black screen, so in order to use nvidia's driver, you'll need to boot your machine in '''csm-mode'''.<br />
<br />
This can't be achieved directly, but depends on apple's firmware agreeing that your partition layout warrants this as presumably they implemented the feature to allow booting of windows xp/7, neither which can ordinarily boot off a gpt partitioned disk.<br />
<br />
<br />
'''To be continued..'''<br />
<br />
'''UPDATE''' as of 2015/04/24: someone (me ^^) has found a [http://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573 solution] for booting in UEFI mode while still being able to use the Nvidia drivers.</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=MacBookPro7,1&diff=359107MacBookPro7,12015-02-02T06:23:20Z<p>Thelongdivider: /* Network */</p>
<hr />
<div>[[Category:Apple]]<br />
{{Related articles start}}<br />
{{Related|MacBook}}<br />
{{Related|MacBookPro7,1}}<br />
{{Related|MacBookPro8,1/8,2/8,3 (2011)}}<br />
{{Related|MacBookPro9,2 (Mid-2012)}}<br />
{{Related articles end}}<br />
{{Poor writing|}}<br />
<br />
== Installation ==<br />
To install an x86_64 system, follow the [[MacBook]] EFI installation instructions.<br />
It is recommended to read the [[Unified Extensible Firmware Interface|UEFI]], [[GUID Partition Table|GPT]] and [[UEFI Bootloaders]] pages before trying any of this on your machine.<br />
Also of note, [https://gist.github.com/Apsu/4108795 GIST].<br />
<br />
See notes on '''video support''' before attempting installation!<br />
<br />
''The following assumes that you have somehow managed to install archlinux to a single partition on your drive, and that you still have your osx installation on a different partition.''<br />
=== Dual Boot ===<br />
If you want to dualboot osx and linux, the easiest way to do so is to use [[rEFInd]].<br />
rEFInd is a updated and maintained fork of [http://refit.sourceforge.net/ rEFIt] and should be used in its place.<br />
<br />
I've found it easiest to install rEFInd from osx. Depending on your setup, you'll either install it to your osx partition, or to the ESP partition (install.sh --esp). See [http://www.rodsbooks.com/refind/installing.html#installsh here] for instructions.<br />
Installing to the ESP partition can cause some '''startup delay''', which can be overcome by simply renaming rEFInd's installation folder to "BOOT" and the executable to "bootx64.efi"[http://www.rodsbooks.com/refind/installing.html#sluggish]<br />
<br />
Assuming that rEFInd was installed to the ESP, I've found it convenient to later mount the ESP as my "/boot" directory.<br />
That way, by setting<br />
scan_all_linux_kernels<br />
in your refind.conf, rEFInd will automatically pickup the kernel. All you need to add is a "refind_linux.conf" file to the root of the ESP, containing your boot args. I use:<br />
"Boot with defaults" "root=/dev/sda3 rootfstype=xfs ro add_efi_memmap"<br />
Note that my root partion is sda3 and that I use the xfs filesystem on it, yours may differ!<br />
So my ESP partition looks like this when mounted under "/boot":<br />
EFI/<br />
APPLE/<br />
BOOT/<br />
bootx64.efi<br />
drivers/<br />
icons/<br />
keys/<br />
refind.conf<br />
initramfs-linux-fallback.img<br />
initramfs-linux.img<br />
refind_linux.conf<br />
syslinux/ *** My bootloader of choice, see below ***<br />
vmlinuz-linux<br />
Note that the EFI/BOOT directory is normally named EFI/REFIND and that the bootx64.efi is normally named refind_x64.efi.<br />
==== EFI-Mode ====<br />
You should now be able to boot your mac in efi-mode via the kernel's efistub feature. rEFInd should present you with an option to do so.<br />
See [http://www.rodsbooks.com/refind/linux.html here] for more general information on the topic.<br />
This however has some drawbacks, as mentioned in the '''Video''' section below. <br />
==== CSM-Mode ====<br />
Booting your mac in csm- or legacy-mode provides a solution. To do so, we need a '''hybrid mbr''', with at least one 'active/bootable' partition. See [http://www.rodsbooks.com/gdisk/hybrid.html here] for more general information on how to setup a hybrid mbr.<br />
Simply boot in '''efi-mode''', then assuming you have three partitions, the ESP partition, an osx and a linux partition you'll need to use gdisk to set things up.<br />
gdisk /dev/sda<br />
Press 'p' to print your partition table, which should look somewhat like mine:<br />
Number Start (sector) End (sector) Size Code Name<br />
1 40 409639 200.0 MiB 0700 EFI System Partition<br />
2 409640 393186215 187.3 GiB AF00 OSX<br />
3 393186216 625142414 110.6 GiB 8300 Linux filesystem<br />
Press 'r' to enter recovery and transformation mode.<br />
<br />
Now press 'o' to print your mbr. It should only list a single partition covering the entire disk. Or depending on with which tools you used to partition your disk maybe some other entries.<br />
<br />
Press 'h' to create a new hybrid mbr. You'll be prompted for some input:<br />
Type from one to three GPT partition numbers, separated by spaces, to be<br />
added to the hybrid MBR, in sequence:<br />
I chose to mirror my gpt, so I entered '1 2 3', but it should be enough to just use one partition here. In my example, this would need to be the ESP partition, so '1', but in case you don't want to use the ESP to store your kernels, this could also be the linux partition, so '3'. You decide :) <br />
<br />
Another and maybe more secure way to mirror the gpt is only to enter '1' for the first and only partition, the EFI or boot partition. This prevents the strange behaviour of MacOS. It can happen that MacOS or its bootsystem can't find his partition and will end up in a rather long loop. Then proceed as written below.<br />
<br />
Make sure to say 'Yes' to the next promt:<br />
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): y<br />
Then set at least one partition as active/bootable:<br />
Creating entry for GPT partition #1 (MBR partition #2)<br />
Enter an MBR hex code (default 07): <br />
Set the bootable flag? (Y/N): y<br />
Note the MBR hex code depends on the partition type, press 'l' in gdisk's main menu to list them.<br />
<br />
Press 'o' ('''make sure you're still in the recovery menu!!!''') again to see your new hybrid mbr, in my case:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0x07<br />
3 409640 393186215 primary 0xAF<br />
4 393186216 625142414 primary 0x83<br />
<br />
Or if you choose to only mirror the first one, it can also look like this:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0xEF<br />
<br />
Even if the mbr table looks like this (''note that in the second table only the last two lines are missing''), the bootloader will know what to boot.<br />
You can compare start and end sectors between the two tables if you wish.<br />
<br />
Press 'w' to write the table to disk and reboot.<br />
=== Bootloader ===<br />
The next important thing is the bootloader, which acts as the bridge from refind to your kernel.<br />
Based on the Mode you use to install arch, either '''EFI''' or '''CSM''', you can choose a bootloader of your choice.<br />
But for now, We provide you with information about '''Syslinux''' and '''Gummiboot''', because these are the two we tested successfully for now.<br />
<br />
In both cases I assume that you managed to mount the EFI partition mentioned above to ''/boot/'' already.<br />
<br />
Grub is the one bootloader, which can handle both the EFI and the CSM mode. But because it's mighty, it also can be complex and the configuration are far-reaching. I recommending you, unless you want to configure the smallest detail in the bootloader for an '''un'''forgetting adventure during a booting, to use gummiboot (EFI-only) or syslinux (CSM-only), because both are really easy to setup.<br />
<br />
==== EFI-Mode ====<br />
If you do not need the power and its powersaving feature of the nvidia driver, then you should install [[gummiboot]] or [[Grub]], because these bootloaders are the one which actually works fine with EFI.<br />
<br />
Here, let's do it with gummiboot:<br />
# pacman -S gummiboot<br />
After installing the package, it needs to be configured, so run the installer of gummiboot:<br />
# gummiboot install<br />
<br />
Then you need to create a config file for gummiboot and add an entry for the arch booting. The '''sdaX''' means that you have to replace it with your root partition, in this case it may be '''/dev/sda3'''.<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
As usual, for more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
==== CSM-Mode or BIOS-compatibility ====<br />
Otherwise, if you don't want to miss out the advantages of the nvidia driver, I suggest you to install [[syslinux]] or also [[Grub]] for the CSM-Mode.<br />
We'll use syslinux because it's the simplest to setup, but others should also work. Install it via pacman, and then just execute<br />
syslinux-install_update -i -a -m<br />
It should detect your hybrid mbr and install itself automatically. Refer to [[Syslinux]] for more details.<br />
<br />
Make sure to configure the bootloader's menu entries correctly: (syslinux)<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
APPEND root=/dev/sda3 ro vga=865<br />
INITRD ../initramfs-linux.img<br />
Note that 'sda3' refers to the '''gpt mapping''', 'vga=865' means 1280x800 framebuffer resolution, nicer when using the nvidia driver.<br />
<br />
===== Can't find root device =====<br />
If booting fails, first try to use the initramfs-linux-fallback.img, as it includes more modules than your 'auto-detected' initramfs, and should allow the kernel to actually find your root partition.<br />
You'll then need to rebuild your regular initramfs. Rebuild it with<br />
mkinitcpio -p linux<br />
If you're lucky, the whole booting process with the regular initramfs-linux will end up successfully, if not, then try to add the following configuration and rebuild the initramfs again.<br />
I needed to include modules in the initramfs file. In /etc/mkinitcpio.conf:<br />
MODULES="ata_generic libata xfs"<br />
Note, that you'll only need xfs if your root partition is actually formatted with it, exchange it with the appropriate module for the file-system you use.<br />
<br />
<br />
Once you reboot, rEFInd should now present you with three options, two linux entries and one for osx. One linux entry will boot the kernel via efistub in '''efi-mode''', the other will call syslinux(or your chosen bootloader) which then should boot the system in '''csm-mode'''. Do the latter from now on!<br />
<br />
The easiest way to see if you were successful, is to install the [[Nvidia]] driver and start X.<br />
<br />
== Network ==<br />
[[Wireless_Setup|Wireless Setup]] provides instructions on how to identify your card, but if your MacBook Pro 7,1 is like mine then you'll head to [[Broadcom_wireless|Broadcom Wireless]] and use this command.<br />
<br />
$ lspci -vnn -d 14e4:<br />
<br />
If from this you discover that your full PCI-ID is {{ic|[14e4:432b]}}, then the following advice applies to you: Don't waste time on the {{ic|b43}} driver. I've been fiddling with it for weeks, and switching to {{ic|broadcom-wl}} made all the problems go away. {{ic|broadcom-wl}} might make your device names funky, but that's easily fixed with the udev rule documented on [[Broadcom_wireless|Broadcom Wireless]].<br />
<br />
I also recommend {{ic|netctl}}.<br />
<br />
<br />
{{Note| Alternative solution for using b43:<br />
As of kernel version 3.17.1-2, Broadcom Wireless driver most likely won't work (ERROR @wl_cfg80211_scan :WLC_SCAN error (-22)). The only option seems to be loading the b43 driver in [http://en.wikipedia.org/wiki/Programmed_input/output PIO] mode. To enable PIO mode, install driver by following the guide at [http://wireless.kernel.org/en/users/Drivers/b43 wireless.kernel.org], then load the b43 kernel module with <nowiki>pio=1 and qos=0</nowiki> parameters. To make this happen at boot, create {{ic|b43-firmware.conf}} file in {{ic|/etc/modprobe.d/}} and add the following lines:<br />
<br />
{{hc|b43-firmware.conf|<br />
<nowiki>options b43 pio=1 qos=0</nowiki><br />
<br />
blacklist wl<br />
blacklist brcmsmac<br />
blacklist brcmfmac<br />
blacklist b43legacy<br />
blacklist bcm43xx<br />
blacklist brcm80211<br />
}} <br />
<del>Although using PIO should be much slower than using [http://en.wikipedia.org/wiki/Direct_memory_access DMA], I haven't noticed any performance drop.</del> Further testing showed repetitive occurrences of noticable performance drops. Mostly expressed as rapid decrease of transfer speed, sometimes even dropped connections. It also seems that b43 driver has issues operating at 5Ghz.<br />
<br />
Further testing has proven that with linux-mainline-rc6 (other versions not tested) b43 works not in PIO mode! This prevents the connection drops and dramatic slow downs mentioned above. Use the same /etc/modeprobe.d/b43-firmware.conf above except you should comment out (or remove) the first line:<br />
<br />
{{hc|b43-firmware.conf|<br />
<nowiki>#options b43 pio=1 qos=0</nowiki><br />
}} <br />
}}<br />
<br />
== Video ==<br />
According to the [http://wiki.debian.org/MacBookPro Debian Wiki] the MacBook Pro 7,1 has an [http://www.geforce.com/hardware/desktop-gpus/geforce-GT-320-OEM NVIDIA GeForce GT 320M] in it.<br />
=== Nouveau ===<br />
Works out of the box, performance however is not that great and your system will get quite ''hot'' when running nouveau.<br />
=== Nvidia === <br />
The drivers work, but so far only when booting the mac in csm- or legacy-mode.<br />
See [https://bbs.archlinux.org/viewtopic.php?id=162289 here] for some discussion on the topic.<br />
<br />
In short, booting in '''efi-mode''', will crash the nvidia module when X starts, resulting in a black screen, so in order to use nvidia's driver, you'll need to boot your machine in '''csm-mode'''.<br />
<br />
This can't be achieved directly, but depends on apple's firmware agreeing that your partition layout warrants this as presumably they implemented the feature to allow booting of windows xp/7, neither which can ordinarily boot off a gpt partitioned disk.<br />
<br />
<br />
'''To be continued..'''</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=MacBookPro7,1&diff=359105MacBookPro7,12015-02-02T06:20:48Z<p>Thelongdivider: /* Network */</p>
<hr />
<div>[[Category:Apple]]<br />
{{Related articles start}}<br />
{{Related|MacBook}}<br />
{{Related|MacBookPro7,1}}<br />
{{Related|MacBookPro8,1/8,2/8,3 (2011)}}<br />
{{Related|MacBookPro9,2 (Mid-2012)}}<br />
{{Related articles end}}<br />
{{Poor writing|}}<br />
<br />
== Installation ==<br />
To install an x86_64 system, follow the [[MacBook]] EFI installation instructions.<br />
It is recommended to read the [[Unified Extensible Firmware Interface|UEFI]], [[GUID Partition Table|GPT]] and [[UEFI Bootloaders]] pages before trying any of this on your machine.<br />
Also of note, [https://gist.github.com/Apsu/4108795 GIST].<br />
<br />
See notes on '''video support''' before attempting installation!<br />
<br />
''The following assumes that you have somehow managed to install archlinux to a single partition on your drive, and that you still have your osx installation on a different partition.''<br />
=== Dual Boot ===<br />
If you want to dualboot osx and linux, the easiest way to do so is to use [[rEFInd]].<br />
rEFInd is a updated and maintained fork of [http://refit.sourceforge.net/ rEFIt] and should be used in its place.<br />
<br />
I've found it easiest to install rEFInd from osx. Depending on your setup, you'll either install it to your osx partition, or to the ESP partition (install.sh --esp). See [http://www.rodsbooks.com/refind/installing.html#installsh here] for instructions.<br />
Installing to the ESP partition can cause some '''startup delay''', which can be overcome by simply renaming rEFInd's installation folder to "BOOT" and the executable to "bootx64.efi"[http://www.rodsbooks.com/refind/installing.html#sluggish]<br />
<br />
Assuming that rEFInd was installed to the ESP, I've found it convenient to later mount the ESP as my "/boot" directory.<br />
That way, by setting<br />
scan_all_linux_kernels<br />
in your refind.conf, rEFInd will automatically pickup the kernel. All you need to add is a "refind_linux.conf" file to the root of the ESP, containing your boot args. I use:<br />
"Boot with defaults" "root=/dev/sda3 rootfstype=xfs ro add_efi_memmap"<br />
Note that my root partion is sda3 and that I use the xfs filesystem on it, yours may differ!<br />
So my ESP partition looks like this when mounted under "/boot":<br />
EFI/<br />
APPLE/<br />
BOOT/<br />
bootx64.efi<br />
drivers/<br />
icons/<br />
keys/<br />
refind.conf<br />
initramfs-linux-fallback.img<br />
initramfs-linux.img<br />
refind_linux.conf<br />
syslinux/ *** My bootloader of choice, see below ***<br />
vmlinuz-linux<br />
Note that the EFI/BOOT directory is normally named EFI/REFIND and that the bootx64.efi is normally named refind_x64.efi.<br />
==== EFI-Mode ====<br />
You should now be able to boot your mac in efi-mode via the kernel's efistub feature. rEFInd should present you with an option to do so.<br />
See [http://www.rodsbooks.com/refind/linux.html here] for more general information on the topic.<br />
This however has some drawbacks, as mentioned in the '''Video''' section below. <br />
==== CSM-Mode ====<br />
Booting your mac in csm- or legacy-mode provides a solution. To do so, we need a '''hybrid mbr''', with at least one 'active/bootable' partition. See [http://www.rodsbooks.com/gdisk/hybrid.html here] for more general information on how to setup a hybrid mbr.<br />
Simply boot in '''efi-mode''', then assuming you have three partitions, the ESP partition, an osx and a linux partition you'll need to use gdisk to set things up.<br />
gdisk /dev/sda<br />
Press 'p' to print your partition table, which should look somewhat like mine:<br />
Number Start (sector) End (sector) Size Code Name<br />
1 40 409639 200.0 MiB 0700 EFI System Partition<br />
2 409640 393186215 187.3 GiB AF00 OSX<br />
3 393186216 625142414 110.6 GiB 8300 Linux filesystem<br />
Press 'r' to enter recovery and transformation mode.<br />
<br />
Now press 'o' to print your mbr. It should only list a single partition covering the entire disk. Or depending on with which tools you used to partition your disk maybe some other entries.<br />
<br />
Press 'h' to create a new hybrid mbr. You'll be prompted for some input:<br />
Type from one to three GPT partition numbers, separated by spaces, to be<br />
added to the hybrid MBR, in sequence:<br />
I chose to mirror my gpt, so I entered '1 2 3', but it should be enough to just use one partition here. In my example, this would need to be the ESP partition, so '1', but in case you don't want to use the ESP to store your kernels, this could also be the linux partition, so '3'. You decide :) <br />
<br />
Another and maybe more secure way to mirror the gpt is only to enter '1' for the first and only partition, the EFI or boot partition. This prevents the strange behaviour of MacOS. It can happen that MacOS or its bootsystem can't find his partition and will end up in a rather long loop. Then proceed as written below.<br />
<br />
Make sure to say 'Yes' to the next promt:<br />
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): y<br />
Then set at least one partition as active/bootable:<br />
Creating entry for GPT partition #1 (MBR partition #2)<br />
Enter an MBR hex code (default 07): <br />
Set the bootable flag? (Y/N): y<br />
Note the MBR hex code depends on the partition type, press 'l' in gdisk's main menu to list them.<br />
<br />
Press 'o' ('''make sure you're still in the recovery menu!!!''') again to see your new hybrid mbr, in my case:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0x07<br />
3 409640 393186215 primary 0xAF<br />
4 393186216 625142414 primary 0x83<br />
<br />
Or if you choose to only mirror the first one, it can also look like this:<br />
Number Boot Start Sector End Sector Status Code<br />
1 1 39 primary 0xEE<br />
2 * 40 409639 primary 0xEF<br />
<br />
Even if the mbr table looks like this (''note that in the second table only the last two lines are missing''), the bootloader will know what to boot.<br />
You can compare start and end sectors between the two tables if you wish.<br />
<br />
Press 'w' to write the table to disk and reboot.<br />
=== Bootloader ===<br />
The next important thing is the bootloader, which acts as the bridge from refind to your kernel.<br />
Based on the Mode you use to install arch, either '''EFI''' or '''CSM''', you can choose a bootloader of your choice.<br />
But for now, We provide you with information about '''Syslinux''' and '''Gummiboot''', because these are the two we tested successfully for now.<br />
<br />
In both cases I assume that you managed to mount the EFI partition mentioned above to ''/boot/'' already.<br />
<br />
Grub is the one bootloader, which can handle both the EFI and the CSM mode. But because it's mighty, it also can be complex and the configuration are far-reaching. I recommending you, unless you want to configure the smallest detail in the bootloader for an '''un'''forgetting adventure during a booting, to use gummiboot (EFI-only) or syslinux (CSM-only), because both are really easy to setup.<br />
<br />
==== EFI-Mode ====<br />
If you do not need the power and its powersaving feature of the nvidia driver, then you should install [[gummiboot]] or [[Grub]], because these bootloaders are the one which actually works fine with EFI.<br />
<br />
Here, let's do it with gummiboot:<br />
# pacman -S gummiboot<br />
After installing the package, it needs to be configured, so run the installer of gummiboot:<br />
# gummiboot install<br />
<br />
Then you need to create a config file for gummiboot and add an entry for the arch booting. The '''sdaX''' means that you have to replace it with your root partition, in this case it may be '''/dev/sda3'''.<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
As usual, for more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
==== CSM-Mode or BIOS-compatibility ====<br />
Otherwise, if you don't want to miss out the advantages of the nvidia driver, I suggest you to install [[syslinux]] or also [[Grub]] for the CSM-Mode.<br />
We'll use syslinux because it's the simplest to setup, but others should also work. Install it via pacman, and then just execute<br />
syslinux-install_update -i -a -m<br />
It should detect your hybrid mbr and install itself automatically. Refer to [[Syslinux]] for more details.<br />
<br />
Make sure to configure the bootloader's menu entries correctly: (syslinux)<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
APPEND root=/dev/sda3 ro vga=865<br />
INITRD ../initramfs-linux.img<br />
Note that 'sda3' refers to the '''gpt mapping''', 'vga=865' means 1280x800 framebuffer resolution, nicer when using the nvidia driver.<br />
<br />
===== Can't find root device =====<br />
If booting fails, first try to use the initramfs-linux-fallback.img, as it includes more modules than your 'auto-detected' initramfs, and should allow the kernel to actually find your root partition.<br />
You'll then need to rebuild your regular initramfs. Rebuild it with<br />
mkinitcpio -p linux<br />
If you're lucky, the whole booting process with the regular initramfs-linux will end up successfully, if not, then try to add the following configuration and rebuild the initramfs again.<br />
I needed to include modules in the initramfs file. In /etc/mkinitcpio.conf:<br />
MODULES="ata_generic libata xfs"<br />
Note, that you'll only need xfs if your root partition is actually formatted with it, exchange it with the appropriate module for the file-system you use.<br />
<br />
<br />
Once you reboot, rEFInd should now present you with three options, two linux entries and one for osx. One linux entry will boot the kernel via efistub in '''efi-mode''', the other will call syslinux(or your chosen bootloader) which then should boot the system in '''csm-mode'''. Do the latter from now on!<br />
<br />
The easiest way to see if you were successful, is to install the [[Nvidia]] driver and start X.<br />
<br />
== Network ==<br />
[[Wireless_Setup|Wireless Setup]] provides instructions on how to identify your card, but if your MacBook Pro 7,1 is like mine then you'll head to [[Broadcom_wireless|Broadcom Wireless]] and use this command.<br />
<br />
$ lspci -vnn -d 14e4:<br />
<br />
If from this you discover that your full PCI-ID is {{ic|[14e4:432b]}}, then the following advice applies to you: Don't waste time on the {{ic|b43}} driver. I've been fiddling with it for weeks, and switching to {{ic|broadcom-wl}} made all the problems go away. {{ic|broadcom-wl}} might make your device names funky, but that's easily fixed with the udev rule documented on [[Broadcom_wireless|Broadcom Wireless]].<br />
<br />
I also recommend {{ic|netctl}}.<br />
<br />
<br />
{{Note| Alternative solution for using b43:<br />
As of kernel version 3.17.1-2, Broadcom Wireless driver most likely won't work (ERROR @wl_cfg80211_scan :WLC_SCAN error (-22)). The only option seems to be loading the b43 driver in [http://en.wikipedia.org/wiki/Programmed_input/output PIO] mode. To enable PIO mode, install driver by following the guide at [http://wireless.kernel.org/en/users/Drivers/b43 wireless.kernel.org], then load the b43 kernel module with <nowiki>pio=1 and qos=0</nowiki> parameters. To make this happen at boot, create {{ic|b43-firmware.conf}} file in {{ic|/etc/modprobe.d/}} and add the following lines:<br />
<br />
{{hc|b43-firmware.conf|<br />
<nowiki>options b43 pio=1 qos=0</nowiki><br />
<br />
blacklist wl<br />
blacklist brcmsmac<br />
blacklist brcmfmac<br />
blacklist b43legacy<br />
blacklist bcm43xx<br />
blacklist brcm80211<br />
}} <br />
<del>Although using PIO should be much slower than using [http://en.wikipedia.org/wiki/Direct_memory_access DMA], I haven't noticed any performance drop.</del> Further testing showed repetitive occurrences of noticable performance drops. Mostly expressed as rapid decrease of transfer speed, sometimes even dropped connections. It also seems that b43 driver has issues operating at 5Ghz.<br />
<br />
Further testing has proven that with linux-mainline-rc6 (other versions not tested) b43 works not in PIO mode! This prevents the connection drops and dramatic slow downs mentioned above. Use the same /etc/modeprobe.d/b43-firmware.conf above except you should comment out (or remove) the first line:<br />
<br />
#options b43 pio=1 qos=0<br />
}}<br />
<br />
== Video ==<br />
According to the [http://wiki.debian.org/MacBookPro Debian Wiki] the MacBook Pro 7,1 has an [http://www.geforce.com/hardware/desktop-gpus/geforce-GT-320-OEM NVIDIA GeForce GT 320M] in it.<br />
=== Nouveau ===<br />
Works out of the box, performance however is not that great and your system will get quite ''hot'' when running nouveau.<br />
=== Nvidia === <br />
The drivers work, but so far only when booting the mac in csm- or legacy-mode.<br />
See [https://bbs.archlinux.org/viewtopic.php?id=162289 here] for some discussion on the topic.<br />
<br />
In short, booting in '''efi-mode''', will crash the nvidia module when X starts, resulting in a black screen, so in order to use nvidia's driver, you'll need to boot your machine in '''csm-mode'''.<br />
<br />
This can't be achieved directly, but depends on apple's firmware agreeing that your partition layout warrants this as presumably they implemented the feature to allow booting of windows xp/7, neither which can ordinarily boot off a gpt partitioned disk.<br />
<br />
<br />
'''To be continued..'''</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=Talk:KDE&diff=355171Talk:KDE2015-01-03T17:49:48Z<p>Thelongdivider: /* New article for KDE 5 */</p>
<hr />
<div>== Minimal installation ==<br />
<br />
Minimal installation could be better: suggested kdebase contains program that probably are not used so much (Konqueror, Kwrite), KDE should work fine without kdepasswd and keditbookmarks too. Wallpaper are useless. If available, an option of any kind to completely disable Phonon would be nice, since using ALSA to media playing in Linux is enough, and Phonon is overkill.<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:56, 1 November 2013 (UTC)<br />
<br />
== Using Openbox in KDE ==<br />
<br />
WTF is it doing in the middle of the KDE article? I propose to move it to tips and tricks.[[User:Reflexing|Reflexing]] ([[User talk:Reflexing|talk]]) 11:49, 5 December 2013 (UTC)<br />
<br />
Moved it by myself. [[User:Reflexing|Reflexing]] ([[User talk:Reflexing|talk]]) 11:55, 5 December 2013 (UTC)<br />
<br />
== MariaDB 10.0.12 and Akonadi ==<br />
<br />
'''amish''' has [https://bbs.archlinux.org/viewtopic.php?pid=1435860 posted some instructions] on BBS concerning action that needs to be taken in order to get Akonadi and the new MariaDB (which is a major upgrade) working together. FYI.<br />
<br />
-- [[User:Aexoxea|aexoxea]] ([[User_talk:Aexoxea|talk]]) 11:37, 14 July 2014 (UTC)<br />
<br />
== New article for KDE 5 ==<br />
<br />
Since most of the information on the page are just valid for KDE 4, it would be good to put information about KDE 5 (e.g. what packages are already available through AUR, known problems and workarounds) on an extra page. --unsigned<br />
<br />
:I remember we did something like that when GNOME 3 came out, but it was very different from GNOME 2. I don't know how much an article for KDE 5 would be different from this one: if there's really so little in common between the two releases, I guess starting an article from scratch is better; if however what differs the most is only the installation and troubleshooting, as you wrote in your post, then maybe creating KDE 5 subsections where needed would be best to avoid duplicating content (e.g. there's already [[KDE#KDE 5.x]]). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:18, 24 July 2014 (UTC)<br />
<br />
Also the existing info in the [[KDE#KDE 5.x]] section is out-of-date. There are now packages for oxygen and kwin in [[extra]], and it would be nice to have some information about how to install them. I would add it, but I don't actually know how to do it, since kwin conflicts with kdebase. [[User:Izahn|Izahn]] ([[User talk:Izahn|talk]]) 16:03, 9 October 2014 (UTC)izahn<br />
<br />
I think that the pages should be separated, as they are quite different. If not, the KDE 5.X section should be updated. For example, it says that the frameworks applications will be released in December 2014. It has not been (as far as I know). --Thelongdivider<br />
<br />
== Customizing the lockscreen background ==<br />
<br />
Hi, I've made some [https://wiki.archlinux.org/index.php?title=KDE&diff=349354&oldid=349353 changes] which I'm hope could improve the [[#Setting the background for lock screen]] section, but, now it seems the next section [[#Setting lockscreen wallpaper to arbitrary image]] is solving exactly the same problem in some different (and possibly better) way.<br />
The first section was added with revision [https://wiki.archlinux.org/index.php?title=KDE&diff=276691&oldid=276178 276691], and the second with [https://wiki.archlinux.org/index.php?title=KDE&diff=277565&oldid=277071 277565].<br />
I'm not very experienced KDE user, so I'm in doubt now should one/both of them be removed (or just my changes in first section be undoed :)? Thank you. — [[User:Blackx|blackx]] ([[User_talk:Blackx|talk]]|[[Special:Contributions/Blackx|contribs]]) 07:43, 10 December 2014 (UTC)<br />
<br />
:I don't use KDE, but if [[KDE#Setting lockscreen wallpaper to arbitrary image]] works, that's the proper way to do it (in absence of an official KDE option), since [[KDE#Setting the background for lock screen]] is reset every time {{Pkg|kdebase-workspace}} is upgraded, it requires root privileges and it's much hackier in general (i.e. it messes up the system more). I would mark [[KDE#Setting the background for lock screen]] for deletion, but only if [[KDE#Setting lockscreen wallpaper to arbitrary image]] is confirmed to work. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:19, 11 December 2014 (UTC)</div>Thelongdividerhttps://wiki.archlinux.org/index.php?title=Talk:KDE&diff=355170Talk:KDE2015-01-03T17:49:36Z<p>Thelongdivider: /* New article for KDE 5 */</p>
<hr />
<div>== Minimal installation ==<br />
<br />
Minimal installation could be better: suggested kdebase contains program that probably are not used so much (Konqueror, Kwrite), KDE should work fine without kdepasswd and keditbookmarks too. Wallpaper are useless. If available, an option of any kind to completely disable Phonon would be nice, since using ALSA to media playing in Linux is enough, and Phonon is overkill.<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:56, 1 November 2013 (UTC)<br />
<br />
== Using Openbox in KDE ==<br />
<br />
WTF is it doing in the middle of the KDE article? I propose to move it to tips and tricks.[[User:Reflexing|Reflexing]] ([[User talk:Reflexing|talk]]) 11:49, 5 December 2013 (UTC)<br />
<br />
Moved it by myself. [[User:Reflexing|Reflexing]] ([[User talk:Reflexing|talk]]) 11:55, 5 December 2013 (UTC)<br />
<br />
== MariaDB 10.0.12 and Akonadi ==<br />
<br />
'''amish''' has [https://bbs.archlinux.org/viewtopic.php?pid=1435860 posted some instructions] on BBS concerning action that needs to be taken in order to get Akonadi and the new MariaDB (which is a major upgrade) working together. FYI.<br />
<br />
-- [[User:Aexoxea|aexoxea]] ([[User_talk:Aexoxea|talk]]) 11:37, 14 July 2014 (UTC)<br />
<br />
== New article for KDE 5 ==<br />
<br />
Since most of the information on the page are just valid for KDE 4, it would be good to put information about KDE 5 (e.g. what packages are already available through AUR, known problems and workarounds) on an extra page. --unsigned<br />
<br />
:I remember we did something like that when GNOME 3 came out, but it was very different from GNOME 2. I don't know how much an article for KDE 5 would be different from this one: if there's really so little in common between the two releases, I guess starting an article from scratch is better; if however what differs the most is only the installation and troubleshooting, as you wrote in your post, then maybe creating KDE 5 subsections where needed would be best to avoid duplicating content (e.g. there's already [[KDE#KDE 5.x]]). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:18, 24 July 2014 (UTC)<br />
<br />
Also the existing info in the [[KDE#KDE 5.x]] section is out-of-date. There are now packages for oxygen and kwin in [[extra]], and it would be nice to have some information about how to install them. I would add it, but I don't actually know how to do it, since kwin conflicts with kdebase. [[User:Izahn|Izahn]] ([[User talk:Izahn|talk]]) 16:03, 9 October 2014 (UTC)izahn<br />
<br />
I think that the pages should be separated, as they are quite different. If not, the KDE 5.X section should be updated. For example, it says that the frameworks applications will be released in December 2014. It has not been (as far as I know).<br />
<br />
== Customizing the lockscreen background ==<br />
<br />
Hi, I've made some [https://wiki.archlinux.org/index.php?title=KDE&diff=349354&oldid=349353 changes] which I'm hope could improve the [[#Setting the background for lock screen]] section, but, now it seems the next section [[#Setting lockscreen wallpaper to arbitrary image]] is solving exactly the same problem in some different (and possibly better) way.<br />
The first section was added with revision [https://wiki.archlinux.org/index.php?title=KDE&diff=276691&oldid=276178 276691], and the second with [https://wiki.archlinux.org/index.php?title=KDE&diff=277565&oldid=277071 277565].<br />
I'm not very experienced KDE user, so I'm in doubt now should one/both of them be removed (or just my changes in first section be undoed :)? Thank you. — [[User:Blackx|blackx]] ([[User_talk:Blackx|talk]]|[[Special:Contributions/Blackx|contribs]]) 07:43, 10 December 2014 (UTC)<br />
<br />
:I don't use KDE, but if [[KDE#Setting lockscreen wallpaper to arbitrary image]] works, that's the proper way to do it (in absence of an official KDE option), since [[KDE#Setting the background for lock screen]] is reset every time {{Pkg|kdebase-workspace}} is upgraded, it requires root privileges and it's much hackier in general (i.e. it messes up the system more). I would mark [[KDE#Setting the background for lock screen]] for deletion, but only if [[KDE#Setting lockscreen wallpaper to arbitrary image]] is confirmed to work. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:19, 11 December 2014 (UTC)</div>Thelongdivider