After a few days of debating whether or not to buy a Nexus One, I finally gave in a bought one.  Rachael ended up getting a Droid Eris (Verizon) for Christmas, so in the course of a few weeks I gained access to two fantastic Android-powered phones.  I had been compiling a list of mobile application ideas and the fact that I now have the hardware to test on motivated me to start looking into Android development.

After getting the Android SDK setup I needed to connect my N1 and push an application to it for testing on real hardware.  I found some Android documentation that discussed connecting up an Android device over USB.  However, after following the steps on this page, I was still seeing strange output when running adb devices:
List of devices attached
????????????    no permissions
This led to some searching which turned up a blog post.  Basically, the Google Android team hasn’t added the Vendor ID for the Nexus One.  Apparently HTC’s USB Vendor ID isn’t correct.  So, I followed these steps to fix it:

1. Create/edit a udev rules file:
   sudo vim /etc/udev/rules.d/51-android.rules
2. Add the following line to this file:
   SUBSYSTEM=="usb", SYSFS{idVendor}=="18D1", MODE="0666"
   (Note the vendor ID of 18D1. This was changed from the HTC vendor code of 0BB4.)
3. Restart udev using either
   sudo reload udev
   or
   sudo service udev reload
4. Connect your Nexus One.
5. Run
   adb devices
   and you should see something like
   List of devices attached
############ device

Hopefully Google updates the documentation to include the Vendor ID 18D1 rather than making us hunt for this number ourselves.  Enjoy!

Following the instructions on this site, I created a new file (/etc/hal/fdi/policy/mouse-wheel.fdi) as root that contains:

<match key="info.product" string="TPPS/2 IBM TrackPoint">
<merge key="input.x11_options.EmulateWheel" type="string">true</merge>
<merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
<merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
<merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
<merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge>
<merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
</match>

If you don’t want to restart, you can log out and restart the gdm and hal services.  However, I simply restarted and scrolling worked upon logging in!

The document here is apparently the original source of this information.  I’m mostly posting this for myself for future reference (and in case either of the afore mentioned pages go down).

It really would be nice if 64-bit Linux was supported by Google rather than having to find these work-around builds.  Clearly it works for us, what is the holdup?

The two extensions I couldn’t live without were Tab Mix Plus and Google Gears.  After some digging, I found a TMP thread with a link (xpi) to a development build that works with Firefox 3.5.  Also, I found a Google groups thread and a blog post with a few links to Linux x86_64 builds of Gears.

Once I upgraded these two extensions I was happy enough to continue using 3.5 permanently rather than just playing with it for an hour or so.

Note: The builtin support for OGG video is amazing.  The problem is it’s only in Firefox right now, so I don’t really expect to see widespread adoption of it.  However, it is one great step towards getting rid of plugin-based video based on flash.

DISCLAIMER:I have no idea if what I have here is a good idea beyond the fact that my video card is working properly under linux-rt.  My computer froze a couple times with the following setup but I’m not sure if it’s the fix or the fact that linux-rt apparently doesn’t play well with multiple core machines. Or the computer freezy gnomes. Whatever. Use at your own risk.

I’m running Kubuntu 9.04 on AMD64.

While setting up my linux audio recording setup on Kubuntu 9.04 I installed the linux-rt meta-package (which right now points to linux-2.6.28-3-rt) for real time process scheduling.  I was dismayed and not at all surprised that the proprietary nVidia driver for my GeForce 7950  GT did not work immediately when I booted up out of GRUB with the new kernel.  So, I downloaded the latest nVidia driver from http://www.nvidia.com/object/linux_display_amd64_185.18.14.html and tried to install as I have to do every time there is a new linux kernel update by running this with the downloaded script:

$> sudo sh NVIDIA-Linux-x86_64-185.18.14-pkg2.run

The script informs you that it needs to compile the kernel module as usual, but dies saying compilation was unsuccessful. Following the advice of some forum posts I found, I extracted the script into its source tree with:

$> sudo sh NVIDIA-Linux-x86_64-185.18.14-pkg2.run -x

which creates a directory with a script nvidia-installer.sh and the source tree. I ran the installer manually with:

$> cd NVIDIA-Linux-x86_64-185.18.14-pkg2
$> sudo ./nvidia-installer


Compilation fails again at the same step. Inspecting /var/log/nvidia-installer.log tells us:

