Guylhem Rom: First Qtopia 1.5 Release Options

[guylhem]

Hello

The first "end user ready" release is being uploaded. It features a nice GUI and should work out of the box (no command line special knowledge should be necessary)

Get it on: http://externe.net/zaurus/guylhem-rom/

The only bugs I could find (and honnestly, they are not serious drawbacks) are:
- some remaining keyboard remapping (power/record are used like a jogdial, but should also be able to start applications - they can't yet)
- the network application refuses to add new interfaces. So I replaced the usual netsetup by a different one I compiled and I created a "Get online" icon, which can be used to create a new connection, before using the network application (that's the only if you really want to use the old one called netsetup.old). I have no idea why it doesn't work :-( Trolltech version works fine, Sharp doesn't. Any help would be welcome

If you feel like giving a try, your feedback would be very welcome. What you get :
- a polished qtopia 1.5 rom loaded with applications
- a cleaned filesystem (no symlinks everywhere)
- 24 Mb free to add your own applications (I doubt you'll need them - it's *loaded* with applications, basically every app I use is there, PIM, Hancom, Opera, etc etc.)

What's new since last version :
- added qtopia 1.5 interface
- made sure it worked well
- fixed the zoom/systemtime bugs reported in the standalone qtopia packages.

What's missing :
- special modules used by special card. If you have such a card, please tell me or adf so we can compile your missing module for you

To install it, simply restore the nandbackup. That's all. On reboot, you may see jffs2 errors - that's normal. It's just very verbose. You are presented with a login: if you log in, qtopia won't start. Press home twice to open another console. Press userkey/light to move between consoles. You must log out of every shell so Qtopia may start 30 seconds later. However the keyboard may not be usable if you didn't return to the first console. So if you want to use qtopia, simply don't log in.

Anyway, let's start the beta test ! I'm also preparing a dedicated feed for the ROM. If you have a .ipk that works fine and you think should be interesting to other people, please send me a URL where I can download it and add it to the feed.

If you think some application should be included by default, please tell me too. I'd like to create a "different" rom, very user oriented. Everything should be simple and work out of the box - the apps. I did choose tend to do that.

Guylhem

[guylhem]

Hello

Regarding the keymap, I tried to match as closely as possible a standard pc keyboard, to avoid problems when using different kind of keyboards (external internal etc). A 100% match was not possible because in qtopia keycode 30=Fn is hardcoded, while on a pc keyboard keycode 30=A. So I used keycode 125 (left window) for A, and 30 for FN. Besides that it's a 100% pc keyboard. Specials keys (ex: Address, Home, Power...) have been remapped to F1->F12 so you can use them with a standard PC keyboard and pocket-pc keyboard (IIRC pocketpsc have a similar F1->F12 remapping for their special keys). Please read driver/char/tosa_rawmap.h and the tosa_keymap.map if you need more details.

It may sound like a big hack but it's the cleanest possible solution. With qtopia 2.1 the 125/30 difference will go and it'll be a 100% standard pc keymap.

So if you have keyboard problems now, 2 solutions :
- only a doesn't work: this means you are using a standard pc table. swap 125 and 30 in the source code of your applications
- most keys don't work as they should : this means you are using a dead beat zaurus table. Use a standard pc table instead. Can't help much :-(

I'll try to look into vnc issues. I've added keypebble as requested. The fbvncserver removal notes maybe should go in the FAQ? I'll edit the postrm scripts to add that to make sure it uninstalls cleanly.

As for interfaces and applications, I don't want to dictate my choice but I think I'm quite close to the truth (if there's any :-) - that qtopia is the solution, and end users applications should be provided. More could be provided - integrating perl is certainly possible, but IMHO since it's a language people who need it certainly know how to do "ipkg install".

I'd like to minimise the complexity of using this rom for most people. This means that big hacks (ex: moving Qtopia to the SD, etc) will not be configured by default, but I'll do everything I can to help them: I wouldn't want such hacks to damage normal interfaction with the ROM (no boot questions : reflash and it works :-)

A good possibility for other UI would be using different directories in /opt which could be mounted to external medias. If you guys can create a Qtopia 2.1, GPE, PdaXrom tarball that simply requires untarring and symlinking, I'll be happy to provide them with the ROM, along with instructions on how to use that. adf, if you reflash to 2.1 soon, please tar cvf /opt/QtPalmtop or whatever they are using and put the tarball online. I'll try to make it work on the 1.0rc1.

Anyway, this is getting too long :-) I'd like to conclude simply - everybody who wants to participate in the rom, to give a hand, is welcome. [even nice icons are needed for apps which have non VGA icons.] A CVS is not really possible at the moment (to have a big partition, you need to reflash, but once you've used guylhem rom you could certainly do upgrades with simples patches), neither is a simpler "initrd.bin and power+ok" install, but I'll think about what we could do.

I tried to do the initrd.bin etc approach and had big problems with my Z. I lost important data. If I get donations or if I'm offered a spare 6000 to work on the rom, I'll certainly be able to develop much easily, but for now I'd rather play it safe :-)

Maybe it could be a CVS of the root filesystem, so anyone can edit the files and submit modifications ? But IMHO there's not a strong demand. I haven't received many patches. I'll post the root filesystem for 1.0rc1 online soon, with installations instructions for those who want to hack. But IMHO a nand reflash is much much better (you're sure it will always work)

Anyway I'm open. Please tell me how you think the development should go, and if you like the roadmap. As adf said, I'm not quite satisfied by opie/oe/oz. I've to publish an editorial (soon - really :-) on my thoughts, but basically 1) braking binary compatibility is bad 2) shipping unfinished/untested distributions is worse 3) imposing developpers/contributors to use the entire buildsystem weighting several Gb is like telling them "please don't contribute".

[CoreDump]

Anyway I'm open. Please tell me how you think the development should go, and if you like the roadmap. As adf said, I'm not quite satisfied by opie/oe/oz. I've to publish an editorial (soon - really :-) on my thoughts, but basically 1) braking binary compatibility is bad

Actually, in this case it is good. Good as in a 100-300% floating point performance increase and overall faster application launch times. Anyone who has used a Sharp ROM who now uses an OZ ROM knows what I'm talking about.

2) shipping unfinished/untested distributions is worse

The current OZ branch is labled "unstable" for a reason.

3) imposing developpers/contributors to use the entire buildsystem weighting several Gb is like telling them "please don't contribute".

