Thursday, March 24, 2011

Configuring Lenovo TrackPoint Mouse Wheel Emulation Scrolling in Ubuntu

I have a Lenovo X120e and have grown accustomed to using the once-loathed TrackPoint (also known as the nubbin, the navigation nipple, the eraserhead, and others) for scrolling through Web pages, windows, etc. as I would with a mousewheel. Here is how you would do it in Ubuntu (in this case 11.04 Natty Narwhal, but it should apply to anything Maverick or later:

Open up a terminal and type:
gpointing-device-settings
UPDATE (8/13/11): The package isn't installed by default in 11.10 Oneiric Ocelot, so you'll have to install it first, either through Synaptic package manager or by typing
sudo apt-get install gpointing-device-settings
Select the TrackPoint device from the pane on the left. Mine is called "TPPS/2 IBM TrackPoint." In the middle of the window, you'll see a checkbox labeled "Use wheel emulation." Check the box, along with the ones labeled "Enable vertical scroll" and "Enable horizontal scroll" as you see fit.
You'll also need to select your scroll button from the pull-down menu. In my case, it was button 2, but YMMV.

While you're here, you can also switch to the TrackPad options and disable your trackpad, if that's what you're into.

Wednesday, March 23, 2011

Ubuntu Natty on Lenovo ThinkPad X120e

If you've read my earlier post regarding Maverick on this machine, you'll know I ran into a few annoying issues.

The biggest problem was that my Broadcom wireless driver kept getting deactivated with every reboot, so I decided to try installing Natty instead.

The first issue I ran into with Natty was that the installer kept crapping out before the partitioning phase with an error about ubi-partman failing to start due to error 141. There are a couple of Launchpad bugs filed for this error, but a claimed fix that was checked in a few days earlier did not seem to help things. What fixed me up, though, was using the alternate install image, which uses an ncurses-based installer rather than the fancy Ubiquity installer.

So, moving on, everything installed fine and, upon booting into the new system, the hardware driver manager detected my wireless card and recommended the proprietary Broadcom SLA driver. Click to enable, reboot and wireless should be fine and dandy.

If you opted for the default Ralink card, it should be detected and supported out-of-the-box, without even needing to consult the driver manager.

By default, the system utilizes the open source "radeon" driver, with 3D support provided by the Gallium3D backend. This should be fine for light 3D duties, such as Compiz, though it does have a show-stopping bug that will cause crashes, loops and reboots under heavy stress, such as 3D games. As long as you don't play any games, though, you should be fine. If you want to play games and/or use video decoding acceleration, you'll have to install the proprietary Catalyst driver, but it is not yet compatible with the X Server included in Natty. This will be resolved before final release in April.


At this point, my system works pretty well, except for an odd dependency hell issue that is preventing Unity from installing/running because of some Compiz virtual package conflict B.S., though I suspect this will be sorted out in a couple of days. UPDATE (3/23/11): fixed now.

I haven't tried suspend/hibernate yet, but will update with results as soon as possible.
UPDATE (3/23/11): waking from suspend seems fine, though my notification stuff isn't updating (wireless is showing that it's disconnected, even though it's not, etc). Hibernate, in contrast, seems totally b0rked. It just sits there blowing its fan and blinking the sleep LED on the front edge until you do a hard poweroff. :(

UPDATE (4/1/11): To get multitouch working on your trackpad, install the package gsynaptics (not to be confused with the synaptic package manager):
sudo aptitude install gsynaptics
and then type:
gpointing-device-settings
You should be able to enable two-finger scrolling from the trackpad menu. While you're there, you can configure the navigation nub for mousewheel emulation, if that's what you're into.

Everything else I've tested, including audio and webcam, work just fine. Even the function volume keys work.

Things I haven't tested:
HDMI-out
audio over HDMI
VGA-out

The middle scroll button works too, it just takes a little configuration.

Friday, March 18, 2011

My First Mid-horns for Hifi

I've spent a lot of time on audiophile forums reading about the advantages of horns over purely cone-based speakers, including crisp sound reproduction, consistency, "realism" and extremely high sensitivity. The drawbacks, of course, being high cost (sometimes ridiculously so), a dearth of non-vintage models to choose from, few places to demo products before buying and, perhaps most importantly, the tremendous size requirements for horns that will reach lower frequencies. Horns are also known for their "honkiness" and directivity, which can be a problem if you often listen to music outside of your stereo's "sweet spot."

While any driver can be horn-loaded, when people talk about horns, they usually mean a compression driver with a horn attached to the front, either through bolting (the standard for audiophile equipment) or via a threaded, screw-on junction (the standard for professional equipment). Relative to normal drivers, compression drivers have very low distortion due to the small size of the membrane and the relatively short distance the membrane needs to travel.

So, as I began looking into mid-horns, most of the information available online suggests that you will need to purchase vintage equipment, such as 1950s-era JBL compression drivers and similarly aged JBL or Altec Lansing horns or else build your own horns, which can be a daunting task to say the least. If you go on eBay and look for these products, you'll see that very little is available for less than $1,000, as they have reached the status of collectors' items and are priced as such.

However, I also noticed that horns and compression drivers are still used quite extensively in professional audio settings, such as stage monitors and PA speakers. In fact, Selenium's D250-X compression driver has performance specs that looked very similar to those of the multi-thousand-dollar, vintage compression drivers I was seeing on eBay, including an uncrossed frequency response from 400 Hz to approximately 9 kHz and a sensitivity of 107 db at 1w/1m, but with a power handling capability of 150w (vs. very low power handling on vintage equipment). The biggest difference, though, is the price: ~$35!

These MCM drivers are also a good, cheap option, with a low frequency range down to 100 Hz!

Likewise, when looking into mid-horns, the prices for newly constructed or high-quality vintage equipment usually range from ~$750+ up to tens of thousands of dollars. This is simply too expensive for me, so I began looking for other options, including DIY solutions and professional audio. At this point, I had to make some decisions, including which horn curve I wanted to use.

Deciding on horn curves is basically a matter of weighing a series of compromises and figuring out what matters to you most/least. While conical horns tend to have the least honky horn coloring and are also easy to construct, owing to their straight-angled sides, they are also the least space-friendly and also tend to be very ugly, in my opinion. Exponential horns take up considerably less space than conical horns for a given frequency response, but they are more difficult to construct, due to their curved sides. Similarly, square/rectangular horns tend to have better dispersion and listening angles than round horns, while round horns impart less distortion to the sound wave.

I decided that a round exponential, while difficult to construct, would be my best bet, since I want to experience the horn sound and my space is limited (my listening room is less than 200 sq feet).

While weighing my options, I came across some potentially good options in the pro realm, including the Dayton Audio H12RW 12" waveguide and the Selenium HL14-25 exponential horn. The waveguide was attractive to me because it can easily drop right into an existing speaker cabinet designed to house a 12" woofer. However, waveguides are a little different from traditional horns, and that's really what I wanted to try. That in mind, I went with the HL14-25 horns, which have a suggested frequency range from approximately 600 Hz to 5 kHz, well inside the range of the driver.

When I received the horns, I first tested them by wiring them in series with my Phase Technology Teatro 7.5s (8 ohm, 90 db sensitivity, freq. resp. of 40 Hz to 20 kHz), but the sensitivity of the horns was too far off from that of the Teatros, such that the horns were ear-splittingly loud by the time the volume was high enough to hear the Teatros comfortably. With that in mind, I resurrected my old Sony solid state receiver (100w per channel) and wired it to push the Teatros and my subwoofer while my Dared VP-20 pushed the Selenium horns. This way, I could independently adjust the volumes to achieve a good balance between the horns and the Teatros, and then use my preamp's volume control as a sort of 'master volume.'

To run my initial tests, I left the horns uncrossed and expected a good bit of distortion below the 400 Hz mark, since that's as low as the drivers are supposed to go. I cautiously kept the volume very low as I didn't wish to blow my new drivers on their first go 'round. However, I was pleasantly surprised to find that the horns handled the lower frequencies quite gracefully, with no distortion that I could notice--even when playing as loud as I could comfortably stand--and with a fairly smooth (though rapid) rolloff below around 600 Hz. I'm assuming this success is largely due to the fact that the horns are probably receiving only a handful of watts instead of the 100+ watts that are normally shoved through them in professional applications.

Based on this experience, I have decided not to bother with a crossover at this time, though I may revisit the issue in the future.

I guess the real question now is: "How does it sound?" In short, it sounds fantastic. The frequency range covered by the horns encompasses guitar solos, most vocals and organs, which all sounded a bit anemic on my Teatros alone. The clarity and definition in these frequencies is truly astounding and must be experienced. If you've only ever heard cone drivers for this range (like me before I bought these horns), it's honestly impossible to imagine how rich the sound reproduction can truly be.

My setup is designed to allow for extensive A/B testing (in addition to the independent volume control for the Teatros and horns, the VP-20 has independent volume control for each channel), and this is where the improvements really shine. Even my wife (who is very honest about differences she can and can't hear, often to my chagrin) was blown away by the disparity between Teatro+horn vs. Teatro alone.

The horns admittedly have some strong directivity, but they also have a good--though different--sound off-axis, such that listening outside of the sweet spot is still nice, just not the same as getting right there in the middle.

Here are a couple of pictures of the horns sitting on top of my Teatros:

In the first picture, you can see the VP-20 that pushes them, as well a little bit of my disc changer, preamp and crummy solid state amplifier.

Tuesday, March 15, 2011

Ubuntu Maverick on Lenovo X120e Fusion Laptop

UPDATE 3/23/11: Natty seems to work much better with these systems, so I recommend skipping Maverick and going straight for 11.04, even thought it's still in Alpha stage at the time of this writing. Check out my post about it here.

Original Post:
Due to a wonderful pricing error at Lenovo, I got a really sweet deal on a Thinkpad X120e laptop, featuring AMD's new Zacate Fusion chipset.

When trying to install Ubuntu 10.10 Maverick on it, though, the Ubiquity installer kept failing with this error:
grub-install efi-dummy failed. This is a fatal error.
To fix this, you need to go into the computer's BIOS and, under the boot tab, change the uEFI settings to try 'legacy' first. This will allow Ubuntu to install grub successfully.

After you make that change, installation should be able to complete and you can reboot into your new system.

That's as far as I've gotten so far, so I'll update this post as I find out more.

Update (3/15/11): I ran into a few more issues that I had to muddle through: wireless networking and waking up after closing the lid of the computer.

First, we'll fix the suspend issue, since it's the easier of the two.

Update 3/23/11: Actually, this doesn't fix anything. It still has problems after a few seconds of having the lid closed (i.e., when it actually goes to sleep). Sorry for any inconvenience. I'll add a real solution if/when I find one.

Open up a terminal and type:
gconf-editor
It will bring up a window with lots of configuration items. Navigate to apps > gnome-power-manager > actions, then change the default entry for sleep_type_battery from 'hibernate' to 'suspend.'

This should get you fixed up.


Now for the tedious one...wireless.

If you have the default Ralink wireless card, for now you'll have to get the driver from the manufacturer's website, build it and install it (download it here). However, the driver *should* work out-of-the-box in Natty.

UPDATE 3/21/11: annoyingly, my system keeps deactivating the driver. I give up on Maverick and have to recommend skipping to Natty instead.
On the recommendation of others, I purchased my machine with the optional Broadcom 802.11 a/b/g/n wireless card instead of the default Ralink card. Unfortunately, the Broadcom card isn't much better. It uses the 802.11 Linux STA driver, but the device isn't supported by the version available in the official Ubuntu repos. Instead, we'll have to download and install it directly from Broadcom.

To get it going, first you want to download the driver from this page. The drivers are specific to your CPU architecture, so make sure you get the right one. After that, we need to install some prerequisites to build the driver:
sudo apt-get install build-essential linux-headers-`uname -r`
Now, we'll navigate to wherever you downloaded the driver (I'm going to assume it's located in the default ~/Downloads directory):
cd ~/Downloads
Decompress the archive:
tar -xvf hybrid-portsrc_x86_64-v5_100_82_38.tar.gz
and then build and install the driver:
make && sudo make install
The driver is now installed, but we need to activate it and tie up some loose ends. So, still in a terminal, type:
sudo depmod -a
This will fetch all of the dependencies for drivers located in /lib/modules (including our newly installed driver).

Now, we'll make sure no conflicting drivers are in use by typing:
sudo rmmod bcm43xx
sudo rmmod b43
sudo rmmod b43legacy
and then try our new driver out by typing:
sudo modprobe lib80211_crypt_tkip && sudo insmod wl.ko
At this point, your wireless should start working. If it does, we need to make sure conflicting drivers don't start bothering us again by typing:
sudo gedit /etc/modprobe.d/blacklist
and adding these lines:
blacklist b43
blacklist b43legacy
blacklist bcm43xx
Save and exit. Then, back in the terminal, type:
sudo gedit /etc/modules
and add:
ieee80211_crypt_tkip
at the bottom. Then, type:
sudo gedit /etc/rc.local
and add this:
sudo insmod /lib/modules/[whatever your kernel revision is]/wlan/wl.ko
to the end of the file, but before it says "exit 0."

You should be all set at that point. If you need to reverse these steps for whatever reason, just go back through these steps and delete the lines we added.

Last, we'll talk a bit about graphics drivers. The open source drivers do not support our fancy new APU graphics, so we'll have to use the proprietary fglrx driver binary blob from AMD, which you can install through the 'Additional Drivers' applet, located under the System > Administration menus. However, after rebooting, you'll see (at the time of this writing) a translucent black square in the bottom-right corner of your screen that shows an AMD logo and says 'Unsupported hardware.'

This can be avoided by manually installing a newer fglrx driver directly from AMD instead of using the package from the official repos, but that adds its own hassles that I didn't feel like dealing with, such as needing to manually reinstall the driver after every kernel update. If you would rather go that route, you can find detailed instructions here.

Tuesday, March 8, 2011

Filter and Shader Stacking In SSNES

Themaister just added support for multipass shader application--a.k.a. shader stacking--to SSNES, his excellent (and recently GUI-fied) frontend for libsnes. His implementation includes some interesting and fancy options, including configurable scale factors for the first pass (i.e., the first shader). This allows hq2x to be scaled to its expected scale factor during the first pass and then scaled up again to fit the desired resolution, resulting in much better retention of detail (see this post for a side-by-side comparison of the two scaling methods). Additionally, we can use the second pass to stack a scanline shader on top of the resulting image, or even cgwg's CRT shaders:
As you can see, this combination greatly smooths out the jaggies and rounds the curves without blasting out all of the details, like hq2x can often do on its own.

This two-pass shader implementation also allows users to control the amount of bloom applied by a bloom shader in the first pass simply by modifying the scale factor. Here are two examples in which I've stacked blargg's NTSC filter, cgwg's CRT-Flat v3 shader, and Whateverman's simplebloom shader (rendered at 2x and 1x respectively):
In my opinion, this combination of bloom+CRT shaders+NTSC filter is exceptionally close to the Photoshop renders that inspired the CRT shader effort.

Windows binaries for this latest version of SSNES are available here, while Linux users can download deb binaries from my PPA repo. Mac users can also get in on the fun, but they'll have to compile everything themselves, as no one is providing Mac packages of SSNES yet.

As always, any shaders covered here are available in my mediafire account.

Thursday, March 3, 2011

Themaister's Waterpaint and Scanline Pixel Shaders for SNES

Themaister, author of the excellent libsnes interface SSNES, has been working on some really fantastic GLSL pixel shaders for use with compatible emulators, such as bsnes and SNES9x.

First, we'll take a look at the waterpaint shader, which has an effect similar to smoothing filters, such as SuperSaI, but with a little extra fattening that gives it the appearance of a watercolor painting:
This looks great already, but text can sometimes get a bit hard to read and some details get flattened out, so he also made a version that includes light scanlines (both the standard horizontal scanlines, as well as faint vertical lines, as would be found in a phospher mask):
I think this version does a better job of maintaining fine details and really looks nice, especially on Zelda:LttP.

Next, he produced a beautiful (and easily customizable) resolution-agnostic scanline shader. In contrast with my own scanline shaders, Themaister's shader will work with any scale factor instead of having one hardcoded in. Here's how his default version looks without and with bilinear filtering (smooth video), respectively:
In addition to this default, I modified the settings to create medium and dark scanline settings, as well (each shown without and with bilinear filtering enabled, respectively):

You can download these shader's from my mediafire account. If you would like to modify the scaline shaders yourself, you can play around with these figures:
const float base_brightness = 0.95;
const vec2 sine_comp = vec2(0.05, 0.15);