Unity Launcher/Sidebar Missing on Ubuntu 11.10

Posted on Monday 7 November 2011 by J. D. Bartlett

As I mentioned previously, I recently installed Ubuntu 11.10 on a new laptop. Then Unity stopped working. And so did Unity 2D. This is a problem, since those are the only two desktop sessions installed by default with the latest Ubuntu.

Mode of Failure

When I logged in, I could see the desktop, and a menu bar across the top—Nautilus was clearly running. The Unity launcher which normally appears down the left-hand side of the screen was missing, as was the clock and other status information normally in the top right-hand corner of the screen.

A Really Useful Tip

Pressing Ctrl+Alt+T opens up a terminal. This is easier than what I had been doing (new window in Nautilus, Ctrl+L, type “/usr/bin”, find and run xterm).

What Others Did

Lots of other people have had this problem, and there seem to be a few standard solutions. None of these solutions worked for me, but I list them here in case you find them helpful.

  • Install CompizConfig Settings Manager (ccsm) and make sure that the Ubuntu Unity plugin is turned on.
  • Reset unity with unity --reset
  • Reset all of the Compiz settings according to these instructions
  • Completely restore unity with unity --replace

More detailed suggestions are available on TuxGarage,  Ask Ubuntu and Ubuntu Forums. Notice that if any of these pages tell you to restart gdm, you’ll probably have to restart lightdm instead because that’s the display manager that Ubuntu 11.10 uses.

What I Did

After trying just about every solution I could find, I had reached the point of frustration. I had two leads: ccsm was showing corrupt profile names in the profile selection drop-down under “Preferences”. This turned out to be a dead end. I suspect it’s just a bug in ccsm. And some commands (including /usr/lib/nux/unity_support_test -p) were giving me a message about libgl.so being missing (cannot open the shared object file). It was this last lead which led to my solution. I found libGL.so on my system, then linked to it in /usr/lib/.

$ locate libGL.so
/usr/lib/i386-linux-gnu/mesa/libGL.so.1
/usr/lib/i386-linux-gnu/mesa/libGL.so.1.2
$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/

Then I logged out (by killing gnome-session from the terminal), and tried again and everything worked.

Why it Broke

I don’t know.

It was working immediately after the Ubuntu install. I think I may have changed something in ccsm before it broke. But I can’t be sure because I’ve been using my own custom window manager instead of Unity so it took me a while to realise it was broken.

Posted in midlength | Tagged , , , , | 4 Comments

Broadcom Wireless BCM43224 on Thinkpad, Ubuntu 11.10

Posted on Friday 14 October 2011 by J. D. Bartlett

I have a new ThinkPad. It’s nice and shiny. It comes with Windows 7, so I installed Ubuntu 11.10.

The snazzy Broadcom Corporation BCM43224 802.11a/b/g/n [14e4:0576] wireless card did not work out of the box in Ubuntu. This is odd, because Broadcom provides open source drivers and Ubuntu has built them and packaged them very nicely.

I checked that the wireless worked in Windows, then searched the Internet for solutions. Everywhere that I looked, I found potential solutions. The trouble is, none of them worked for my laptop.

Then finally, I found the answer: my Lenovo ThinkPad doesn’t have an Acer wireless card. It thinks that it does.

So, to make everything work, I added the following lines to /etc/modprobe.d/blacklist.conf:

blacklist acer-wmi
blacklist b43
blacklist ssb
blacklist bcma

I don’t know how many of these lines were necessary, but I know for certain that the acer-wmi kernel module needs to be disabled. You will need to reboot the computer so that these changes will be applied (or manually turn off the modules listed above using rmmod).

In my investigations, I also rebuilt the Broadcom drivers according to these instructions and applying this patch. This may or may not have contributed to getting things working.

Posted in midlength | Tagged , , , | 5 Comments

Pygtk: reparented windows responding to size allocations

Posted on Monday 25 April 2011 by J. D. Bartlett

Today’s post is an obscure technical one that I imagine will be completely irrelevant to all of my normal readers at the time I write this. I write to save someone in the future from the hours of debugging and Googling that I had to do to solve this problem.

