Linux Mint Debian Edition (LMDE) UP8 on Thinkpad X131e

I recently acquired a Thinkpad X131e.  It's the 3372-3FU, which is the AMD -- meaning AMD CPU, ATI Radeon HD 7340, and Broadcom wifi.   I'm used to Intel-based systems and Nvidia Optimus systems (with Intel as fallback).

Having previously used a system with broadcom wifi chipset, I knew I would need to load some non-free, closed-source wifi drivers on this new system.

Getting Started

I replaced a Thinkpad X61t (tablet) system for this system.  The Thinkpad X61t had my standard LMDE install with Update Pack 8.  It had a Intel CPU (core 2 duo), Intel Centrino wireless and  OCZ Vertex 3 60-SSD.

I thought I would at least be able to transplant the SSD and boot into my install (perhaps with no wifi and fallback to default drivers for video).

My first challenge was with the SSD.

Low Profile Drive

I had completely neglected that the industry created a new and shorter kind of 2.5" hard drive standard.  The drives are 7mm tall versus the standard 9.5mm.  My 2 year-old OCZ Vertex 3 drive would not fit in this Thinkpad X131e, that apparently uses the "low profile" 7mm standard drives.

I realized by looking at the SSD case, that most of the cases was likely just "filler".  What stopped me from finding out was a "warranty void" sticker.  Having still 1 year warranty on the drive, I decided to go for it, and void my warranty -- if the drive dies, I'll be eager to replace it by a larger drive anyways.  Opening up the drive, I realized my intuition was correct -- the SSD consisted of a slim board (no bigger than 5mm in depth).  I kept the bottom of the case for protection from the board ever meeting contact with the metal bottom of the laptop, and placed a plastic insulator sheet adapted from an old 2.5" HD caddy on the top side of the drive (to avoid the top portion making contact with the laptop case door).  Warranty issue aside, the SSD issue was resolved.

Wifi causes Linux to hang at startup

I quickly realized that upon bootup that I couldn't make it past the init.d startup scripts without the laptop completely hanging.  I did a trial-and-error, disabling the startup services (by starting up in recovery mode, dropping me to a root prompt before the services start up).  In the /etc/init.d directory, you can simply remove the execute permission on startup services that you suspect are causing the issue, and then trial-and-error until you find the offending service.  I realized quickly that it was the networking service causing issues, and shortly after that, the wifi in particular.  To allow me to at least boot up the system with ethernet, I needed to completely disable wifi.  It was not sufficient to log onto the BIOS and disable the Wireless LAN antenna.  I found I needed to go to IO Port Access and disable Wireless LAN.  Upon doing this, I was able to boot up with a network connection (over ethernet).

Installing broadcom wifi drivers

Fairly simple to do.  With a proper working internet connect over ethernet, I was able to run:

sudo apt-get install broadcom-sta-dkms

This downloaded and installed the kernel modules for the broadcom wifi.

Broadcom STA is a binary-only device driver to support the following IEEE

802.11a/b/g/n wireless network cards: BCM4311-, BCM4312-, BCM4313-,

BCM4321-, BCM4322-, BCM43224-, BCM43225-, BCM43227-, and BCM43228-based

hardware.

After re-enabling Wireless LAN in IO Port Access, I was able to boot up with a wifi connection.

Xserver fails

With xorg not understanding AMD/ATI graphics with a regular install (get the error No Screens Found on startup of xorg/xserver), I realized I needed to install some working graphic drivers.  

Avoiding the debate over installing the latest open-source drivers or the closed-source proprietary drivers, I decided to opt for the proprietary which happen to be fairly up-to-date.

I made my first mistake by trying to install the ATI Catalyst 14.10 and 14.20 beta drivers from the Linux section on the ATI website.  The installer installs the drivers successfully, but the installer isn't actually doing anything.  Trying to run the buildpkg manual method with the software fails, and you end up going in an endless loop of troubleshooting.  I wasted a day after realizing I simply won't be able to use the installer method as its designed to only install to a 32-bit system, whereas I'm using a 64-bit install.

