Guylhem Rom: First Qtopia 1.5 Release Options

[adf]

absolutely. i'd love to see this quingy working on this rom.

maybe a mount script can be added... so that new users will just untar a gui to a card.. pop in the card and get a "mount blohgui on your systm Y/n?" prompt? this gets more interesting

[gfdsa]

thats the idea, adf, i did not advance lately, my wife took the device to read at home, so i cant try what i've compiled...

[hbo]

0
.0
it's simple, really. just su
and do mkdir /mnt/card/tmp  (or mnt/cf/tmp if you prefer it on cf) and then do
ln -sf  /mnt/card/tmp /tmp

do it from a console in qtopia?  This is exactly how I fixed the install issue.

That doesn't work when the new tmp is on cf. At least it doesn't when the cf is formatted with ext2. I got the "splash screen never goes away" symptom after making hhe change on my tosa. I was able to recover by using the "press / repeatedly after init starts" trick. When I got in to the text console, I saw that /mnt/cf wasn't mounted. Having /tmp pointing to nonexistent path makes some programs cranky, for some reason.

you could remove /tmp first.
or do ln -s instead of ln -sf (though i expect you'll get an error)

That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.

[bear426]

Will this work on the SLC 3000? If it does, and since I'm a novice when it comes to Linux, will I be able to do this myself without having a clear understanding of the language? What exactly will this release do, if anything, for my 3000? Also, if your new release works with the SLC 3000, will it provide a better PIM? I think the one on this unit sucks, especially when it comes to synchronizing my contacts/calendar/tasks and notes from outlook. Also, will it be recognized and easily configured by my Socket Low Power WLAN CF card? It isn't recognized on the unit the way it is at present. As you can see, I am a complete novice when it comes to this product and its operating system. Also, could you guide me to where I might find books or such on how to operate the zaurus SLC3000? As I'm sure you know, all that information came from Japan and hence is written in Japanese, which I can neither read nor understand. Your help is greatly appreciated on all of this. Thanks.

[adf]

0
.0
it's simple, really. just su
and do mkdir /mnt/card/tmp  (or mnt/cf/tmp if you prefer it on cf) and then do
ln -sf  /mnt/card/tmp /tmp

do it from a console in qtopia?  This is exactly how I fixed the install issue.

That doesn't work when the new tmp is on cf. At least it doesn't when the cf is formatted with ext2. I got the "splash screen never goes away" symptom after making hhe change on my tosa. I was able to recover by using the "press / repeatedly after init starts" trick. When I got in to the text console, I saw that /mnt/cf wasn't mounted. Having /tmp pointing to nonexistent path makes some programs cranky, for some reason.

you could remove /tmp first.
or do ln -s instead of ln -sf (though i expect you'll get an error)

That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.

1). hence the parentheical /mnt/cf, and the other discussion about fstab and cf mounts
2). i wasn't sure if you did ln -s when something of that name existed where you were intending to put the link would not give you a "file of that name already exists" type of error.

woudn't it make more sense to use sd for tmp and var and that sort of system stuff, though... given that cf has both larger storage options (wads data and media) and is use as a kind of bus for other devices (lan modem camera bluetooth) and so is likley to be more susceptible to being swapped in and out? sd on the 6k is pretty much limited to 1 gig and under data storage.

[hbo]

you could remove /tmp first.
or do ln -s instead of ln -sf (though i expect you'll get an error)

That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.

1). hence the parentheical /mnt/cf, and the other discussion about fstab and cf mounts
2). i wasn't sure if you did ln -s when something of that name existed where you were intending to put the link would not give you a "file of that name already exists" type of error.

1) I missed that. Sounds like it might be a useful read. 8)
2) If the something is a directory, or a symlink to same, ln -s will just assume you meant to create the link inside the directory. It would be an error on a plain file. (That one still trips me up from time to time, after 20 years of Unix. )

woudn't it make more sense to use sd for tmp and var and that sort of system stuff, though... given that cf has both larger storage options (wads data and media) and is use as a kind of bus for other devices (lan modem camera bluetooth) and so is likley to be more susceptible to being swapped in and out? sd on the 6k is pretty much limited to 1 gig and under data storage.