The Situation

I am writing a Python GTK program. The program reparents another application’s window (let’s call it window A) using gdk.window_foreign_new() and gdk.Window.reparent(). I have written a custom GTK widget that wraps the GDK representation of window A, complete with a do_size_allocate() method so that when the widget is resized, the size allocation is passed on to window A.

The Problem

Everything works fine for very simple applications using my custom widget, but I run into problems when I try to add the custom widget as a descendant of an EventBox. Under the hood the event box has its own window (let’s call it window E). The symptoms that I see make it look as if window A has mistakenly been placed in my application’s root window rather than being placed in window E. That is to say, if window E should appear at offset (5, 12) compared to window E, it instead appears at offset (5, 12) compared to the application’s root window.

The Solution

After much investigation and tinkering, and a certain amount of frustration, I stumbled across something that made everything just work, and before long, I narrowed it down to this line of code, run just before (after might work too) the code that reparents window A:

self.get_parent_window().xid

I tried self.get_parent().realize() at first, but that had no effect. For some reason, accessing the xid (underlying system window id) of the parent window causes everything to magically work. Go figure.

Posted in midlength | Tagged , , , , | Comments Off on Pygtk: reparented windows responding to size allocations

A Letter to King Larry

Posted on Monday 18 April 2011 by J. D. Bartlett

Mr J. D. Bartlett,

To His Royal Highness King Larry, by the grace of God, King of Google, Lord High Executioner of Blogger, Emperor of YouTube and his other domains.

Monday 18 April 2011

 

Your Royal Highness,

First of all, allow me to congratulate you on your recent ascension to the throne. As your loyal subject I was somewhat disappointed that I was unable to attend Your Majesty’s coronation. I was hoping that Your Highness would hold the ceremony somewhere conspicuous and easily accessible in the realm of YouTube, but alas, the momentous event seems to have passed without fanfare.

I write this letter in response to the recent education reforms in the land of YouTube. As I understand it, citizens of the realm who have been caught in the act of piracy are to be given a chance to reform their behaviour by sitting an examination pertaining to matters of copyright and copyright laws. Those who refuse to sit the exam will face the harshest penalty imaginable: exile.

I heartily approve of this measure. Indeed, I am writing to humbly request that Your Majesty extends this measure. It seems to me that, should Your Majesty so desire, similar examinations could be put in place for citizens who break other laws and conventions of the land. For instance, your highness is no doubt aware that YouTube, while renowned for the many grand works of art that its citizens produce, has long repulsed visitors by the sheer quantity of garbage found in her streets and commentways. Perhaps Your Majesty would consider requiring citizens with three downvotes to take an examination or risk exile from the realm. Perhaps, in time, similar punishment could face those dastardly citizens who upload pointless or misleading videos.

I commend Your Highness on taking such a deep interest in the affairs of your subjects and I look forward to witnessing your future decisive actions in these matters.

Your humble servant,

J. D. Bartlett.

Posted in midlength | Tagged , , , | Comments Off on A Letter to King Larry

Does a DUO Pen Work in Ubuntu

Posted on Monday 11 April 2011 by J. D. Bartlett

I’ve recently bought a PnF DUO Tigital Tablet Pen. Basically it’s a pen and a sensor which use ultrasonics to turn your screen into a touch screen. PnF provides supporting software for Mac and Windows, but not for Linux. In this article I discuss the pros and cons of using this product with Ubuntu, based on my own fiddling.

Does it Work?

The short answer: yes, with a little bit of set-up

The slightly longer answer:

  • The DUO Pen sensor is a USB Human Interface Device. It behaves like an external tablet device, so it will work as a pointing device out of the box. Be warned, it will be initially uncalibrated, so the position of the pointer will not match where you’re actually holding the pen.
  • The DUO Pen provides another USB endpoint (endpoint 3) which the Windows support software uses to send calibration details to the device. I haven’t decoded the exact signals sent to this endpoint, but basically, when you use this device on Windows, the sensor itself remembers the calibration details. This means that you may need to perform a calibration using Windows / Mac OS before you use it in Ubuntu.
  • I couldn’t get the right-click functionality to work under Ubuntu. In Ubuntu, pressing the right-click button behaved exactly the same as left-clicking. Under Windows, right-clicking worked fine. I didn’t spend the time to figure out why.

