After a couple days of tinkering, I still can't figure out where the chroot is getting it's default path information under sh.

But, BASH is much easier to change. Change /etc/passwd so that 'root' and 'user' use /bin/bash instead of /bin/sh. Then alter /etc/bash.bashrc (under the EasyDebian chroot) and add
PATH=${PATH}:/any/other/paths:/more/paths
to the end of that file. If you don't want to do the ldconfig I mentioned earlier, you can also add a LD_LIBRARY_PATH to the end of this file. (Don't forget to export LD_LIBRARY_PATH). Ldconfig is the cleaner way to go though (for the purists out there).

PS1 (the default prompt) is set in /etc/profile. Mod it to your hearts content.

Finally, if you want to be able to 'su user' (so you aren't root all the time), you will need to change /etc/login.defs. You will want to change the line that starts with ENV_PATH to be the non-root users default path. If you want to 'su back to root (say from LXDE), you might want to do the root version right above it too.

There you go. A working set of environment variables for development.

Add in this cable mentioned in this thread attached to a USB keyboard (Walmart) and I'm good to go!

Great part is that none of this affects my 'default' maemo environment (different lib versions, etc), and since the partition is on the external card, it doesn't die if I have to reflash!

For those worried about space, I took the full EasyDeb package, ran localepurge, bumped it to a 3G partition, downloaded most of the Gnu toolchain, subversion, a couple of (largish) custom libs, xmeacs (hoping to use with usbmouse.deb (didn't work)) and the current projects I am working on. I still have about 1.5G of my 3 left.

OK. One more question.

If I use the regular maemo xterm, or the debian chroot (which is just the regular xterm running a specific comman), then I have access to all the changes I made to the rx-44 file. Tis very nice. When I plug in my external keyboard via the USB port, it uses a standard 104-key layout. In other words, by 810 HW keyboard works the way I programmed it to, and my USB external works the way the keys say.

But, if I fire up LXDE things are a little different. It looks like qole made good on the promise to grab the .Xmodmap file from someone and stuck it in. Took me a while to notice, because they chose about the same mods as I did (great minds think alike?). The problem is that Xmodmap overrides all keyboards, not just defines a keyboard.

This is a problem because (for whatever reason) Nokia did some odd things with their (American) keyboard. For instance, on a regular US keyboard, the 'plus' key is a shifted 'equals'. On a Nokia N810 US hardware keyboard, you get the equals from FN 'plus'.

So, with the .Xmodmap in place, I lose the ability to press = and ".
(since the Xmodmap relegates them to Fn-land).

I can copy the xkb files from the Maemo section to the debian partition (in fact qole's scripts do that automatically), but they don't seem to work.

When take out (via a mv) the .Xmodmap-keymap file, all I get is the standard US keymappings.

So, Maemo is doing something with the xkb files that LXDE is not. Seems like it should be fairly straightforward to find the difference and fix it, but so far I have not had any luck.

Does anyone else out there have more experience with using xkb? Specifically in either setting up LXDE to use (all) the maemo kbd files, or where in maemo the X config files are (so that I can compare them to the LXDE versions.

Thanks

I don't have an N810, so I can't comment much on your problem. But I can say that there are two .Xmodmap files, one for the N810 and one for the N800. Perhaps you could switch to the N800 one for your external keyboard? The two files should be clearly named in your home directory...

They are, and I could either do that, or swap the file in and out (rename via script as needed). I was hoping to come up with a way to gain the native ability to 'do the right thing automagically'.

That is not possible to do with .Xmodmap (unless you do the fileswitching), as the two keyboard layouts are exactly the opposite of each other at least for the +/= key (Nokia uses unshifted +, standard keyboard uses unshifted =).

It looks like LXDE does have the ability to do xkb. I just need to find out how Maemo 'knows' how to map each keyboard to the correct xkb file, then figure out how to map that into the chroot environment (since at least some of the paths aren't the same).

BTW, qole: are you still actively working on the .ext image file for
the Debian image? If so, would you be interested in some 'pruning' that can be done to cut the size down? It should be at least a couple of megs, but might be more. Lots of little files scattered here and there that got left over from things it looks like you pulled from the image (icewm stuff, for instance) or from 'debianisms' that you aren't using (since it isn't a full system).

If you ever plan to release a newer version of the image file it might be useful.

elschemm:

If you want to make a pruned, lean-and-mean rootfs for me, I will gladly use it in a future release. I just did an update last month, but I'll do another one if you can strip out a significant amount of cruft...

You can either post instructions for removing the cruft, or I will give you upload privileges to my server and you can upload a tarball.

Thanks. I just grabbed a copy of the file again and copied it to my big work computer. I'll keep two versions. One that's stock and one that has my changes. Then if I find enough I can email you the list of files.

BTW: Is there any particular reason that you have the file tarred? Tar does not compress things at all, in fact it makes things slightly larger than the original. It's only about 10K for your current image, but thats 10K of wifi-download plus the untar time.tar

Thanks, I would appreciate that (as would many others, I'm sure).

You've got a point. Why not just compress the file instead of tarring and compressing?

I guess it was just a habit... I tar and compress the rootfs file (for good reason, it contains many many files), so I just automatically did the same for the image file.

I'm not really a developer, everything I've done here someone else in the forums patiently taught me

I wonder how much extra time is added to untar and un-bzip2-it instead of just un-bzip2-ing it?

On my Dual-Quadcore 3.2 GHz with a high speed SATA drive, untarring only took a few seconds. But, thats slightly more hardware than the N810 has.

For comparison, the bunzip takes 36 seconds.

So, using this totally un-scientific info, you _might_ be able to save 15-20% of the time. Have to try it for real to see for sure.

Frankly, I suspect it will depend on the memory card. Since there is only the one file, it should amount to a file copy from the device to the device. It's going to have to pass into memory first, since I don't think tar would be smart enough to issue a direct disk copy. The read is going to be sequential, as well as the write. I've read a few places that SD cards don't handle that as well as random. Of course, since you are alternating the read and write, maybe that's not an issue.

For somebody with a 'cheap' Class 2, it will likely take longer than someone with a 'well designed' Class 6. (I'll leave the arguments on which vendor is which to other threads)

If memory serves though, there was an issue in one of the EasyDeb threads about people using an older/non-gnu version of tar to untar it. Removing the tar would solve that dependence.

Bummer. Not having a lot of luck with the xkb stuff.

From what I have found, it looks like Xephr is hardcoded only to look at event0 - event3 (from strings). I'll have to see if I can find the source code somewhere and verify that.

You can mostly fix the problem by changing the following lines in the n810 .Xmodmap-keymap file:
keysym plus = plus plus equal
to keysym plus = plus equal equal
keysym apostrophe = apostrophe apostrophe question
to keysym apostrophe = apostrophe quotedbl question

The plus/equals key will still be backwards on the USB keyboard, but at least you can type an = now (shift-+).