Guylhem Rom: First Qtopia 1.5 Release

[hbo]

Got it regarding the relationship of this ROM to OE/OZ. It's sort of like Cacko, but for the 6K. That's worth pursuing.

I'm looking at fbvncserver first, assuming it's going to be similar to the debian package. Just now, I'm having trouble with tssimd and kbdsim, so I can't reproduce the odd stuff I was getting earlier.

Did you ever find a workaround for the package manager and external storage?

[hbo]

Well, I got to remember how to recover from uninstalling fbvncserver. Removing the package leaves the touch screen shim in place, so I did 'rm /dev/tssim;reboot' which left me without a working touch screen. That's because the install changes the /dev/ts file into a FIFO, which tssimd presumably reads before passing the data on to the real device, which is /dev/sharp_ts. The fix is to do 'ln -sf /dev/sharp_ts /dev/ts' and reboot. I had done this once before on my 5500, so the whole situation was vaguely familiar, LOL.

Reinstalling fbvncserver and perforing the calibration got me to a working console over VNC from my SuSE laptop. I confirmed that the keymap is completely scrambled. I'm comparing the contents of keysim2scancode.c from the fbvncserver-0.9.5 sources (the latest available on the SDG website) to keycode.tbl from externe.net. It appears that the scrambling is due to a mismatch in these two files. I haven't tried building fbvncserver yet, but I notice that the file in question contains the line:

   #include "keysym.h"

Which isn't in the distribution. Perhaps it's in the libvncserver distribution which is mentioned as required in the README.

That's enough for tonight.

[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".

[Mickeyl]

[deleted]

[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: [Select]

+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: [Select]

+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.

[hbo]

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 :-(

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79891\"][{POST_SNAPBACK}][/a][/div]

I think this will be a problem going forward. If applications have to be patched to work with your ROM, it means that forks of those apps will have to be maintained by the project. Each time there is a new release of, for instance fbvncserver, someone will have to do the work to integrate a patch to make the guylhem keyboard map work with the app. There will be user confusion as well. Even if fbvncserver, again for example, is included in the base release, a user may very well run out and install the newest release from SDG. When they keyboard fails to work, the user will be mystified. I also note that there are issues with IR keyboards. "Sell your keyboard" isn't a great response for the general user population.  

Is there another way to approach the problem of supporting a full PC keyboard? I assume what you are trying to do is to support all the keys that don't work with the standard map. From the fbvncserver README:

      6 - Known bugs/limitations

    - Because the keyboard simulation happens at the lowest level in the kernel,
      it can't simulate quite all the keyboard inputs you'd normally find on a
      full-size keyboard.

Is there any way to supplement the Zaurus keyboard map and yet leave it upwardly compatible with the unique mapping most apps expect?

[guylhem]

Honnestly, there's no best way I know. Breaking everything if using sharp model is not an option, since it means that you won't be able to use normal keyboards in acceptable ways (that means no Fn keys, no keypad, no edit keys - or no external/internal keyboard combination at the same time).

To make it work, the keymap has to be changed- there's no other way -I tried everything.

Since it has to change, the best solution for the changes is to mirror a standard PC keyboard keycodes, so that you gain compatibility with USB/bluetooth keyboards. Regarding IR keyboards and fbvncserver, they have been changed to support the broken approach.

This will cause minor compatibility problems with default Sharp ROMs/applications, due to the hardcoded keycode for Fn. Recompiling (or editing the binary if you feel like hacking) could fix them. I opted to swap 125 and 30 in the /opt/Qtopia/etc/*.tbl, to make the problem go away without too much hacking. Yet I intend to clean that better in the future - hopefully with a recompiled 2.1

IRK and VNC will soon be fixed.

[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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79894\"][{POST_SNAPBACK}][/a][/div]

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)

[hbo]

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.


[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

They did that:
 [a href=\"http://www.openzaurus.org/official/unstable/3.5.3/sl6000/bootstrap-image-tosa-20050409225341.rootfs.jffs2]http://www.openzaurus.org/official/unstabl...41.rootfs.jffs2[/url]

I'm annoyed by basic things not working in Opie 1.2, but I make allowances for the fact that it's a development release. (I do think they have been unwilling or unable for a long time to produce a "stable" release, but that's another matter.) I give you the benefit of the same doubt. There are even more basic things broken in 0.9, but I'm not complaining: I'm contributing.

[hbo]

You do provide source to the GPL binaries you redistribute, don't you Guylhem?

And, patching binaries just isn't sustainable, let alone ethical/legal. You have no guarantee you will be able to pull off the same hacks in the next version, or the next or the next. And you are only one guy. If you play by the FL/OSS rules, you get to leverage a lot of extra help.

Update: Hmm. I see that muesli321 just joined the forum today. Could it be I've been trolled?  :

[adf]

I would say you got trolled.  

 

btw.. anyone looked at damnsmall linux?  the guy that does it has a dillo (for those who use X/gtk--gpe, pdaX, Pocketworkstaion) that does frames and ssl. might be worth compiling for pw.

[hbo]

I would say you got trolled.   

[div align=\"right\"][a href=\"index.php?act=findpost&pid=79932\"][{POST_SNAPBACK}][/a][/div]

Maybe so. But the idea of patching binaries for general release is disturbing to me. I get the impression that Guylhem thinks that's the right solution to make binary-only packages work with his ROM's non-standard (for the Z) keymap.  I have problems with this when the source is available, as I've noted here. Doing that for your own use just to get something working is understandable (although probably illegal in the case of proprietary code,) but basing a distro on that is, well, it's insane. It won't scale. It means this project can;t go much of anywhere. People who respect copyright law, on which the GPL rests, after all, will reject it because of the illegal nature of the binaries.  Those who ignore that aspect will find sooner or later that a particular app they have been relying on can't or won't be adapted to the g-ROM after some major change in the app or the ROM.

Please tell me I'm wrong about such patching being the general approach here.

[adf]

last time I checked all the patches were on externe.net/zaurus/kernel , I think.

The binaries got posted in /flash/.....  and there were separate parallel dirs with source and patches.

If the current set isn't up yet, I am assuming it will be.  Have a look.  

I think the troll was about opera, etc in the Qtpalmtop.rom not having source posted. I take that to be more of a fair use issue, as it doesn't pretend to be anyting but sharprom on a nand resize, and anyone with a 6k is entitled to use sharprom.   afaik the patches that are actual new guylhm rom stuff get posted.

[adf]

of course, if using guis made by people other than guylhem gets to be an issue, then I guess it is back to my gui ripper script idea, that would be freely distributable and all ow people to successfully use and rip guis on their own? (fair use stuff again).