Debian GNU / Linux on Samsung ATIV Book 9 Plus
Samsung just recently released a new piece of kit, ATIV Book 9 plus. Its their
top of the line Ultrabook. Being in on the market for a new laptop, when I
heard of the specs, I was hooked. Sure it doesn't have the best CPU in a
laptop or even amazing amount of ram, in that regard its kind of run of the
mill. But that was enough for me. The really amazing thing is the screen, with
3200x1800 resolution and 275DPI. If you were to get a stand alone monitor with
similar resolution you'd be forking over anywhere from 50-200% the value of
the ATIV Book 9 Plus. Anyway this is not a marketing pitch. As a GNU / Linux
user, buying bleeding edge hardware can be a bit intimidating. The problem is
that it's not clear if the hardware will work without too much fuss. I
couldn't find any reports or folks running GNU / Linux on it, but decided to
order one anyway.
My distro of choice is Debian GNU / Linux. So when
the machine arrived the first thing I did was, try Debian
Live. It did get some tinkering of BIOS (press f2 on
boot to enter config) to get it to boot. Mostly because the BIOS UI is
horrendus. In the end disabling secure boot was pretty much all it took.
Out of the box, most things worked, exception being Wi-Fi and brightness
control. At this point I was more or less convinced that getting GNU / Linux
running on it would not be too hard.
I proceeded to installing Debian from stable net-boot
cd. At first with
enabled but secure boot disabled, installation went over fine but when it came
time to boot the machine, it would simply not work. Looked like boot loader
wasn't starting properly. I didn't care too much about UEFI so I disabled it
completely and re-installed Debian. This time things worked and Debian Stable
booted up. I tweaked /etc/apt/sources.list switching from
Testing. Rebooted the machine and
noticed that on boot the screen went black. It was rather obvious that the
problem was with KMS. Likely the root of the problem was the new kernel
(linux-image-3.10-3-amd64) which got pulled in during upgrade to testing. The short
term work around is simple, disable KMS (add nomodeset to kernel boot line in
So now I had a booting base system but there was still the problem of Wi-Fi
and KMS. I installed latest firmware-
iwlwifi which had the
required firmware for Intel Corporation Wireless
7260. However Wi-Fi
still did not work, fortunately I came across this post on arch linux
wiki which states that the
Wi-Fi card is only supported in Linux Kernel
After an hour or so of tinkering with kernel configs I got the latest kernel
to boot with working KMS and Wi-Fi. Long story short, until Debian moves to
kernel >3.11 you'll need to compile your own or install my custom compiled
package. With the latest kernel pretty much
everything works this machine. Including the things that are often tricky,
like; suspend, backlight control, touchscreen, and obviously Wi-Fi. The only
thing remaining thing to figure out, are the volume and keyboard backlight
control keys. But for now I'm making due with a software sound mixer. And
keyboard backlight can be adjusted with (values: 0-4):
echo "4" > /sys/class/leds/samsung::kbd_backlight/brightness
So if you are looking to get Samsung ATIV Book 9 and wondering if it'll play
nice with GNU / Linux. The answer is yes.
Cross Compile with make-kpkg
I got myself one of the fancy shmancy netbooks. Due to a habit and some
hardware issues I needed to compile a kernel. The problem here though is that
it takes for ever to build a kernel on one of these things. No sweat I'll just
build it on my desktop, it'll only take 5-10 minutes. But of course there is a
catch. My desktop is 64bit and this new machine is an Atom CPU which only does
The process for compiling a 32bit kernel on a 64bit machine is probably a lot
easier if you don't compile it the Debian way. But this is not something I
want to do, I like installing the kernels through the package manager and
doing this type of cross compile using make-kpkg is not trivial. There are
plenty of forum and email threads about people recommending to use chroot or
virtual machines for this task, but that is such a chore to set up. So here is
my recipe for cross compiling 32bit kernel on 64bit host without chroot / vm,
- Install 32bit tools (ia32-libs, lib32gcc1, lib32ncurses5, libc6-i386, util-linux, maybe some other ones)
- Download & unpack your kernel sources
- run "
linux32 make menuconfig" and configure your kernel for your new machine
- clean your build dirs "
make-kpkg clean --cross-compile - --arch=i386" (only needed on consecutive compiles)
- compile your kernel "
nice -n 100 fakeroot linux32 make-kpkg --cross-compile - --arch=i386 --revision=05test kernel_image" for faster compilation on multi-CPU machines run "
export CONCURRENCY_LEVEL=$((cat /proc/cpuinfo |grep "^processor"|wc -l
- At this point you have a 32bit kernel inside a package labeled for 64bit arch. We need to fix this, run "
fakeroot deb-reversion -k bash ../linux-image-18.104.22.168_05test_amd64.deb". Open the file
vim/emacs and change "
Architecture: amd64" to "
Architecture: i386" exit the bash process with ctrl+d
- That's it, now just transfer the re-generated deb to destination machine and install it.
Many if not all ideas for this process come from reading email
threads the comments made by Goswin Von
Brederlow were particularly helpful, thanks.
Every six months the internet lights up with stories that Canonical & Co has
done the unthinkable they have increased the number following the word Ubuntu.
In other words they have release a new version. This is a well understood
concept to differentiate releases of software. As the version increases it is
expected that new features are introduced and old bugs are removed (hopefully
more are removed than added).
Versioning distributions and releasing the versions separately is a common
practice, employed by most if not all distributions out there. Ubuntu has
adopted the policy of releasing regularly and quite often. But there is a
different approach it revolves around a concept I call "Versionless" where you
do not have a hard release but instead let the changes trickle down. In the
application world these releases are often called nightly builds. With
distributions it is a little bit different.
First of all its worth noting that distributions are not like applications.
Distributions are collection made up by applications and a kernel, the
applications that are included are usually stable releases and so the biggest
unpredictability comes from the combination and configuration there of. As a
result one of the important roles for distro developers is to ensure that the
combination of the many applications does not lead to adverse side effects.
This is done in several ways, the general method is to mix all the
applications in a pot, the so called pre-release and then test the
combination. The testing is done by whole community, as users often install
these pre-releases to see if they see any quirks through their regular use.
When the pre-release becomes stable enough it is pushed out the door as a
In an ideal world after this whole process all the major bugs and issues would
have been resolved and users go on to re-install/update their distribution
installations to the new release -- without any issues. The problem is that
even if the tests passed with flying colors does not mean that on the user
will not experience problems. The more complicated a configuration that a user
has the more chances they will notice bugs as part of upgrade. This is
particularly evident where there are multiple interacting systems. Doing a
full upgrade of a distribution it is not always obvious what change in the
update has caused this problem.
Versionless distributions are nothing new, they has been a staple of Debian
for a while. In fact it is the process for testing package compatibility
between release, but it is also a lot more. There are two Debian releases that
follow this paradigm, Debian Testing
and Debian Unstable. As applications
are packaged they are added to Debian Unstable and after they fulfill certain
criteria, IE they have spent some time in Unstable and have not had any
critical bugs filed against them, they are then passed along to Debian
Testing. Users are able to balance their needs between new features and
stability by selecting the corresponding repository. As soon as the packages
are added to the repositories the become immediately available to user for
What it really comes down to is testing outside your environment is useful but
it cannot be relied solely upon. And when upgrades are performed it is
important to know what has changed and how to undo it. Keeping track of
changes for 1000's of updates is nearly impossible. So update small and update
often, use Debian. Good packages managers are your best friend, but only
second to great package developers!
Monitor hot plugging. Linux & KDE
Apparently Linux does not have any monitor hotplugging support which is quite
a pain. Every time you want to attach a monitor to laptop you have to
reconfigure the display layout. This is a tad frustrating if you have to do
this several times a day. And it doesn't help that KDE subsystems are a bit
flaky when it comes to changing display configuration. I've had plasma crash a
on me 1/3 times while performing this operation.
Long story short I got fed up with all of this and wrote the following 3 line
script to automate the process and partially alleviate this head ache
xrandr --output LVDS1 --auto --output VGA1 --auto
kquitapp plasma-desktop &> /dev/null
kwin --replace & &> /dev/null
kstart plasma-desktop &> /dev/null
You probably need to adjust the xrandr line to make it behave like you want
but auto everything works quite well for me. Check man page for xrandr for
For further reading on monitor hot plugging I encourage you read launchpad
bug #306735. Fortunately there are solutions for this problem, however
they are on the other side of the pond.
Update: Added the kwin replace line to fix sporadic malfunction of kwin
(disappearance of window decorations) during this whole operation.