Calibrating the DUO Pen

Using xinput_calibrator

While playing around with my DUO Pen, I came across xinput_calibrator, which provides software calibration for touchscreen devices. It’s packaged for Debian/Ubuntu and source code is also provided. I built it from source and I found it refreshingly easy to build.

To use xinput_calibrator, first list all the pointing devices connected to the system:

$ ./xinput_calibrator --list

Then run xinput_calibrator with the device you wish to calibrate, selected from the list.

$ ./xinput_calibrator --device "HID 1b28:4617"

The thing to be careful of here is this: if the hardware calibration of the DUO Pen is such that your pointer can never reach the edges of your screen, no amount of software calibration will solve your problem. You’ll need to change the hardware calibration either by using a Windows / Mac computer, or by writing a driver for calibrating the device.

Using the Windows Support Software

I’ve only done the calibration on Windows, so I can’t comment on what it’s like on a Mac.

If your computer is set up to dual boot, I imagine that you could attach the sensor to your screen, boot to Windows, calibrate the device, then boot to Linux and everything would work just fine. In my case, I calibrated my Ubuntu desktop computer using my Windows-booted laptop. I attached the sensor to my desktop monitor but plugged it into my laptop. Then after launching the calibration program, I measured (with a ruler) the positions of the points where it asked me to touch. I scaled these to the size of my desktop screen, and created a graphic in Inkscape to help me to press the right points. After calibrating in this way, I still had to use xinput_calibrator on Ubuntu to get the calibration right.

A word of warning about the hardware calibration: if your sensor is very close to but not quite parallel to the side of the screen, it’s possible for there to be some points on the screen which the sensor can’t unambiguously triangulate the position of. If you use the Windows software to calibrate the device for a configuration like this, the pen will stop working as a pointing device. If this happens, simply adjust the position of the sensor (move it a bit further from the screen and straighten it if possible), and perform the calibration again and it will start working.

Cracking the Code

If any of you are adventurous enough, you could write calibration software for Linux. Or you might just want to record the messages which your particular calibration sends to the device so you can replay them to the device from within Linux. In either case, you’ll need visibility of the communication between the Windows driver and the USB device.

The resource I found most useful in this regard was an article by Jesper Thomschütz (Jespersaur) on reverse engineering the Windows USB driver for the Luxeed LED keyboard. This article was particularly relevant because the DUO Pen is a Human Interface Device so, like the Luxeed LED keyboard, using a Windows virtual machine and intercepting its packets in Linux will probably not work (I didn’t actually try it).

In his article, Jesper said that he couldn’t get any useful data using USBSnoop, but SnoopyPro worked for him. I had the opposite experience. I couldn’t get SnoopyPro working, but USBSnoop worked quite well, though things did not quite work the way that the howto document described. My notes:

  • My DUO Pen had a vendor id of 0x1b28 and a product id of 0x4617. So in USBSnoop, it appears as “USB\Vid_1b28&Pid_4617&Rev_0000”.
  • I found that after first running the software, selecting the device and clicking “Install”, I had to restart the computer before the capturing would work.
  • The howto describes having to click “Install” and “Replug” every time you plug the device in, and “Uninstall” and “Replug” after unplugging it. I found I simply had to physically unplug the device, delete the log file, and physically replug it.

The howto document for USBSnoop also contains instructions on replaying in Linux USB data which was captured in Windows. I haven’t attempted this part of the howto myself.

Conclusion

The PnF DUO Digital Tablet Pen works ok under Ubuntu, but you may need a Windows or Mac computer to perform the initial calibration.

Posted in long | Tagged , , , , , | Comments Off on Does a DUO Pen Work in Ubuntu