Overview
I got this on the spur of the moment, but fortunately it worked out nicely in the end.
This is not a complete guide, more of a reassurance that things are possible, and a trail of bread-crumbs for searching on.
Have not tried suspend or hibernate. That’s typically a lot of work and a lot of system instability until you get it totally dialed in, if you ever do, so I just shut it down and restart. I do most of my work in a VM, and those are easy to suspend.
I installed after turning legacy boot on in the BIOS; I think GPT partition tables might be supported in the installer, but not sure. This is a very nice feature to have in the BIOS.
Don’t do anything graphical. Do not install GNOME/KDE/anything that will try to start X on system startup. You can change that later once it’s working, if you really want to.
Laptop came with a 128GB SSD and a 1TB HD. Raw-dumped Debian netinst image to a USB stick and booted off that. I installed to a smaller primary HD partition, and formatted the rest of the HD for LVM, carefully leaving the SSD initially untouched. Initial install was pretty easy, if frightening, because I didn’t really have a backup plan, I’d blown my hardware budget, and the 10 minutes I spent with pre-installed Windows 10.1 were the most rage-inducing moments of my life.
Wired Ethernet works fine.
After initial boot, you’ll probably want to add non-free to your /etc/apt/sources.list
Wireless is a Atheros QCA6174. Install firmware-atheros package. Kernel 4.9.0-5-amd64 complains about not finding firmware 5, but firmware 4 seems to work okay.
X11. This is a challenge because it’s an Optimus laptop, meaning it has both integrated(Intel i915) and discrete(NVIDIA GeForce GTX 1070) graphics chips. The Intel is wired to the laptop screen, and the NVIDIA drives all the external outputs.
Kernel command line arguments: acpi_osi=! "acpi_osi=Windows 2009". Find the following variable in /etc/default/grub and edit as follows(see file for instructions on what to do afterwards):
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi=\"Windows 2009\""
From what I can understand of this, it tells the kernel to tell the ACPI BIOS that the machine is running Windows 2009, and hence, it will behave slightly differently, and not use the latest interface. It’s weird, but it helped a lot.
Recommend installing bumblebee-nvidia package, which should get you a working X11 display the fastest. It’ll start the Intel based X server, and should let you run 3D apps on the NVIDIA chip, via Bumblebee magic. But you can’t use the NVIDIA proprietary driver as a xrandr sink, only a source(as of Debian 9 stable 2018 January). Maybe the Nouveau driver supports this? I dunno, I like using the NVIDIA driver. So you can’t really use the external screens with just one X server this way.
You could theoretically start up an additional X server with the NVIDIA driver to drive the other screens, but that’s kind of a pain to have multiple X servers.
So you may want to use the NVIDIA X server, and use the modesetting driver to render to the built-in screen. The power consumption is still pretty low, unless you’re actually using 3D.
Steps in using the NVIDIA card, from a working Bumblebee configuration(get that working first):
Recommend logging in remotely via SSH from another computer, so that you can kill X remotely and hopefully get console back(or at least reboot cleanly) if something goes wrong.
Switch to the NVIDIA GLX libraries. Use “update-glx --config glx”: It’s a text-menu program that re-jigs everything for the GLX setup of your choice. It would be a huge pain otherwise.
Here is my xorg.conf file; an aggregate of various posted examples, some docs reading, and a little trial and error. Allegedly the latest Intel video driver can do the xrandr sink thing, but it didn’t work for me, and the modesetting driver did.
You’ll need the following lines in your .xsessionrc, to bootstrap your xrandr configuration(though if you leave it plugged into an external monitor on startup, that might work too):
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
Before attempting to actually start the Xserver, shut off the bumblebeed service, which will turn on the NVIDIA chip as a side-effect. And also load the NVIDIA kernel module, which won’t load automatically for some reason. You may want to add this to a startup file at some point, but I just do it manually every bootup for now, because I’m weird.
systemctl stop bumblebeed.service
modprobe nvidia_drm
Try starting X. Hopefully everything works :)
At that point, you can use xrandr to turn on and arrange additional screens. I use fvwm for a window manager, and I just restart it after adding/removing monitors that change the overall screen size.
Audio: seems to work fine.
Haven’t tried Thunderbolt or USB-C ports yet, but USB 3.0 ports work fine.
There’s a big fat 100GB SSD partition that contains probably the Microsoft re-install files. It makes a perfect /usr partition, as it’s seldom written to, but read from frequently.
LCD subpixel aliasing. Take a screenshot of your browser on a page with black text on a white background, and zoom in. If you see color fringing, it’s working. I ended up recompiling freetype with Debian’s source compilation system, and swapping in *just* the Freetype dynamic lib(keeping a copy of the stock one, naturally), restarted X, and that seemed to fix it. I think the Debian binary libs are shipped with it disabled in Freetype 2.6.3 due to potential patent issues. Later versions of Freetype(2.8.0+) do subpixel differently, so they can be enabled in binary libs by default. In any case, the actual config in /etc/fonts is already set up for subpixel, so at least you don’t have to mess with that.
Kanji in your xterm: Install uim, uim-xim, uim-mozc, uim-utils. Relevant daemons get the systemd treatment, so that just works. Configure with uim-pref-gtk3 or whichever, to taste. Install every Japanese font you think you might like, from apt-cache search. I use this xterm command line:
xterm -class UXTerm -u8 -fd "IPAGothic" -fa "Liberation Mono" -fs 12 -fx "-jis-*-*-*-*-*-12-*-*-*-*-*-*-*" -fg green -bg grey14
class UXTerm(see /etc/X11/app-defaults) is defined with some initial helpful values for its menus and stuff.
-u8 tells it to expect UTF-8
-fd sets the double-width font to IPAGothic(one I happen to like).
-fa sets the single-width font.
-fs sets the normal font size for both -fd and -fa
-fx is the tricky part: it’s passed to uim-xim to tell the input method server which font to render the pre-edit text with. The pre-edit is what shows up before you hit Enter. It must be an old-fashioned X font selection string(not fontconfig, like -fd and -fa). You can also set this in the uim configuration program, but it won’t change sizes then, and I like having a range of xterm sizes to choose from. You can use xfontsel to find another font string if you like; the important thing is obviously that it needs to have Kanji, and to match the size with the other font sizes.
-fg is default foreground color, and -bg is default background.
This means Kanji in vim. vim is special to me. XeTeX can handle UTF-8. TeX is a happy place.
Other terms might be easier. But they’re not xterm.
Lights: It’s nice to have some control over the pretty lights that the Alienware 17 is festooned with.
There’s a few large, ambitious projects out there, one of which is a Python GUI, and I think the other is like a mix of Java and C++ JNI, but I recommend this code, because it’s just a little bit of C that doesn’t require a service or systemd or anything. It’s unapologetically hacky, but it works, and you can review the entire code base in a short amount of time. Here’s what you’ll need to keep in mind:
dependencies: libusb-1.0-0-dev libreadline-dev.
The code is configured to look for USB ID 187c:0527, but my R4’s Alienware light device is 187c:0530. So double-check with lsusb for what your Alienware device name is, and update the code where it differs(in run.c and functions.h):
dev = libusb_open_device_with_vid_pid(NULL, 0x187c, 0x0530);
The docs and provided light configs assume 4 bit color per channel, but the 0x0530 revision has 8 bits of color per channel. So remember if you’re trying to set a solid color(operation 3), instead of rg:b0(bytes 7-8) at the end, you’ll need to set rr:gg:bb(bytes 7-9) at the end. Blink is probably extended similarly.
If you want “morph” to work, you need to fix the code to send 12 byte packets, rather than 9. This is because morph requires two colors, which are now 3 bytes each instead of 1.5, so the command no longer fits within the 9 bytes that all the open source projects are currently sending.
functions.h: change the second to last parameter of libusb_control_transfer call from 9 to 12. Don’t change the first 9, as that is unrelated.
functions.h: adjust “pad with zero” loop to pad to 12 rather than 9.
run.c: allocate 12 bytes for buf, rather than 9.
The zones just take a while to figure out. Some seem to be empty, and there’s 3 bytes worth(bytes 4-6). See the sample configs in the seq directory, check out the docs included, and mostly you’ll use the “run” command, passing configs as it’s argument. It’s lots of fun to play with, figuring out all the zones and such.
It’s not very obvious how sequence numbers work, across zones, within zones, and with the loop code. But it’s fairly easy to tweak.
Now you can do fun things, like make your Alienware logo light up red when someone demands changes to your pull requests!!!
I should probably interact with the nice people who are maintaining all these AlienFX packages and point these things out, but after 9 months at a hyper-social startup, the mere thought of additional social interaction fills me with terror.
Extra Keyboard keys: (upside down ワX, upside down ン1-9): Apparently Alienware likes Katakana, and I can’t really blame them. Anyways, I wanted these mapped to F13-F22 in X windows. This turned out to be non-trivial, and I encountered many red herrings along the way.
There are two steps: mapping the scan codes to key codes, then mapping the key codes to X key codes. The scan codes config needs to be done as root, and the X keycodes should be done as your usual user.
For the scan codes, you’ll need to work with udev/systemd(they work together a lot). The default config file is /lib/udev/hwdb.d/60-keyboard.hwdb, and therein you’ll find lots of interesting comments and configs. But you’ll want to add something very much like this hwdb file, and place it in the directory /etc/udev/hwdb.d To derive this file, the identifier I got using the evemu-describe program from the evemu package, and I wildcarded the version info. The scan codes I got from running “evtest /dev/input/event0” and pressing the keys. Complete this stage with the following commands:
udevadm hwdb --update
udevadm trigger /dev/input/event0
evtest /dev/input/event0 # make sure its working as expected
For the next stage, you’ll want to debug with xev. First see what those keys are now mapped to in X, if anything... probably not something desirable, but maybe they’re okay for you.
The actual XKB infrastructure is rather daunting. There’s probably a nice, legit way to do this, involving myriad config files from /usr/share/X11/xkb which are used in combination with the setxkbmap “master” config to generate a configuration for feeding to xkbcomp. But that’s a pain, so just do this:
xkbcomp :0 keymap.xkb # dump the config from your running X server to a file.
# modify key bindings for FK13-22 in that file. Note that <FK13> should appear first to define it in terms of the keycode(that part is fine), and then to apply that symbol to an X keycode(that you’ll probably want to adjust). For example, this is the first line I edited(it was originally XPlayUkelele or some silly xkeysym like that):
key <FK13> { [ F13 ] };
xkbcomp keymap.xkb :0 # This loads the modified file back into the X server.
There’s probably a ton of ways to load this keymap automatically on X startup, but doing the aforementioned line from your .xsessionrc will probably work fine. Just remember to use the absolute path to your keymap.xkb file, in case the X server doesn’t cd to your home directory(maybe it does, not sure, but this’ll work either way).
Why Bother?
I feel worried for my computer when Windows is running on it. That anxiety was always in the back of my mind when using my previous Alienware laptop(which I’ll probably put Debian on at some point). I played games more back then, so I just used a Linux VM on it to do work.
A computer running Linux or a BSD variant just feels peaceful. You know what it’s up to, and it doesn’t have to do much. It doesn’t hassle you to install updates every 15 seconds.
It runs very smoothly, and is very power-efficient. I feel like my computer is relaxed.
I suppose you could get a Mac and that would be okay, but I prefer the Alienware hardware, and the simplicity of Linux.