Can't login to paspberry pi; raspi-config design bug

It's a second time I stumbled upon this issue. It's funny that the first time was so long ago that I forgot about it completely and had to troubleshoot the issue from scratch again. This is a good reason to finally write it down.

After you get a new version of raspbian image copied to your SD card and boot up the RPi, you'll be greeted by the raspi-config utility. It'll offer you to do a lot of things and, naturally, you'll follow the menu options from top to bottom. So, among the first things you'll do will likely change the password. Then, a few line down, if you're not in UK, you'll change the keyboard layout from the UK (default) to whatever (US in my case.) For the most cases it'll go smooth; however, there are occasions when it won't. What if your password contains a symbol character, say # (Shift-3 in US layout)? While still in the UK keyboard layout, this would be a British pound (currency symbol.) After you change your layout to say US, typing Shift-3 won't produce British pound sign anymore, rather #. So, the password is incorrect and you unreasonably keep calling yourself stupid for forgetting your password (as quite a few people did on RPi forums.)

So, now your only option is to power off RPi, pull out the SD card from RPi, insert it into another computer, open /boot/cmdline.txt, and append init=/bin/sh. Then unmount SD, insert it into RPi and power on. Upon boot up, the screen will look like RPi froze in the middle. Don't worry, it loaded the shell but for some reason did not show up the shell prompt. Just press Enter, and the shell prompt will show up. Now, type
    passwd pi
and Raspbian will ask you to change the password. Since you have your desired keyboard layout now, you can go ahead and enter any non-alphanumeric characters you want for your password. Unless you decide to change your keyboard layout again, you should be safe. Finally, you need to undo the change you made to /boot/cmdline.txt so that your RPi boots normally.

P.S.: what's the raspi-config design bug you ask? Well, IMHO, the sequence of steps should first offer you to change the keyboard layout, and then the password, not the other way around.

The frame size of the video does not match the settings

According to my popular search engine, this is not an unusual problem when dealing with H.264 video encoding. I, in particular, stumbled upon this one in Corel VideoStudio. My video was captured with Samsung Galaxy Tab using its out of the box video recorder. The compression algorithms are H.264 for video and AAC for audio. The frame size is 1280x720. What I was trying to do was a simple concatenation of several video clips. Selecting encoding output as "Same as first video clip" would produce the following error message:

I suspect that the default H.264 profile in Corel VideoStudio is the "baseline profile," for which the max supported resolution is 720x?, hence the error above. 

To work around this issue in Corel (the approach would be similar in other software packages) one needs to select a H.264 main profile, which supports higher encoding resolutions. Again, in Corel, choose Create Video File / Custom option. Then, select "Save as Type" = *.mp4, click Options, select Compression tab, and set video type to H.264-Main.

Finally, go back to general and notice new (higher!) resolution options became available. Choose the one you want. I was happy to enjoy the 1280x720 option.

 Happy encoding!

Solving "can't read Hotmail e-mail"

Surprisingly, this issue is quite widespread. I fell a victim of it too. In short, I can log in to Hotmail (live.com,) but then clicking left and top menu items as well as e-mail subjects does nothing, no matter what browser I use. In my case it was surprisingly simple - I had Java applets filtered on my router. Disabling this filter brought Hotmail back to life for me.

