OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Guylhem Rom => Topic started by: guylhem on May 07, 2005, 10:50:56 pm
-
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/ (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
-
Getting it now this should be excellent.
XQT comes to mind as a much used app that will fit, if it isn't there already.
still messing w/ the pocketworkstation stuff, for those interested. Looks like maybe the fbvnc that I'm using isn't happy. People have sorted this out elsewhere..It shouldn't be too awful.
btw I have space and some badwidth, --I'll start compiling kernels and modules and do a little hosting if you like?
-
killer splash screen
tree explorer? or advancedfm, maybe?
very snappy.
This is a definite improvement in the way the 6k works, thanks.
I need to go play with it for a while now....
-
Great rom!
Just tried, very usable!
Now planning to upgrade to Opera7.5
-
Regarding the splash screen - believe it or not but *I* took the pic in the everglades. Really ! Guess why it's got such a big mouth ? I was *that* close :-)
If you have suggestion on opera, etc. [especially if you can provide me with an updated version .ipk where voice stuff works : I tried multiple times but never suceeded ] well I'm quite open.
Regarding treeexplorer, it's not GPL, I don't like it a lot -complex user interface. There must be better software out there.
-
what a fuck...ing time it should took you for such a job.
great man, thanks for feeding our great 6000
i'll give it a try a soon a possible.
a good, "indispensable" ipk for me is "tipterm" also called "terminal" its a vt100 emulator really simple to use and i use it on a daily basis in my job.
if you don't like treeexplorer, why not a good mc, or all other double panel explorator?
i'll tell you if its really simple to install, if i manage to, so it will be.
thanks again guylhem
also if you want to implement bt with cf, it would be great no?
-
a small issue.
when trying to install packages, small ones go just fine, but big ones (like opera or tree explorer) crash with a no space error in tar. I'm guessing that this has to do with how tmp is allocated. you have a quick fix by any chance?
also,
cf does not seem to auto mount quite right in qtopia 1.5. I suspect tyhis is in fstab. I'll poke at it.. I think it shouldn't be a big deal. it mounts manually. I'll just change the vfat fstpe to auto
I see you have devinmg i.6 set for cf. this work ok if devimg is put there?
-
Hello
rip- it tooks a long long time. A grand total may be ~ 2 to3 weeks, but selfishly I though I had to do it because every rom sucked. I wanted the tool for the job, so I created it myself.
I just hope everybody will like it. vt100? qkonsole should be fine - I tweaked it to use userdef button as a "alt tab". bluetooth shouldn't be a problem either. All my scripts are in /usr/local/bin BTW - adapt them to your needs. It's shipped with bluez 2.16 - the latest version available, and obexftp for cell phone operation (sync, pics...)
I just didn't compile every kernel module possible. Feel free to ask adf, he'll compile them for you (if you know which module your card needs)
adf - regading fstab - oops. I use ext2 on my SD. I will fix that. devimage is not working yet - I've got to fix its paths, etc. It should take a while. Regarding ipkg - oops again. To minimise flash wear, I put /tmp and /var in a ramdisk. It's only 1 Mb that's why it's exhauting. I'll fix that. Meanwhile simply replace /tmp link by a real /tmp when you do an install.
-
fixed both easily. thnx. gott play around with the kernel this week. atm i'm getting errors in "tools". something unnecessary I thought was interesting, no doubt.
a small nagging issue with a qtopia applet..if you have any insight on it.
inputhelper (and probably, though I haven't tried it the usb mouse applet for the c3k) heeps the
"powerbar" of qtopia on top when using xqt. this seems to me to be something in the applet itself saying "stay on top"
It really needs to be fixed, I think. any ideas? It might just boild down to tweaking the applet a little....
anyone up to trying?
(I'll get to trying it myself eventually, though no guarntees of success..)
-
the link to get the opera 7.5 http://www14.software.ibm.com/webapp/downl...CBW71&S_CMP=&s= (http://www14.software.ibm.com/webapp/download/preconfig.jsp?id=2003-11-19+08%3A22%3A14.918983R&S_TACT=104CBW71&S_CMP=&s=)
actually if u untar the ipk, you can get the file opera_arm.ipk, which is actually the opera w/o rubbish, just around 2.3mb.
you can get them here if u like, but i'll remove them later:
http://www.syhk.net/temp/zaurus/opera/multimodal_arm.ipk (http://www.syhk.net/temp/zaurus/opera/multimodal_arm.ipk)
http://www.syhk.net/temp/zaurus/opera/opera_arm.ipk (http://www.syhk.net/temp/zaurus/opera/opera_arm.ipk)
i can install opera_arm.ipk using sharp rom, but failed with Guylhem rom.
maybe i'll test it later
Regarding the splash screen - believe it or not but *I* took the pic in the everglades. Really ! Guess why it's got such a big mouth ? I was *that* close :-)
If you have suggestion on opera, etc. [especially if you can provide me with an updated version .ipk where voice stuff works : I tried multiple times but never suceeded ] well I'm quite open.
Regarding treeexplorer, it's not GPL, I don't like it a lot -complex user interface. There must be better software out there.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78763\"][{POST_SNAPBACK}][/a][/div]
-
opera_sl-5x00-7.30.9965_arm.ipk
installs cleanly, if someone needs it:
http://www.gfdsa.org/~gfdsa/opera_sl-5x00-7.30.9965_arm.ipk (http://www.gfdsa.org/~gfdsa/opera_sl-5x00-7.30.9965_arm.ipk)
-
WOW! A ROM for a 6k? I must be dreaming. Well, there is OZ, but I don't class it as usable on a 6k yet.
Are these instructions correct?
http://externe.net/zaurus/guylhem-rom/README (http://externe.net/zaurus/guylhem-rom/README)
I'm not really very happy about NAND updating.
Why isn't it possible to just use the update menu (hold ok and power on), with initrd, zImage, updater.sh, and possibly a few other files on a cf/sd card?
Thanks
Simon
-
done straight forward, all stuff works, wifi also with wep key 40 bits
sd formatted in ext 2 recognized fine
could you have a look into this ipk:
http://my-zaurus.narod.ru/memory.html (http://my-zaurus.narod.ru/memory.html)
it works on normal rom and make a swap on ram, sd or cf available till 32 meg and give a status of memory.
thanks a lot guylhem, i'll test it in all possible ways.
-
opera_sl-5x00-7.30.9965_arm.ipk
installs cleanly, if someone needs it:
http://www.gfdsa.org/~gfdsa/opera_sl-5x00-7.30.9965_arm.ipk (http://www.gfdsa.org/~gfdsa/opera_sl-5x00-7.30.9965_arm.ipk)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78871\"][{POST_SNAPBACK}][/a][/div]
Does this version of Opera do the small screen formatting correctly? On every 7.xx version I've seen, save 7.25 from the Cacko feed, the small screen formatting is optimized for the 5x00 series, which just gives you a 240 pixel wide column down the left side of the screen.
I haven't got my 6k yet - but I'll probably be going for this rom when I get it.
-
pb i think, i cant install anything to sd or cf, it just does not give me any choice. is there anything i missed?
the file manager see all files in cf and sd
and my sd is ext2formatted
-
Guylhem,
Thought I'd clean up your README file a little. I didn't see an email address in there to send this, so I'm attaching it here.
-
Bug List (Qtopia GUI):
------------------------------------------------------------
1 - unable to change the Time Zone to other than what's listed. a subsequent reboot then allows the new timezone to show up
2 - SD card not detected (Kingston 512M SD)
3 - note - all your connections/WEP keys etc are listed
4 - new wireless connections with a 128 bit WEP key unable to connect
5 - new wired connections aren't working (shows up, but can't connect)
6 - sharp PIM information is gone (no biggie, just didnt expect it)
7 - removing-inserting CF cards multiple times(ethernet, then modem) caused the Z to hang
8 - creating a new modem connection file complains "Can't create ppp setup file"
most of my data/ipks/etc is on my SD so I was unable to test anything else. On the bright side, it does appear to be snappier. I notice that there are quite a number of useful items on the list.
Observed boot errors:
-----------------------------------------------------------
blkmtd: error: missing `device' name
...
IrCOMM protecol (Dag Brattli)
cramfs: wrong magic
FAT: bogus logical sector size 45147
Eep. Child "ascii-xfr" (ino #1312) of dir ino #1301 doesn't exist!
(it complains zknights.desktop, codepages, p80211.o, QtEmbedded-0.spec, LAN.conf, VPN.conf PAN.conf, DialUp.conf, IRDA.conf, PPPoEW.conf, libpan.so, f, l)
(it also has quite a number of Inode #xxxx was a directory with children - removing those too...)
(then says a bunch of Cannot remove child "xxx", ino #4895, because it doesn't exist (zknights.desktop, ascii-xfr, codepages, QtEmbedded-0.spec, LAN.conf, VPN.conf, PAN.conf, DialUp.conf, IRDA.conf, PPPoEW.conf, libpan.so, f, l, p80211.o)
...
modeprobe: Can't locate module usb_ohci_tc6393
...
pxa_sd_stopclock: clock stop time out. (retries 2x10 times) then gives up
VFS: Can't find ext2 filesystem on dev mmcd(60,1).
Comments:
-----------------------------------------------------------
I suspect a number of those errors are because it can't find the SD card. I also observed that the SD card drivers loaded up just prior to the login prompt. I tried keeping the SD card in, and inserting it after it boots, but no icon for the SD card shows up at the bottom.
Creating a modem connection via the @ Tab, "Get Online" works
Creating a wired/wireless connection via the @ Tab, "Get Online" doesn't connect
rebooting to the console, SD card in.
When I remove the SD card:
pxa_sd_wait_response: card removed (cmd=12)
pxa_sd_wait_response: card removed (cmd=12)
pxa_sd_wait_id_response: card removed (cmd=12)
pxa_sd_wait_id_response: card removed (cmd=12)
When I reinsert the SD card:
pxa_sd_stopclock: clock stop time out. (retry count x) x = total of 10 times
give up!![SD]-clustsize = 4000
mmcda: mmcda1
mmcda:mmcda1
VFS: Can't find ext2 filesystem on dev mmcd(60,1).
mmcda: mmcda1
mmcda:mmcda1
VFS: Can't find ext2 filesystem on dev mmcd(60,1).
(I think it's because it thinks the SD card is ext2 rather than the default fat?)
note: If I drop down to the console, and su, then change the /etc/fstab entry to fat, I'm able to do a mount, but it won't unmount automatically. It will however allow me to read the sd, and the sd icon appears.
sharp's default fstab entres are as follows:
/dev/mtdblock2 / jffs2 ro,noatime 1 1
/dev/mtdblock3 /home jffs2 defaults,noatime 1 2
none /dev/shm tmpfs size=1m,noauto 0 0
/dev/mmcda1 /mnt/card auto noauto,owner 0 0
none /dev/pts devpts gid=5,mode=620 0 0
changing the /dev/mmcda1 line to match sharp's default one allows me to type in:
mount /dev/mmcda1 (upon which the SD card now shows up properly). The SD card icon will unmount properly if the card is pulled out, but I have to drop down to the console and mount it manually whenever I reinsert it (unfortunately, the GUI software install program only shows "Internal Flash" as the only location I can install anything to (the SD or CF card doesn't show up).
-
You could just mount the sd card manually, or edit fstab and/or mtab
Things seem to install just fine. Loaded the camera software (and module) kino2, advanced fm, some libs wellenreiter, multimodal (couldn't find a 755 ipk and was too lazy to strip it)browser XQT (which runs very nicely from internal flash) qtopia mamory applet, the ffpe kernel etc.
can't find my belkin irk ipk though...(re did my sytem a few weeks ago..I seem to have kepth the targus version.
a question, though.
how does one set the processor speed from commandline?
also I can see the need for a few scripts eventually.(would you like tmp on cf or sd? etc) and maybe the inclusion of swapd in the basic part of the rom? (with a yes/no on boot or installaion)
-
i'm testing the rom...and things works well...
A strange thing....
SL6000 seems slow when i try to use some default apps....
i noticed that speed is set to slow.... so i try to select MAXIMUM after this may i have to reboot the ZAURUS or the new frequency is set without rebooting ???
if i want to put qtopia 1.5 on my SD may i use the SYS backup without gui and untar the qtopia1.5 tgz file ? Are theese files updated ?? I need more ram on my SL6000....
-
ken,
Thanks a lot for the readme. I'll use it. Thanks for the bug report too. Regarding the bugs, as you guessed the SD problems come from fstab. If I use sharp defaults, it has problem with my ext2 card. I think I'll ship with vfat per default, and keep ext2 for me if I can't find a play to have both play nicely. I also tweaked the sdcontrol script IIRC from /etc/ to have ext2, so you need to edit it too.
For the Timezone, I just click on the globe item, replace the timezone, close the app, open the date appplication again and set it. How is it different from a stock sharp rom?
The network problems are strange. I'll see if I can test it more but I don't understand why such problems happends. Regarding my wep keys etc, guys please don't distribute them :-) I'll try to clean the next release better (I only have 1 6000 for both my personnal use and rom releases !- a second one would help, I'll consider purchasing a spare)
Most of the boot errors are normal (cramfs for ex.) I'm removing blkmtd and usr_ohci errors which I added.
adf, click on the battery for overclocking. Installation targets and the "filebrowser" tabs don't work for some reason. I'll try to fix it.
I guess the remaining important bugs are :
- network connections
- vfat SD card issues
I'll try to post an update soon.
PS: could someone please send me a .tar.gz of /opt/QtPalmtop.rom/lib/fonts? Deleted it by mistake while working on font issues.
-
very good job guylhem, tried yesterday, without mentioning the listed above issues, i can.t connect usb keyboard, the device is detected, but not claimed by a driver, i suspect it should be kbdsim? or i lack hid drivers?
-
>for me if I can't find a play to have both play nicely. I also tweaked the sdcontrol >script IIRC from /etc/ to have ext2, so you need to edit it too.
I'm not sure what you tweaked, you might have to explain it to me later.
>For the Timezone, I just click on the globe item, replace the timezone, close the >app, open the date appplication again and set it. How is it different from a stock >sharp rom?
The sharp rom basically takes in the new settings as soon as you add it, no need to open and close the app again.
>The network problems are strange. I'll see if I can test it more but I don't
I'm not sure why either. It's probably something small that was overlooked. Possibly may have to do with your cleaning up all the symlinks. I agree that the sharp rom had a ton of weird symlinking.
>Most of the boot errors are normal (cramfs for ex.) I'm removing blkmtd and >usr_ohci errors which I added.
My guess on this is the device wasn't created in /dev. As for the ohci error, I think it's possibly a pathing or permission issue.
>PS: could someone please send me a .tar.gz of /opt/QtPalmtop.rom/lib/fonts? >Deleted it by mistake while working on font issues.
Not a problem. I just don't have your email to send it to ...
-
wep key 40 bits entered and surfing ok,
qtopia destop restore ran fine from the craddle
rotation works fine but seems to need a recalibration.
i'll try my cf bt pretec later.
any help about installing things elwere than in internal memory?
-
I suppose I could compare the network settings that you have with what Sharp produces and grab ifconfig and other info ...
Network settings for the Sharp rom are stored in /home/zaurus/Applications/Network/modules
-
another little pb, the file browser after a reboot shows your sd files, not mine
obliged to eject the sd and to plug it again, then its fine
-
adf - regading fstab - oops. I use ext2 on my SD. I will fix that. devimage is not working yet - I've got to fix its paths, etc. It should take a while. Regarding ipkg - oops again. To minimise flash wear, I put /tmp and /var in a ramdisk. It's only 1 Mb that's why it's exhauting. I'll fix that. Meanwhile simply replace /tmp link by a real /tmp when you do an install.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78819\"][{POST_SNAPBACK}][/a][/div]
hum hum, i don(t know what file to edit/change to change the /tmp path, could you help?
many thanks
-
adf - regading fstab - oops. I use ext2 on my SD. I will fix that. devimage is not working yet - I've got to fix its paths, etc. It should take a while. Regarding ipkg - oops again. To minimise flash wear, I put /tmp and /var in a ramdisk. It's only 1 Mb that's why it's exhauting. I'll fix that. Meanwhile simply replace /tmp link by a real /tmp when you do an install.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=78819\"][{POST_SNAPBACK}][/a][/div]
hum hum, i don(t know what file to edit/change to change the /tmp path, could you help?
many thanks
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79054\"][{POST_SNAPBACK}][/a][/div]
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
and you are all set.
maybe the same should be done w/ var.
-
no unicode fonts btw, had to copy files from Qtopiarom.tar.gz previously installed
-
I can click on the battery f i am in qtopia.
If not... what are the commands for the various clock speeds. Imagine qtopia was not at all installed... how would I change clockspeeds then?
(atm I'm thinking of how to change 'em in pocketworkstationvnc--though I still haven't figured out the keymap issue I think it haas to to with -hw specification in fbvnc, but I haven't had a lot of luck yet)
-
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
and you are all set.
maybe the same should be done w/ var.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79094\"][{POST_SNAPBACK}][/a][/div]
[/quote]
uhhhh , made the changes on tmp and the brick reboots itself and stuck on splashscreen for 30 minutes, ...
reset = same thing, had to reflash again, hihi
-
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.
you could remove /tmp first.
or do ln -s instead of ln -sf (though i expect you'll get an error)
-
i appologize for my incompetence, but witch /tmp have i to remove?
and also is there any fix for the add/remove applet only showing internal memory as the only path for install?
am i the only one to have this pb?
-
add/remove applet ?
how to get there? i have all the panel filled with stuff i want to remove
-
well, sorry, windows typology rests....
icon name under settings is "software"
when installing anything cliked, only one choice offered: internal.
also gulhem, i have an air cable, do you know how to configure that?
-
if you are in a console in qtopia there is, effectively, only one /tmp...the one inside QtPalmtop.rom
as to the applet thing....if they don't come up in add/remove, you could try subapplet? a I don't know it that handles uninstalling, though.
the gui packagemanager internal only option is a kind of side effect of this setup, imho. because QtPalmtop.rom can be anywhere (any one try it over nfs yet?--might be an interesting soution to situational work/home/school demands) it is difficult to say it should definitely look outside itself. I suspect, though that you could edit ipkg.conf and do install -d from commandline.
Personally I prefer having all of th z-rom stuff onboard. it lets me mix and match cf and sd stuff freely without concern that i'm scrambling my sytem. (the tmp and var thing should probably be scripted, though) zright now, if I want something more than qtopia ioffers I use pocketworkstation on my sd--all self contained as well. (hmmmm the possibilites for cheap arm based desktops with mobile self contained os that can be transferred to other devices or used as thin clients.....)
-
IRK.
the "a" key on my ir keyboard does not work. the other keys all do. the "a" key sends ???? to irk--which i take to mean that it sends something, but irk has no idea what. I suspect this is a by-product of the keymap fix. Any ideas for a fix for this? maybe a boot time thing that connects the ir kbd pre qpe? out of my depth here, obviously
USB
hid, usbmouse and usb kbd don't seem to autoload...and loading them after booting into Qtopia is a pain. (didn't bother w/ the mouse)
since no one seems to own 6k N models, at the very least both usb (with kbd mouse and storage support --including the toshiba module--don't know if you did that or not, just thought it should be mentioned)
and wireless should probably be compiled in. the extra kernel size isn't much and the result is good.
Qtopia 2.1
lpotter says 2.1 is sharp package compatible.. ( I was just pestering him about this... see the qtopia 2.1 available soon thread) and has a sane dir structure to boot. It warrants more investigation, maybe?
Maybe 2 rom versions? a qt2.1 "sharp" and a qt 2.1 "floating point" down the road?
Idle speculation
any possibility of a pdaX version?
-
IRK.
the "a" key on my ir keyboard does not work. the other keys all do. the "a" key sends ???? to irk--which i take to mean that it sends something, but irk has no idea what. I suspect this is a by-product of the keymap fix. Any ideas for a fix for this? maybe a boot time thing that connects the ir kbd pre qpe? out of my depth here, obviously
USB
hid, usbmouse and usb kbd don't seem to autoload...and loading them after booting into Qtopia is a pain. (didn't bother w/ the mouse)
since no one seems to own 6k N models, at the very least both usb (with kbd mouse and storage support --including the toshiba module--don't know if you did that or not, just thought it should be mentioned)
and wireless should probably be compiled in. the extra kernel size isn't much and the result is good.
though i seem to rmember problems compiling hid in the last kernel -- I skipped it and just did the lesser mouse and kbd options...
Qtopia 2.1
lpotter says 2.1 is sharp package compatible.. ( I was just pestering him about this... see the qtopia 2.1 available soon thread) and has a sane dir structure to boot. It warrants more investigation, maybe?
Maybe 2 rom versions? a qt2.1 "sharp" and a qt 2.1 "floating point" down the road?
Idle speculation
any possibility of a pdaX version?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79329\"][{POST_SNAPBACK}][/a][/div]
-
installating in other places besides internal flash: I'm working on that. I have no idea why the file manager tab doesn't show my SD card, but shows my CF card. The installation target could be set by editing /etc/ipkg.conf
too many apps by default: sorry, but I think they should all be included. most roms are just roo empty. remove if you want, but let other people who won't get apps by themselves take advantage of the already selected apps.
irk: you're right this is a byproduct. edit your driver to send keycode 125 for A, and 30 for the key you want to act like FN. Sorry, there is no other way. Sharp Qtopia 1.5 hardcoded that FN=30, even if for the rest of the keyboards in the world keycode 30 =A
usb : found the bug. Forgot to include stuff in my kernel compilation. Fixed.
I'll try to release an update soon.
-
>installating in other places besides internal flash: I'm working on that. I have no >idea why the file manager tab doesn't show my SD card, but shows my CF card. >The installation target could be set by editing /etc/ipkg.conf
Tried that a while back, doesn't work.
>too many apps by default: sorry, but I think they should all be included. most >roms are just roo empty. remove if you want, but let other people who won't get >apps by themselves take advantage of the already selected apps.
There's just a few that I'm thinking you might want to exclude, mainly because they're actively updated. Otherwise not a biggie.
-
I had wondered about the usb thing after I posted that. It looked like at least some of the stuff was laready compiled in as it loaded.
will do with the key thing... should be no big thing.
will try to get oe going in the next day or two,
-
doing a fastffpe kernel with the usb fix btw?
and on oe.... do you want me to test it before tarring it? It will make the thing a good bit bigger, but will likely save time, and you'll get a cmplimentary copy of nano
-
Hello
ken : if ipkg.conf doesn't help, I'll have to see where the problem is.
Regarding apps, which one should be updated? Updating them at each release is not a problem.
adf: just compile "USB support for HID devices" in Drivers/USB section. I compiled only a part, and that didn't really help.
For oe, I'm only interested in the toolchain. Just follow the instructions (I can't - I hate following instuctions. I have to try by myself) from oe website and you'll end up with many .ipk and a cross compiler.
I'm only interested in the cross compiler. Locate where it is (it features files such as arm-linux-gcc) and to a .tar.gz of the uplevel directory. Try to run arm-linux-gcc -v to see which version it reports. Then send me a list of the files in that tar (tar ztvf file.tar.gz > list) so I can quickly check is everything is there.
Guylhem
-
this quick post to ask if its not a good idea to include zeditor and a pdf reader in rom apps coming with flash restore. i hate vi and i don't know other console editor.
-
Hello
ken : if ipkg.conf doesn't help, I'll have to see where the problem is.
Regarding apps, which one should be updated? Updating them at each release is not a problem.
adf: just compile "USB support for HID devices" in Drivers/USB section. I compiled only a part, and that didn't really help.
For oe, I'm only interested in the toolchain. Just follow the instructions (I can't - I hate following instuctions. I have to try by myself) from oe website and you'll end up with many .ipk and a cross compiler.
I'm only interested in the cross compiler. Locate where it is (it features files such as arm-linux-gcc) and to a .tar.gz of the uplevel directory. Try to run arm-linux-gcc -v to see which version it reports. Then send me a list of the files in that tar (tar ztvf file.tar.gz > list) so I can quickly check is everything is there.
Guylhem
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79436\"][{POST_SNAPBACK}][/a][/div]
Will do.
You want the 2.95 kernel cross compiler stuff too? there isn't really much to that.. just a matter of taking the standard 2.95 xcompiler and changing a couple names -like arm-linux-gcc to arm-linux-gcc2.95, or something very close. it is just a naming thing to make bitbake.conf happy. It is the same cross compiler you are already using, i bet. I used the same cross compiler to do oz and the integrated version of your kernel last month... took about 10 characters to switch it back and forth.
I take it you are planning to patch an oz kernel, compile opie, pull opie, repartition, install the new kernel and put opie in place of the current Qtpalmtop.rom?
If so, want to give gpe a go? if gpe were done this way, and the Qt stuff run on it the way it has recently been done on pdXrom (so that qt apps can be run) this woud be real interesting--esecially if it were tweaked to run stuff from multiple feeds (like debian arm... ) The only real issue i saw with the last gpe was that the supplied minimo didn't quite work right--and of course the small feed.
this brings up something i've been wondering about... have you noticed that op and matchbox are both in debian? make the sd / and the nand /boot (?) and use the debconf and debtools and kdrive that oe builds and a native debian might be possible.
re the hid thing... i don't have a menuconfig in front of md, so I'll be a bit vague....
in usb under hid there are raw (?)? mouse and kbd support options. on the previous kernel version I could compile those, and they'd drive a usb mouse and keyboard, but not the hid option. Full hid never quite compiled... i always ended up hang ing on to the module, though it didn't get used, I don't think
-
speaking of multiple guis, one of the ideas that i did like in guylhem ideas was having guis on sd or cf, and leaving possibility of fbcon only device, then it could be brought to situation when you can manage the stuff similar to xdm, for example qingy, which is an DirectFB based login manager, which im trying to compile for arm now
for pdaXrom stuff - its simple, there should be only --prefix=/opt/pdaXrom added, and assuming you have a sym link or you mount your SD to /opt, it will run, may be with some light scriptiing for library pathes, for GPE, i should look how it's compiling system is implemented, but im pretty sure that its possible to have all gpe's stuff inside one directory
then it all can be packaged, or t least tarballed with some pre- and post- installation scripts, and distributed
-
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
-
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...
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79147\"][{POST_SNAPBACK}][/a][/div]
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)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79147\"][{POST_SNAPBACK}][/a][/div]
That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.
-
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.
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79147\"][{POST_SNAPBACK}][/a][/div]
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)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79147\"][{POST_SNAPBACK}][/a][/div]
That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79504\"][{POST_SNAPBACK}][/a][/div]
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.
-
you could remove /tmp first.
or do ln -s instead of ln -sf (though i expect you'll get an error)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79147\"][{POST_SNAPBACK}][/a][/div]
That won't give you an error. It will just symlink /tmp/tmp -> wherever you said.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79504\"][{POST_SNAPBACK}][/a][/div]
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79508\"][{POST_SNAPBACK}][/a][/div]
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79508\"][{POST_SNAPBACK}][/a][/div]
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(.
-
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?
-
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.
-
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....?
-
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)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
(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).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
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?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
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[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
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
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
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 ).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79540\"][{POST_SNAPBACK}][/a][/div]
Yes, that sounds like the ticket! What was the title of that thread about /mnt/cf issues? 8)
-
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....?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79544\"][{POST_SNAPBACK}][/a][/div]
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?
-
[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?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79548\"][{POST_SNAPBACK}][/a][/div]
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.
-
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
-
It should be doable. I wonder what start/stop daemon do, exactly? (It's generally obvious, but the devil's in the details.)
-
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?
-
On my collie I have OZ 3.5.3/Opie 1.2 and nxclient. This is what I get when I try to run it:
root@collie:/# /usr/NX/bin/nxclient: symbol lookup error: /usr/NX/bin/nxclient: undefined symbol: _7QString.shared_null
And this is what ldd on /usr/NX/bin.nxclient gives me:
libqte.so.2 => /opt/QtPalmtop/lib/libqte.so.2 (0x4001e000)
libqpe.so.1 => /opt/QtPalmtop/lib/libqpe.so.1 (0x40349000)
libm.so.6 => /lib/libm.so.6 (0x4045a000)
libc.so.6 => /lib/libc.so.6 (0x40507000)
libts-0.0.so.0 => /usr/lib/libts-0.0.so.0 (0x40614000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4061e000)
libz.so.1 => /usr/lib/libz.so.1 (0x40649000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40661000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40688000)
libdl.so.2 => /lib/libdl.so.2 (0x40699000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x406a4000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
-
Last one for tonight.
So I was wrong about it depending on opie at all.
'start-stop-daemon' is a link to busybox on OZ 3.5.3. I think it would be safe to write a shell script replacement to just run the damned first argument in the background, possibly redirecting stdin/stdout to useful places.
We may have quick success with this, which would be really cool. But I still think porting the KNX client would be better for the long term.
-
can we get the source? I hadn't looked.
It could also be repacked with the necessary script and put tin the feed....
-
adf - I don't need 2.95 toolchain - already got that. I'd be interested in the 3.3 or 3.4 they are using to do softfloat mplayer/libsdl/games etc.
gpe, pw, etc. are interesting ideas but IMHO qtopia is the way to go.
for the kernel don't go to drivers/input but drivers/usb (the options you mention are from drivers/input)
-
I'll have to look again,
lmy last "solution" was to enable the whole thing i n drivers/input
and then Not compile hid in usb i( i think there was something about usb hid in /usb.. I'll have to look) but just raw keyboard. i dunno. will get to it this weekend.
as to the qui option thing, yeah.. for a general purpose gui Qt is probably the way to do it. I was thinkin more along the lines of interesting alternatives.
have you poked at the latest Qtopia 2.1? It might be useable in this Rom with not too much agony. (though i didn't have a lot of luck with opera, lpotter seems to think that the problem was not qtopia 2.1 itself might be worth double checking)
Did you see the qemu oe thread this morning? there is, link and all, a disk image from a debian system with OE installed.
you might grab that, since it is up right now, and don't see having a tarrball ready to go for 2 or 3 more days
-
I reflashed this evening with the 0.9 release. Aside from the microdrive not getting mounted, I noticed something else that happened the first time around. I was getting ready to install X-Qt, so I remade the link from /tmp to point at the microdrive. I also put the Z in its cradle for the first time since I'd flashed it this time around. The screen on the Z switched back to the "Gator" photo! It's as if the runqpe command had exited on an error, and the qpe.sh script had done a chvt back to the splash screen. How do you do switch virtual terminals using the keyboard or buttons in this ROM?
I just realized that pulling the temp files out from under qtopia is probably not a great idea. 8) But it's the only way to get installations of large ipks to work.
Is there a Wiki/Twiki where we could centralize bug reports and development info for this ROM?
-
home key to open a new terminal.
maybe you should put /tmp on sd till you get your microdrive reliably automounting?
on a completely different note....
Guylhem,
to assign a to 125 and fn to 30..... where do I do this? I had just assumed it would be in the irk key customization stuff, and is not.
those roll-up usb keyboards are kinda looking good
-
Is there a Wiki/Twiki where we could centralize bug reports and development info for this ROM?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79695\"][{POST_SNAPBACK}][/a][/div]
probably on his homepage forums (externe.net)
-
maybe you should put /tmp on sd till you get your microdrive reliably automounting?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79708\"][{POST_SNAPBACK}][/a][/div]
I fixed it by moving /etc/rc.d/init.d/pcmcia, which sets up the cf drivers on the Z, to /etc/rc.d/rc.pcmcia and removing the symlink /etc/rc.d/rc5.d/S05pcmcia. Then in /etc/rc.d/rc.sysinit, I put a call to rc.pcmcia right before local file systems are mounted like so:
. /etc/rc.d/rc.pcmcia start
action "Mounting local FS:" mount -a -t nonfs
#action "Mounting remote FS:" mount -a -t nfs
Since I have an entry in /etc/fstab for my microdrive, it gets mounted by the second line above, and this allows me to maintain the link /tmp -> /mnt/cf/tmp. /var is another matter. The pcmcia script makes heavy use of /var, and I was unwilling to study the problem of removing the dependency, or risk just mounting on top of it. But now the logs have the full 1MB to play with.
It's cool that syslog is running on this ROM. It's very helpful for debugging problems and learning about the details of the startup. However it won't do to keep that in production, since it would fill up quickly.
Next up, why doesn't the qpe package manager work for non root targets?
I'm willing to host a Wiki, BTW. It would be a complement to these forums, not a replacement.
-
A wiki is ready on externe.net/zaurus/faq.
It's C700 centric ATM, but I'm going to upgrade it.
-
A wiki is ready on externe.net/zaurus/faq.
It's C700 centric ATM, but I'm going to upgrade it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79745\"][{POST_SNAPBACK}][/a][/div]
Cool.
Can I start a bugs page for the current guylhem ROM?
-
Please do ! That's the purpose of the wiki
I suggest the following pages:
- installation notes
- bugs
- features suggestions
Maybe a sum up of this thread would be good
Guylhem
-
adf, to swap 125 and 30 you need to edit the sourcecode. I suggest you sell the IR keyboard and get an axim bluetooth one (aka stowaway) or a USB one as you suggest.
I'll support them much more easily than a IR keyboard I don't have.
BTW - the stowaway keyboard is now working fine! Will soon take care of the USB one.
-
another reason for an install script or two imho.
there will be people who want to have access to logs. maybe a 1st run? setup the image with a marker set to 0, on boot check the maker, if it is 0 run the script? (have the script write 1, of course) ask "Do you want /tmp on sd or cf?" Do you want to use system logs warning this can use lots of space y/N?" if y then ask about var the same a /tmp. you copuld probably use the same thing to assign acceptable targets for ipkg.
this would also make a nice (if slow way) to set up the qtpalmtop.rom at whatevet target is wanted -- copy to/mount from(cd sf, internal...nfs?-- having an nfs or samba option might be nice for some offices?)
and on boot ask for gui target location. this would make either purpose specific setups, or different guis (I think at the very least there will be those that want opie and those that want qtopia2) easy to manage on a handful of diferent cards, or with a handful of different images.
and this would lead to the last (if feaseable) script--that does not go on the rom.
one that rips guis to an installable useable tarball (obviously tis would go somewhere down the road.)
-
I fixed /tmp ipkg problems using /home/tmp in /etc/ipkg.conf
Regarding the log files however, I'm not sure what I should do. Ideally they should be capped to 100ko each. Maybe I'll just cut them clean at each suspend ?
Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
If all goes as planned I'll release a 1.0rc1 monday
-
Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]
I was thinking along the lines of a future "idiot-proof" release.
-
Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]
I was thinking along the lines of a future "idiot-proof" release.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79782\"][{POST_SNAPBACK}][/a][/div]
btw. I think maybe a vnc client should be included..or at least in the feed? the only one I can find that works with the qtopia 1.5 setup is opie-keypeble 1.0.
-
I fixed /tmp ipkg problems using /home/tmp in /etc/ipkg.conf
Regarding the log files however, I'm not sure what I should do. Ideally they should be capped to 100ko each. Maybe I'll just cut them clean at each suspend ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]
If there's a newsyslog.conf, it's supposed to trim/rotate logs
Regarding moving the GUI, IMHO it should be up to the person doing that. Simply moving /opt/QtPalmtop (That's the current name - .rom reminded me of sharp oddities) to /mnt/cf/ etc should be enough.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]
I'd prefer not having it in /mnt/cf, as the cf usually has to be removed to put in cards, like network, bluetooth, modem, etc
-
Please do ! That's the purpose of the wiki
I suggest the following pages:
- installation notes
- bugs
- features suggestions
Maybe a sum up of this thread would be good
Guylhem
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=79774\")
Great!
I created a guylhem ROM development section at [a href=\"http://externe.net/zaurus/faq]http://externe.net/zaurus/faq[/url] with links to the three pages you suggested above. I created the InstallationNotes page with a description of my hack to make /tmp on CF work. The other two pages still haven't been created. I'll look at them later today.
I think that I will "cherry pick" items from this thread to include. If anyone would like to add to, subtract from or reformat what's there, or create more content, please do!
Edited to correct broken link pointed out in the third following post.
-
I fixed /tmp ipkg problems using /home/tmp in /etc/ipkg.conf
Regarding the log files however, I'm not sure what I should do. Ideally they should be capped to 100ko each. Maybe I'll just cut them clean at each suspend ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79780\"][{POST_SNAPBACK}][/a][/div]
If there's a newsyslog.conf, it's supposed to trim/rotate logs
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79809\"][{POST_SNAPBACK}][/a][/div]
That functionality is provided by various packages on the various distros. On RHEL[34] and SuSE, it's the logrotate package, and the file is /etc/logrotate.conf with a /etc/logrotate.d subdirectory. I know LSB defines how packages provide log rotation scripts. Anyhow, it doesn't happen automatically. We'd need to provide something to get the functionality.
-
I'm thinking about a flexible base system on top of which people could layer many different type of GUIs and/or application suites, as has been discussed here.The guylhem ROM project could provide a standard load, similar to the current 0.9 load, but also provide a bare-bones system and supporting software to roll your own environment. I'd be interested in contributing to such an effort. What do you all think?
-
I created a guylhem ROM development section at http://externe.net/faq (http://externe.net/faq) with links to the three pages you suggested above. I created
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=79828\")
I'm sure you mean [a href=\"http://externe.net/zaurus/faq]http://externe.net/zaurus/faq[/url]
-
I'm sure you mean http://externe.net/zaurus/faq (http://externe.net/zaurus/faq)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79835\"][{POST_SNAPBACK}][/a][/div]
Yup.
Thanks for catching the broken link!
-
ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.
as a personal bit of madness, though i really like using the ram w/ qt onboard anpocketworkstaion on my sd, I could see shrinking my qt setup some and making a "huge" base install sytem with a ton o moduls and libs.
-
ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.
as a personal bit of madness, though i really like using the ram w/ qt onboard anpocketworkstaion on my sd, I could see shrinking my qt setup some and making a "huge" base install sytem with a ton o moduls and libs.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]
My tastes run that way too.
But, the point is, those are my tastes, which aren't identical to yours, which..
If we put some thought now into what it would take to layer a personality on top of a minimal core, I think it would lead to a more flexible and useful system later. Since Gutylhem has been doing a lot of the work on this project, (it is named after him 8) I think we should start with his choice of apps as the "standard" install. As things stand, I think you can rip and replace just about anything in the system, since you can write to all the (visible) filesystems. But wouldn't it be nice to define a set of tasks to make it a QT/X-Qt/PW/GPE/Whatever system or all of the above? We don't have to write this all at once. We just have to avoid dependencies between the layers so that such a system is possible. And to do that, we need to define the layers, at least to some level of detail, if not fully specify them.
Thoughts? Are we reinventing part of the OE wheel?
-
ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]
I've tried OZ and it's flavors. To be honest with you, gpe is a bit sterile, but stable. Opie is nice but a bit buggy at the edges. If you want a choice of GUIs, then wouldn't that be what OZ is about? I can pretty much live with how he has things set up. He has a point about certain apps can always be updated with later versions (as long as this keeps moving).
What I think is more important, is making sure the most used of apps is there. Which means things like a good media player of some sort that can play tons of things. zbedic is nice of course - I was surprised that OE is still on 0.9.4 rather than 0.9.5. And so forth - cover the basics of what people need and would use.
The image program would be a problem though - photostorage does large images, which I haven't seen others do.
As for however he wants it released is fine by me --- using nand restore is fine. That certainly simplifies things. Maybe later that could be tuned to whatever.
For me, I'm hoping at some point we could have a cvs type of system, so we can participate in the debugging of things.
-
nah...
Guylhem is doing great stuff with the default rom setup.
what the gui replacement system would consist of are a few scripts to mount images, and maybe make links.
The pain will be loading tarring and untarring and troubleshooting the additional guis.
Guylhem's next bit will be opie, I think.
Other than help testing that, maybe we can figure out how to do stuff on qtopia 2.1, then rip and move it around?
I think the X roms should probably be the last thing we touch (though I really like x) just because they will be different and are eveolving fastest.
My first issue is the &*(&*$%^#!! keymap issue with fbvnc 1.71 (latest). apparently what is needed is to use loadkeys and maybe guylhem's tosa.map to fix it up. I can't seem to make it go..nor an i seem to figure out why. It is probably child's play too...
Anyone have an idea?
I also should setup oe this weekend.
and load and tar Qtopia 2.1. (which so far, I can't seem to install opera on).
I probably should sort out the irk issues too... but I chickened out there and ordered a roll-up usb kbd
so.. the agenda for the sideshow (while Guylhem is putting on the main event) should be what? 2.1? pocketworkstation issues? getting ready for opie? ( I need to make some kernel modules too, I think.. though the old ones I made seem to work ok)
opie--when it gets done-- is going to be sweet on this rom btw
edit: this is assuming the stuff we try works with the curent guylhem kernel. I know that doing a kernel update in qtopi2.1 did not work. the mobile QtPalmtop obver g-rom might?
-
ultimately, I agree. a choice of guis, and the flexibilty created byt a system done that way would be best overall.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79838\"][{POST_SNAPBACK}][/a][/div]
I've tried OZ and it's flavors. To be honest with you, gpe is a bit sterile, but stable. Opie is nice but a bit buggy at the edges. If you want a choice of GUIs, then wouldn't that be what OZ is about? I can pretty much live with how he has things set up. He has a point about certain apps can always be updated with later versions (as long as this keeps moving).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]
That was the sense of my question about reinventing the wheel. OE builds Familiar and OZ already, so they should have the business of integrating different systems from parts down cold. I agree with your assessment of OZ/Opie.
What I think is more important, is making sure the most used of apps is there. Which means things like a good media player of some sort that can play tons of things. zbedic is nice of course - I was surprised that OE is still on 0.9.4 rather than 0.9.5. And so forth - cover the basics of what people need and would use.
The image program would be a problem though - photostorage does large images, which I haven't seen others do.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]
All well and good. But what if you're tone deaf? A media player might not fit what you want to do with the Z. What about an X server running alongside a QT environment? Most people wouldn't want that, but I do.
The list is actually endless. I have no use for Portabase or several others of the apps in 0.9. I can't live without Perl on the Qtopia side. (If that were in the base, I could write some killer integration software! 8) Other people will have a completely different list. I can hear all the Python devotees yelping with alarm at the mention of Perl, for instance.
I'm not suggesting that there shouldn't be a default set of apps that reflect someone's idea of what the perfect mix is. I'd just like to see some thought given to decoupling the base OS from the GUI and applications layer. That would make it easier to rip and replace, at the very least.
As for however he wants it released is fine by me --- using nand restore is fine. That certainly simplifies things. Maybe later that could be tuned to whatever.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]
The only objection I can see is that the entire flash gets written to, and there are a limited (though large) number of writes the flash can take. It occurs to me that this may not be a real big concern for the average user, however. I'm not positive, but I'll bet most Z users don't reflash that often. OTOH, there's a high proportion of hackers and tinkerers in the Z community, so maybe it is an issue.
For me, I'm hoping at some point we could have a cvs type of system, so we can participate in the debugging of things.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79851\"][{POST_SNAPBACK}][/a][/div]
That would be nice. If I had access to Guylhem's keyboard patch, then I could patch fbvncserver to match it.
-
...
My first issue is the &*(&*$%^#!! keymap issue with fbvnc 1.71 (latest). apparently what is needed is to use loadkeys and maybe guylhem's tosa.map to fix it up. I can't seem to make it go..nor an i seem to figure out why. It is probably child's play too...
Anyone have an idea?
...
so.. the agenda for the sideshow (while Guylhem is putting on the main event) should be what? 2.1? pocketworkstation issues? getting ready for opie? ( I need to make some kernel modules too, I think.. though the old ones I made seem to work ok)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79854\"][{POST_SNAPBACK}][/a][/div]
The keyboard issues also impact the fbvncserver from SDG Systems. Personally, I think that's one I might be able to tackle. Surely its just a matter of modifying the VNC server's map (in the driver for clients local to the server) to match what the kernel is expecting? The other high priority bug for me is that the package manager won't let you install to CF or SD. Since the ipkg command won't do the links when you do a '-d cf' that's a real pain.
I have a cross compile environment, but I'm not set up to build the kernel for testing. Are you doing anything special? (Other than "make oldconfig; make depend; make bzImage"?)
-
actually, i tend to do 600l configs a bit differently than guylhem does his configs.
He has gone to compiling more stuff in, so that difference is less...
But I compile in all the basic usb stuff, do usb bluetooth comiplied in, and ignore the rest of bluetooth (since I have an "L")... compile in wireless and ipv6 and tunneling support, that sort of thing.
The new kernel has changed a bit.. so I am having to feel my way around to get a good "L" version-centric kernel. ATM I'm having something in "tools" die on me... likely something I thought looked like fun but didn't really need too
Other than that.. I use his source when I compile.... It's right there on externe for download
If you can get the fbvnc keyboard issues sorted out, I expect that will help a lot of people... I know I'd like the option on PW..and (though I didn't know of the problem yet) I do occasionally use fbvncserver to work on my Z
As for the great gui debate
A). A basic gui that is compatible with the largest number of packages and has the most useable interface is obviously the highest priority. ATM that is indeed Qtopia 1.5. I think, Ultimately that Gutlhem's roadmap is correct, and that Qtopia 2.1 will make the best solution.
. As to reinventing OZ. Guylhem is planning (you read his roadmap?) to implement fast floating point and gcc 3.x stuff eventually. This will surely mean dabbling with stuff OZ has done.But using opie does not necessarily mean it will wind up the same as OZ/6k.. which is merely the product of a much bigger project. I think it would be more like tuning OE to build something very specifiacally tweaked for the 6k/G-rom. this is not the same.. though it is a huge project. The roadmap.. says it is heading for a softfloat enabled qtopia 2.1.
OK. Softfloat 2.1 then is the goal. Opie is a likely by product.
By version 1.5 of this Rom QTopia 1.5 and Opie will be available options, I think. right there is an argument for making gui changes easy. when Qtopia 2 is added as default, there will be 3 possible guis-- 1 default. If one of us loonies wants an X gui there will be 4. and why not? I think we should pitch in to help make this work.. but I don't think that precludes stuff like making multiple gui options easier to have.
Right now, I suppose troubleshooting the existing stuff is something the 6kers should be working on... but obviously we can do that stuf and branch out a little too
and having multiple gui options is not reinventing oz. there will be only one official one.. and all of them are derivate of other projects. A very different proposition, I think.
-
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?
-
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.
-
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".
-
[deleted]
-
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.
+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?
+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.
-
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?
-
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.
-
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.
-
you have mail ( I think)
-
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]
(http://index.php?act=findpost&pid=79910\")
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.
-
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? :
-
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.
-
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.
-
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.
-
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).
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79937\"][{POST_SNAPBACK}][/a][/div]
I'm not worried about that. A lag between current binaries and posted source is a technical violation of the GPL, but I assume it's all in good faith, particularly if it doesn't go on too long.
Using a public VC system gets you out of trouble there, of course.
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79937\"][{POST_SNAPBACK}][/a][/div]
Well, that's interesting. Has he patched the Opera binary to use his keymap? I assume so. The legal and ethical questions you can argue about, but the practical problem is that we will all have to rely on Guylhem to do the patching for subsequent releases, or else do it ourselves with varying results. And if a new binary app comes out that allows for, say, immediate attraction of selected members of the appropriate gender, then we'll have to.. well, we probably wouldn't have to wait long for him to patch the keymap on that app. But you get the idea. That approach will not scale. It is guaranteed to make this project a backwater in the (already small) Zaurus community.
The custom keymap is far more trouble than the problem it's designed to solve, IMHO.
-
Saying oh here is the great SDK and OE should have provided that in the first place where the binaries are clearly illegal warezed. The SDK fails to comply with GNU licenses (not even considering the proprietary bits in it). It fails to answer under which license resulting code has to fail. Does that Qtopia code allow commercial development at all?
Is that the 150$ SDK from Trolltech?
And I really hope it is obvious why OpenEmbedded or handhelds.org can't host nor provide such illegal binary blobs.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79941\"][{POST_SNAPBACK}][/a][/div]
Here are the top 24 lines of the LICENSE file in the root of the Qtopia.tgz on externe.net:
The Qtopia Environment is Copyright (C) 2000-2001 Trolltech AS and
other authors as specified in the file headers.
You may use, distribute and copy the Qtopia Environment under the terms
of GNU General Public License version 2, which is displayed below.
Sharp SDK is copyrighted by Sharp and *not* released under the GPL.
So please try to avoid using libsl and libdtm unless you application
absolutely *requires* it.
-------------------------------------------------------------------------
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
So, under the GPL, he has the right to redistribute, no?
-
it's alaska, not arkansas. I have no idea if the cereal ever made it here or not... I was a kid in NY in the 70's, and I thought tbhe cereal tasted like sweetened fiberboard
I agree that making something that doesn't scale is pretty much shooting yourself in the foot. But what essential bit of the rom is a patched binary? and if it exists is it something that is there as a fixture or more as a placeholder in a proof-of-concept thing with the intent to be relpaced asap?
what exactly are we talking about here? the keyboard fix in Qtopia? Qtopia 1.5 isn't slated to be the gui for this rom for very long. Hopefully 2.1 presents a better prospect in this regard.
-
it's alaska, not arkansas. I have no idea if the cereal ever made it here or not... I was a kid in NY in the 70's, and I thought tbhe cereal tasted like sweetened fiberboard
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79952\"][{POST_SNAPBACK}][/a][/div]
Shoot. I was born in Alaska and I didn't recognize the abbreviation. We moved to California when I was five, so I guess I can forgive myself.
I agree that making something that doesn't scale is pretty much shooting yourself in the foot. But what essential bit of the rom is a patched binary? and if it exists is it something that is there as a fixture or more as a placeholder in a proof-of-concept thing with the intent to be relpaced asap?
what exactly are we talking about here? the keyboard fix in Qtopia? Qtopia 1.5 isn't slated to be the gui for this rom for very long. Hopefully 2.1 presents a better prospect in this regard.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79952\"][{POST_SNAPBACK}][/a][/div]
No, it's the apps. According to what I understand, the kernel has a modified keymap, so all the apps have to be patched to work with it. That's why fbvnc and fbvncserver have screwed up keymapping. They aren't patched for the g-rom kernel. For applications where you have the source, you can change the mapping and recompile. But for binaries, the only way is to patch the binary, which I'm supposing Guylhem has done. (I'd still be pleased to be proven wrong about that.) Actually, I'd write a shim along the lines of kbdsim that would map the old style to the new style keycodes. That way you wouldn't have to modify the binary apps. If that were the default mode, then you could use all the rest of the world's apps unchanged, and also provide some that could use full PC keyboard, by telling the shim to get out of the way.
-
now for something completely different.
remember how early in the qtopia 2.1 releases there were complaints that it was slow??
apparently sharp had optimized libqpe 1.5 for the 6k?
wellllll I was tarring up 2.1 for this rom and just happened to see..amidst al the lib Blah.2.1.so stuff a linqpe-1.5.3.so. I wonder...
anyway it is straight and unmodified frm TT
-
now for something completely different.
remember how early in the qtopia 2.1 releases there were complaints that it was slow??
apparently sharp had optimized libqpe 1.5 for the 6k?
wellllll I was tarring up 2.1 for this rom and just happened to see..amidst al the lib Blah.2.1.so stuff a linqpe-1.5.3.so. I wonder...
anyway it is straight and unmodified frm TT
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79957\"][{POST_SNAPBACK}][/a][/div]
I'm new to development on the Z. Where are you getting Qtopia 2.1? All I see for download at qtopia.com is the 1.7 stuff.
-
there is a thread on it around here somewhere....
hit "view new posts"... it should show up
edit: find it here:
http://www.qtopia.net/modules/users/downloads.php (http://www.qtopia.net/modules/users/downloads.php)
-
edit: find it here:
http://www.qtopia.net/modules/users/downloads.php (http://www.qtopia.net/modules/users/downloads.php)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79960\"][{POST_SNAPBACK}][/a][/div]
Kewl!
Thanks!
-
it is pretty nice. would be better on guylhem's base, imho. --toss 1.5 entirely if we can use this
let me know if you get opera working. The problem is almost certainly that the opera ipk expects a different diectory structure than is to be found in 2.1 incidentally, this is built on the OZ that nx is supposed to work with...
edit: the tarball of /opt/Qtopia (it is qtopia and not QtPalmtop on this rom is here. it will untar to give you /opt in the tree, though, so stuff will have to be moved around a little.
http://www.anyerlildog2.com/zug/ (http://www.anyerlildog2.com/zug/)
-
it is pretty nice. would be better on guylhem's base, imho. --toss 1.5 entirely if we can use this
let me know if you get opera working. The problem is almost certainly that the opera ipk expects a different diectory structure than is to be found in 2.1 incidentally, this is built on the OZ that nx is supposed to work with...
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=79965\")
I wondered about that as soon as I saw the notice that they had built on top of "a fairly stable version of OZ."
edit: the tarball of /opt/Qtopia (it is qtopia and not QtPalmtop on this rom is here. it will untar to give you /opt in the tree, though, so stuff will have to be moved around a little.
[a href=\"http://www.anyerlildog2.com/zug/]http://www.anyerlildog2.com/zug/[/url]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79965\"][{POST_SNAPBACK}][/a][/div]
Given the possibility of running NX (which I use to access work) I think I'll just load that puppy up directly.
Thanks again! I'll let you know about Opera. (But I see the IBM "multimodal" version is at the same dload site alongside this ROM. I wonder ..)
-
I tried the multimodal. said it installed....and nothing. a directory issue, as it has been all along in OZ, I suspect.
the solution would be probably to edit the ipk and tell it to install to places that actually exist. MrSquishy did that for opera 7.55 from multimodal for OZ 3.5.2, (it doesn't work on 2.1, though..so things are probably a little different) advancedfm from cacko and other stuff seem tom install just fine, so this should be workable. I tried to install nx..had the same experience as opera..which tells me almost nothing.
keep us posted as you go
-
Missed something earlier...
the apps are not modified. i pulled opera 7.25. and installed the multimodal in G-rom 0.9 worked perfectly.
there are just one or two apps (both open afaik--irk and fbvnc) that I know of that are borked.
What has been done is guylhem changed the keymap in the kernel, then modified the one in qtopia to work with it it... so no apps have been touched, and those slated to be touched are gpl and can be.
the binary hacking issue is a chimaera. no such thing is happening, and the modified maps are posted and documented.
Glad that got straight
-
Missed something earlier...
the apps are not modified. i pulled opera 7.25. and installed the multimodal in G-rom 0.9 worked perfectly.
there are just one or two apps (both open afaik--irk and fbvnc) that I know of that are borked.
What has been done is guylhem changed the keymap in the kernel, then modified the one in qtopia to work with it it... so no apps have been touched, and those slated to be touched are gpl and can be.
the binary hacking issue is a chimaera. no such thing is happening, and the modified maps are posted and documented.
Glad that got straight
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79970\"][{POST_SNAPBACK}][/a][/div]
That's certainly better than I thought. Thanks.
I still have some concern because of the possibility that "Joe Random Application" may not work with guylhem out of the box due to the unique keymap. That puts a support burden on the producers of distributions relying on that kernel, and that's a barrier to scalability. It's not as large as the one thrown up by patching binaries, though.
-
true enough, but if the apps use the keymaps on the system, rather than do shortcuts, it should be fine. I think the only place we see trouble is io "adapter" apps --fbvnc and irk that handle keymaps internally in some way.
more problems along these lines would be a concern, sure.... but I doubt there will be very many of them.
and in zaurus world "joe random app" probably has issues of some kind on most roms. I'd say that this was part of the beauty of OZ, but pretty often OZ apps don't work on OZ, even when they are included in the rom. It gets annoying.
-
(since i was already clear on guylhem's last post)
hbo... how did you put 2.1 on your system?
were you runing G-rom w/qtopia 1.5 and did an update? or did you untar the qtopia i tarred up yesterday? or did you just update a generic sharprom to check out 2.1?
-
(since i was already clear on guylhem's last post)
hbo... how did you put 2.1 on your system?
were you runing G-rom w/qtopia 1.5 and did an update? or did you untar the qtopia i tarred up yesterday? or did you just update a generic sharprom to check out 2.1?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80059\"][{POST_SNAPBACK}][/a][/div]
I ran the update procedure on top of sharprom, I think.
I'm trying to see if I can actually get nxclient to work. I'm also getting to remember why OZ 2.X drove me back to the sharprom on my collie. : )
-
try installing libopie1 and libopie2 ( i think you can get 'em from the zaurus feed-- if not , from cacko).
take some notes on what happens and get a hold of lpotter ( the qtopia guy that talks to us here -- and seems largely responsible for 2.1) he seemed interested in nx on the rom.
see the 2.1.1 threads.. I mentioned it yesterday, so it shouldn't be too hard to find the discussion.
NX would be very cool on a Z ;0
-
try installing libopie1 and libopie2 ( i think you can get 'em from the zaurus feed-- if not , from cacko).
take some notes on what happens and get a hold of lpotter ( the qtopia guy that talks to us here -- and seems largely responsible for 2.1) he seemed interested in nx on the rom.
see the 2.1.1 threads.. I mentioned it yesterday, so it shouldn't be too hard to find the discussion.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80062\"][{POST_SNAPBACK}][/a][/div]
OK, thanks for the pointer.
NX would be very cool on a Z ;0
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80062\"][{POST_SNAPBACK}][/a][/div]
480x640 (or vice versa) seems to be the minimum resolution to make something like nxclient practical., Keypebble and qrdesktop work very nicely on my 860. But nxclient would be uniquely useful to me, since I routinely use it to access my client's sites.
I'm not a C++/QT hacker (although I have the Blanchette/.Summerfield book, it's down the stack in my reading list.) or else I'd look at porting KNX. Having the source code on an open platform is a huge advantage, as your struggles to run nxclient show.
-
http://www.pdaxrom.org (http://www.pdaxrom.org) has a nice website setup. I'm wondering if something similar would work for this? The bug page is nice, however I'm not sure if it's easy to maintain or not. It does make it easy to spot things though.
-
If we had enough interest to start such a site, I could host it. Though I'll bet Guylhem would prefer to use externe.net, which is fine with me. The project is pretty small as it is, so I think the elaborate stuff isn't called for, yet. What I would like to see is an accessible version control repository. That way I could track development, and get a better idea of where I could help. (I also might be less likely to get spooked by trolls. 8) there's sourceforge, of course, though Guylhem might prefer a European provider.
-
NX would be very cool on a Z ;0
http://www.nomachine.com/experimental_products.php (http://www.nomachine.com/experimental_products.php)
-
hbo, I'll try to host that on externe - I prefer having everything at hand.
Yet I don't want non free parts exposed - distributing them in a big nand file which can only be restored on the 6000 is one thing, exposing them on the web is something else I don't want to do. - that would be like promoting their use :-/
The next release (if I have the soft float stuff ready) will be shipped without sharp apps- kino2 and zplayer will be there instead.
If I can find suitable replacements for hancom and opera (that could be the non free Picsel, which will refuse to run on machines without licenses - now I need somebody in japan to get me one !) that would be acceptable - only libsl and libzdtm, which are publically distributed by sharp, would remain. A good step towards 100% free software.
I'll see what I can do.
BTW - my long promised editorial is on http://externe.net/zaurus/modules.php?op=m...order=0&thold=0 (http://externe.net/zaurus/modules.php?op=modload&name=News&file=article&sid=57&mode=thread&order=0&thold=0)
-
If I can find suitable replacements for hancom and opera (that could be the non free Picsel, which will refuse to run on machines without licenses - now I need somebody in japan to get me one !) that would be acceptable - only libsl and libzdtm, which are publically distributed by sharp, would remain. A good step towards 100% free software.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80099\"][{POST_SNAPBACK}][/a][/div]
Being that I purchased my 6000L, personally I don't see why I couldn't continue using the applications that came with my purchase. I'm more than willing to reinstall the applications that it comes with. In fact, it's my preference, as I currently sync my data to my palm desktop. I can live with my current version of Opera, etc. It's not like I'm using someone else's copy.
I think as long as you don't include it in the distribution, then it's cool. We can always use the ipk that comes with our CDs.
As for the mplayer stuff, using the qtopia libs is cool, b/c I still have my original license. Just make a disclaimer page saying that if we download it, it is conditional that we already have a license for it (which we obviously do, as I don't think it's possible to have a 6000L without the software). I'm perfectly fine with using my existing Sharp things where needed. I *like* being able to install all the various ipks. While certain apps aren't perfect, they do work. As long as it's stuff that is already on my currently licensed things, I don't mind using it.
-
hbo, I'll try to host that on externe - I prefer having everything at hand.
Yet I don't want non free parts exposed - distributing them in a big nand file which can only be restored on the 6000 is one thing, exposing them on the web is something else I don't want to do. - that would be like promoting their use :-/
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=80099\")
That's fine. How about a repo for the Free (libre) stuff?
...
BTW - my long promised editorial is on [a href=\"http://externe.net/zaurus/modules.php?op=modload&name=News&file=article&sid=57&mode=thread&order=0&thold=0]http://externe.net/zaurus/modules.php?op=m...order=0&thold=0[/url]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80099\"][{POST_SNAPBACK}][/a][/div]
That's quite an effort. I'm not sure I agree that the Opie framework should die. I have three basic reasons for that opinion. First, the same was said of Gnome and KDE: that that there was one too many desktop framework on Linux/*BSD. They also said that the competition would kill Linux on the desktop. Neither of those statements have panned out, and it's been 10 years since KDE started up. Second, I worry that opening fire on Opie could be divisive, and could alienate volunteers who have given time to that project. You could thus actually worsen the split by casting the problem in either/or terms.
I'm not worried about Trolltech's opaque development process, although I wish it were otherwise. They've been doing the same thing with QT itself over the years, but have come through famously for the KDE community, at least after the dual licensing decision was taken.
I think that an entente cordiale is needed between the two camps. Something like freedesktop.org, or maybe freedesktop.org itself. That way, the Opie volunteers could participate without fear that the process was designed to annihilate them. That sort of pressure doesn't produce cooperation, in my experience.
-
Of course.. there is always the X based desktop option good on office apps, not so good on handheld browsers..though minimo is looking better.
can siag be compiled against qt? Looks at a quick glance.. like no. could be compiled for X though....
koffice compiled for z? could it be done?
I don't know much about non gtk office apps....
-
Of course.. there is always the X based desktop option good on office apps, not so good on handheld browsers..though minimo is looking better.
can siag be compiled against qt? Looks at a quick glance.. like no. could be compiled for X though....
koffice compiled for z? could it be done?
I don't know much about non gtk office apps....
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80131\"][{POST_SNAPBACK}][/a][/div]
The issue is still the small screen and code size. If you simplify and unclutter the interface to a big, heavy desktop office app, and cut out half the features to reduce code size in order to adapt it to a handheld, it's not clear to me that you end up with anything better suited to the small environment than if you had started from scratch. But there's all that free (in both senses) code out there, so the thought often occurs to me that this or that desktop app would do well on my Z. I'm looking at KNX in that regard now, although that guy is a bit of a special case as regards the UI.
The glaring ommision that Guylhem points out in his paper is the web browser piece. I got both Mozilla and Firefox running under pocket workstation on my Z, but that was with a 4GB microdrive and 128MB of swap! And still they were slooow. It is the first time I've tried that where the zaurus hasn't locked up, however, so that's progress. The last time I looked at Minimo, it didn't impress me. But it certainly has potential. If someone could give embedded konqueror some love, it might be made to be servicable.
My guess is that there are too many crying needs and not enough skilled volunteers. That's why the whole split with OE dismays me so much. I've been away from the community for a couple of years, so I hadn't caught up with developments. I'm still not all the way up to speed, but the tension between modern features and backwards compatibility is a familiar story. (heh heh. he said "familiar") The trouble is that users often get squeezed in such disputes, and that certainly seems to be happening here.
Maybe an "entente cordiale" isn't possible between the Qtopia and OPIE crowds. Maybe what's needed is a shotgun wedding, in which neither the bride nor groom need be present. That is, can we devise an environment that will host both types of apps? If WINE can run winders on Linux, surely its possible to play with union mounts and the dynamic loader in such a way as to give each type of app what it expects from the system?
In that connection, can someone point me at documentation on hard vs. soft float on the ARM? I thought it was all soft float since the ARM doesn't have an ALU.
-
honestly, see the best hope for a free oss browser currently to be dillo. vanilla dillo doesn't do frames or ssl. there is a patched version on damn small linux that does. compiling it to run on a Z X distro would probaby work out ok.
the best hope for a future browser free/oss would be minimo. nothing in qt being developed currently.
also..I think you'll find that the pdXrom version of firefox is less painful to use. I have heard that it is perttty snappy there.
so... maybe gpe or pdax bear another look in the search for a gui? or a native X option to G-rom?
of course, an outofthebox rom for general ust on which opera can be installed i likley stikll the best default
-
...
of course, an outofthebox rom for general ust on which opera can be installed i likley stikll the best default
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80248\"][{POST_SNAPBACK}][/a][/div]
I'm afraid so. Until one or another FL/OSS browser approaches Opera in speed, compatibility and footprint, then running that beast will be a requirement for any general purpose Z ROM, IMHO.
It's not that having X11 on Z isn't nice, or even a requirement, for me. It's just that the appropriately sized apps are mostly on one or another QTE environment. The thing that makes X11 compelling for me is not X11, it's pocket workstation. With the development environment and apps of Debian Sarge, kept up to date by one of the biggest FL/OSS armies out there, the promise for the future, and my comfort level for the present is assured. If I were forced to, I would make that my sole environment on the Z.
But I'm not forced to do that. I can have my cake and eat it too. It's actually remarkable, and pretty cool, that I can run Debian/X apps alongside the QTE stuff. But, am I satisfied with this? Noooo. I want more! More compatibility and therefore more apps to choose from. I will commit the narcissistic sin of believing that is what drives most of my fellow technology enthusiasts.
So I think a distro that could run most apps would be a hit.
[addendum]
I'm also not happy that I have to chroot to get the Debian environment. I understand why that is, but I still don't like it. It means I have to have two Perl installations on the system. for example.
-
my take as well... ultimately we need to go to handheld debian. And honestly, a unique guylhem rom that was a model specific foundation to a native debian would be a really good thing, and a useful and popular one.
I disagree about the X-based office apps being necessarily bigger. Siag is pretty tiny. It isn't available on the Z yet.. but the source is available.
Dillo with the patches could make a good browser, it is small and nimble and open. And I certainly put bets on minimo getting good-- mozilla.org is pretty hot. Now doing a light "on the nand" x os, with the opition to boot into a bigger card based version of the same might be a good solution, or just assuming that /usr /home /opt /var and /tmp were going to be on a card might be good. If the X-server were optimized for the Z it could be effective and snappy either way.
The thinkg is..this might be a bit down the road.
checking out pdaX now
-
I disagree about the X-based office apps being necessarily bigger. Siag is pretty tiny. It isn't available on the Z yet.. but the source is available.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80262\"][{POST_SNAPBACK}][/a][/div]
I don't know that one. Is it a word processor? Office suite? Do you create a lot of business documents on your Z?
Dillo with the patches could make a good browser, it is small and nimble and open. And I certainly put bets on minimo getting good-- mozilla.org is pretty hot. ...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80262\"][{POST_SNAPBACK}][/a][/div]
It took them a long to to get that way. But, persistence paid off in that case.
... Now doing a light "on the nand" x os, with the opition to boot into a bigger card based version of the same might be a good solution, or just assuming that /usr /home /opt /var and /tmp were going to be on a card might be good. If the X-server were optimized for the Z it could be effective and snappy either way.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80262\"][{POST_SNAPBACK}][/a][/div]
I think code size is an issue here. QT embedded is pretty lean and mean. Partly that's because they leave out features like the network stuff, and partly it's just not having the X11 heritage of a hugely bloated research system running on successively more powerful machines, which meant there was less incentive to curb the bloat. It's not insurmountable, but it's a real issue.
But as my Zaurii get more powerful, they start being able to cope with the bloat. If I had 128MB of SDRAM in my 6K, I'll bet it would do a lot better with Mozilla.
checking out pdaX now
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80262\"][{POST_SNAPBACK}][/a][/div]
Yeah, I caught your posts in the other thread. 8) Let me know how it goes. At the moment, I'm back to the sharprom. I'm layering on all the software I want prior to doing a NAND backup and reflash with whatever looks interesting at that point.
-
I don't do a tremendous amount of office apps on my Z.
siag is a small suite... started a few years ago and was made for weak/tiny desktops then. I keep whining about it neding to be compiled... maybe I should do it.
gpe and pdaX have managed to trim down X pretty efecctively. it is still bigger than qt, but much better than you might guess.
-
i was using dillo on an embedded system we were working on for my job, it far from good
as for firefox, it runs fine on Z/Xqt , the only thing is loading time, it takes about 2 minutes to load it, minimo starts much faster btw
i was thinking about prelinking stuff for big applications, but its a waste of memory
however, X SHOULD be there on the rom ...
-
Guylhem,
Regarding the issue of what can be useful, I thought perhaps it may be useful if I put together a rough list.
1- The palm desktop for me is useful, also it would mean if I had a Palm, I could easily move to the Z without having to replace everything. The standard apps that come with the Sharp ROM can already do that. That ability would continue to be important. I'm not concerned about license issues, because a license already came with my Sharp. I would guess that I could easily install this application if it wasn't included in the distribution. Which would also mean that things like "today" would not be useful unless it replaced one of the applications. The key there would be "is it better, more useful, more feature packed, more compatible, etc".
2- Sharp ROM compatibility is great. It means that there is a huge library of applications that I can easily use. It's also why I keep finding myself returning back to the Sharp ROM. Quite a lot of software written for the 5500 work nicely with it. I will say that the idea of a "fast library" is very attractive in that it increases the useability and "adds on" a feature. Again, I'm not too concerned on the license issue as my 6000L already has a license (at least that's my impression).
3- a few applications on the Sharp ROM are a little obsolete. Rather than "replacing" them with another application, perhaps the idea of just "removing" them would be a good choice. If I decided that I wanted to keep that application, I wouldn't mind just installing it later on my own. Of course that best thing is if I could install it on my SD rather than my main memory. That gives me a choice, wihtout having unneeded applications. I guess a "barebones" thing would be attractive.
4- Libraries are always a pain. Knowing which one I need + which one works best is something that isn't the easiest. This is where your expertise I think is great. You've gone through all that and have tried to optimize it as much as possible. Multimedia is one area that would be useful. Specific instructions as to installing Kino and mplayer as well as the versions would be cool. I could probably live with it already installed. The only caveat is it seems that it's an evolving product. If there are specific tweaks you've done that are humbug, that would be a good reason to already include it.
5- Game emulators such as snes9x pose a small issue with things like keyboard mapping (instead of having to deal with a reverse keyboard). I'm not sure everyone wants to play games, but an easy process for this would be great.
6- GPS I think is a hot issue. Unfortunately things like gpsdrive doesn't work. I tried kstars on the OZ and it's a bit slow on the 5500. It is rather neat though, and is quite feature packed. I think things like this that were repacked into a fashion that would make it easy to install would be a nice touch. I think this kind of an issue is why people have been trying to get things like newer versions of opera going, etc. I suspect that Sharp ROM compatibility is going to remain a fairly useful issue for a while. This is where having a certain version of Opera already preinstalled is a struggle. On one hand, it does work. On the other hand, we're a little bit stuck. It seems wasteful to have to install another version if there's already a version installed.
7- Certain utilities that you popped in are indeed useful. The console for instance, is much more useful than the one that the Sharp ROM has. Those are the kinds of things that are a pleasant surprise. I think the idea of having a fast library is probably the most compelling idea. It allows things like games to run at decent speeds.
Comment: I think where I'm going is I really don't mind being stuck in the Sharp ROM world, because things do work for the most part. Your use of the fast libraries is a compelling reason to alter that perception --- provided I don't lose the current functionality I already enjoy with the Sharp ROM. I don't mind "new features" as long as I dont' lose much of the "old features".
Hope this rambling is useful ...
-
Don't be afraid to voice your thoughts - it's quite usefull.
I share your opinions- I'm an avid user of palm desktop (jpilot more exactly) and good PIM is very important to me. I'm also very concerned by compatibility and IMHO breaking it at the moment is only worth for several applications such as mplayer/snes9x, which could be statically compiled in softfloat anyways!
Basically, I want something polished and doing a good job.
Regarding GPS or specialised hardware, I can't really help because I don't have that hardware. If you want me to make your GPS work, get me a bluetooth GPS [I spend already too much on toys I don't need]- any model that does NMEA (ie work with the Zaurus) will be fine :-)
We need mostly 1. maps 2. software - I've got several ideas (using the nasa "world wind" database for ex to use satellite bitmaps instead of vectorial maps) but I can't work on such feature right now - because I can hardly emulate how a real GPS will work.
My current priority is releasing a 1.0rc1 soon with a couple of softfloat binaries and fixed fonts (2 Mb of nice fonts - for opie-reader). I will then certainly work on integrating X windows apps since someone offered to forward me the microdrive. I can schedule the GPS next. I've several days off in the following weeks so it's totally possible.
-
>fixed fonts
unicode i hope? i know for you latin-1 is enough :-)
-
You can get nice set of fonts from OE - dejavu fonts are good for most Europe users.
-
Regarding GPS or specialised hardware ...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80340\"][{POST_SNAPBACK}][/a][/div]
Not a problem. We don't have gpsdrive now, so it's not like I'm losing something. zRoadmap does work on the Z now, and it's not bad, but it still needs more polish, like voice prompts, showing street names, etc.
fixed fonts (2 Mb of nice fonts - for opie-reader). I will then certainly work on
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80340\"][{POST_SNAPBACK}][/a][/div]
Regarding fonts ... having a ton of fonts for me isn't a super priority, but I do use a few efonts - for the asian dictionaries. Currently of them all, efont_240_50_t10.qpf is probably the most useful, as it presents the chinese language in a larger display for others to see (via zbedic). I do have the 12 and 16 point fonts also installed in the even I need something smaller. I haven't installed one yet for the european languages, but I do plan to do so in the future. In all honesty, installing it myself isn't a big deal, as just some simple symlinking to my SD card is all that's needed for it to work. I wonder if having too many fonts is like how on windows, where the more fonts you have, the slower the system becomes? I have no idea on this.
That brings me to an entirely different topic ... updates.
I think for a basic installation, the nand restore method is fine. However, at some point, having the ability to update needed parts of the system via small updates (like how cvs works) is something highly desireable. That would relieve the concerns of those not wanting to use up the the amount of limited times they can do nand stuff. More importantly I'm thinking, is the relief it would do in terms of your bandwidth. The OZ update stuff isn't bad, except they've been experiencing a few issues regarding the gui portion of it. The command line part of it is ok from what I understand (much of it is the messages that you don't see during the gui update process --- you don't know the why of it if it's stuck or not). The libqte2 part is probably one of the largest of the files that takes the longest to update.
-
dejavu fonts ? Didn't know about them - latin1 was fine for me as you suggested :-)
I'll try to get them and use them.
Guylhem
-
Regarding GPS or specialised hardware, I can't really help because I don't have that hardware. If you want me to make your GPS work, get me a bluetooth GPS [I spend already too much on toys I don't need]- any model that does NMEA (ie work with the Zaurus) will be fine :-)
You can get apps for a desktop machine (I was lookint at WinXP, but I'm sure the same exists for Linux) which will spit out pretend NMEA data down a serial link, or probably over an ethernet connection (a la gpsd) so you could probably try this way without any hardware. If you're interested I'll see if I can dig up the names of the apps I saw.
Si
-
This thread looks interesting
https://www.oesf.org/forums/index.php?showt...t=0&#entry80451 (https://www.oesf.org/forums/index.php?showtopic=11666&pid=80451&st=0&#entry80451)
-
Just FYI that was under pdaXrom.
This thread looks interesting
https://www.oesf.org/forums/index.php?showt...t=0&#entry80451 (https://www.oesf.org/forums/index.php?showtopic=11666&pid=80451&st=0&#entry80451)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80454\"][{POST_SNAPBACK}][/a][/div]
-
btw, qt's irda apps are not working...
-
the dial-up and other non-wlan stuff shows up in the connect dialog after i removed guylhem dial-up/bluetooth connections from network settings
tested ppp/irda/nokia 6100, works fine