I decided to use the Debian repository instead.  I already had the non-free directive in my apt source.list file.  I simply followed the instructions found on the Debian Wiki for ATI (https://wiki.debian.org/ATIProprietary).  

Making sure I already had the linux-headers for my kernel installed (uname -a showed 3.11-5.dmz.1-liquorix-amd64, so I ensured I had the linux-headers installed by running sudo apt-get install linux-headers-3.11-5.dmz.1-liquorix-amd64).  Next I installed the ATI drivers by running:

sudo apt-get install fglrx-driver

After the kernel driver installs, you need to have the installer configure xorg to understand how to work with ATI.  You would run:

sudo aticonfig --initial

Apparently, if the kernel module fails to build/install/load, the aticonfig changes to xorg are sufficient enough to get X windows to load with a fallback graphic driver.  It will be a display with a slow refresh rate with other performance factors, but it will load.  I realized that the version included with Update Pack 8 doesn't compile the module properly for the Linux Kernel 3.13 that I had installed.  Apparently ATI announced it does not yet support Linux Kernel > 3.11.  I did find references to patches people have created to get the kernel modules to build on 3.14, etc, but to deal with that on another day, I decided to just use Linux Kernel 3.11.  I was able to successfully build and load the ATI Catalyst 13 Beta drivers in the Linux Mint Debian Edition Update Pack 8 repository.  Backlight adjusting via function key was working properly with the proper module loaded -- on the fallback, the backlight function keys don't work, a sign you are falling back. 

Now, if you boot up the system, you should have wifi and proper working X windows.

With the proper driver loaded, 3D acceleration is supported (and the ATI control panel will work). The command fglrxinfo will return a GL version number.  When fallback driver is active, you won't receive a GL number with fglrxinfo.  Further, with the proper drive loaded, if you perform a lsmod, there will be a fglrx driver loaded.

Additional Notes

After some reading, I decided to add the directive "nomodeset" to my grub.cfg.

Compiz wouldn't load correctly (window manager crashed, windows displayed without a window manager, etc).  I expected compiz to work with a near-latest ATI proprietary driver installed and loaded (with 3D kernel module compiled and loaded).  I did read that the latest open-source ATI driver SHOULD have compiz support also working when the Mesa GL lib is also loaded.  Naturally you cannot have both open and closed source drivers installed on the system at the same time.  Once I have things stable, I will troubleshoot further.

Hibernation/Suspend

I use pm-suspend and pm-hibernate setup with laptop tools on all my systems.  Both fail to suspend or hibernate the system.  I can suspend and resume successfully by running as root:

echo "mem" >  /sys/power/state

The same trick for hibernation, 

echo "disk" >  /sys/power/state

results in a system that cannot thaw from hibernation properly.  Running the hibernate command does work though.

Therefore, I use the following two commands

to suspend:

echo "mem" >  /sys/power/state

to hibernate:

hibernate

ThinkPad keyboard overlay for non-ThinkPads [day 2 of 20-days-of-posts series]

Yesterday I discussed a workaround in Linux to remap keyboard keys to mouse buttons to cope with a trackpad (http://ddurdle.blogspot.ca/2013/12/living-with-laptop-without-trackpoint.html).  Today I demonstrate a ThinkPad keyboard overlay that I created for my Ultrabook.

Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

Tired with an ultrabook's trackpad, especially with failing trackpad buttons, I decided it was time to finally re-purpose a spare ThinkPad keyboard.

The keyboard I've used is from a old ThinkPad X30.  I needed a keyboard to USB converter.  I happen to have an old USB trackpad keyboard that I wasn't using anymore.  The keyboard has a host board that hooks up to a "standard ThinkPad" keyboard (at that time being any X20/T20/R20/R30 etc), along with a numeric keypad and trackpad.  I'm only going to use the keyboard component.

The controller board in the keyboard case also included a bunch of non-conductive foil that protects the board from pressure exerted by the user on the keyboard.  I decided to use it.

I decided to use a singular colour of block -- red -- as I had a lot of long planks that I could use fairly easily to give the keyboard some stability.  A bottom look of the layout is below:

The base is 40 by 19 blocks.  The height is 2 blocks.

A top view:

I hold together the base planks with various 1/3rd height blocks throughout.  I avoid the placing them in the mid-left area as the controller board will be seated here.  It's a region where I use the longest planks.

Along the inside, on the left and right I place various full height blocks.  The keyboard will rest on these and provide it stability when the user presses down.  The keyboard has a drop down on the right-top side (close to the print screen and page buttons).  I make use of this to lock the keyboard in its place by using a long 2 by 16 block of 1/3rd height.  The middle-top of the keyboard raises up (where the LEDs are), so I raise up by 1/3rd height and place another 2 by 16 block of 1/3rd height to further hold the keyboard.  This piece represents the highest point in the overlay (2 blocks high).

On the bottom I place some "roof tile" blocks (incline blocks).  These are perfect to provide the keyboard a slight slant down for comfort typing, but provide the needed support for preventing the keyboard from sliding.  In the middle-bottom, I extend out a bit with 2 layers of 1/3rd height blocks which will provide support for the trackpoint buttons, preventing them from flexing when pressing down.

The keyboard is in place.  On the left bottom, I ensure the keyboard doesn't move by using a 2 by 3 plank with a "peak roof tile" piece.  I decide to pop the FN key (otherwise the 2 by 3 plank prevents it from working).  I am still able to use the FN key, and for the amount that I use it, it really doesn't matter.  On the right side I place a second "peak roof tile" piece.  It prevents the right CTRL and right ALT from pressing down fully, but the keys do work, just not as comfortable as I'd like.  But these keys I don't use much, so I can live with it.

As you can see, I have it seated on my ultrabook.  I added some extension pieces on right to have it hug the ultrabook completely (so it doesn't slide).

The keyboard and trackpoint are very comfortable to use (believe it or not).

Now a little bit more of the magic that holds the keyboard in place.

A closer look on the left side, you can see a some 1 width blocks that connect to the far left bottom of the overlay.  These allow for room for the USB plug and power plug for the ultrabook.  They box in these plugs, adding support to prevent the keyboard from sliding back and forth.  There happens to be no ventilation holes on this side of the ultrabook, so the blocks with holes are purely decorative.

A closer look on the right side, you can see these "road barrier" blocks that I use to extend out from the bottom right side of the keyboard overlay.  These provide support for the right side of the keyboard from sliding.  They also provide appropriate access to the audio and USB connectors.  I run the USB cable from the controller inside the overlay out on this side as well.

That's everything :)

From an operational point of view, in Windows, the keyboard is detected as USB keyboard.  But if you install the Lenovo USB ThinkPad with trackpoint drivers, it will operate 100% of the function of a true ThinkPad keyboard (trackpoint, all the function keys, volume keys, etc).

In Linux, the keyboard is detected as an Ultranav Lenovo keyboard.  The function keys appear to be working, but I haven't fully tested them all (hibernation, sleep, etc).  Volume buttons work.  The trackpoint of course works, but I have't been able to get the trackpoint middle-button scrolling fully working.  Even on a ThinkPad, it doesn't work out-of-the-box until you've applied the following "fix":

#! /bin/sh

xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1

xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 8 2

xinput set-prop 'TPPS/2 IBM TrackPoint' "Evdev Wheel Emulation Timeout" 200

xinput set-prop 'TPPS/2 IBM TrackPoint' "Evdev Wheel Emulation Axes" 6 7 4 5

Replacing the  TPPS/2 IBM TrackPoint with the correct name, the fix doesn't appear to be having the desired effect.  Once I work it out, I'll post the fix.

The trackpoint sensitivity is also not adjustable.  You normally adjust it on a ThinkPad with:

echo -n 220 > /sys/devices/platform/i8042/serio1/sensitivity

There are no devices with a sensitivity control.

One of the questions you might be asking is what about the pressure on the ultrabook's keyboard and trackpad.  For the keyboard, the machine has a chicklet-style keyboard, and because the bottom of the overlay is perfectly flush, it doesn't press down on any keys.  Further, the trackpoint nor the use of it seems to have an effect (unwanted interaction) with the trackpad.  However, because I can foresee there being  problems, especially with accidentally resting my fingers on the trackpad, I disable them at my desire in Linux by running an xinput disable.  You can decipher the names of these devices by simply running xinput.  The trackpad showed up as a PS/2 Mouse under Virtual core pointer and the keyboard as AT Translated Set 2 keyboard.  I disable them by running xinput disable AT Translated Set 2 keyboard and xinput disable PS/2 Mouse.  My ultrabook also has touchscreen inputs, which are not affected by these changes.  You can substitute disable with enable to undo the changes.  Naturally, if you disable the inputs, they won't remain disabled after a reboot (so either run them again with a script manually or set them on bootup with /etc/init.d/rc.local).

Living with a laptop without a trackpoint or without a middle mouse button [day 1 of 20-days-of-posts series]

I've been addicted to the trackpoint since I started using one in the '90s [I haven't owned or used a mouse on a regular basis since the '90s].  Truth be told, it wasn't even a IBM ThinkPad -- it was a business model HP Omnibook laptop.

If you haven't used one before, you probably wouldn't appreciate what you're missing.  If you are a ThinkPad enthusiast, you probably appreciate the advantages of a trackpoint -- how it allows you effortlessly move around the screen without taking your fingers off the keys or keyboard.

Even on my desktops, I've always used an equivalent USB keyboard with a trackpoint.

The trackpoint has been one of the many features of the ThinkPad that has kept me a consumer of the line over the years.  Even my Sony ultraportable P799 laptop has a trackpoint.

But there is still bound to be a time where I'll need to use a PC or laptop that doesn't have a trackpoint.  The trackpad has become the standard pointing device on almost all laptops and ultrabooks, and there doesn't exist a single ultrabook with a trackpoint.  Further, most trackpads don't feature the third mouse button that the ThinkPads have.  The third mouse button also has proven invaluable, making it critical for a "copy-and-paste" shortcut in Linux or in putty.  The only thing worse with coping with a laptop without a trackpoint is having to also deal without the middle mouse button.

In Linux, there are some options that don't involve using external devices or USB keyboards.  You can remap keyboard keys as mouse buttons.  I personally find I never use the right Alt, "menu" or right Ctrl keys.  The ideal solution, for me, would be to remap these buttons as mouse buttons (left, center, right). 

Not only does this allow provide you with your missing middle mouse button, but it also brings the buttons closer to your fingers since they are keys on the very same keyboard you have your hands positioned over.  Most trackpad buttons after all are located under the trackpad, which is generally the lower end of the bezel, requiring you to remove your hands from the keyboard to use.

With the keys remapped, you can keep your hands close the keyboard.  With this configuration, I typically will use either my thumb or forefinger to navigate the top edge of the trackpad to control the pointer, while I use the three remaining fingers to press the keys mapped to the mouse buttons.  It took me some getting used to, but then again, I never got used to the trackpad even after months of having to deal with one on an ultrabook.

The select-and-hold feels a little "left handed" in this configuration.  On a traditional trackpoint I use my thumb to hold and my forefinger to select, whereas in this configuration I use my thumb to select.

The solution can be adapted to your needs.  If you find it more natural, you can equally just as easy remap the left Ctrl, "Windows" and left Alt keys as moue buttons (left, middle, right).

Solution:

I've created a shell script that I've setup to start on login (in Debian/Ubuntu, can be a script listed in Startup Applications or call the script or commands from /etc/init.d/rc.local):

#! /bin/sh

setxkbmap -layout us

xkbset m

xkbset exp =m

xmodmap -e "keysym Alt_R = Pointer_Button1"

xmodmap -e "keysym Menu = Pointer_Button2"

xmodmap -e "keysym Control_R = Pointer_Button3"

setxkbmap sets the keyboard layout and should be pre-installed in most distributions.  xkbset lets you map mouse buttons to keyboard keys.  It isn't installed by default on most distributions, but is included with most distributions.  In Debian, it is a simple apt-get install xkbset.  xmodmap does the magic of mapping key functions, in this case to mouse buttons.

Pointer_Button1, Pointer_Button2, and Pointer_Button3 represents the left, middle and right mouse buttons.  Alt_R,  Menu and Control_R represents the three keys I discussed earlier.

If the left side of the keyboard is more to your liking (for instance, if you are left handed), then you can use the keys Control_L, Windows and Alt_L key names.

Obviously, the keys remapped will no longer function with their original programmed behaviour.  I found myself only using the left Alt and Ctrl keys, so I never missed the right key equivalents.

Was going to replace the existing WLAN card in the X61T with a newer, more linux friendly version, but I couldn't get the screws loose, and ended up stripping them in the process. So in the end, I decided to hack the second WLAN card by covering pin 20 with electrical tape, adding a 4th antenna into the palm rest, and viola. Now the machine has two WLAN connections, one that is newest technology that is very linux friendly. Plus there is some signal loss due to the digitizer and touchscreen interfaces causing interference with the antennas, so the added antenna in the palm rest make the connections more reliable.