/home/labadorf/video_drivers/NVIDIA-Linux-x86_64-185.18.14-pkg2/usr/src/nv/os-interface.c:130: error: incompatible types in assignment

After poking around some forums there were some suggestions about replacing some SEMAPHORE code in certain driver source files, but they were for the wrong driver version (177) and didn’t work. Alright, well I have the source for both the kernel and driver, I thought, so let’s see what this incompatible type assignment is. At the end of the day, I traced the error to a couple lines of code earlier in usr/src/nv/os-interface.c. Apparently, the driver is trying to pass some raw_spinlock_t kernel struct to a function that can only accept spinlock_t structs when it detects you’re using a real time kernel. So, I thought a little commenting might do the trick…

Original os-interface.c source:


86 typedef struct os_sema_s
87 {
88 nv_stack_t *sp;
89 struct completion completion;
90 #if defined(CONFIG_PREEMPT_RT)
91 raw_spinlock_t lock;
92 #else
93 spinlock_t lock;
94 #endif
95 S032 count;
96 } os_sema_t;
97


Modified code:

86 typedef struct os_sema_s
87 {
88 nv_stack_t *sp;
89 struct completion completion;
90 //#if defined(CONFIG_PREEMPT_RT)
91 // raw_spinlock_t lock;
92 //#else
93 spinlock_t lock;
94 //#endif
95 S032 count;
96 } os_sema_t;
97


Lo and behold, on recompiling the driver everything works fine. Now, I suppose there may have been a good reason to use the raw version of the struct, but I got all of my audio stuff running with much lower latency AND using both monitors on high resolution (which is really handy since some of these audio apps take up a lot of screen real estate). There are a couple bugs open on this issue so I didn’t feel the need to post anything (though none of the comments there helped with my problem), hopefully someone will figure out what the problem is and fix it soon.

Note: By default the installer replaces whatever driver you have with the new one. You have to unpack the driver source and use the installer manually if you want to use different kernels and not recompile the driver every time. Look at this post and specifically Switcher’s comment 12 for instructions on how to do that.

Like I said, the commenting out I’ve done may be a terrible, terrible idea, but as I know nothing about graphics drivers and even less about kernel building I’m playing the ignorant fool. Good luck.

gconftool -s --type bool /apps/update-notifier/auto_launch false

I’m currently running the currently unreleased Ubuntu Jaunty on virtually all of my machines.  At times, such as when resuming my notebook, I find that my X session has died.  This is not that much of an inconvenience for me—I do most of my work within a screen session that exists as long as the machine stays running, regardless of what X decides to do.  However, services such as ssh-agent must be restarted when creating a new X session and along with this restart comes a new set values for SSH_AGENT_PID and SSH_AUTH_SOCK.  In addition, it is possible that DISPLAY may change as well.

While these variables have changed, the screen sessions values have not been updated.  So when I re-attach to the running screen session and attempt to use ssh, I find that rather than using the running ssh-agent process to cache my passphrase, I am prompted in my terminal to enter the passphrase.  If I were able to use the updated environment variables I could use the ssh-agent process and all would be fine.

As I normally do, I googled for this issue and ran across this solution to the problem.  Rather than reiterate the details presented in this post, I simply show the two zsh functions I’ve written, as they differ sightly from the afore mentioned post:

grabvars()
{
VARS="SSH_AGENT_PID SSH_AUTH_SOCK DISPLAY"
 
#For each variable in $VARS
for x in $(echo $VARS) ; do
eval echo $x=\$$x | sed  's/=/="/
s/$/"/
s/^/export /'
done 1>$VARSLOC
}
 
sourcevars()
{
if [[ -f $VARSLOC ]]; then
source $VARSLOC
fi
}

Note that VARSLOC names the file that the export statements should be written to.

How do I use these two functions?  sourcevars is called every time a new shell is created (I’ve simply added a call to this function in ~/.zshrc).  grabvars is only called when I create or attach to a screen session, so I’ve aliased ‘screen’ to be ‘grabvars; screen’.  So now when I first login and create a new terminal, this terminal has the updated environment vars.  I do a ‘screen -DR session_name’ to attach, which then calls grabvars, the correct values are written to VARSLOC, and my screen session is attached.  If I create a new window in my screen session, the correct variables are now set.  If I want the updated variables in an exsiting window, I simply call ‘sourcevars’.