Debian/Testing (Jessie) GNU/Linux on Auros X3 Plus V6 14in 1.8kg extreme "Gaming" laptop.
This report is listed at TuxMobil - Linux on laptops, notebooks, PDAs and mobile phones
This is an extreme laptop, designed for gaming, and bought in Shenzhen from
the official distributor, GPlustore.
It was chosen because of a need for simultaneous 3D CAD work, 2D PCB CAD design,
Dual web browsers for research purposes and for Embedded Operating System
development including regular kernel and u-boot compiles as well as full
OS compiles. Ordinarily an extreme desktop would be chosen for this task,
but at present I am constantly on the move.
The specifications are simply off the charts:
* 8 Core skylake i7 at 2.7ghz, turbo to 3.2ghz, overclockable to 4 ghz
* up to 32gb of 2400mhz DDR4 RAM
* 14in 3200 x 1800 LCD
* 1.8kg in weight
* Aluminium chassis (helps act as a heat sink) with dual fans behind the LCD
* slots for two M.2 PCIe NVMe SSDs (capable of 2.1GB/sc write and 0.5GB/s read)
* Atheros E220x Gigabit Ethernet
* Intel dual-band Wireless 802.11ac 8260
* Intel Graphics running the LCD and HDMI
* "Headless" (Optimus) NVidia GTX 1060 GPU with *SIX* (6) GB of RAM
* 3 USB3.1 Ports
* MicroSD Card slot
* Intel USB Bluetooth (8087:0a2b)
Not only is it an extreme machine, it also looks really nice, and appears
to be well designed. Unlike many machines in its class, it doesn't weigh
very much either. It's not perfect by any means (more on this later), but
it's deeply impressive.
Most important question: can it run any version of linux and expect the
full hardware to work? Well, it's an extremely recent and powerful set of
chips, so you need the most up-to-date kernels (but not too up-to-date).
4.7.8 has been found so far to be the optimal combination of "recent
enough to have everything working" but not "too recent so as stuff starts
failing".
(Update 2017jan25: 4.8.0 from debian/testing is also confirmed working,
importantly also working with the NVIDIA GPU).
At the time of writing, after an auto-hibernate event the Audio
is not fully functional if an application has it open during hibernate,
and there is a potential hardware issue with symptoms indicative of
cross-talk between the Ethernet and PCIe buses: when extremely large
amounts of data are being transferred, the NVMe PCIe Card goes funny and
some severe warnings ("Corrected" errors) - dozens per second - show up
in /var/log/kern.log (and on the console, which is extremely annoying).
However it is necessary to be writing at the full 500MBytes/sec and
to be saturating the Gigabit Ethernet in order to hit this problem.
No data corruption has yet actually occurred, but it is of some concern
and needs investigating.
Also: one thing that very very few people in the world would even notice:
to my eyes the LCD flickers when it is predominantly black. Moving my
eyes from side-to-side I would estimate the LCD frequency to be somewhere
around 100 Hz, and the LCD Backlight's PWM frequency to be lower than normal
(it's supposed to be around 10khz so that people cannot notice it).
Most people are incapable of noticing this consciously, but I can.
Fortunately when running white-on-black and running desktop wallpaper that
isn't a dark colour, it becomes less noticeable.
Installation of Operating Systems
---------------------------------
The first thing that needs to be done is to go into the BIOS (F2),
look for the option to set "Windows 7" settings, save, and reboot.
This will allow a UEFI-formatted USB stick to be recognised, such that
it becomes possible to install anything at all. Selecting F12 at boot
time brings up a "boot selection" menu: any external USB sticks
(and probably SD Cards) that contain UEFI boot partitions and managers
are shown.
The chosen first attempt was a straight Debian 8.6.0 "Live" Hybrid ISO,
just to verify that things were functional. 8.6.0 has the 3.16 kernel,
and on initial exploration it seemed to work well (resulting in the
purchase of the machine). Further investigation, using the Debian 8.6.0
"XFCE" Hybrid ISO, showed that the 3.16 kernel simply does not recognise
the skylake video hardware. Amazingly however, this actually was the only
hardware that was not recognised properly. XFCE however did come up, in
VESA mode, out-of-the-box, at a strange incorrect aspect ratio resolution
which was probably 1280x1024 but squashed vertically. It did not warrant
further investigation.
Throughout all of these installs, the NVMe PCIe SSD was fully recognised,
worked just fine, and, unlike the Lenovo Yoga 900 Hell On Earth scenario,
was set up to be a sane "AHCI" setting in the BIOS instead of being set
to RAID (and then prevented and prohibited from being modified).
A partitioning decision was made to go with software-raid (with a
single NVMe drive at the moment) so that it could conceivably be upgraded
to dual RAID later. This did cause a bit of sysadmin problems later
(nothing to do with the hardware itself) but it was successfully resolved.
Based on the success so far, next up to try was a straight rsync copy
over from the previous machine (Gigabit Ethernet working perfectly
out-of-the-box), because that was also running a 3.16 kernel, and had
a UEFI grub installation. The 3.16 kernel, initrd and grub settings
from the Debian 8.6.0 XFCE install were left on, whilst everything else
was wiped out, and the old OS files dropped into the root partition.
The initial boot did not go well, because the initrd and /etc/fstab and
many other things were all set up for the older system. This required
keeping the Debian 8.6.0 XFCE USB-stick around and using its "advanced
rescue" option. Normally you would not be doing anything remotely as
complex as trying to copy one UEFI-booting system's hard drive contents
over to another system with completely different hardware and a radically
different partitioning layout, so the complexities involved are out of
scope of this report.
Several hours later, success was achieved and it was time to try running
Xorg. That failed completely. However, before giving up on the 3.16 kernel,
because it was not realised that this hardware is an "Optimus" setup, where
the NVidia GTX 1060 GPU is acting as a "co-processor" to the Intel HD
Graphics which is the hardware responsible for doing the actual displaying,
the NVidia proprietary drivers (375.20 at the time of writing) were downloaded,
compiled and installed. This was an incredibly straightforward task:
apt-get install nvidia-kernel-dkms
That's it. That's all it took. nvidia driver source downloaded, compiled
and installed. However, this was where I discovered that the 1060 GPU is
in "headless" mode, because when trying to set it up in xorg.conf, XOrg.0.log
showed that there were no eDP displays on *any* of its ports! That's when,
after a bit of research, I discovered "bumblbeed" (apt-get install bumblebeed)
and "optirun" and bbswitch (apt-get install bbswitch-dkms), all of which
amazingly appear to have been around for quite some time.
This still however did not fix the Xorg "not working", but it did at least
allow for confirmation of the NVidia kernel modules as loading, and working,
which turned out to be crucial information later.
Next up on the priority list was getting the i915 hardware running. "lspci -v"
under the 3.16 kernel showed no signs of a driver, and, more worryingly, if
run twice resulted in the entire machine hanging irrevocably, necessitating
a power-cycle.
The decision was therefore made to try the debian/sid 4.8.0-1-amd64
kernel, which was immediately successful (see list of files at
the end for a recommended /etc/apt/sources.list). The full LCD
resolution - 3200 x 1800 - was immediately recognised and started up.
The trackpad started up immediately. USB Mice: fine.
'echo 20 > /sys/class/backlight/intel_backlight/brightness' worked
perfectly, to set the backlight brightness. Fvwm2 came up in a split
second, as did the default programs fired up from xinitrc, including
firefox (which normally takes a few seconds to start up).
The next task therefore to try on the list was the NVidia "headless" GPU.
"dpkg-reconfigure nvidia-kernel-dkms" was therefore run successfully, the
kernel modules built... and that's where the problems started again.
"modprobe nvidia" gave the completely ridiculous error "Your GPU is not
supported, please check the README at www.nvidia.com". Just to double-check,
that was actually done, and yes, PCI device 1c20, known as a GTX 1060, is
listed as supported. Bear in mind that it worked perfectly under the 3.16
kernel.
Further investigation (including attempting compilation of Linux kernel
source directly (apt-get install linux-source-4.8) and attempting to use
both the gcc 5.4.1 *and* gcc 4.8 compilers proved unsuccessful. What finally
did it was to use the linux-source-4.7, recompiling it because the prebuilt
packages have since been removed from Debian/SID. That was carried out with
the following steps:
apt-get build-essential
apt-get install mkinitramfs
apt-get linux-source-4.7
cd /usr/src/linux-source-4.7
xzcat /usr/src/linux-config-4.7/config.amd64-none-amd64.xz > .config
make menuconfig (then exit immediately or add in your own kernel suffix)
make -j12 bzImage modules
make modules_install
make install
This process works perfectly because the Debian Kernel Team have modified
the linux kernel source to add in hooks for setting up the initial ramdisk
for debian. If you are using "vanilla" 4.7 kernel source you will NOT have
the same level of convenience, and may need to build your own initrd and
have grub run manually.
Amazingly, doing a manual command to compile the nvidia 375.20 module also
worked perfectly:
dkms build -m nvidia-current -v 375.20 -k 4.7.8lkcl
dkms install -m nvidia-current -v 375.20 -k 4.7.8lkcl
where the suffix "lkcl" had been added into the kernel build above during
"make menuconfig" (CONFIG_LOCALVERSION="lkcl" in the .config)
A reboot was required (NVIDIA: please get your act together, it's not
acceptable to force people to reboot UNIX systems. We're not windows users)
and following that, because bumblebeed was installed, after firing up
fvwm2, "optirun glxinfo" worked perfectly. Further tests, such as
"optirun glxgears" showed the limitations of this experimental system
(fvwm2 switches off windows when they're moved, to a wireframe), as the
glxgears froze when optirun reported:
primus: warning: dropping a frame to avoid deadlock
and glxgears remained frozen and required termination. However, from a
hardware perspective, this exercise can be said to be a complete success
on the Accelerated GPU front.
Update 2017jan25: since accidentally upgrading to 375.26 in order
to test out opencl, it appears that 4.8.0 (standard debian/testing kernel)
and 4.8.11 work perfectly well. NVIDIA: you are still not off the hook.
See NVIDIA section below.
UEFI and Grub
-------------
I am not a fan of UEFI. Especially the fact that it is a means and method
of preventing and prohibiting people from truly owning the hardware that
they legitimately and legally purchased. Fortunately, there turns out to
be a way to reset the hardware back to sane defaults:
apt-get install grub-efi
Once this is installed, a new option appears on the grub menu at boot time.
If this is selected, the system immediately reboots. However, on pressing
F2 and exploring the BIOS options, it had changed *yet again* to something
more sane. The option to permit "Legacy OS" booting had appeared.
"Secure Boot" was completely disabled, and many other welcome things. On
talking to Aorus Tech Support, apparently these options all appear when
"Remove Secure Variables" is selected, but grub-efi appears to have actioned
that on our behalf.
Whilst it is not strictly necessary to use grub-efi (certainly selecting
"Windows 7 Boot defaults" seems to do the trick) it is most welcome to not
be forced to use UEFI boot at all, and thus to be able to set up and use
simple recovery boot media again.
Wireless
--------
Uses the Intel 8260 Dual-band WIFI. Installation of the firmware package
worked perfectly:
apt-get install firmware-iwlwifi
which resulted in the following two lines in /var/log/kern.log:
Dec 11 19:23:51 localhost kernel: [ 6101.848567] iwlwifi 0000:04:00.0:
firmware: direct-loading firmware iwlwifi-8000C-21.ucode
Dec 11 19:23:51 localhost kernel: [ 6101.848878] iwlwifi 0000:04:00.0:
loaded firmware version 21.302800.0 op_mode iwlmvm
This may prove to be valuable information to people endeavouring to install
other OSes, or to try to install straight Debian 8.6.0 which may not have
the exact same firmware ucode file.
Bluetooth is an Intel USB device, which has not yet been tested (personally
I don't need or want it). it is failing to find the firmware:
Dec 11 04:39:29 localhost kernel: [ 6.528016] bluetooth hci0:
firmware: failed to load intel/ibt-11-5.sfi (-2)
which is fine with me.
Audio
-----
Audio is a bit odd. On first boot it's fine, and comes up perfectly, but
after the ACPI default idle time results in the laptop going to sleep, on
resume the *entire* Audio PCI device is simply... not there any more. As
in, "lspci" shows it to be *missing*. This would go some way towards
explaining why snd-hda-codec-hdmi has had to be blacklisted. This is going
to need further investigation (and "sleep" mode disabled).
Update: on further investigation, /etc/modprobe/sound.conf had an entry
which was configuring snd-hda-intel for a macbook pro. removing the
relevant "options snd-hda-intel" line seems to have resolved the problem
of both snd-hda-codec-hdmi and the Audio PCI device entirely going offline
of the PCI bus, to be confirmed after letting the machine auto-suspend.
Update: letting the laptop suspend to RAM automatically worked fine,
whilst "optirun vlc" was open after a film had stopped playing.
There were no serious kernel errors reported after resume (which would
indicate that it was the misconfiguration that was the likely cause of
the errors). What *did* happen however was that the audio would not
play after the "resume". It was necessary to exit vlc and restart it,
in order to have the sound operational again. A further test will
be carried out, pausing and issuing "killall -STOP vlc" then letting
the laptop suspend automatically.
Update: s2disk or s2ram results in various ACPI and other resets on
resume, which take some time to complete. Audio remains non-functional
until these resets are completed.
Speakers
--------
2 Watt per channel and clearly high quality. Best laptop speakers I've
ever encountered. Not tinny at all: actually has some bass to them, which
means that Aorus have gone to the trouble of putting in decent-sized
resonance chambers. Beats Apple Macbook speakers hands down.
Video Playback with vlc
--------------
This is complicated, but seems to run better for certain kinds of videos
when using optirun. The vlcrc config used, which needs to be placed
into ~/.config/vlc/, and is set up to use xcb_glx for video output, is
included (see files listed at the end), where the packages needed to be
installed include:
apt-get install vdpau-va-driver nvidia-vdpau-driver libvdpau-va-gl1
libva1 vainfo
followed by ensuring that films are always watched with "optirun vlc".
CPU usage then seems to stabilise around 30%, whereas with certain CODECs
it can be as low at 15% without optirun, but a 100% load on a single
core (with plenty of dropped frames) on others (mkv files with high-res
H264). These exact same high CPU load files when run under optirun end
up around 30%, which is tolerable.
SDCard
------
It's a standard Realtek Device 522a. works perfectly. Does throw up this:
Dec 11 21:10:28 localhost kernel: [12498.917338]
mmc0: cannot verify signal voltage switch
Dec 11 21:10:28 localhost kernel: [12499.042815]
mmc0: new ultra high speed SDR50 SDHC card at address 59b4
HD Webcam
---------
The USB-based UVC Video HD (1280x720) Camera, works perfectly out-of-the-box:
tested with guvcview (which segfaults on exit but is not the camera's
problem). Also tested with the (proprietary) http://zoom.us application,
which again worked perfectly.
Backlight
---------
'echo 20 > /sys/class/backlight/intel_backlight/brightness' works great.
There are plenty of tools which can be used and they should all work perfectly.
The only thing: at low brightness values, the LED backlight PWM frequency
has unfortunately been set to such a low value that the screen is CLEARLY
visibly flickering. This can easily be demonstrated by turning the screen
white (display a white image), switching off the room lights, setting the
brightness down low, getting a piece of cardboard and poking a small hole
in it, then, whilst your eyes are fixed firmly forwards, unmoving, wave
the cardboard directly across the screen. The faster you wave it, the
more chance you have of being able to see, instead of a continuous line as
an afterimage on your vision, you will see a series of dots *exactly* as
you do on HD 1080p60 live sports television (golf, cricket or tennis).
For the majority of people however they simply do not have the visual
acuity of their visual cortex to perceive this flickering, so should be
absolutely fine. For those people with greatly increased visual perception
it's a complete utter pain and not something to be expected in a $USD 2,500
laptop.
Suspend and Resume
------------------
s2disk: tested... needs some care. resume can hard-crash, may be related
to GPU.
s2ram: tested... needs some care.
Update 2017jan25 on s2ram: when the laptop is extremely busy (100% on
one particular task), s2ram doesn't like it and won't be able to actually
suspend the process, instead sometimes choosing to hang. Once I have
had s2ram give me a message after 20 seconds, "3 tasks could not be
suspended"... after that it just sat there.
Additionally, after wake-up I have to rmmod snd-hda-intel and modprobe
it again (which requires terminating any programs that have alsa devices
open). This would all be fine if I was using jackd or somesuch.
s2disk I have stopped using temporarily because resume is so unreliable
(will re-test now that I have 4.8.11 installed and working). I noticed
that starting xorg with the bumblebeed daemon running would guarantee
a crash, which I tracked down to xorg doing a scan of the PCIe bus and
trying to do nothing more than read the pcie config device node. Stopping
bumblebeed would sort this out, but I have not since tried s2disk since
discovering that trick.
Causes for Concern
------------------
The following log messages are not entirely making me happy:
* i915 VGA error
Dec 11 21:00:33 localhost kernel: [11904.351340]
[drm:intel_pipe_update_end [i915]]
*ERROR* Atomic update failure on pipe A
(start=399454 end=399465) time 192512 us, min 1788,
max 1799, scanline start 392, end 1617
which is something to do with the i915 VGA controller. seems to be
harmless (so far)
* PCIe port Bus Errors during simultaneous use of Ethernet.
Dec 11 04:39:29 localhost kernel: [ 5.528926] pcieport 0000:00:1c.0:
AER: Corrected error received: id=00e0
Dec 11 04:39:29 localhost kernel: [ 5.528934] pcieport 0000:00:1c.0:
PCIe Bus Error: severity=Corrected, type=Data Link Layer,
id=00e0(Transmitter ID)
Dec 11 04:39:29 localhost kernel: [ 5.528979] pcieport 0000:00:1c.0:
device [8086:a110] error status/mask=00001000/00002000
Dec 11 04:39:29 localhost kernel: [ 5.529015] pcieport 0000:00:1c.0:
[12] Replay Timer Timeout
This occurred at boot time, right just as the Atheros GbE was being
initialised, and it was also repeated interminably during an extremely
rapid "apt-get update" when apt was able to download at around
1700Mbytes/sec. This is some cause for concern, despite the fact that
it says "Corrected".
Given that it *only* occurs when *both* the Gigabit Ethernet is being used
*and* the NVMe is being written to at high speed, we can logically propose
the hypothesis that it's a power-related issue (not enough of it), or that
there is some form of cross-talk between the GbE high-speed operation and
the PCI Express bus.
This would tend to indicate that there is a PCB layout or design flaw,
which appears as of yet to not be causing any actual data loss, not that
any has been detected... yet. Needs to be closely kept an eye on.
* Weird NVidia kernel module load fail:
Dec 12 00:08:42 localhost kernel: [ 83.554820]
NVRM: This is a 64-bit BAR mapped above 4GB by the system
Dec 12 00:08:42 localhost kernel: [ 83.554820]
NVRM: BIOS or the Linux kernel, but the PCI bridge
Dec 12 00:08:42 localhost kernel: [ 83.554820]
NVRM: immediately upstream of this GPU does not define
Dec 12 00:08:42 localhost kernel: [ 83.554820]
NVRM: a matching prefetchable memory window.
Dec 12 00:08:42 localhost kernel: [ 83.554825]
NVRM: This may be due to a known Linux kernel bug. Please
Dec 12 00:08:42 localhost kernel: [ 83.554825]
NVRM: see the README section on 64-bit BARs for additional
Dec 12 00:08:42 localhost kernel: [ 83.554825]
NVRM: information.
Dec 12 00:08:42 localhost kernel: [ 83.554843]
nvidia: probe of 0000:01:00.0 failed with error -1
Dec 12 00:08:42 localhost kernel: [ 83.554891]
nvidia-nvlink: Nvlink Core is being initialized,
major device number 244
Dec 12 00:08:42 localhost kernel: [ 83.554936]
NVRM: The NVIDIA probe routine failed for 1 device(s).
Dec 12 00:08:42 localhost kernel: [ 83.554938]
NVRM: None of the NVIDIA graphics adapters were initialized!
Dec 12 00:08:42 localhost kernel: [ 83.554941]
nvidia-nvlink: Unregistered the Nvlink Core, major device number 244
This turned out to be due to double-mounting /run/shm (manually) on shm,
as well as /tmp on tmpfs and /var/tmp on tmpfs. Don't do that, and everything
works fine.
* Intel USB Bluetooth kernel panic:
Dec 12 00:22:57 localhost kernel: [ 654.506797] Bluetooth: hci0:
Minimum firmware build 1 week 10 2014
Dec 12 00:22:57 localhost kernel: [ 654.506800]
------------[ cut here ]------------
Dec 12 00:22:57 localhost kernel: [ 654.506804]
WARNING: CPU: 3 PID: 3881 at drivers/base/firmware_class.c:1125
_request_firmware+0x44d/0xa70
that does it: decided to blacklist both the bluetooth module and btintel
with an /etc/modprobe.d/bluetooth-blacklist.conf file
* USB mouse not working after ACPI event notification:
Dec 12 00:38:39 localhost kernel: [ 1587.535032]
usb 1-9: reset high-speed USB device number 5 using xhci_hcd
Dec 12 00:38:39 localhost kernel: [ 1587.815141]
[drm] RC6 on
Dec 12 00:38:39 localhost kernel: [ 1587.979051]
usb 1-2: reset low-speed USB device number 9 using xhci_hcd
Dec 12 00:38:39 localhost kernel: [ 1588.263606]
PM: resume of devices complete after 1764.380 msecs
Dec 12 00:38:39 localhost kernel: [ 1588.264006]
usb 1-5:1.0: rebind failed: -517
Dec 12 00:38:39 localhost kernel: [ 1588.264010]
usb 1-5:1.1: rebind failed: -517
Dec 12 00:38:39 localhost kernel: [ 1588.264557]
PM: Finishing wakeup.
This is a cheap-and-cheerful portable USB mouse which regularly goes
to sleep and can't be properly woken up. Apparently there's supposed to
be a way to change PM / ACPI settings to get it not to go to sleep. It
needs replugging after starting Xorg... and after s2ram... and after s2disk...
and after plugging in the PSU... and after taking out the PSU... but honestly
this is nothing that doesn't (annoyingly) also occur on a macbook pro.
In other words it's a general (annoying) GNU/Linux problem, not a specific
problem exclusive to this particular hardware.
Update: the ACPI and various other resets that occur immediately after
s2disk or s2ram take some time to complete. The mouse is FUNCTIONAL
immediately before these resets take place, and, if it is not being
moved during the time in which they take place, it becomes NON-FUNCTIONAL
and requires removal. The command which was previously used to reset
various ACPI and kernel options was "powertop", which is currently
being run in "calibrate" mode to see if that fixes things.
Update: decided to remove laptop-mode and replace it with tlp. Chosen
configuration /etc/default/tlp is available in the files at the end
of this report
Update: running vlc, returned to using vaapi
--------------------------------------------
Don't try to use nvidia opengl (especially not with optirun), it's just
not stable enough, uses too much CPU anyway. Edit ~/.config/vlc/vlcrc
and add this:
avcodec-hw=vaapi
then set video out to xcb_xv:
vout=xcb_xv
Under debian you can do this:
apt-get install vdpau-va-driver gstreamer1.0-vaapi i965-va-driver
and you should have all the hardware-acceleration needed. CPU usage
should then never really exceed 20% and should stay at 800mhz, whereas
using the nvidia GPU and opengl it was easily exceeding 45% and
pushing upwards of 2ghz.
Batery life is therefore greatly improved by using vaapi.
Update: running debian 4.9.6 kernel 2017feb22
-----------------------------------
Works great so far... but requires the addition of acpi_os_name="Windows 2009"
as a workaround for a rather extreme regression which terminates all and
any possibility of starting up. details here: http://bugs.debian.org/855558
Still early days, will keep an eye on things. Lots of weird stuff going on
with ACPI but it seems to be more stable than 4.8... so far...
Conclusion
----------
Despite the niggles, which amazingly are very few and are related more to
this being very recent hardware, this machine is perfectly functional and
is such a high specification that it's actually quite difficult to carry
out any kind of mental "benchmarks" comparisons against other machines.
* A full Debian Linux kernel 4.7 build, with all the modules that entails,
completes in under half an hour (timed and with all cores running at
3.2ghz: 17 elapsed minutes).
* "updatedb" takes two seconds to index the entire drive, where it
takes 25 seconds on the machine that this one is replacing: a $USD 1,500
Macbook Pro that was state-of-the-art only three years ago. That's
millions of files on a laptop hard drive with a history dating back
ten years... fully indexed in TWO seconds.
* A "dd if=/dev/zero bs=1G count=10 of=~/test" bewilderingly and genuinely
completes at a rate of 480 megabytes per second - a whopping ten times
faster than any other SSD I've encountered. Reading the same 10 gigabyte
file using a reverse dd command completes in FIVE seconds.
* A highly complex openscad 3D render which a three year old state-of-the-art
macbook pro struggled to produce a framerate of six to eight per second for
is now easily three times that when using optirun, and is even around twice
that just using the newer Intel HD graphics.
If I actually wanted to use it for games under Linux, it would make a really
good choice. Howver, I bought it because I need to run several extremely
resource-hungry applications side-by-side, as well as run multiple virtual
Operating Systems - all simultaneously - all on the same *portable* hardware,
and for that task alone it is a phenomenally good choice. One that, although
it was quite a lot of pre-evaluation research was still an enormous risk
that seems to have paid off.
Where previously I was running ten 80x58 xterms side-by-side on a 2560x1600
LCD without overlapping, on this 3200x1800 LCD I can now run twelve and
could even make them 80x65 and still just have room at the bottom of
the screen for a taskbar (if I actually ran tasksbars). Where previously
I was limited to only four 80x56 xterms to the left of two 1200x700 web browser
sessions, I can now expand that to SIX 80x65 xterms to the left of two
1280x800 web browser sessions (chrome and firefox).
Plus, if I really wanted to, the Intel HD Graphics supports additional LCDs
including 4k HDMI, and now that this has USB 3.1 it becomes possible to run
extra USB-based displays. Personally though I am a huge fan of the
UD-160, it holds a nostalgic place in my heart (and has worked under
Linux for over six years).
Message to NVIDIA
-----------------
The only thing - the last thing - I will say is to NVidia: you have to
get your act together and stop acting like idiots with this "proprietary
drivers" attitude. You need to read this:
http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develop-open-source-graphics-drivers-1649632.html
Now compare that to the MASSIVE inconvenience of learning that there's
a binary incompatibility between the proprietary crud that you released in
the 375.20 nvidia driver and the linux 4.8 kernel, when compiled for Debian
(which uses strong stack protection by default). You have got to stop
thinking that you have the resources to do this on your own, that there is
some "advantage" to keeping the source code a quotes secret quotes. You
sell hardware. You don't sell software. You're a hardware company. Get
over yourselves and release the damn source code. Including the signing
keys so that technical people can HELP you fix problems, and don't become
a burden on your resources but become a valuable addition to your team as
well as being ambassadors for your company. Right now, we RESENT using
your hardware. We don't celebrate or ENJOY using your hardware, because
of the risks associated with buying it - that being CRITICALLY DEPENDENT
on your ailing and inadequate "support" - could end up costing a business
far more than the value of this extremely powerful laptop.
Get your act together, for god's sake.
Update on NVIDIA 2017jan25
--------------------------
Turns out that that the 375.26 proprietary driver now works with the 4.8
Debian kernel (4.8.0-2-amd64 and directly from debian-supplied linux
kernel source, currently at 4.8.11).
NVIDIA: you are still not off the hook.
Hardware Info
-------------
The obligatory lspci, lsusb, cpuinfo and meminfo can be found
here, as well as the xorg.conf file,
sources.list and many others that may prove useful in setting up this
incredible machine with a GNU/Linux Distro. If you would like any other
info or reports please ask, contact me via lkcl.net
Links
-----
* http://gplustore.com/product/aorus.php
* http://www.aorus.com/Product/Spec/X3%20Plus%20v6