Talk:Microsoft Surface Pro 3

From ArchWiki
Latest comment: 10 July 2020 by TornaxO7 in topic Change topic into "Microsoft Surface"

Booting into the installer

I feel this section should be overhauled, and reformatted to match this more closely. I've never done any major wiki edits, and would be glad to do it if nobody responds. Don't want to step on any toes. 00:14, 25 December 2015‎ Jeffhoe


This was as much as I was allowed to put here, Arch wiki has some guidelines on no c&p-ing info, so that was the most lightweight version I could write that would be allowed to be posted. Txomon (talk) 23:17, 24 December 2015 (UTC)Reply[reply]


Okay maybe I'll do an edit and if it doesn't work out we can just revert it. Jeffhoe (talk) 23:20, 24 December 2015 (UTC)Reply[reply]

Additions and Revisions

I think we should add and/or revise the following points, as significant progress has been made in terms of compatibility:

'DONE'1. Kernels There is a patched kernel available in the AUR which was updated recently. [1] This makes the installation for Arch users very easy. Furthermore only the camera patch and the multitouch patch are required for kernel 4.3+. The only drawback I had was that I needed to use DKMS install for VirtualBox to run the Win 7 VM.

'DONE' 2. Multitouch I think this is outdated. Full functionality can be unlocked with the current patch and different .conf file. Ref [2]

'DONE'3. Pen The pen input can/should be tuned according to this reddit post: [3] Works quite well for me.

4. Desktop environment Might be worth to mention which DEs work currently well, especially regarding HIDPI. From my experience Cinnamon and Gnome work best, whereas Gnome appears to be well suited regarding touch input and supports the SP3's tablet/hybrid nature by its design/workflow.

'DONE' 5. Virtual keyboard For users who like to use it as a tablet, this might be useful. Unity has a very nice onboard integration and works flawlessly. The same(similar) can be achieved in Gnome by using two extensions: [4]

6. Secure Boot I am not sure if this is necessary to mention, but in case users use grub as bootloader /boot/EFI/systemd/ needs to be adjusted.

7. Rotation/Brightness/Palmreject I think it worth mentioning that these features can be enabled by using python scripts: Rotation: [5] (designed for SP1 but at least rotation and brightness work on SP3) or [6] The second option also includes palmrejection. But in case the pen is tuned like described above, the pen name needs to be adjusted in autorotate.py from NTRG0001:01 1B96:1B05 Pen to NTRG0001:01 1B96:1B05 Pen stylus. Autobrightness: [7] Palmrejection: see above, this [8] could work. However I was not able to do so.