Now, I doubt Hotmail uses any Java applets (can't say for sure though; just not interested in digging any deeper.) One thing for sure - I don't have Java installed, so there is nothing to block here. Most likely, this is an issue with DD-WRT build incorrectly classifying some javascript files as java applets, which is likely a good story for a separate post.

How to program DirectFB in C# on Raspberry PI (and other embedded devices / SoCs)

Raspberry PI is a very popular and extremely affordable ARM based computer. Among other things, it runs several flavors of Linux, including Debian (called Raspbian in R-Pi world.) Lots of interest in R-Pi world revolves around its graphics and how to unleash its power the easy way (which is not necessarily the right one.) For example, this post  raises an interesting question - how to access kernel's framebuffer via DirectFB in C# (mono.) I've been studying DirectFB for a few days now, and even though C is my language of choice, I have some experience in C#, so I decided to accept the challenge. Here is what I did:

1. Install mono runtime and c sharp compiler
apt-get install mono-runtime mono-mcs

2. Install directfb package for development
apt-get install libdirectfb-dev

3. Build and run directfb example drawing a single line. This is needed to test that DirectFB works properly on Raspberry PI. I copied the sample code into the line.c file, then compiled as follows.
Note that in order to run this successfully, your account needs to have read/write rights to the /dev/fb0 device (userspace interface to the kernel's framebuffer.) Alternatively, you can drop to the root shell.
gcc line.c -o line `pkg-config directfb --cflags --libs` sudo ./line If everything's fine, you should see a horizontal line on  a black background.    

4. Now it's time to try the same in C#. The obvious option is P/Invoke. If I were to develop a C# library for DirectFB, I would (have to) replicate all DirectFB structures in C# code. This is however an overkill for a proof of concept, so here I am cutting corners. It's not the best approach, but definitely the fast one. So I create another shared library in C that wraps the needed set of DirectFB API calls and exposes them to the C# world in a much simpler way. These calls accept no parameters and return void, eliminating the need to replicate numerous DirectFB structures in C#. The corresponding files are dfbwrap.h and dfbwrap.c:

dfbwrap.h
#ifndef __DFBWRAP_H__ #define __DFBWRAP_H__ #include <directfb.h> void Init(int argc, char **argv); void DrawLine(int left, int top, int right, int bottom, unsigned int rgba); void Flip(); void Dispose(); #endif

dfbwrap.c (compare this to the DirectFB line sample - they are almost identical)
#include "dfbwrap.h" static IDirectFB *dfb = NULL; static IDirectFBSurface *primary = NULL; static int screen_width = 0; static int screen_height = 0; #define DFBCHECK(x...) \ { \ DFBResult err = x; \ \ if (err != DFB_OK) \ { \ fprintf( stderr, "%s <%d>:\n\t", __FILE__, __LINE__ ); \ DirectFBErrorFatal( #x, err ); \ } \ } void Init(int argc, char **argv) { DFBSurfaceDescription dsc; DFBCHECK (DirectFBInit (&argc, &argv)); DFBCHECK (DirectFBCreate (&dfb)); DFBCHECK (dfb->SetCooperativeLevel (dfb, DFSCL_FULLSCREEN)); dsc.flags = DSDESC_CAPS; dsc.caps = DSCAPS_PRIMARY | DSCAPS_FLIPPING; DFBCHECK (dfb->CreateSurface( dfb, &dsc, &primary )); DFBCHECK (primary->GetSize (primary, &screen_width, &screen_height)); DFBCHECK (primary->FillRectangle (primary, 0, 0, screen_width, screen_height)); } void DrawLine(int left, int top, int right, int bottom, unsigned int rgba) { DFBCHECK (primary->SetColor (primary, (rgba >> 24) & 0xFF, (rgba >> 16) & 0xFF, (rgba >> 8) & 0xFF, rgba & 0xFF)); DFBCHECK (primary->DrawLine (primary, left, top, right, bottom)); } void Flip() { DFBCHECK (primary->Flip (primary, NULL, 0)); } void Dispose() { primary->Release( primary ); dfb->Release( dfb ); }

The line below compiles and links it into libdfbwrap.so which we will use in our C# app:
gcc dfbwrap.c `pkg-config directfb --cflags --libs` -fpic -shared -o libdfbwrap.so

5. Create and build C# app. I put my C# code into the client.cs:
using System; using System.Runtime.InteropServices; using System.Threading; namespace client { class MainClass { public static void Main (string[] args) { Init (args.Length, args); DrawLine(100,100,200,100,0xFF0000FF); DrawLine(200,100,200,200,0x00FF00FF); DrawLine(200,200,100,200,0x0000FFFF); DrawLine(100,200,100,100,0xFFFFFFFF); Flip (); Thread.Sleep(3000); Dispose(); } [DllImport("libdfbwrap")] static extern void Init(int argc, string[] args); [DllImport("libdfbwrap")] static extern void DrawLine(int left, int top, int right, int bottom, uint rgba); [DllImport("libdfbwrap")] static extern void Flip(); [DllImport("libdfbwrap")] static extern void Dispose(); } }

This is a build command:
mcs client.cs

6. Finally, run the result (don't forget about proper access for your account to /dev/fb0 or drop to root shell)
mono client.exe

If everything's fine, you'll see a square with red, green, blue, and white sides for 3 seconds.

DirectFB API has functions to draw a lot more primitives and also to render text which you can access the same way.

HP Pavilion g1310, no wireless in Linux after kernel upgrade

At some point I remember downloading Broadcom wireless driver sources from their website and compiling them manually. Some time later I upgraded Linux kernel from 3.5.0.16 to 3.5.0.23 and my wireless stopped working. With lspci I could see the device recognized by the system; however, lsmod would not show any wireless driver loaded.  This time I chose to install the driver source from the repository, which also compiles the sources and installs the driver:
    apt-get install --reinstall bcmwl-kernel-source

HP Pavilion g1310, linux boots into black screen

When booting HP Pavilion g1310 into Linux (Ubuntu 12.10, Linux 3.5.0.x),  it seems like the system hangs. At some point the screen turns black and nothing happens. This may be true for various laptops, not just this one. In reality, the system boots with brightness setting set to zero; therefore, system appears to hand when it does not. On this particular model, hitting F3 (or Fn-F3, depending on BIOS setting for functional keys) increases brightness and shows up login screen. Well, doing this every time the system boots is annoying. The solution:
1. Determine the max brightness value
    $ cat /sys/class/backlight/acpi_video0/max_brightness
    10
2. Add a line into /etc/rc.local to adjust brightness between zero and max_brightness (5 in my case) at boot right above the "exit 0" line
    echo 5 > /sys/class/backlight/acpi_video0/brightness
3. Reboot