Given the difficulty with cf, absolutely. 8). But my cf is a microdrive, which is a better place than solid state to put lots of ephemeral files. Also, that sucker is thick compared wih the average cf card, so it's a real pain to take out once it's in the socket. My goal is to find an OS that meets all my requirements and stick with it, so I never have to take the (ext2/3 formatted) thing out in order to put in my flash media. 8) So far, the Sharp ROM is closest, with the guylhem ROM close behind. Neither have some features on my wish list, however, like ext3 in the kernel and the ability to run nxclient. (That last is a stretch, but it might be possible with a writable root a la guylhem.) I have two beefs with this ROM. The first is the inevitable rough spots that a system in development is bound to have. And guylhem is nowhere near as bad as OE in that regard. Second, I don't like the choice of apps. This is also inevitable, I think. On a system that offers so much choice, people are bound to make a lot of different ones. The writable root does lessen the impact of that, however.

I'm a Linux systems engineer/architect/admin by trade. I know enough about various incarnations of the kernel to understand the bugs I run into, but I've never written kernel code of my own. I could contemplate integrating a system of my own, however, which is probably the only way I'm going to get close to everything I want. But finding the time is tough. That means I do appreciate all the time folks are putting in to this project and others. This particular project is interesting because it's the only advanced effort besides OZ for the Tosa, and it may be a good springboard for my own efforts. Given my time constraints though, for now I'll just be leeching along with all the other users. 8(.

[ken]

Guylhem,

When you have a chance, could you post the source for the current build you're working on? Maybe we might get lucky and find some overlooked things?

[adf]

hmmm.... ok
If you want an os on the microdrive, and ext3 maybe we can sort this out.

I recompiled the last version of this kernel w/ ext3 built -in.. so that should be no biggie (onvce I figure out some of the stuff on this new version)

keep in mind that there is no real need to even have qtopia in the guylhem rom... or it can be scaled down, or more 6k friendly versions of some oe stuff might well appear..as might some stuff from pdaX.
this is all very new.

I suggest, though, that you stick w/ the guylhem rom and put pocketworkstation on your microdrive (make it ext2 for now..we can sort out new kernel builds in a little while).

Pocketworkstation can be talked to with:
--its native, and very fast fbvnc. I have been having keymap issues with this method though.. maybe you can help sort those out?

--xqt. very popular. kinda fat though, and has a few weaknesses. Try it out..it might suit you, like I said this method is popular

--opie-keypebble 1.0 from within Qtopia a nice compromise, imho. works pretty well so far.

Probable and likely methods:

--the vncviewer in Qtopia 2.1 Vnc is vnc, right?

---opie-keypebble in real opie

---X via gpe or pdaxrom

--x via a simple x server.