I beg to differ.

CODE

+mhentges@oe-head:~/OpenEmbedded/bitbake >du
262M    .
+mhentges@oe-head:~/OpenEmbedded/bitbake >

The full uncompressed build environment is about 260MB (snapshot from today, FWIW), not "several GB".

However, it appears to be logical that one needs to compile all dependencies in order to build a certain application. The build environment will do that automatically for you.

Maybe you were talking about the HDD space consumed by upstream sources and binary packages including all dependecies?

CODE

+mhentges@chroot01:~/OpenEmbedded >du sources/  tmp
1,3G    sources/
5,8G    tmp

This is the disc-space required to build an opie-image and to compile about 80% of all available opie apps in OE. Opie-Image alone shoud be well below 3GB

If you can't spare a lousy 3-5GB w/ todays HDDs prices you are indeed out of luck. But that is hardly the fault of OE or OZ.

[guylhem]

Anyway I'm open. Please tell me how you think the development should go, and if you like the roadmap. As adf said, I'm not quite satisfied by opie/oe/oz. I've to publish an editorial (soon - really :-) on my thoughts, but basically 1) braking binary compatibility is bad

Actually, in this case it is good. Good as in a 100-300% floating point performance increase and overall faster application launch times. Anyone who has used a Sharp ROM who now uses an OZ ROM knows what I'm talking about.

That's right. It's much better. But at the same time, you are using a different sync method, not providing libsl equivalents etc. etc. so compatibility is broken at multiple levels. That's sharp fault for imposing libsl and other oddities, but there should be an intelligent workaround.

I mean, using softfloat is not the problem by itself - softfloat is good ! Mostly for the binaries which can take advantage of it, say mplayer. In fact, they could use LD_PRELOAD while the rest of the system would stay in hardfloat until a good solution is found (zync was very promising) to be 100% sharp compatible where it matters.

2) shipping unfinished/untested distributions is worse

The current OZ branch is labled "unstable" for a reason.

Then don't ship it and don't announce it. Or ship it without GUI (I did that :-) - it prevents end users from giving it a try when they shouldn't. If you don't do any of that, people will install it and complain.

3) imposing developpers/contributors to use the entire buildsystem weighting several Gb is like telling them "please don't contribute".

If you can't spare a lousy 3-5GB w/ todays HDDs prices you are indeed out of luck. But that is hardly the fault of OE or OZ.

I can't. And it's OE fault, unless there's a misterious "bitbake offer me a new HD" option I don't know. Go to externe.net/zaurus/sdk. You'll have the 2.95 toolchain and 1.5 qtopia in less than 200 Megs- so you can do differently.

Just give me the same for OE ! All I'm asking in the 3.4 toolchain and the /opt/Opie. I don't want everything else. Hell - just give me the 3.4 toolchain for x86 in a tarball and I'll be happy :-)

I've been asking that for weeks. I don't want the crosstools script version, I want your version. Why is it nowhere on the website to download? Why could nobody offer me a tarball? I really don't have 2 Gb. In fact I have 155 Mb free at the moment on my 40 Gb disk. And I won't purchase additional space - because I don't need it, except if I want to play with OE.

Don't get me wrong. OE is impressive, and you are doing great things. But I think it could be even better if little modifications were done - the ones suggested above, and (flame flame) dropping opie and moving to qtopia 2.1 while fixing/porting apps to use it!

You know the motto : destroying is the easiest, creating is harder, maintaining/fixing is the most complicated. The hard work is on making something compatible while fixing issues at the same time.

[adf]

you have mail ( I think)