To help figure out what is going on, here are two commands (run as user in an X terminal) and their output (exact) on my N900. I have a US N900 that I purchased from amazon.com. And I flashed it with
RX-51_2009SE_1.2009.42-11.002_PR_COMBINED_002_ARM.bin
The output here also match yours, no error, but the keyboard has exactly the same behavior as before, only the letters work.
After the setxkbmap command, type a key on the internal keyboard then type a key on the bluetooth keyboard. I don't know why this is necessary but I found on mine it is both necessary and sufficient.
Also I found that sometimes (but not always) after doing this, the Enter key on the bluetooth keyboard has no effect in an X terminal even though it does have effect in an Emacs window. But Ctrl-J and Ctrl-M can generate Enter. I don't know why this sometimes (but not always) happens.
After the setxkbmap command, type a key on the internal keyboard then type a key on the bluetooth keyboard. I don't know why this is necessary but I found on mine it is both necessary and sufficient.
Also I found that sometimes (but not always) after doing this, the Enter key on the bluetooth keyboard has no effect in an X terminal even though it does have effect in an Emacs window. But Ctrl-J and Ctrl-M can generate Enter. I don't know why this sometimes (but not always) happens.
Enter+letters+backspace+space+arrows work without problems so far (no need to modify anything), swift, numbers, special punctuation,... doesn't work.
Also I found that sometimes (but not always) after doing this, the Enter key on the bluetooth keyboard has no effect in an X terminal even though it does have effect in an Emacs window. But Ctrl-J and Ctrl-M can generate Enter. I don't know why this sometimes (but not always) happens.
It appears that this correlates with whether the internal keyboard slider is open or closed. If it is closed then the Enter key on the bluetooth keyboard doesn't work in an X terminal (but does in an X windows Emacs). If it is open then the Enter key on the bluetooth keyboard does work. I don't know why.
Everything went smoothly, until I got to my second xkbcomp check...
Code:
% xkbcomp -i 4 :0.0 /tmp/post-setxkbmap.txt
...at which point it became apparent that my setxkbmap command is not actually changing anything.
The two output files are identical (anybody know how to get 'diff' on the n900? I had to transfer the files to my laptop), and the keyboard behavior has not changed.
Ran as 'user', $DEVICE bound to :0.0, bluetooth device ID 4, No errors, verbose (-v 10 -print) output identical to qobi's, etc..
I had left the "-print" argument in my script, so setxkbmap wasn't actually doing anything. Now I get the same error ("Error loading new keyboard description") as everyone else (other than qobi).
Does anybody know the point of the blank "-I" (as in "eye") argument? Does it rely on any assumptions about the present working directory from which the command is executed?
Variations on the setxkbmap command get me variations on the error...but nothing that makes me happy.
Does anybody know the point of the blank "-I" (as in "eye") argument? Does it rely on any assumptions about the present working directory from which the command is executed?
It only works for me if I specify two -I, the first one blank. My guess is that the first blank -I clears the default path. The man page for setxkbmap (on Debian Lenny) doesn't mention anything about this:
-I directory
Adds a directory to the list of directories to be used to
search for specified layout or rules files.
But the man page for xkbcomp (on Debian Lenny) says:
-Idir Specifies top-level directories to be searched for files
included by the keymap description. After all directories
specified by -I options have been searched, the current direc-
tory and finally, the default xkb directory (usually
/usr/lib/X11/xkb) will be searched.
To prevent the current and default directories from being
searched, use the -I option alone (i.e. without a directory),
before any -I options that specify the directories you do want
searched.
