This happens to me when you first turn on and turn off the keyboard. Not sure of the cause, but it appears to stem from the application not being notified completely of the input method change. Minimizing and unminimizing the application (or selecting a different application, then returning) seem to knock some sense into the app.

@ desktop:

Do you guys ever lose the BT connection with your keyboards (FM & TO)?

I have finally got my keyboard (the Freedom mini) working satisfactorily (not perfectly), and thought that I would share all the tips and tricks involved. So I wrote up a wiki page on Maemo. Check out http://maemo.org/maemowiki/HowTo_SetupKeyboard for the details. There isn't anything terribly new there, but it puts together bits and pieces from many different sources; I haven't found anywhere else that puts them all together.

Unresolved problems for me are:

• Typing still does not disable the screen blanking.
• The keyboard seems to disconnect excessively often.

I suppose that someone will eventually get the screen blanking sorted.

I think that using a newer version of the bluez drivers/utils might help with the disconnections. Does anyone know when Maemo is going to upgrade from the upstream source?

lon, that looks like excellent progress. I'd be happy justy to get the Num key working properly, which your fix appears to do. However, although I am reasonably PC literate from a hardware/windows perspective, I don't know Linux and I don't have a Linux box (which I think I'd need to get root?). Is there any way of achieving what you have without access to a Linux box and/or Linux guru?

Many thanks for this information

Without activating xmodmap, I had been able to use lower case, upper case and numerical characters in xterm. The Alt Gr key however is a bit strange. Pressing it with another key does not produce anything, for example E, R and T do not give the dollar, pound and euro signs as suggested by the green signs on the keyboard. However, pressing Num and Alt Gr simultaneously gives a numerical lock which gives a series of new characters with the shift key. In fact the shifted number keys are exactly what you get on the top row of a qwerty keyboard (for example shift-4 gives a dollar sign). Is this the same for your freedom mini when paired with the 770 without xmodmap?

Download the VMWare Player here:
http://www.vmware.com/products/player/

Download the Umbuntu virtual machine for the player here:
http://www.vmware.com/vmtn/vm/ubuntu.html

Then you can hook up your 770 to your Windows machine via USB and run the needed app to unlock root access. This is how I did it myself. You'll need the default root/user password for Umbuntu, which I forget, but somebody should be able to help you with that. I found it after a few minutes using Google.

Or you can use the Windows based release -51 firmware patcher posted in another thread, re-flash your 770 with the patched Nokia release using the Nokia firmware updater utility for windows, and then get access to root from xterm. Worked great for me and I'm a Linux neophyte...

Thanks Michael and eskin. I'll give one of those suggestions a try and report back.

Set up my su-8w with the 0.3 version of the BT plugin. Before I managed
to pair, this produced a few reboots, but it seems to be stable now.

My main trouble at the moment is that I can work via ssh on the
command line and in nano, but not in emacs, as many keys are not
correctly interpreted by emacs (in xterm). Could this be related to
the Opera bugs / multiline text input methods discussed in this thread?

To make my set-up clear: osso-xterm on the 770, ssh into a work
machine, all commands are run in the xterm window (no X forwarding!):

Examples of problematic inputs are ' ` (tick and backtick), which (on the
Nokia) one has to produce with the Fn key. (Interestingly, the numbers
and the +? sign work) I realize that the remote shell already gets
strange(?) characters, but seems to interpret them correctly:

When I type under od -ta
0+'
on the remote machine, I get as keys pressed
0+B4
i.e., the ' is seen as B4 although, e.g., the shell interprets this correctly.
Emacs, however, reads this as M-B M-4 with nonsensical results.

Anyone having any ideas? I am very much an emacs person, so this
"hurts" -- thanks,

Stefan

I can't speak as to all the details of your setup, but it is clear what is happening in your example: the keyboard is generating the Unicode character U+00B4 (ACUTE ACCENT), not the character U+0027 (APOSTROPHE), which is probably what you wanted instead. The character is then UTF-8 enccoded, which results in the two bytes 0xC2, 0xB4 being transmitted to the remote computer. Emacs isn't expecting UTF-8 input, so it interprets the 8th bit as "meta", resulting in M-B, M-4.

Solution: change your modmap so that apostrophe is generated, rather than acute accent. You may also want to configure emacs to accept 8-bit input (UTF-8 encoded).

Lon