Doing the pocketworkstation/keypebble bit, I get the best of the optimised qtopia stuff, and pim functionality (that I really don't use) screen rotation on the fly and a virtual screen bigger than my vga if I like--plus scaling, though opie-keypebble nedds to be disconnecte/reconnected to do that. Keypebble runs right in a qtopia window, so you are in both systems pretty efeectively. it also means I have the option to pop in and out of the heavier debian stuff while taking advantage of extremely well optimised apps like opera

The "native" fbvnc, if we could sort out the keymaps, gives on the fly scaling and rotation. stop/starts only necessary to change the size of your virtual X desktop. and better speed than keypebble. need to kill Qtopia to run it, though

there is a very long thread and several websites on xqt. It really is worth checking out


this (G-Rom, Pocketworkstation) method also allows changeing gui parts of guylhem rom without either killing your debian setup or messing with the underpinnings. In your case you could put different zaurus gui setups (qtopia 1.5, 2.1 and opie --as they get working) on different sd cards and have readily accessable z guis at the swap of an sd, while keeping the "guts" of your rom on internal mem and your debian system on your microdrive. (man, I think I'LL do this --it sounds fun!)
I have pocket workstation on a very removeable (though it doesn't happen much) 1 gig sd.

sound more suitable? I bet the apps you need are in debian arm and as for the rest, opera and kino2 and stuff like that make the most of your z in areasd that need speed, and guylhems basic rom gives excellent hardware support--and if you don't fill up the 56 megs with guis-- a lot of room for modules and libs and scripts ).

EDIT: you might have to edit both mtab and fstab to get your cf working right. I only editied fstab and have to mount manually after reboot.

[adf]

I heard back for Klauss W. on the keymap thing. he also says use loadkeys. the thing is when i do loadkeys tosa.map (or was it tosa.keymap.... it is an html file, though, right?)
I get nothing. I'll try again, but I strongly suspect I have the wrong file, or the file in the wrong format or am incorectly using loadkeys.

suggestions....?

[hbo]

hmmm.... ok
If you want an os on the microdrive, and ext3 maybe we can sort this out.

I recompiled the last version of this kernel w/ ext3 built -in.. so that should be no biggie (onvce I figure out some of the stuff on this new version)

Cool.

keep in mind that there is no real need to even have qtopia in the guylhem rom... or it can be scaled down, or more 6k friendly versions of some oe stuff might well appear..as might some stuff from pdaX.

(This discussion is informed by stuff you said later in your message.)
I think this is the right approach. A minimilist os shell to support layering personalities on top gives the user the choice. My ideal OS for the Z would be able to run apps from all the environments out there, so I'd like to load up the ROM with alternative libraries that I could talk ld.so into loading based on a particular app's requirements. I'm not sure how I'd accomplish that in the case where different libc versions were required. Anyhow, others might have different hardware, and/or be looking for less flexible environments. So they could choose another stack to fill up the internal flash.

this is all very new.

I suggest, though, that you stick w/ the guylhem rom and put pocketworkstation on your microdrive (make it ext2 for now..we can sort out new kernel builds in a little while).

I've been running PW on the Sharp ROM up to now.

Pocketworkstation can be talked to with:
--its native, and very fast fbvnc. I have been having keymap issues with this method though.. maybe        you can help sort those out?

Haven't tried this. I've been using X-Qt. The fbvnc setup would be a fb Xserver to the clients and a VNC server to the Z (or whomever) right? The rotation feature sounds great. I think I'd like to give it a whirl. The keymapping would be an issue of mapping Zclient<->VNC <->Xserver<->X client. Sort of tricky?

--xqt. very popular. kinda fat though, and has a few weaknesses. Try it out..it might suit you, like I said this method is popular

--opie-keypebble 1.0  from within Qtopia a nice compromise, imho. works pretty well so far.

j

I like the sound of that. The attractive thing about the X-Qt solution is that the Qt apps keep working. Sounds like this would acheive that goal too, as you detail later in your message.

...
The "native" fbvnc, if we could sort out the keymaps, gives on the fly scaling and rotation. stop/starts only necessary to change the size of your virtual X desktop. and better speed than keypebble. need to kill Qtopia to run it, though

That last item scotches this approach for me, personally. PW is great, and the Tosa is the first handheld I've owned that can run Mozilla(!) without locking up, but Opera is the right browser for the Z.

... great scheme for running gui personalities on SD cards omitted for brevity, but duly noted!

sound more suitable?  I bet the apps you need are in debian arm   and as for the rest, opera and kino2 and stuff like that make the most of your z in areasd that need speed, and guylhems basic rom gives excellent hardware support--and if you don't fill up the 56 megs with guis-- a lot of room for modules and libs and scripts ).

Yes, that sounds like the ticket! What was the title of that thread about /mnt/cf issues? 8)

[adf]

I heard back for Klauss W. on the keymap thing. he also says use loadkeys. the thing is when i do loadkeys tosa.map (or was it tosa.keymap....  it is an html file, though, right?)
I get nothing.  I'll try again, but I strongly suspect I have the wrong file, or the file in the wrong format or am incorectly using loadkeys.

suggestions....?

btw so far ican get nxclient to say cannot find start stop daemon. Is this good? can we get past this? or is it a kiss of death kind of error?

[hbo]

[btw so far ican get nxclient to say cannot find start stop daemon. Is this good? can we get past this? or is it a kiss of death kind of error?

Well, maybe a hearty handshake of death.

start-daemon is an OZ or Opieism, NXclient is a closed source tool that was compiled to work with OZ 3.2.something, and libopie 0.9.x. So it's possible we could fake it out into thinking it was still living in that environment, but it probably wouldn't be easy, and there's no guarantee we wouldn't run into a show-stopper.

Now of course there is KNX in KDE 3.4. So there is open source code for an NX client on a QT base. This might be the right way to go as an alternative to putting bandaids on nxclient.

[adf]

except....
Qtopia 2.1 is based on what I think is the right version of OZ....
So.... either we can try to set up 2.1 in g-rom (which I think guylhem plans)
OR we can try to kidnap the right libs.

hmm I have an old libopie.. .8 something, I think.. the "libopie1" package. it is installed, though and deosn't seem to help.

If lpotter will post a link to dl his build root the lib could be gotten that way too.

I think that grom w/2.1 is ultimately the way to go, though.. it is built on the old "stable" oz.

I also think I know someone with an old OZ feed...... hmmmmmmmm

[hbo]

It should be doable. I wonder what start/stop daemon do, exactly? (It's generally obvious, but the devil's in the details.)

[adf]

lmao.... I was wondering that too.

I guess we try to rip the libopie? maybe I could patch it in where my exiting libopie1 currently lives?

or give it a shot in 2.1?