8. Troubleshooting Maybe we could add some quirks which are currently encountered, like HIDPI scaling (still a lot of programs don't do it properly, e.g. Playonlinux or scaling/DPI in Wine or a VM needs to be adjusted to 150%/196 dpi) or a lot of apps are not really touch-compatible (as far as I know all Gnome apps are but for example Thunderbird is not, or Chromium has problems with the input (When I hit the adress bar, a tab gets closed)).

I think with these additions we could show that running Linux on the SP3 has become a proper option and works nearly flawlessly.

In case help is needed from my side, I am would be willing to start with the editing.

Best! --DonHugo (talk) 13:54, 9 January 2016 (UTC)Reply[reply]

Sorry for the delay, I started to integrate the new parts into the Wiki. DonHugo (talk) 17:18, 28 February 2016 (UTC)Reply[reply]


Uau! Really good sum up of the advances! Some commentaries that have come to my mind.

2. Multitouch IIRC, the drawback of enabling multitouch was that it disabled the color light in the mayus key in the cover.

4. Desktop environment From my experience, running at full resolution is a headache, there are a lot of programs that are not prepared for HiDPI so I just run them in 1080x720 resolution, using Gnome.

6. Secure Boot This would need to be documented in Unified_Extensible_Firmware_Interface#Secure_Boot, because it's an standard (it would be different if we were to add some firmware loading on this stage, etc.)


So, all your points IMO would make a great addition to the article, please feel free to edit, and I will try to review it!

Txomon (talk) 11:17, 11 January 2016 (UTC)Reply[reply]

wifi unstable on newer kernels

https://www.reddit.com/r/SurfaceLinux/comments/629eso/surface_book_ubuntu_1704_411rc3_wifi_troubles/ https://www.reddit.com/r/SurfaceLinux/comments/6akq0e/surface_pro_3_on_ubuntu_how_to_get_the_wifi_to/ https://forum.manjaro.org/t/surface-pro-3-wifi-no-networks-detected/31784

I will try https://aur.archlinux.org/packages/linux-surfacepro3-git/

Sgitkene (talk) 13:04, 30 October 2017 (UTC)Reply[reply]

Hello everyone! New user here. I have a surface pro 3 which I am "arching" right these days. This whole wiki page seems heavily outdated, as at the time of this post (20/12/2018) almost everything worked out of the box: buttons, type cover (pro 4), touch, etc... Only issue I encountered is wifi indeed, which locks after a sleep/suspend. After ensuring I have all the devices firmwares at the latest version (>>Microsoft website here<<), it seems that all is necessary to do is reload the mwifiex_pcie module with the following commands:

  1. modprobe -r mwifiex_pcie
  2. modprobe mwifiex_pcie

And that's it. I suggest to automate the whole process by creating a script which will be automatically managed by systemd while sleeping/resuming the system:

/usr/lib/systemd/system-sleep/surfacepro3-wifi.sh
#!/bin/sh
# This script provides a dirty workaround for
# the wifi lock issue encountered after resume
# on a Surface Pro 3. It works by deactivating
# the mwifiex_pcie kernel module before sleep
# and reactivating it after resume.
	case $1/$2 in
  pre/*)
    modprobe -r mwifiex_pcie
    ;;
  post/*)
    modprobe mwifiex_pcie
    ;;
esac

Remember to make it executable with:

# chmod +x /usr/lib/systemd/system-sleep/surfacepro3-wifi.sh

I'm new to wikis but I'd love to fix the page in my spare time after I ensure everything is working properly. How do I handle the task?

Maikewng (talk) 00:50, 20 December 2018 (CET)

Addendum: it seems as the solution I reported previously only partially resolves the issue. After more investigation it seems that disabling the wifi power saving feature entirely improves the situation better. The command is:

# iw dev wlp1s0 set power_save off

I've written a small udev rule file to automate the command every time an event is called on the device. Feedback welcome as it is my very first time handling udev rules:

/etc/udev/rules.d/surfacepro3_wifi_fix.rules
# Disable wifi power saving on Surface Pro 3
KERNEL="wlp1s0", RUN+="/usr/bin/iw dev %k set power_save off"

Updated on 22 December 2018: Updated rulefile Maikewng (talk) 16:53, 20 December 2018 (CET)

Welcome to the wiki, Maikewng. Now there are different ways to add your udev-workaround:
  1. You know the wifi chip is surface pro specific (no other devices use it): click the little edit button next to Microsoft_Surface_Pro_3#Pen/Touchscreen issues in Xournal (the last subsection in troubleshooting), add a new descriptive subsection below it (e.g. "Wifi resume failures") and go for it (be aware other users' machine may boot with a different dev name for it).
  2. You don't know if other devices use it, but also not if some other surface batch may have another chip in the device. In this case, best use a crosslink to our general Power management#Network interfaces example (instead of your own hc code) from the new troubleshooting item.
  3. You know for sure other devices use the chip: Add it to Wireless network configuration#Troubleshooting drivers and firmware in a general manner and crosslink to it from a new troubleshooting item in this article.
Ok? --Indigo (talk) 20:29, 20 December 2018 (UTC)Reply[reply]

Hello guys! I'm using Surface Pro 3 till today, and i think i found a way to improve the situation. It seems that both of the method don't work very well on my device, so i found out why: The udev rules seem not to be working for me, since everytime i go to suspend, the power management will turn it self on. I found a way to turn it off half-permanently, using CRON.

First, create a directory where you want to store the file.

# mkdir -p /etc/pm/power.d

Then create a script in it:

# nano /etc/pm/power.d/marvell_wifi_fix

I used nano but you can use whatever you want. Then, enter the following contents to the file:

/etc/pm/power.d/marvell_wifi_fix
#!/bin/bash

/usr/bin/iw dev wlp1s0 set power_save off

Save the file, and edit the owner of this file to root and set proper permissions, rwx for owner:

# chown root:root marvell_wifi_fix
# chmod 700 marvell_wifi_fix

Finally, we'll user CRON to execute the file every minute.

# crontab -e

It will ask which editor to use if you never used it before. I will use nano in this case. Paste the following to the end of the file.

*/1 * * * * /etc/pm/power.d/marvell_wifi_fix

Save it, and we should be fine with our wifi.

Nozomi (talk) 06:09, 20 October 2020 (GMT+8)

Suspend issues

As of 07 Jan 2019, suspend is affected by auto-resuming when a type cover is attached. This happens to me with a vanilla installation and the GNOME desktop. A fix is to disable the wake-up events coming from the cover port at the bottom of the device. This needs to be done at every boot and can be obtained through a systemd unit as follows:

/etc/systemd/system/surfacepro3_suspend_fix.service
# Disable XHC wakeup trigger in /proc/acpi/wakeup
[Unit]
Description=Surface Pro 3 suspend fix

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo XHC > /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

Then enable it with:

# systemctl enable surfacepro3_suspend_fix


--Maikewng (talk) 21:14, 7 January 2019 (UTC)Reply[reply]

Sensors (rotation, ambient light)

When using a GNOME desktop, autorotation and ambient light detection can be achieved by installing the package iio-sensor-proxy and rebooting. Refer to Tablet_PC#With_GNOME for additional information.

--Maikewng (talk) 21:40, 7 January 2019 (UTC)Reply[reply]

Change topic into "Microsoft Surface"

I thinks it's better to change the name into this and creating some sections which describes some special options for each device. Because this Githubpage includes already a basic installation for a surface device. The important installation parts (like installing the linux-surface AUR kernel) should be in the first topic and after that you can add other sections which descripes how to enable other features for which surface device.

—This unsigned comment is by TornaxO7 (talk) 16:53, 10 July 2020‎ (UTC). Please sign your posts with ~~~~!Reply[reply]