I want page up/page down to work in xterm. There's a way to get at the functionality using a "toolbar" but that wastes screen real estate for keys. For every other key I need, I was able to use xmodmap (see this thread for details). That was so easy, I figured it had to be capable of taking this on. Indeed, I added the following definitions:
keycode 104 = Return Escape Escape Escape Escape keycode 111 = Up Prior keycode 113 = Left Home keycode 114 = Right End keycode 116 = Down Next
So I can do Fn+D-pad center and get escape, plus I have page up/page down/home/end by holding down shift with the d-pad directions.
However, this was totally useless, as the Maemo xterm gobbles these keys and turns them into scrollbar ops! I investigated some and this is not your typical overeager xterm configuration, this is a specialized app called osso_xterm. osso_xterm is advantageous for a variety of reasons, I'm sure, and the extensions (easy font control, use of the maemo menu system, good response to fullscreen) all work so easily that I do not want to give it up. But it uses something called "VTE", which is basically a GTK widget that provides a terminal. Very slick, and so on, but it has this flaw. It hardcodes certain _useful_ keys to useless functionality. The most moronic part is it contained remappings for both Prior and KP_Prior. It could have trapped just one of them and let us bypass it but nooOO!! Well, plus at least one of the guys to hack on it was kind of a moron, but I digress (and aren't we all, at moments, anyways?). Anyways, it's open source software sooooooo...
Now, I am not good at unraveling what to do when configure fails. It didn't want to build under scratchbox2 effortlessly because it wanted some more of a gnome environment than I had provided. So be it. I threw together a Makefile and config.h manually and was eventually able to compile it in the hackiest fashion possible. Then I modified it. I fixed what I perceive to be a bug applying shift to special keys (if the key says it doesn't care about modifiers, it shouldn't care about modifiers), and I also removed these hardcoded scrollbar operations. Problem solved, osso_xterm is now totally usable.
So this is a little lesson in open source. The things I am up against are unwieldy behemoths, just as in any closed platform (such as windows) or semi-closed platform (such as OS X). But unlike OS X, my enemy is autoconf/automake, which are very easy to bypass. My enemy is a short-sighted open source hacker, and I am his equal (he grants me this right, I love him for it). And so on. Result = victory. Anyways if anyone also wants page up to work in osso_xterm, 
Oh, discovery! That useless key below the "home" key is escape!
I figured out fullscreen. Apps have to handle it independently. There is a key "HILDON_HARDKEY_FULLSCREEN" (GDK_F6) that you receive KeyPress events for, and on those you can call gtk_window_fullscreen()/gtk_window_unfullscreen(). Easy enough. The wm doesn't handle it (neither does HildonWindow) because so many apps have specialized fullscreen behavior. The gtk_window_*fullscreen() functions just (I think) generate the WM events to tell the WM to do it. So it should be easy to do outside of GTK as well.
It is exactly this easy to generate outside of GTK:
static void
toggle_fullscreen(Window win)
{
XClientMessageEvent xclient;
memset (&xclient, 0, sizeof (xclient));
xclient.type = ClientMessage;
xclient.window = win;
xclient.message_type = XInternAtom(ggl_x_display, "_NET_WM_STATE", 0);
xclient.format = 32;
xclient.data.l[0] = 2; /* _NET_WM_STATE_TOGGLE */
xclient.data.l[1] = XInternAtom(ggl_x_display, "_NET_WM_STATE_FULLSCREEN
", 0);
xclient.data.l[2] = 0;
xclient.data.l[3] = 0;
xclient.data.l[4] = 0;
XSendEvent (ggl_x_display, x_root_win, False,
SubstructureRedirectMask | SubstructureNotifyMask,
(XEvent *)&xclient);
}