**** BEGIN LOGGING AT Sat Jan 19 02:59:56 2008
Jan 19 05:35:12 <altereog> Centuarium is the greek key word for a location appropriate for a sanctuary
Jan 19 05:36:29 <dexi> : O
Jan 19 05:37:44 <altereog> logan 5, are you here?
Jan 19 05:38:24 <altereog> jessica 6 ?
Jan 19 12:18:47 <voi1> Hi, I flashed my Openmoko with the official snapshot (kernel and rootfs); i wanted to add the unofficial feeds of "ScaredyCat", but if I want to ipkg upgrade, it upgrades the kernel too and the neo (as in wiki explained) crashes on boot. Am I able to be avoiding upgrading the other programs on the ScaredyCat-Feed without upgrading the kernel?
Jan 19 12:26:39 <`pwgen`> hi
Jan 19 14:19:18 <kyz> hi
Jan 19 16:09:51 <KrisAbsinthe> good morning
Jan 19 16:10:04 <voi1> morning
Jan 19 16:10:12 <dcordes_> good evening
Jan 19 16:10:24 <zedstar> afternoon :)
Jan 19 16:10:37 <dcordes_> somebody got night left?
Jan 19 16:10:46 <mbuf> dcordes_, yes
Jan 19 16:10:53 <zedstar> lol
Jan 19 16:12:49 <voi1> a question: I flashed into my neo the official snapshot of Openmoko. After this I wanted to add the "ScaredyCat"-Repo-Feed to ipkg. If i upgrade openmoko, ipkg wants to upgrade kernel-modules too, and so it crashes on boot (as explained in wiki). Am I able to upgrade all but the kernel-modules?
Jan 19 16:13:45 <KrisAbsinthe> Well if you cant update the modules updating the kernel is probably a bad idea
Jan 19 16:14:32 <KrisAbsinthe> is there a specific feature you are trying to get working, or just latest OM
Jan 19 16:14:44 <voi1> Yes, but if I write "ipkg upgrade", it upgrades the kernel too automatically.
Jan 19 16:14:58 <voi1> the latest OM would be nice. (scrummvm too)
Jan 19 16:15:03 <voi1> *scummvm
Jan 19 16:15:54 <KrisAbsinthe> I usually go with either the latest OM or angstrom and modify them to my liking 
Jan 19 16:16:33 <voi1> Do you compile the latest source-code yourself? or where do you get the images?
Jan 19 16:17:20 <KrisAbsinthe> just a second ill send link
Jan 19 16:17:45 <KrisAbsinthe> http://wiki.openmoko.org/wiki/Repositories
Jan 19 16:17:55 <KrisAbsinthe> this is where they are all listed
Jan 19 16:18:04 <KrisAbsinthe> im using 2007.11
Jan 19 16:18:37 <KrisAbsinthe> with matchbox-desktop from angstrom
Jan 19 16:18:39 <voi1> hm.. k, and did you add other feeds too? or only the default-feeds?
Jan 19 16:18:47 <voi1> hm, k
Jan 19 16:19:04 <KrisAbsinthe> angstrom's repos are nice 
Jan 19 16:19:43 <KrisAbsinthe> i tried scaredycat once, didnt care for the stability
Jan 19 16:20:03 <voi1> and angrstrom's is stable?
Jan 19 16:21:17 <KrisAbsinthe> more than scaredycat , in my opinion, but you have to use moko as a base unless you want to try and get *everything* working manually  
Jan 19 16:22:03 <voi1> okay.
Jan 19 16:22:20 <KrisAbsinthe> OM kernels and modules are good, but i dont care for the GUI. So I use a desktop environment 
Jan 19 16:23:07 <voi1> thanks a lot. i'll try some of your hints.
Jan 19 16:24:10 <KrisAbsinthe> NP, if you have any feature you want working let me know, I bought the Neo the day it went on sale and have been having fun ever since 
Jan 19 16:25:42 <voi1> thx, i'll fall back to you, if the time comes :-)
Jan 19 16:31:13 <mbuf> i think they should have one for community developer requirements, http://openmoko.com/careers-index.html :)
Jan 19 16:47:55 <bbb8> hey
Jan 19 16:48:32 <KrisAbsinthe> hello
Jan 19 16:51:28 <bbb8> hows OM going? :)
Jan 19 16:52:24 <KrisAbsinthe> Good,  still some issues, some easily solved some not so easy
Jan 19 16:52:48 <bbb8> good, hows the powermanagement issues going?
Jan 19 16:53:23 <KrisAbsinthe> Still needs work, but i can get 5+ hours away from power
Jan 19 16:54:18 <bbb8> is that on standby
Jan 19 16:54:20 <bbb8> ?
Jan 19 16:54:53 <mbuf> KrisAbsinthe, does freerunner have self-powered charging?
Jan 19 16:55:01 <KrisAbsinthe> yeah, talk time i dont know, cause im stuck in a GSM 850 area
Jan 19 16:55:17 <Vegar> self-powered charging?
Jan 19 16:55:23 <KrisAbsinthe> I know very little about 'FreeRunner'
Jan 19 16:55:42 <mbuf> Vegar, using external power chargers, compared to USB bus-powered
Jan 19 16:55:49 <bbb8> oh, u have one of the 850 devices with u? or you had to return it to them?
Jan 19 16:56:33 <mickeyl> evening
Jan 19 16:56:35 <KrisAbsinthe> I still have it. Im involved in a test, they will be sending me a modified GTA01 to test with 850,
Jan 19 16:56:50 <bbb8> mbuf, like taking out the battery 'n chargin in external chargers?
Jan 19 16:57:24 <bbb8> o ok, i thought they sent out the devices some time ago 
Jan 19 16:57:46 <bbb8> good evening micheyl
Jan 19 16:57:52 <PP|Spydon> isn't the battery exactly the same as many nokia batteries?
Jan 19 16:57:59 <mbuf> bbb8, that can be done even now; i meant without taking out the batteries, using some external power source
Jan 19 16:58:07 <bbb8> well not exactly the same
Jan 19 16:58:18 <KrisAbsinthe> Oh i bought one many months ago, if you live in a small city or bigger you should be ok
Jan 19 16:58:22 <bbb8> the neo battery has more capacity from the BL-5C
Jan 19 16:58:29 <PP|Spydon> I see
Jan 19 16:58:40 <KrisAbsinthe> I use my nokia battery as a backup
Jan 19 16:59:24 <PP|Spydon> how nice, my father used to work at nokia so we have tons of those batteries :P
Jan 19 16:59:25 <bbb8> cool
Jan 19 16:59:33 <bbb8> haha great!
Jan 19 16:59:38 <PP|Spydon> yeah ^^
Jan 19 16:59:55 <bbb8> but remember quality will not be as good :p
Jan 19 16:59:57 <bbb8> brb
Jan 19 17:01:43 <PP|Spydon> yeah but it's always good to have a backup incase you run out of battery
Jan 19 17:02:31 <KrisAbsinthe> Im thinking of adding solar panels to the back of mine, cost is about $20 total 
Jan 19 17:14:31 <bbb8> solar panels would be awesome
Jan 19 17:14:41 <bbb8> what's the thickness?
Jan 19 17:15:30 <cesarb> solar panels do nothing when the phone is on your pocket
Jan 19 17:15:42 <bbb8> no not on your pocket
Jan 19 17:16:16 <bbb8> for example if in ur office u got some some sunlight then u'll put it there :)
Jan 19 17:16:47 <bbb8> how long would it take to charge fully from those small panels?
Jan 19 17:18:33 <KrisAbsinthe> depends on the amps used, I will do the calculations and let you know.
Jan 19 17:18:59 <bbb8> sure, post it on the community mailing list
Jan 19 17:19:11 <Vegar> bbb8: you'd have to place it outside the window
Jan 19 17:19:16 <KrisAbsinthe> sure, 
Jan 19 17:19:17 <Vegar> or have the window open
Jan 19 17:19:50 <bbb8> why?
Jan 19 17:20:11 <KrisAbsinthe> Actually its not just "Solar" it has to do with light particles reacting with a crystal based chemical inside the solar panel
Jan 19 17:20:33 <bbb8> true,
Jan 19 17:20:38 <bbb8> the photons
Jan 19 17:20:42 <KrisAbsinthe> right
Jan 19 17:20:51 <bbb8> but why would the window closed be a problem,
Jan 19 17:21:05 <cesarb> KrisAbsinthe: but the energy output you get from office-style fluorescent lighting is not as much as you'd get from a huge nuclear furnace
Jan 19 17:21:12 <bbb8> unless the window is painted black
Jan 19 17:21:32 <Vegar> bbb8: for the same reason that you don't get a tan through the window
Jan 19 17:21:56 <bbb8> well i never really tried that vegar :p
Jan 19 17:22:15 <KrisAbsinthe> i agree with that, but at the least it would slow the discharging under poor lighting 
Jan 19 17:22:33 <bbb8> so how much of the radiations get reflected from the window?
Jan 19 17:22:37 <cesarb> Vegar: actually, the reason you don't get a tan is that the glass is blocking a lot of the UV
Jan 19 17:22:46 <cesarb> Vegar: unless it's a special UV-transparent glass
Jan 19 17:24:18 <bbb8> oh ok
Jan 19 17:24:56 <KrisAbsinthe> this history channel thing is great
Jan 19 17:25:33 <kdean06> I just plug in my USB cable at work. :)
Jan 19 17:25:46 <KrisAbsinthe> i cant admin is a d*ck
Jan 19 17:25:52 <kdean06> Oh.
Jan 19 17:26:31 <bbb8> hmm
Jan 19 17:26:35 <Vegar> bbb8: I might be wrong
Jan 19 17:26:58 <voi1> Would the solar panel connected to phone via usb or directly?
Jan 19 17:27:24 <KrisAbsinthe> i want to layer the back of the phone with the panels
Jan 19 17:27:44 <bbb8> well i think tanning is actually from the UV like u said, but i don't know how much it affects in the charging from solar panels
Jan 19 17:28:16 <bbb8> because as long as there's light, like plants u know
Jan 19 17:28:29 <bbb8> the chlorophyl
Jan 19 17:28:53 <bbb8> u can have them inside the house with the window closed.
Jan 19 17:29:21 <KrisAbsinthe> as long as there is some photons bouncing around to use
Jan 19 17:29:42 <bbb8> i think so...
Jan 19 17:30:00 <bbb8> not sure tho......
Jan 19 17:30:05 <KrisAbsinthe> ive done some experiments with solar energy
Jan 19 17:31:00 <voi1> is photosynthese the same physical thing as the photovoltaic technology?
Jan 19 17:31:19 <bbb8> not exactly, but i think it's both the photons doing the function there..
Jan 19 17:31:33 <bbb8> what do u think KrisAbsinthe?
Jan 19 17:32:02 <SpeedEvil> The reason office lighting doesn't produce power is illumination levels.
Jan 19 17:32:15 <SpeedEvil> It's some 100th of direct sunlight
Jan 19 17:32:25 <voi1> the same thing would be awesome, then we could reduce co2 and produce oxygen.
Jan 19 17:32:25 <KrisAbsinthe> The mechanism is different but the principle is the same 
Jan 19 17:32:31 <voi1> ;-)
Jan 19 17:32:45 <bbb8> yea but does it matter if ur next to a closed window or open SpeedEvil?
Jan 19 17:32:48 <KrisAbsinthe> we could use fresk O2
Jan 19 17:32:52 <KrisAbsinthe> *fresh
Jan 19 17:33:23 <bbb8> yea and save the world eh?
Jan 19 17:33:35 <SpeedEvil> A 12W CFL produces around 3W of light - about 1/333 of the energy in a square meter of sunlight - equivalent to about a 6cm square window
Jan 19 17:33:36 <voi1> like Al Gore
Jan 19 17:34:13 <SpeedEvil> Closed or open window with sunlight shining through has relatively little effect - as long as it's not got solar reflective film in
Jan 19 17:34:15 <bbb8> how about those UV lights? :D
Jan 19 17:34:30 <SpeedEvil> that cuts visible light by a factor of several.
Jan 19 17:34:58 <bbb8> yea, like the sunglasses?
Jan 19 17:35:05 <KrisAbsinthe> Ok, im pretty sure that if you had a solar panel in direct sunlight and monitored the voltage and then covered it with a glass panel that it would do very little, as always i reserve the right to be wrong ;)
Jan 19 17:35:14 <SpeedEvil> Consider the input power. To get a light level equivalent to full sunlight, you need 2000W per square meter of lights.
Jan 19 17:35:26 <SpeedEvil> And that's very efficient lights
Jan 19 17:36:09 <KrisAbsinthe> I think this may require a Wiki when i start this, its set in stone now lol
Jan 19 17:36:10 <SpeedEvil> KrisAbsinthe: straight glass has little effect - treated glass - to reflect sunlight as much skyscrapers are covered with - is a different story
Jan 19 17:36:28 <SpeedEvil> google alt.solar.photovoltaic faq
Jan 19 17:36:32 <KrisAbsinthe> Totally agree with that
Jan 19 17:37:08 <bbb8> :)
Jan 19 17:37:52 <bbb8> how about the uv lights speedevil?
Jan 19 17:38:02 <SpeedEvil> What about UV lights?
Jan 19 17:38:02 <bbb8> 'n KrisAbsinthe?
Jan 19 17:38:24 <bbb8> would they be any different from normal room lights?
Jan 19 17:38:57 <SpeedEvil> No.
Jan 19 17:39:18 <bbb8> altho they're at a higher frequency?
Jan 19 17:39:24 <SpeedEvil> They are marginally more efficient in some cases (germicidal tubes) but at that wavelength common solar cells stop working
Jan 19 17:39:38 <bbb8> oh ok
Jan 19 17:39:50 <SpeedEvil> Not to mention that they cause serious skin cancer and almost instant severe sunburn
Jan 19 17:40:22 <SpeedEvil> http://en.wikipedia.org/wiki/Solar_radiation shows (third or so graphic down?) what light is emitted byu the sun, and hits
Jan 19 17:40:44 <ewon> morning
Jan 19 17:42:22 <KrisAbsinthe> we should develop a cell that works with IR
Jan 19 17:42:36 <ewon> IR is line of sight
Jan 19 17:42:50 <cesarb> ewon: they are talking about solar cells
Jan 19 17:42:53 <ewon> oh
Jan 19 17:42:55 <ewon> oops :)
Jan 19 17:43:06 <KrisAbsinthe> hehe
Jan 19 17:43:06 <cesarb> ewon: lurk more ;-)
Jan 19 17:43:26 <ewon> hey, I'm king lurker, I average around one line a week
Jan 19 17:43:30 * cesarb knocks on wood and runs run-qemu-snapshot
Jan 19 17:44:12 <KrisAbsinthe> anyway so yes, there will be a WiKi
Jan 19 17:45:15 <SpeedEvil> KrisAbsinthe: standard cells do.
Jan 19 17:45:18 <SpeedEvil> KrisAbsinthe: google.
Jan 19 17:45:49 <KrisAbsinthe> I didnt know that. I love learning
Jan 19 17:47:06 <KrisAbsinthe> SpeedEvil: do you happen to know if there are solder points that would be good for this on the GTA01
Jan 19 17:47:16 <SpeedEvil> For what?
Jan 19 17:47:29 <KrisAbsinthe> adding  solar cells
Jan 19 17:47:34 <SpeedEvil> No.
Jan 19 17:48:00 <SpeedEvil> It's probably easiest to make a replacement back with a shim sticking between the battery socket and the battery
Jan 19 17:48:31 <KrisAbsinthe> thats what i thought, just didnt know if there would be a better place for this. Thank you
Jan 19 17:48:48 <cesarb> SpeedEvil: wouldn't adding things in parallel to the battery be evil? It's a lithium one, after all...
Jan 19 17:48:55 <SpeedEvil> No.
Jan 19 17:49:02 <SpeedEvil> Only if you do it wrong.
Jan 19 17:49:55 <cesarb> SpeedEvil: but by making it too easy to put things there, you are making certain per Murphy's someone will do it wrong
Jan 19 17:50:14 <KrisAbsinthe> those people should buy a multimeter
Jan 19 17:51:38 <SpeedEvil> There is no simple way in GTA01 to get to vbattery 
Jan 19 17:51:41 <SpeedEvil> Or vusb
Jan 19 17:52:44 <KrisAbsinthe> the + and - is listed on the battery though
Jan 19 17:53:02 <SpeedEvil> I mean other than the battery.
Jan 19 17:53:15 <SpeedEvil> You do not simply connect a solar cell across the battery unless you want it to explode
Jan 19 17:53:23 <SpeedEvil> you need a battery manager chip
Jan 19 17:54:03 <KrisAbsinthe> so your saying build a USB solar panel
Jan 19 17:54:20 <SpeedEvil> http://youtube.com/watch?v=4OsBc8RqSKU
Jan 19 17:54:34 <SpeedEvil> Now imagine that happening 6" from your genitals.
Jan 19 17:54:47 <SpeedEvil> KrisAbsinthe: or buy one.
Jan 19 17:55:02 <KrisAbsinthe> that was the best video i have ever seen
Jan 19 17:55:20 <KrisAbsinthe> eh, i like building stuff
Jan 19 17:55:46 * cesarb thinks Wikipedia should have an article on "exploding battery". It has one on "exploding whale" already...
Jan 19 17:56:10 <bbb8_> back
Jan 19 17:56:14 <SpeedEvil> http://www.dealextreme.com/details.dx/sku.4813 for existing USB solar panels
Jan 19 18:02:05 <cesarb> Great, for some reason I don't know yet, "echo userspace > scaling_governor" is acting as if it was a NOP :(
Jan 19 18:02:23 <cesarb> That makes it a bit harder for me to test... :(
Jan 19 18:02:57 <SpeedEvil> \n probs/?
Jan 19 18:04:20 <bbb8__> .
Jan 19 18:04:25 <cesarb> SpeedEvil: nope, echo -n also didn't work :(
Jan 19 18:05:23 <cesarb> And it is on scaling_available_governors, so it's not that it didn't get loaded (I compiled it as built-in, in fact)
Jan 19 18:07:00 <cdbot2> * * OM Bug 1189 has been created by audriusa(AT)bluewin.ch
Jan 19 18:07:01 <cdbot2> * * Click on the program category line in the Application manager does not always open the category list.
Jan 19 18:07:03 <cdbot2> * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1189
Jan 19 18:10:34 * cesarb decided to go ahead, since it's only qemu, and use "performance"
Jan 19 18:11:08 <cesarb> qemu did say "s3c_clkpwr_write: SLOW mode on" and later "s3c_clkpwr_write: SLOW mode off", but now the timer seems to not be working very well
Jan 19 18:11:46 <cesarb> it's advancing 5s for 10s of real time; it did work fine while in SLOW (except for the small emulator-related annoyance that there's no IDLE in SLOW, so it maxes the real CPU)
Jan 19 18:12:22 <CIA-15> freesmartphone.org: 03emdete * r46 10/trunk/software/py-proto/ (pygpsd.py pygsmd.py pyneod.py): 
Jan 19 18:12:22 <CIA-15> freesmartphone.org: allow empty elevation and azimuth in nmea (as gllin sends on warmstart
Jan 19 18:12:22 <CIA-15> freesmartphone.org: for a while) in pygpsd
Jan 19 18:12:22 <CIA-15> freesmartphone.org: fix a bug in pygsmd for standalone mode (no activation from muxer)
Jan 19 18:12:57 <Vegar> why are they doing it all in python?
Jan 19 18:13:10 <emdete> Vegar: fast prototyping ;)
Jan 19 18:13:40 <ArteK> mkdir /tmp/.bluemote
Jan 19 18:13:40 <ArteK> touch /etc/bluemote.cfg
Jan 19 18:13:40 <Sup3rkiddo> because python is cool
Jan 19 18:13:42 <Vegar> good point
Jan 19 18:14:13 <emdete> Vegar: perhaps, if we know the api and the implementation we redo everything in vala
Jan 19 18:15:08 <balrog-kun> cesarb: iirc qemu does nothing except saying "SLOW mode on" when the SLOW mode is switched to :)
Jan 19 18:15:49 <cesarb> balrog-kun: it also seemed to adjust its timing stuff, since the time inside qemu passed at the correct speed (I checked by running "date" twice 10s apart in real time and comparing the result)
Jan 19 18:16:10 <cesarb> balrog-kun: at least my code didn't crash and/or burn, which is what I wanted to check
Jan 19 18:16:20 <balrog-kun> cesarb: that must be the kernel separately adjusting the clock
Jan 19 18:16:53 <balrog-kun> emdete: have you seen the gypsy python bindings?
Jan 19 18:16:53 <cesarb> balrog-kun: precisely. It adjusts the clock to match the new frequency; qemu must be adjusting its own frequency if things are to keep in sync
Jan 19 18:18:36 <emdete> balrog-kun: no. i need a udp-plugin for gypsy. i took a look at it and found it too complex. the python binding is for client side? gyspy talks d-bus, so it should be easy with any language
Jan 19 18:18:42 <balrog-kun> i think qemu just adjusts its frequency as a result of the clock adjustment by the kernel, and not as a result of switching SLOW mode on or off
Jan 19 18:19:51 <balrog-kun> emdete: yeah, i'm just thinking that it may be used as a base for other program's interfaces
Jan 19 18:20:00 <balrog-kun> or a freemsartphone standard
Jan 19 18:20:12 <balrog-kun> freesmartphone.org
Jan 19 18:21:41 <cesarb> balrog-kun: hm, I took a quick look at the qemu code, and it doesn't seem to do any frequency adjust at all... which might mean my timer adjust code might not be working correctly :(
Jan 19 18:22:25 * cesarb is a bit too careful and doesn't think he's ready to test on the real hardware yet
Jan 19 18:23:40 * balrog-kun doesn't think anything bad can happen to the real hardware resulting from bad writes to registers :)
Jan 19 18:23:46 <SpeedEvil> Nowhere in the manual does it say that you can actually screw the CPU
Jan 19 18:24:15 <SpeedEvil> I would be a bit careful before trying NAND writes
Jan 19 18:24:36 <emdete> balrog-kun:  that's the point: in the future pygpsd will do exactly the same on the dbus as gypsy
Jan 19 18:25:18 <cesarb> SpeedEvil: it's a bit hard to avoid NAND writes when you have the userspace running...
Jan 19 18:25:43 <cesarb> SpeedEvil: and it's a bit hard to test without the userspace running :|
Jan 19 18:25:50 <emdete> balrog-kun: all the daemons on the neo run unstable in the past. i hadn't the time to implement all in c, so i startet with the prototypes in py
Jan 19 18:26:11 * cesarb is, in fact, more worried about what the LCM can do if you misprogram something
Jan 19 18:26:52 <SpeedEvil> cesarb: course it's not.
Jan 19 18:26:57 <SpeedEvil> cesarb: boot and run off SD
Jan 19 18:27:07 <SpeedEvil> cesarb: or worst-case, remount NAND ro
Jan 19 18:27:29 <balrog-kun> emdete: sure, i just mean the api, if some api totally different from all existing implementations is chosen for the standard i don't think it will be very successful
Jan 19 18:28:29 <cesarb> SpeedEvil: actually, I was planning on testing without the SD... one less thing to go wrong, and I don't have to write the notifier for it yet if I won't use it ;-)
Jan 19 18:28:41 <balrog-kun> you can boot an initramfs for some experiments too
Jan 19 18:28:57 <balrog-kun> but i don't think something irreversible can happen to the NAND
Jan 19 18:28:58 <cesarb> SpeedEvil: remounting ro sounds like a good idea, "just in case"
Jan 19 18:29:02 <SpeedEvil> cesarb: Or even RAMFS
Jan 19 18:29:14 <SpeedEvil> balrog-kun: somehow write 1000 times to the boot sector
Jan 19 18:29:30 <SpeedEvil> balrog-kun: that's irrecoverable - in principle 
Jan 19 18:29:36 * Sup3rkiddo tries
Jan 19 18:29:49 <balrog-kun> SpeedEvil: because of siwthing the clock modes?
Jan 19 18:30:02 <SpeedEvil> (the boot sector is only specified for 1000 writes)
Jan 19 18:30:10 <SpeedEvil> balrog-kun: I can't imagine how that'd happen
Jan 19 18:31:52 <SpeedEvil> Just saying that it is in principle possible to irrecoverably brick a neo
Jan 19 18:32:06 <SpeedEvil> (well, barring SMD rework)
Jan 19 18:32:27 <balrog-kun> yeah, that's possible
Jan 19 18:33:12 <balrog-kun> and i'm sure if it says in the specs that the NAND can survive at least 1000 writes, it stops working at exactly 1001st write
Jan 19 18:33:31 <balrog-kun> :)
Jan 19 18:34:20 <SpeedEvil> It's in practice as I understand it likely to survive 50K
Jan 19 18:34:28 <SpeedEvil> before getting a bit error
Jan 19 18:34:43 <SpeedEvil> But it's only guaranteed to be error free for 1000.
Jan 19 18:35:13 <SpeedEvil> The whole flash is guaranteed to take 100K writes before getting enough bad blocks to drop before its capacity.
Jan 19 18:38:25 <emdete> balrog-kun: yes, shure, gpsd would be fine because of all the prgrams using it. but i prefere dbus so at least gypsy's api must be supported. imho gypsy's api has some ugliness also... :(
Jan 19 18:39:34 <balrog-kun> *nod*
Jan 19 18:39:59 <emdete> balrog-kun: and hier py rocks in: changing the api is a peace of cake ;)
Jan 19 18:52:05 <voi1> Are the packages downloades by ipkg stored or removed after installing?
Jan 19 18:54:11 <emdete> voi1: they go to /tmp and are removed afterwords
Jan 19 18:54:33 <Vegar> why was ipkg renamed?
Jan 19 18:54:37 <voi1> okay, thx
Jan 19 18:54:49 <borg_> voi1: http://wiki.openmoko.org/wiki/Opkg
Jan 19 18:55:20 <borg_> "there are potential trademark issues with using the Ipkg name"
Jan 19 18:55:30 <PBeck> hi
Jan 19 18:55:33 <borg_> the question is imo, why does oe use ipk and not deb's?
Jan 19 18:55:45 <Vegar> ah
Jan 19 18:55:47 <borg_> there are so many deb's around
Jan 19 18:55:48 <Vegar> thanks borg_ 
Jan 19 18:55:54 <borg_> why use ipk?
Jan 19 18:56:02 <Vegar> because it's lightweight
Jan 19 18:56:03 <zash_> ipk use less space they say
Jan 19 18:56:13 <borg_> yes, but is that valid today?
Jan 19 18:56:29 <Vegar> yes, it's an embedded device
Jan 19 18:56:49 <Vegar> and how many debs are there for the ARM architecture?
Jan 19 18:58:35 <borg_> the whole debian repository?
Jan 19 18:58:50 <KrisAbsinthe> if so im switching
Jan 19 18:59:03 <borg_> of course
Jan 19 18:59:22 <borg_> josch has a debian running on his neo
Jan 19 18:59:40 <borg_> and why is a deb bigger then an ipk?
Jan 19 19:01:25 <borg_> http://sicherheitsschwankung.de/post/jan/2007-08-26/debian-neo1973
Jan 19 19:02:43 <Vegar> borg_: ipkg 0.99 support ".deb format"
Jan 19 19:02:53 <Vegar> http://handhelds.org/moin/moin.cgi/Ipkg
Jan 19 19:03:18 <dcordes_> hm debian on neo good idea
Jan 19 19:03:29 * dcordes_ wants to try it on zaurus
Jan 19 19:04:08 <borg_> Vegar: yes, but why dont we just switch to apt-get or aptitude and deb only?
Jan 19 19:05:00 <Vegar>     *
Jan 19 19:05:00 <Vegar>       The control programs are several hundred kB.
Jan 19 19:05:00 <Vegar>     *
Jan 19 19:05:00 <Vegar>       The meta-data, (/var/lib/dpkg), is several MB.
Jan 19 19:05:00 <Vegar>     *
Jan 19 19:05:02 <Vegar>       The package granularity is rather coarse, (eg. many packages include documentation)
Jan 19 19:07:01 <mwester> There's a port of Debian to ARM.  It can't be that difficult to make the Neo work with that distro, for those who really want to run a desktop distro on a cell phone ;)
Jan 19 19:07:18 <borg_> mwester: it is already done ;)
Jan 19 19:07:33 <mwester> Well, then, there's your apt-get.
Jan 19 19:07:50 <cesarb> SpeedEvil: I created http://wiki.openmoko.org/wiki/User:CesarB/cpufreq with a more detailed explanation of what I'm doing (feel free to fix any mistake on it)
Jan 19 19:07:52 <dcordes_> mwester: maybe some feel more complete when they have their desktop distro around.
Jan 19 19:07:58 * mwester doesn't care to carry an external hard drive about with him for a cell phone :-D
Jan 19 19:08:06 <borg_> but then i have to make lots of debs for myself :)
Jan 19 19:08:17 <KrisAbsinthe> Does anyone have a link for bin of debian?
Jan 19 19:08:34 <borg_> KrisAbsinthe: ask "josch" when he is back here
Jan 19 19:08:40 <KrisAbsinthe> thx
Jan 19 19:09:02 <mwester> It is rather cool, though, that we can even discuss running a standard distro like Debian on the device in the first place.
Jan 19 19:09:31 <KrisAbsinthe> true, if a desktop is all that some people want, they can run OM with matchbox-desktop
Jan 19 19:18:46 <emdete> cesarb: that sounds like long awaited code.. what is the state of the project currently?
Jan 19 19:19:04 <cesarb> emdete: as explained on the link I just posted ;-)
Jan 19 19:20:13 <emdete> cesarb: i didn't see how far it's already gone...
Jan 19 19:20:13 <cesarb> emdete: about half of the drivers are done, the ones left are either optional (SD - you can remove the SD chip; IIS - you can just not use the sound) or shouldn't cause too many problems... but I'm still wary of actually testing on real hardware
Jan 19 19:20:51 <cesarb> emdete: for two reasons: one, it's 2.6.24, which is not as well-tested as 2.6.22; two, the code I've written is completely untested ;-)
Jan 19 19:21:30 <emdete> cesarb: i am not very familar with cpufreq and linux. what exactly is possible with it? a daemon can lower/restore the frequency?
Jan 19 19:22:08 <SpeedEvil> yes
Jan 19 19:22:21 <SpeedEvil> according to CPU load or other factors
Jan 19 19:22:29 <cesarb> emdete: it allows a governor (a separate piece of code) to set the target cpu frequency. One of the governors, "userspace", allows you to do it from a daemon.
Jan 19 19:24:14 <emdete> cesarb: cool think... i really would like to have that soon :)
Jan 19 19:24:24 <emdete> cesarb: does om pay you for that?
Jan 19 19:25:16 <cesarb> emdete: no, but I have a GTA01 which I want to be able to use for more than just a few minutes untethered each time ;-)
Jan 19 19:25:37 <cesarb> emdete: if I were paid, it would go way faster than "a couple of drivers each week" :D
Jan 19 19:25:45 <emdete> cesarb: :D that's what i need it for too.
Jan 19 19:27:32 <cesarb> emdete: that's what I like most about free software -- if something doesn't work the way I want it to work, I can go and bash the code until it does
Jan 19 19:27:44 <daMaestro> lol
Jan 19 19:27:46 <daMaestro> +1
Jan 19 19:28:00 <emdete> cesarb: exactly, but thre is so much todo...
Jan 19 19:28:10 <cesarb> emdete: ...and so little time.
Jan 19 19:28:45 <emdete> cesarb: exaclty... i try to help with user space daemons...
Jan 19 19:34:23 * cesarb wtfs
Jan 19 19:34:30 <CIA-15> freesmartphone.org: 03mickeyl * r47 10/trunk/standards/otapi/ (2 files): 
Jan 19 19:34:30 <CIA-15> freesmartphone.org: otapi/Network:
Jan 19 19:34:30 <CIA-15> freesmartphone.org: * add operator selection (Register, RegisterWithProvider)
Jan 19 19:34:30 <CIA-15> freesmartphone.org: * enhance ListOperators format
Jan 19 19:34:42 <cesarb> scaling_governor says it's performance, but scaling_setspeed (from userspace) is there???
Jan 19 19:41:40 <cesarb> hm, running with cpufreq.debug=7, I can see the cpufreq core isn't calling the notifiers when I'm thinking it should be calling the notifiers. Looks like there's a bug in my code.
Jan 19 19:47:13 <cesarb> great, the quite poor cpufreq documentation forgot to mention cpufreq_notify_transition... that's what I get for following the documentation :(
Jan 19 19:54:17 <KrisAbsinthe> whats the resolution of the GTA01
Jan 19 19:54:40 <zash_> VGA?
Jan 19 19:55:43 <KrisAbsinthe> maybe i worded that wrong, i mean screen size res (800x600?)
Jan 19 19:57:02 <KrisAbsinthe> got it 480x640
Jan 19 19:58:37 <daMaestro> which really looks awesome
Jan 19 19:58:52 <daMaestro> once we get screen flipping going.. web browsing will be sick
Jan 19 19:59:01 <KrisAbsinthe> I so agree,
Jan 19 19:59:03 <daMaestro> (read: sick == cool, good, etc)
Jan 19 19:59:03 <mwester> sick?  I think it will be rather good, actually.
Jan 19 19:59:08 <mwester> oh.
Jan 19 19:59:24 <summatusmentis> screen flipping will be tied to accelerometers right?
Jan 19 19:59:29 <daMaestro> yes
Jan 19 19:59:36 <summatusmentis> sick ;-)
Jan 19 19:59:42 <daMaestro> and iirc, manually can be done with the gta01
Jan 19 19:59:56 <KrisAbsinthe> Makes me wish i wated for the second model, looks like ill have two lol
Jan 19 19:59:58 <Tronic> I wonder if the CPU is fast enough to run the screen.
Jan 19 20:00:00 <daMaestro> (i'd expect some tap target to issue the flipping)
Jan 19 20:00:01 * summatusmentis doesn't have any openmoko right now, will have qemu soon
Jan 19 20:00:23 <daMaestro> Tronic, gta01? .. somewhat
Jan 19 20:00:26 <daMaestro> depends on what you are doing
Jan 19 20:00:29 <Tronic> gta02, mostly.
Jan 19 20:00:32 <summatusmentis> KrisAbsinthe: you may be able to upgrade the board.... potentially
Jan 19 20:00:39 <daMaestro> ah, yes... gta02 should be great
Jan 19 20:00:50 <KrisAbsinthe> that would be so great!!!!
Jan 19 20:00:52 <daMaestro> it will have a gpu and a 400Mhz risc
Jan 19 20:00:54 <SpeedEvil> summatusmentis: that's looking _very_ unlikely
Jan 19 20:00:55 <Tronic> I cannot tolerate the delays that are there in all modern mobile phones.
Jan 19 20:01:09 <summatusmentis> SpeedEvil: purchasing a gta02 board is unlikely?
Jan 19 20:01:16 <summatusmentis> I didn't mean upgrade in the sense of soldering
Jan 19 20:01:18 <SpeedEvil> summatusmentis: you basically need to completely rebuild the phone
Jan 19 20:01:22 <daMaestro> i'm not sure what the gpu is going to be (i'd not looked at the clock at least(
Jan 19 20:01:30 <SpeedEvil> summatusmentis: and the LCD is glued on for example.
Jan 19 20:01:41 <SpeedEvil> (to the PCB)
Jan 19 20:01:41 <summatusmentis> SpeedEvil: oh... I didn't realize that
Jan 19 20:01:42 * daMaestro is more then likely going to also buy a gta02
Jan 19 20:01:54 <KrisAbsinthe> yup
Jan 19 20:02:04 <daMaestro> the cost is a little bit of a kick in the junk
Jan 19 20:02:08 <summatusmentis> there are still plans for an 850MHz version (GTA02us) right?
Jan 19 20:02:15 <SpeedEvil> yes
Jan 19 20:02:17 <daMaestro> but if the hardware works >:) this time.. i'll be happy
Jan 19 20:03:06 <KrisAbsinthe> ill be much happier writing apps for the GTA02, much more to do with it
Jan 19 20:03:30 <daMaestro> yeah, but there are still a lot of bug fixing that can be done for the gta01
Jan 19 20:03:37 <daMaestro> (i should say for the core applications)
Jan 19 20:03:53 <daMaestro> gsmd has come a long ways since first getting the phone :-D
Jan 19 20:03:56 <KrisAbsinthe> agreed
Jan 19 20:03:57 <summatusmentis> calls are able to be made sucessfully?
Jan 19 20:04:06 <summatusmentis> I've been out of the loop
Jan 19 20:04:06 <daMaestro> summatusmentis, yes (i can)
Jan 19 20:04:10 <daMaestro> and incoming too
Jan 19 20:04:17 <summatusmentis> awesome
Jan 19 20:04:26 <daMaestro> sms via the gsmd stuff (i don't think they are working via the gui yet)
Jan 19 20:04:35 <KrisAbsinthe> yup. me too. when im in a GSM 1900 area,... anyone who is paying attention,. i bitch about that alot
Jan 19 20:04:44 <daMaestro> reading the phone book off the sim is something that i look forward to
Jan 19 20:05:15 <daMaestro> KrisAbsinthe, you seem to be us bound... what carrier?
Jan 19 20:05:25 <daMaestro> u.s.*
Jan 19 20:05:48 <KrisAbsinthe> no sms via the GUI and it still does not import contacts from SIM
Jan 19 20:05:50 <daMaestro> (unless road runner offers service outside of the US and i didn't know)
Jan 19 20:06:02 <KrisAbsinthe> AT&T/Cingular
Jan 19 20:06:09 <summatusmentis> I hoping to find that tmobile has decent coverage where I go to school, then I'll be buying gta02
Jan 19 20:06:12 <daMaestro> hmm.. i don't seem to have any issues here in CO
Jan 19 20:06:30 <daMaestro> summatusmentis, i've had nothing but good luck with the tmobile network
Jan 19 20:06:31 <ljp> qtopia can access the sim contacts
Jan 19 20:06:40 <KrisAbsinthe> Its just my area, google mechanicsburg,OH
Jan 19 20:06:42 <summatusmentis> daMaestro: are you paying for data? if so, what paln?
Jan 19 20:06:58 <KrisAbsinthe> yes qtopia can
Jan 19 20:06:58 <daMaestro> summatusmentis, i have data for my att sim, but not for my tmobile
Jan 19 20:07:11 <summatusmentis> what's the cost on att?
Jan 19 20:07:13 <daMaestro> summatusmentis, there is some new "unlimited" data plan that is like $9.95/m
Jan 19 20:07:18 <daMaestro> (for tmobile)
Jan 19 20:07:38 <daMaestro> att can be on-demand $.10/KB or something like $19.99/m for unlimited
Jan 19 20:07:57 <summatusmentis> and that's unlimited for use on the handset, supposed to be used for small browsing on a little non-smartphone?
Jan 19 20:07:59 <daMaestro> i've not looked as i can't reliably teather yet
Jan 19 20:08:04 <summatusmentis> mm
Jan 19 20:08:24 <daMaestro> it's unlimited access to GPRS
Jan 19 20:08:42 <KrisAbsinthe> with the neo and unlimited data, free internet anywhere
Jan 19 20:08:47 <daMaestro> which, i think, also includes their 3g offerings... but that doesn't matter much for a neo
Jan 19 20:08:53 <bbb8> :( i wish the telecom company here in qatar (qtel) had a monthly unlimited plan for internet
Jan 19 20:08:54 <KrisAbsinthe> on laptop YAY
Jan 19 20:09:11 <daMaestro> bbb8, yeah.. i've looked at some of the overseas rates.. it's just amazing
Jan 19 20:09:19 <daMaestro> bbb8, something like $20/10MB
Jan 19 20:09:23 * daMaestro boggles
Jan 19 20:09:28 <summatusmentis> assuming I can find decent gsm coverage, I'll be picking up gta02
Jan 19 20:09:34 <bbb8> we pay like 10 QAR for 1 MB, that's around..... lemme see
Jan 19 20:09:35 <KrisAbsinthe> wow, thats terrible 
Jan 19 20:09:52 <daMaestro> summatusmentis, tmobile and att have pretty damn good coverage
Jan 19 20:10:03 <bbb8> that's 2.75 USD per MB
Jan 19 20:10:16 <daMaestro> yeah, so i was just about on.. $27/10MB
Jan 19 20:10:22 <daMaestro> that is just sooooo yuck
Jan 19 20:10:25 <KrisAbsinthe> yea, if I drive 5 miles in any direction im in a GSM 1900 area,
Jan 19 20:10:26 <bbb8> yea :( it's too much!
Jan 19 20:10:28 <summatusmentis> daMaestro: I go to school in rural western MN, and live in rural ME when I'm not in school(on the border of complete dead zone in northern ME)
Jan 19 20:11:08 <bbb8> 'n i use internet alot on phone, so i bought n95 so i can connect with the wireless router
Jan 19 20:11:14 <daMaestro> i have noticed some signal dropouts from att :-/
Jan 19 20:11:25 <daMaestro> but tmobile almost always has a great signal
Jan 19 20:11:37 <KrisAbsinthe> I thought the service was better when it was just Cingular
Jan 19 20:11:53 <summatusmentis> daMaestro: where though? I'm not worried about good signal in cities, I just spend most of my time in the middle of nowhere
Jan 19 20:12:12 <daMaestro> KrisAbsinthe, well.. you are not an iphone user, so you are a second class consumer to them
Jan 19 20:12:35 <KrisAbsinthe> Yup lol
Jan 19 20:12:41 <daMaestro> summatusmentis, gsm has a pretty good distance ability... but i have no idea about your situation
Jan 19 20:12:57 <KrisAbsinthe> http://www.gsmworld.com/roaming/GSM_WorldPoster2007A.pdf     
Jan 19 20:13:05 <KrisAbsinthe> that is the GSm master list 
Jan 19 20:14:51 <summatusmentis> I'll ask around
Jan 19 20:15:24 <daMaestro> KrisAbsinthe, lol.. that is a $30 pdf if bbb8 would download over gprs
Jan 19 20:15:38 * daMaestro boggles again
Jan 19 20:15:44 <KrisAbsinthe> There may be some impending mods or firmware for GSM 850
Jan 19 20:15:47 <KrisAbsinthe> LOL
Jan 19 20:16:15 <KrisAbsinthe> of course IRC over GPRS would cost a small fortune 
Jan 19 20:16:29 <bbb8> haha yea
Jan 19 20:16:46 <bbb8> 'n the calls are very expensive too,
Jan 19 20:16:51 <KrisAbsinthe> I say we all just go back to BBSing
Jan 19 20:17:07 <bbb8> qtel is the monopoly in here, the only telecom company in Qatar
Jan 19 20:17:14 <KrisAbsinthe> kinda dated myself there
Jan 19 20:17:31 <bbb8> but now they're getting new licenses for vodafone or some other company
Jan 19 20:17:33 <KrisAbsinthe> Wow thats horrible 
Jan 19 20:17:34 <CIA-15> freesmartphone.org: 03mickeyl * r48 10/trunk/standards/otapi/ (README org.freesmartphone.GSM.PDP.xml): otapi: add first sketch at org.freesmartphone.GSM.PDP
Jan 19 20:17:35 <mjr> KrisAbsinthe, let's not overgeneralize, there are countries with sane data plans available :]
Jan 19 20:17:38 <bbb8> hopefully the prices will be better
Jan 19 20:17:42 <bbb8> yea i know
Jan 19 20:18:00 <bbb8> 'n all their services are fucked up
Jan 19 20:18:02 <bbb8> internet censored
Jan 19 20:18:29 <bbb8> u can go 'n write nude on google.com 'n it'll come out blocked,
Jan 19 20:18:37 <bbb8> or alot of websites not contained any pornography
Jan 19 20:18:40 <KrisAbsinthe> well that would just piss me off
Jan 19 20:18:43 <bbb8> containing*
Jan 19 20:18:48 <bbb8> yea,
Jan 19 20:18:57 <bbb8> proxies all don't work,
Jan 19 20:19:04 <bbb8> only tunneling with tor 'n some other programs work
Jan 19 20:19:04 <KrisAbsinthe> when does it end, is free thinking blocked there 
Jan 19 20:19:22 <bbb8> so on linux i'm stuck to the slow tor, 
Jan 19 20:19:39 <bbb8> free thinking is not blocked, but u can't really talk freely
Jan 19 20:19:40 <bbb8> :p
Jan 19 20:20:17 <bbb8> u know what they did at some time?
Jan 19 20:20:23 <bbb8> it was "eid" like holiday 
Jan 19 20:20:35 <bbb8> whhere everyone calls familys 'n americans call home 'n stuff
Jan 19 20:20:42 <bbb8> they blocked all voIP programs
Jan 19 20:20:55 <KrisAbsinthe> that is cheeky
Jan 19 20:20:58 <bbb8> so that people use the telephones 'n get charged very very high prices
Jan 19 20:21:26 <bbb8> 'n then they said that they had to reduce the bandwidth of the things 'n bullshit and that they didn't turn off the voIP on purpose
Jan 19 20:21:45 <KrisAbsinthe> sounds like bull shit to me
Jan 19 20:21:51 <bbb8> it is :p
Jan 19 20:22:08 <daMaestro> bbb8, so, you must really enjoy the prospects of a "free open source" phone?
Jan 19 20:22:31 <daMaestro> granted, you'll still need a carrier; it will still be a step in a positive direction
Jan 19 20:22:41 <bbb8> haha hell yea i do :p 
Jan 19 20:22:56 <bbb8> but hopefully soon the vodafone will open 'n everything will be better,
Jan 19 20:23:04 <daMaestro> excuse me; you would still need transit (gsm or ip or whatever)
Jan 19 20:23:10 <bbb8> thing is QTel is owned by a sheikh, 'n sheikhs control the country in here,
Jan 19 20:23:21 <bbb8> they can do whatever they want
Jan 19 20:23:32 <KrisAbsinthe> bbb8: where are you?
Jan 19 20:23:39 <bbb8> so if they want they can tell vodafone to not have their prices low, so not many people switch from Qtel
Jan 19 20:23:41 <bbb8> Qatar,
Jan 19 20:23:46 <bbb8> u know next to saudia arabia,
Jan 19 20:23:47 <bbb8> bahrain
Jan 19 20:23:50 <bbb8> united arab emirates
Jan 19 20:23:55 <summatusmentis> oh god! I'm emulating openmoko inside of a virtualized debian, inside of OS X
Jan 19 20:23:58 <bbb8> there in the middle of the persian gulf
Jan 19 20:24:39 <KrisAbsinthe> is all internet censored there?
Jan 19 20:25:44 <bbb8> not all, pornography, some gulf concerned political stuff, things against islam, things against the sheikhs 'n the emirs of the surrounding countries
Jan 19 20:25:48 <bbb8> these kinda things,
Jan 19 20:25:56 <bbb8> and alllllot of proxy 'n anonymous tool websites
Jan 19 20:25:59 <KrisAbsinthe> i see
Jan 19 20:26:17 <bbb8> tor website was even blocked, but now it's not 'n that's really weird, they never do such a thing
Jan 19 20:26:46 <KrisAbsinthe> i dont like censorship at all , it interests me to know how other countries work
Jan 19 20:27:19 <bbb8> yea, that's exactly why i use tor,
Jan 19 20:27:28 <bbb8> anyone know a better tool for linux? for anonymizing traffic>?
Jan 19 20:27:34 <bbb8> tunneling?
Jan 19 20:27:37 <cesarb> bbb8: ssh
Jan 19 20:27:52 <KrisAbsinthe> you can ssh into my box, i dont care
Jan 19 20:28:19 <daMaestro> you can also find many public shell accounts that will allow you to tunnel
Jan 19 20:28:29 <KrisAbsinthe> yup
Jan 19 20:28:38 <daMaestro> freeshell.org (for example) (search: http://giyf.us/free+shell+account
Jan 19 20:28:41 <daMaestro> )
Jan 19 20:28:48 <KrisAbsinthe> is tor the same as onion routing?
Jan 19 20:28:53 <bbb8> yup
Jan 19 20:28:58 <KrisAbsinthe> thought so
Jan 19 20:29:10 <cesarb> KrisAbsinthe: tor is only one implementation of the general concept of onion routing
Jan 19 20:29:30 <bbb8> what other implementations are out there?
Jan 19 20:29:42 <cesarb> KrisAbsinthe: there were others like (IIRC) IIP or I2P or something like that
Jan 19 20:30:06 <KrisAbsinthe> See , learn something everyday 
Jan 19 20:30:13 <bbb8> yup :)
Jan 19 20:30:20 <bbb8> anyone tried freenet?
Jan 19 20:30:31 <bbb8> freenetproject.org
Jan 19 20:31:06 <cesarb> bbb8: don't bother. it's extremly slow, and the only interesting content there was a blog called "Cave of Evil"
Jan 19 20:31:18 <bbb8> oh
Jan 19 20:31:30 <bbb8> what was interesting in it?
Jan 19 20:31:31 <cesarb> bbb8: (granted, I last used it back when I was on university, many years ago)
Jan 19 20:31:59 <bbb8> oh ok
Jan 19 20:32:02 <cesarb> bbb8: it was an interesting blog, like the several interesting blogs you can find in the open Internet
Jan 19 20:32:07 <bbb8> how about JAP?
Jan 19 20:32:23 <bbb8> anon.inf.tu-dresden.de/index_en.html
Jan 19 20:32:27 <cesarb> bbb8: i vaguely recall seeing that acronym somewhere, but other than that I have no idea
Jan 19 20:32:52 <bbb8> the website is censored in here, 
Jan 19 20:32:57 <bbb8> so can't tell u what's in there...
Jan 19 20:33:50 <bbb8> check " Description of Artwork: Websites containing pornography, political criticism of Gulf leaders and anti-Islamic themes are being blocked by Qtel. Chat sites are also being blocked because they serve as a threat to telephone services which Qtel has a monopoly over."
Jan 19 20:34:23 <KrisAbsinthe> OMG thats insane
Jan 19 20:34:51 <bbb8> http://www.thefileroom.org/documents/dyn/DisplayCase.cfm/id/1023
Jan 19 20:35:03 <cesarb> wtf... they don't even bother to hide the commercial intent behind the blocking?
Jan 19 20:35:34 <bbb8> haha, no it's not written by them of course,
Jan 19 20:35:57 <bbb8> the source is a daily newspaper called www.gulf-times.com
Jan 19 20:36:07 <cesarb> bbb8: that JAP site looks like another one like tor or I2P
Jan 19 20:36:20 <bbb8> o ok, works on java i believe?
Jan 19 20:36:30 <bbb8> this is how it looks http://www.ordoesitexplode.com/photos/uncategorized/qatarcensor_1.gif
Jan 19 20:37:00 <KrisAbsinthe> wow
Jan 19 20:37:14 <bbb8> haha yea, but it covers the whole screen :p
Jan 19 20:37:43 <KrisAbsinthe> so i assume if you were to order 2600 magazine you probably would never get it?
Jan 19 20:38:07 <bbb8> haha, nah, 1 thing i gotta say, they do this kinda stuff, but they're really stupid in other ways..
Jan 19 20:38:31 <bbb8> like u can simply connect trough the GPRS go surf their whole network, make scans fuck of alot, then they wont even know it.... 
Jan 19 20:38:40 <bbb8> if anyone good with computers comes to qatar
Jan 19 20:38:51 <bbb8> and sees all those poorly encrypted business wireless networks
Jan 19 20:38:59 <bbb8> with WEP encryptions on it,
Jan 19 20:39:09 <KrisAbsinthe> all wifi networks are poorly encrypted
Jan 19 20:39:44 <KrisAbsinthe> chalk one up for war driving
Jan 19 20:39:54 <SpeedEvil> KrisAbsinthe: proof
Jan 19 20:40:11 <SpeedEvil> KrisAbsinthe: publish an attack on non-trivial length WAP keys
Jan 19 20:40:24 <KrisAbsinthe> give me the target
Jan 19 20:40:39 <SpeedEvil> Any WAP AP with a long key
Jan 19 20:41:51 <KrisAbsinthe> sounds like a challenge lol if i get time between OM, College and work ill try to do it soon
Jan 19 20:42:28 <SpeedEvil> Given that nobody has published it at all, I have doubts.
Jan 19 20:42:38 <SpeedEvil> Can you outline your attack against the algorithm?
Jan 19 20:42:45 <summatusmentis> maybe it's just because I'm using qemu-1973, but it seems like parts of the interface are not intuitive, is there a manual or something?
Jan 19 20:43:03 <SpeedEvil> summatusmentis: It's the same on the hardware.
Jan 19 20:43:28 <Vegar> summatusmentis: what's not intuitive?
Jan 19 20:43:31 <cesarb> SpeedEvil: the hardware is more responsive
Jan 19 20:43:43 <cesarb> SpeedEvil: clicking on qemu can be a bit hard
Jan 19 20:43:45 <summatusmentis> SpeedEvil: it seems to me as though the icons are just ambiguous is all
Jan 19 20:43:45 <SpeedEvil> cesarb: more responsive - however a manual would be nice.
Jan 19 20:44:00 <mwester> hehe!  Parts of the GUI look and feel like someone spent a lot of time on it; other parts look like they were just added on as an afterthought, or just to get some basic stuff working.  I suspect that'll all be cleaned up as things get working.
Jan 19 20:44:10 <summatusmentis> Vegar: icons being ambiguous, and there's no easy way to get back to the home screen
Jan 19 20:44:38 <mwester> Having to fight with that blasted power button to close an app is my pet peeve. :)
Jan 19 20:45:06 <KrisAbsinthe> we also need to assign one of the buttons for volume
Jan 19 20:45:22 <summatusmentis> mwester: closing an app?
Jan 19 20:45:45 <cesarb> hm, after setting the speed to 12000 on qemu, the time increases 6s for each 10s; after setting the speed back... the same keeps happening. either qemu's emulation of the timers is wonky, or there's something wrong with my code
Jan 19 20:45:50 <Vegar> summatusmentis: app manager or power button
Jan 19 20:45:57 <mwester> Yes.  If you just navigate the GUI, it just switches windows; the apps stay running.
Jan 19 20:46:09 <summatusmentis> oh, maybe that's why I got confused
Jan 19 20:46:13 <mwester> The only way to kill an app is to use the power button when the app has focus.
Jan 19 20:46:50 <summatusmentis> which I think is 'enter' when it's qemu
Jan 19 20:46:51 <mwester> I'd prefer the classic little "x" in a corner somewhere, myself.
Jan 19 20:47:04 <Vegar> I'm not sure if the power/aux buttons work in qemu
Jan 19 20:47:24 <summatusmentis> Vegar: well, i had to use the aux button to choose to boot the thing
Jan 19 20:47:33 <Vegar> yeah, but I never got it working after that
Jan 19 20:47:33 <balrog-kun> cesarb: perhaps both :)
Jan 19 20:49:00 <Vegar> summatusmentis: to get back to the home screen you click the application's title (top left) and choose "Home" in the dropdown menu
Jan 19 21:04:27 <cesarb> qemu might be a somewhat poor emulation of the real hardware, but it sure does help a LOT
Jan 19 21:06:17 <cesarb> and with -stdio serial, killing gsmd and powering off the "gsm" (to get the serial back), you can watch the kernel output easily (and interact with uboot)
Jan 19 21:09:54 <balrog-kun> a timing accurate emulator would be really hard to make and completely unusable
Jan 19 21:10:07 <balrog-kun> because it would be hundreds times slower than qemu
Jan 19 21:11:10 <SpeedEvil> I debate hundreds.
Jan 19 21:11:13 <KrisAbsinthe> you could build natively ....lol
Jan 19 21:11:37 <SpeedEvil> I'd say 2-3 times at worst
Jan 19 21:12:02 <SpeedEvil> you simply store an instruction time along with the instructions, and total these as you go along
Jan 19 21:12:14 <balrog-kun> considering the optimal implementation?
Jan 19 21:12:19 <balrog-kun> oh, it's not that simple
Jan 19 21:12:33 <mwester> The hardware emulation needs to be involved as well, then.
Jan 19 21:12:40 <balrog-kun> every memory access (even by the processor when reading off instrucitons) has a different timing
Jan 19 21:13:04 <balrog-kun> the caches make a huge difference
Jan 19 21:13:07 <mwester> e.g. the serial port emulator would need to ensure that it toggled the bits in the virtual registers at appropriate times... tough.
Jan 19 21:13:16 <SpeedEvil> You can do a pretty good first cut just by using the instruction timings that must be implied.
Jan 19 21:13:57 <balrog-kun> imho that would be a worse first cut than current qemu
Jan 19 21:14:04 <SpeedEvil> And a static analysis when you load the code
Jan 19 21:14:17 <balrog-kun> qemu has an effect very similar to icache
Jan 19 21:14:44 <SpeedEvil> To do it properly, you'd need to emulate all the nastiness that is cachelines and SDRAM acess timings
Jan 19 21:15:21 * balrog-kun is pretty sure that would be even near 2-3 times slower than qemu
Jan 19 21:15:25 <balrog-kun> err, wouldn't
Jan 19 21:15:58 <SpeedEvil> No - doing it properly certainly wouldn't.
Jan 19 21:16:46 <balrog-kun> cesarb: if you see a part that is poorly emulated in a way not related to timing please report it
Jan 19 21:19:29 <cesarb> balrog-kun: it's related to timing, but not to the _instruction_ timing... it does not seem to be emulating transitions on the clock speeds, and I'm suspecting the timer emulation is less than correct when you play games with the manual reload bit
Jan 19 21:20:33 <cesarb> balrog-kun: see for instance the timer games at http://repo.or.cz/w/linux-2.6/s3c2410-cpufreq.git?a=commitdiff;h=84a9b15c4c93fb9eeccd3d86c237a11822dc31cd
Jan 19 21:20:46 <cesarb> balrog-kun: I'm not sure my code is correct, but I'm not sure qemu's is either
Jan 19 21:21:24 <cesarb> (I reload both the _current value_ and the reload value, and expect both to remain separate. I'm suspecting qemu is mixing them up)
Jan 19 21:21:41 * cesarb hasn't, however, checked how the real hardware reacts
Jan 19 21:23:05 * mwester thinks that cesarb deserves a neo from Openmoko  that he can "sacrifice" for the greater good of the community...
Jan 19 21:23:23 <mwester> Along with a debug board, if you don't have one :)
Jan 19 21:23:26 <cesarb> mwester: lol
Jan 19 21:23:39 <balrog-kun> cesarb: i'm ok with the tick rates not being correct for the s3c timers, and other timers
Jan 19 21:23:51 <cesarb> mwester: I do have one, but didn't find a need for it yet. It's more "just in case"
Jan 19 21:24:24 <cesarb> balrog-kun: if the tick rate is wrong wrt real time, you get the "real time" from within the emulator wrong, which is annoying (the time ticks faster or slower)
Jan 19 21:24:28 <balrog-kun> the timers' resoltuion is quite low anyway, in qemu, because it's a linux program and linux doesn't let you get a really good resolution
Jan 19 21:25:04 <cesarb> balrog-kun: I think you can get good resolution if you use the correct APIs
Jan 19 21:25:25 <balrog-kun> however i would treat it as a bug if things start happening ina wrong order or the values read from registers are incorrect (except the time values in registers)
Jan 19 21:25:31 <cesarb> balrog-kun: and it doesn't need to be that exact, just that the equivalent of 1s in timer ticks has to be more or less 1s, so it won't drift much
Jan 19 21:26:20 <balrog-kun> well, yeah that would certainly be nice
Jan 19 21:26:52 <balrog-kun> but i don't really see that as a bug, or poor emulation
Jan 19 21:27:17 <balrog-kun> i think when you use an emulator you have to assume the time can be completely warped
Jan 19 21:58:24 <cesarb> according to page 287 of the datasheet, I'm wrong.
Jan 19 22:01:13 <cesarb> And the way I'm wrong is that I'm setting the registers in the wrong order :P
Jan 19 22:04:56 <Vegar> meh
Jan 19 22:05:00 <Vegar> I wish qemu would use both my cores
Jan 19 22:09:50 <Vegar> would/could
Jan 19 22:13:32 <cesarb> This is annoying. If I use "cpufreq.debug=7" it all works, but if I use "cpufreq.debug=7 cpufreq.debug_ratelimit=0" it panics when mounting root, apparently because the list of partitions in the kernel command line got truncated.
Jan 19 22:13:52 <cesarb> How short is the command line lenght limit?
Jan 19 22:31:39 <mwester> 1024 chars IIRC
Jan 19 22:32:03 <mwester> u-boot might have a different idea, though
Jan 19 22:33:19 <Vegar> it was mentioned on one of the MLs a few days ago
Jan 19 22:37:17 <pavelm> Hello, everyone.
Jan 19 22:39:18 <Vegar> hi
Jan 19 22:39:58 <pavelm> ...I did not have time for openmoko for awhile :-(. Is there any progress in SMSes and/or powermanagement?
Jan 19 22:40:46 <SpeedEvil> pavelm: ish, and sort-of
Jan 19 22:41:09 <SpeedEvil> pavelm: SMS - there is a SMS applicaiton that reportedly works for some, occasionally.
Jan 19 22:41:18 <SpeedEvil> I don't understand how to use it.
Jan 19 22:41:21 <pavelm> Speedevil: "ish"?
Jan 19 22:41:24 <pavelm> speedevil :-).
Jan 19 22:41:30 <pavelm> Is there some good snapshot I should try?
Jan 19 22:41:34 <SpeedEvil> Power saving - cesarb is working on clock freq changing
Jan 19 22:41:55 <SpeedEvil> I don't know I've never understood how it's supposed to work.
Jan 19 22:42:02 <SpeedEvil> So I'm not sure if it's working or not.
Jan 19 22:42:14 <pavelm> speed: Hmm, I'm afraid clock freqency is not going to help -- unless clock frequency means "suspend the main cpu".
Jan 19 22:42:28 <SpeedEvil> It helps a fair bit
Jan 19 22:42:41 <SpeedEvil> Supply current at 40Mhz is _much_ lower than at 266.
Jan 19 22:42:56 <SpeedEvil> And yes, suspend is needed.
Jan 19 22:43:03 <SpeedEvil> As are numerous other things.
Jan 19 22:43:30 <mwester> Power is consumed mainly as the semiconductors transition between 0 and 1 states; so the slower the clock the less power (and heat).
Jan 19 22:43:44 <SpeedEvil> mwester: as a first approximation.
Jan 19 22:43:44 <pavelm> speed: Well, idle @ 40MHz is not neccessarily too different from idle @ 266MHz, but I guess that depends on cpu heavily.
Jan 19 22:43:56 <SpeedEvil> pavelm: it is quite significantly
Jan 19 22:44:09 <pavelm> mwester: Not in modern cpus :-(. Leakage current got quite high in recent desktop designs.
Jan 19 22:44:20 <SpeedEvil> And yes of course rapid suspend-RAM and resume'd be nice.
Jan 19 22:45:24 <pavelm> speed: I believe suspend-RAM works, except that GSM will not work after resume :-(
Jan 19 22:45:38 <SpeedEvil> pavelm: I mean dynamic - as in 10-100ms 
Jan 19 22:45:49 <SpeedEvil> So it can suspend between user interactions
Jan 19 22:45:56 <pavelm> speed: I see. Thats hard to do unfortunately
Jan 19 22:46:18 <SpeedEvil> Yes.
Jan 19 22:46:46 <pavelm> ScaredyCat is reliable source of recent images, right?
Jan 19 22:46:50 * pavelm goes to download...
Jan 19 22:54:32 <Vegar> SpeedEvil: is that possible?
Jan 19 22:54:40 <SpeedEvil> Vegar: what?
Jan 19 22:54:45 <SpeedEvil> Vegar: yes - in principle
Jan 19 22:54:50 <Vegar> 10-100ms suspend?
Jan 19 22:54:55 <SpeedEvil> Vegar: in practice, there are issues.
Jan 19 22:55:01 <Vegar> right
Jan 19 22:55:30 <Vegar> is that what laptop CPUs do?
Jan 19 22:55:58 <pavelm> vegar: No, normal laptops can't do that. But they can power down significant parts of cpu when idle.
Jan 19 22:56:07 <Vegar> ok
Jan 19 22:57:10 <Vegar> so that's what the C-states are for
Jan 19 22:58:19 <SpeedEvil> And many CPUs essentially do do fast suspend and resume
Jan 19 22:58:26 <SpeedEvil> it's just it's hidden in ACPI
Jan 19 23:01:09 <pavelm> speed: Yes, but it is _cpu_ suspend/resume, so rest of the system stays powered up.
Jan 19 23:03:47 <SpeedEvil> True of course.
Jan 19 23:08:13 <SpeedEvil> However, the amount of state to restore all the peripherals is not high.
Jan 19 23:08:25 <SpeedEvil> Working out how to do it is the issue.
Jan 19 23:11:43 <pavelm> speed: Actually, that's what I'm trying to figure out in my day tjob ;-)
Jan 19 23:12:06 <pavelm> I even have some patches, but SATA refuses to cooperate, and machine without harddrive is basically dead :-(
Jan 19 23:12:15 <SpeedEvil> :/
Jan 19 23:22:31 * SpeedEvil is trying to work on a tiny power saving measure - 8 bit color for the LCD
Jan 19 23:22:42 <SpeedEvil> (partially as a testbed for other hardware)
Jan 19 23:23:11 <pavelm> ok, neo updated, booting...
Jan 19 23:24:33 <pavelm> speed:  I tried that on a PC, and yes it saved a bit of power.
Jan 19 23:25:15 <zash_> orly? less data to send to lcd?
Jan 19 23:26:03 <SpeedEvil> zash_: no
Jan 19 23:26:09 <SpeedEvil> zash_: read less data from memory
Jan 19 23:26:31 <SpeedEvil> zash_: it currently reads 2*640*480*60 bytes/second from the SDRAM
Jan 19 23:26:51 <SpeedEvil> zash_: each byte taken from RAM costs power
Jan 19 23:26:59 <pavelm> ...I've received first SMS on openmoko, good.
Jan 19 23:27:12 <SpeedEvil> pavelm: it saves some 10% power on my laptop dropping to 4 bit mode in X
Jan 19 23:27:15 <SpeedEvil> (when idle)
Jan 19 23:27:38 <cb22> SpeedEvil: 10? thats quite good
Jan 19 23:29:04 <pavelm> ..and I guess I was able to send a message, too. Delivery reports do not seem to work, but I guess I can survive that.
Jan 19 23:30:19 <SpeedEvil> :)
Jan 19 23:30:35 <SpeedEvil> cbrake_away: yes - it is very old hardware - I don't know how more recent hardware would act
Jan 19 23:30:39 <SpeedEvil> cb2:
Jan 19 23:49:21 <cesarb> SpeedEvil: ...wow. That's OLPC-level hackery you did :P
Jan 19 23:49:36 <SpeedEvil> Err - no.
Jan 19 23:49:44 <SpeedEvil> startx -- -bpp 8 
Jan 19 23:50:22 <cesarb> SpeedEvil: I mean, most people wouldn't even THINK of reducing color depth to save power
Jan 19 23:50:30 <SpeedEvil> Oh
Jan 19 23:50:33 <cesarb> SpeedEvil: at least on "normal" (not embedded) hardware
Jan 20 00:06:07 * cesarb is feeling more confident of trying in real hardware now (after a couple of extra bugfixes)
Jan 20 00:06:43 <cesarb> I will have to rebase this thing soon - there are way too many bugfix commits
Jan 20 00:07:53 <SpeedEvil> Go for it! What's the worst that could happen? ( http://youtube.com/watch?v=4OsBc8RqSKU )
Jan 20 00:08:39 <cesarb> I think last time I played with the neo was soon after gllin -- which is when it spontaneously turned off on me, which motivated me to get annoyed enough at the power management to actually try to do something
Jan 20 00:08:58 <CM> SpeedEvil: Hehe.. Nice movie
Jan 20 00:13:52 <cesarb> SpeedEvil: you reminded me of the slashdot "whatcouldpossiblygowrong" tag :D
Jan 20 00:14:12 * cesarb perhaps read slashdot a bit too much
Jan 20 00:14:57 <cb22> hehe i know the fealing cesarb 
Jan 20 00:16:50 <cb22> one thing that made me laugh was when the cocaine vaccine got tagged with iamlegend
Jan 20 00:17:08 <CM> hehe
Jan 20 00:24:06 * cesarb starts flashing his self-built hacked-up 2.6.24 git-HEAD cpufreq kernel
Jan 20 00:24:40 <cesarb> ...together with OpenMoko-openmoko-devel-image-glibc-ipk-P1-Snapshot-20080116-fic-gta01.rootfs.jffs2
Jan 20 00:24:40 * Vegar crosses fingers
Jan 20 00:26:24 * cesarb hears thunder nearby
Jan 20 00:27:08 <borg_> *drum roll*
Jan 20 00:27:39 <zash_> cesarb: quick, buy a ups!
Jan 20 00:27:52 <cesarb> zash_: I do have one
Jan 20 00:28:19 <zash_> then buy one for me ;)
Jan 20 00:28:23 <cesarb> zash_: but it's a "domestic" UPS, which means it's only for a few minutes with both computers on
Jan 20 00:28:53 <SpeedEvil> I have one of those too.
Jan 20 00:29:03 <SpeedEvil> I attached 10 car batteries and a fan.
Jan 20 00:29:10 <cesarb> SpeedEvil: heh
Jan 20 00:29:14 <SpeedEvil> It stays up longer.
Jan 20 00:29:56 <justin111> hey speedevil remember me i was here 2 days ago asking dumb questions
Jan 20 00:30:04 <justin111> about neo
Jan 20 00:30:13 <cesarb> SpeedEvil: my funniest power failure story is when once I came from the university to work, sat down at my chair, logged into the puny linux box below the desk I used as a base, opened mutt... and all the lights came off
Jan 20 00:31:00 <cesarb> SpeedEvil: and then the *very* annoying peeeeep from the several small UPSs behind/below several desks, all of them having to be turned off by hand (the monitors? most turned off, not on the UPSen)
Jan 20 00:31:22 <cesarb> SpeedEvil: in the end, it was one of these times (a power failure lasting several hours affecting most of the country)
Jan 20 00:31:38 <cesarb> SpeedEvil: we had to go home after the building got too hot (no AC...)
Jan 20 00:31:51 <cesarb> well, it's flashed. let's boot it and see what happens.
Jan 20 00:32:21 * SpeedEvil bets on unexplained freeze after decompressing kernel.
Jan 20 00:32:30 <justin111> would learning C++ be worth it 
Jan 20 00:32:45 <cesarb> SpeedEvil: you mean after "Starting kernel ..."? you won :D
Jan 20 00:33:12 <cesarb> SpeedEvil: unless it's set to some bogus quiet mode, it's way before the cpufreq code starts up
Jan 20 00:33:28 <SpeedEvil> It's what's happened every time I've tried hacking on the kernel (once)
Jan 20 00:33:43 <borg_> lol
Jan 20 00:40:03 <cesarb> That's annoying. It works fine on qemu.
Jan 20 00:40:18 <Vegar> does it work if you remove your hacks?
Jan 20 00:40:39 <cesarb> Vegar: I'd guess no, since it doesn't even get to the point where they run
Jan 20 00:40:52 * raster moos
Jan 20 00:41:23 <cesarb> Vegar: the most probably cause is that the 2.6.24.veryrecent kernel I'm using as base doesn't work well with the August "so last year" uboot snapshot
Jan 20 00:41:33 <Vegar> hehe
Jan 20 00:44:45 <cesarb> annoyingly, with the old u-boot it works on qemu too
Jan 20 00:45:07 <mwester> cesarb:  I thought the 2.6.24 kernel was known *not* to run on the GTA01
Jan 20 00:46:20 <cesarb> mwester: urgh
Jan 20 00:46:26 <justin111> raster are you there
Jan 20 00:47:02 <justin111> raster: are you there i have a few ?s on neo
Jan 20 00:47:11 <Vegar> cesarb: from the openmoko-kernel ML: "Alas, 2.6.24.x doesn't boot on GTA01 (the kernel doesn't output anything, so it probably dies very early)"
Jan 20 00:47:16 <cesarb> mwester: that's what I get for being "out of the loop" for so long
Jan 20 00:47:21 <raster> justin111: i am here :)
Jan 20 00:47:24 <SpeedEvil> raster: Oh - on rerunning I got 36 on the render - must have been something wierd with throttling.
Jan 20 00:47:57 <raster> SpeedEvil: aaah thats better
Jan 20 00:47:58 <justin111> raster: would C++ be useful to learn for neo software dev
Jan 20 00:48:01 <raster> yeah
Jan 20 00:48:06 <raster> u got throttled
Jan 20 00:48:08 <raster> :)
Jan 20 00:48:30 <raster> justin111: i guess - yes
Jan 20 00:48:40 <raster> as its a superset of c
Jan 20 00:48:46 <justin111> raster: oh thats good cuz i picked up "learn C++ in 24 hours
Jan 20 00:48:53 <justin111> and bought it
Jan 20 00:49:37 <justin111> raster: what do you think of the android phone
Jan 20 00:49:40 <cesarb> The problem is that one of my patches (the LCD output one) changes significantly from 2.6.24 to 2.6.22 (that code was rewritten for 2.6.24 in a way which made it much easier for me)
Jan 20 00:50:11 <raster> u wont learn it in 24hrs
Jan 20 00:50:12 <raster> :)
Jan 20 00:50:32 <justin111> yeah i figured that out once i opend the first page
Jan 20 00:50:48 <cesarb> "wah the kernel boot flew by like it was on steroids" <- heh
Jan 20 00:50:49 <raster> as for android - meh
Jan 20 00:50:57 * SpeedEvil passes justin111 some high quality illegal learning drugs.
Jan 20 00:51:09 <mwester> cesarb:  http://lists.openmoko.org/pipermail/openmoko-kernel/2008-January/000452.html
Jan 20 00:51:15 <raster> they seem to be playing the "we are using linux and open" card for publicity, but really not  following it
Jan 20 00:51:16 <derekcorwin> I have a Neo GTA01Bv4, it got shipped with a V3 debug board...  was that intended?
Jan 20 00:51:34 <raster> they seem to encourave vendors to add or turn parts of nadroid into closed pieces
Jan 20 00:51:36 * justin111 grunts in compliace and as a thank you
Jan 20 00:52:02 <justin111> i think they wanna be like OM
Jan 20 00:52:02 <raster> also the fact that they have decied that you must program in java (i haven't heard of "native development" currently) just makes me go "ho hum":
Jan 20 00:52:17 <raster> not only that - take java the language and replace its classes with their own
Jan 20 00:52:22 <raster> it doesn't excite me
Jan 20 00:52:27 <justin111> oh
Jan 20 00:52:27 <raster> overall - pretty ho-hum
Jan 20 00:52:42 <raster> though it may meant it will be easier to have OM run on more phones in future
Jan 20 00:52:42 <raster> :)
Jan 20 00:52:45 <Vegar> it almost sounds microsoft-ish
Jan 20 00:53:07 <justin111> lol microsoft-ish
Jan 20 00:53:11 <raster> android also have their own UI stack
Jan 20 00:53:14 <raster> like qtopia
Jan 20 00:53:21 <raster> u need to drink the coolaid
Jan 20 00:53:27 <raster> Om uses X
Jan 20 00:53:31 <SpeedEvil> Maybe. If I was designing a phone, and interested in revenue protection, I'd be very careful about making it unflashable by other flashes
Jan 20 00:53:32 <raster> we are about as standard as it gets
Jan 20 00:53:40 <raster> u use whatever toolkit/lib u like
Jan 20 00:53:44 <justin111> what would you recomend for a nub friendly C++ dev enviorment
Jan 20 00:53:44 <raster> and any language u like
Jan 20 00:54:18 <raster> justin111: dunno - i've been programming since i was 8
Jan 20 00:54:23 <raster> i am not the right person to ask
Jan 20 00:54:32 <raster> i learnt by a very different route
Jan 20 00:54:40 <justin111> how?
Jan 20 00:54:40 <SpeedEvil> basic?
Jan 20 00:55:03 * mwester never learned how to program; he took engineering in school.
Jan 20 00:55:22 <justin111> ok ill ask the guys in the mandriva channel
Jan 20 00:56:04 <raster> justin111: started 24years ago - on vic20's
Jan 20 00:56:06 <justin111> who do you think will be the first to jump the gun and add neo HW support
Jan 20 00:56:07 <raster> then c64's
Jan 20 00:56:10 <mwester> justin111:  there's really only one GUI dev environment that rules them all: eclipse.  Whether it's freindly or not is a question.
Jan 20 00:56:11 <raster> basic then 6502 machine code
Jan 20 00:56:13 * justin111 votes for debain guys
Jan 20 00:56:18 <raster> then amiga and 60k asm for 6 years
Jan 20 00:56:34 <raster> learnt c after miranda and modula2 @ university
Jan 20 00:56:40 <mwester> raster:  which 6502 system, just out of curiousity?
Jan 20 00:56:42 <raster> but i'd been programming for a long time by then
Jan 20 00:56:50 <raster> mwester: x64
Jan 20 00:56:53 <raster> err
Jan 20 00:56:53 <raster> c64
Jan 20 00:57:10 <mwester> Ah.  I have my original KIM-1 in a box in the basement...
Jan 20 00:58:07 <raster> baaah
Jan 20 00:58:17 <Weiss> hehe....c64 and x64 are quite a lot different.. :)
Jan 20 00:58:21 <raster> what is it with openmoko-browser2 failing
Jan 20 00:58:22 <raster> again
Jan 20 00:58:32 <raster> Weiss: i know
Jan 20 00:58:33 <raster> :)
Jan 20 00:58:36 <raster> i typoed
Jan 20 00:58:38 <raster> x is nect to c
Jan 20 00:58:41 <raster> text
Jan 20 00:58:44 <raster> next
Jan 20 00:58:45 <raster> BAH
Jan 20 00:59:41 <justin111> what would you recomend for a compiler
Jan 20 00:59:56 <SpeedEvil> gcc is pretty standard.
Jan 20 01:00:46 <raster> not sure you even should choose
Jan 20 01:00:48 <raster> gtcc
Jan 20 01:00:49 <raster> err
Jan 20 01:00:50 <raster> gcc
Jan 20 01:00:55 <raster> u could use icc
Jan 20 01:00:59 <justin111> what about the intel one is that free or not i remeber reading about it in my linux format magazine
Jan 20 01:01:03 <justin111> icc
Jan 20 01:01:03 <raster> or if u have solaris - sun's cc
Jan 20 01:01:05 <raster> but frankly
Jan 20 01:01:06 <justin111> thats what it was
Jan 20 01:01:12 <raster> gcc is everywhere
Jan 20 01:01:17 <justin111> mandriva linux
Jan 20 01:01:18 <mwester> justin111:  gcc with eclipse is the standard; don't even consider anything else if you're serious.
Jan 20 01:01:22 <SpeedEvil> And compiler is - almost - irrelevant.
Jan 20 01:01:48 <mwester> Microsoft's Visual Studio with their compiler is professional-grade as well, but it costs big $$$
Jan 20 01:01:49 <raster> u cant use icc for corss-compiling develoipment for opnmoko for example
Jan 20 01:02:03 <raster> in the end all compilers pretty much have the same way to control them
Jan 20 01:02:14 <raster> icc claims to create better x86 code than gcc - quite possible
Jan 20 01:02:17 * cesarb considers his options: either wait for 2.6.24 to work on gta01, or redo the framebuffer patch for 2.6.22 and port the rest
Jan 20 01:02:22 <SpeedEvil> And for beginning stuff, there isn't really mch in it.
Jan 20 01:02:32 <raster> but i wouldnt only go playing with other compilers once u have mastered everything
Jan 20 01:02:39 <SpeedEvil> cesarb: oh - setfb
Jan 20 01:02:45 <cesarb> SpeedEvil: ?
Jan 20 01:02:58 <SpeedEvil> cesarb: you can vary the clock frequency of the fb down quite far before it stops displaying
Jan 20 01:03:22 <SpeedEvil> So you could simply ignore that bit for the moment.
Jan 20 01:03:32 <cesarb> SpeedEvil: neat. So you're proposing I for now ignore it like I'm doing with I2C... sounds like a plan
Jan 20 01:03:34 <raster> SpeedEvil: trying to save power?
Jan 20 01:04:11 <SpeedEvil> raster: no - proposing that cesarb try without the proper LCD freq code on his cpufreq patches
Jan 20 01:04:51 <raster> oooh
Jan 20 01:04:53 <raster> cpufreq
Jan 20 01:04:54 <raster> joy!
Jan 20 01:04:59 <raster> joy is me
Jan 20 01:05:01 <mwester> cesarb:  you could post a note on the kernel dev list mentioning your situation; I'm pretty certain folks would be very interested, and perhaps finding and fixing the GTA01 problem will become a higher priority.
Jan 20 01:05:08 <cesarb> raster: http://wiki.openmoko.org/wiki/User:CesarB/cpufreq
Jan 20 01:05:13 <raster> now if only suspend and unsuspend worked...
Jan 20 01:05:19 <raster> on my gta02
Jan 20 01:05:19 <raster> :)
Jan 20 01:07:28 <raster> OW
Jan 20 01:07:34 * justin111 wants a OM phone for his BDay
Jan 20 01:07:41 <raster> changing freq is nasty
Jan 20 01:07:55 <Vegar> would it be inappropriate to ask you about e17, raster?
Jan 20 01:07:56 <raster> thats a lot of drivers and device IO stuff that will hiccup every time u change
Jan 20 01:08:00 * SpeedEvil wants a Hammerhead datasheet for his birthday.
Jan 20 01:08:11 <justin111> whats a network that will work with neo
Jan 20 01:08:13 <raster> Vegar: depends what u are asking :)
Jan 20 01:08:20 <Vegar> raster: ETA?
Jan 20 01:08:45 * raster adds another 2 weeks to the "delay" time
Jan 20 01:08:47 * justin111 wants microsoft to be bought out by OM novell or redhat for his birthday
Jan 20 01:08:57 <raster> we dont have an ETA
Jan 20 01:09:09 <raster> u can use it from CVS if u want
Jan 20 01:09:25 <Vegar> is there much left to consider it release ready?
Jan 20 01:09:41 <justin111> raster: wasnt the consumer version supposed to be ready at 07 end
Jan 20 01:10:11 <SpeedEvil> It was supposed to be ready in Umm. March I think was the earliest time.
Jan 20 01:10:12 <raster> Vegar: see the tracker on enlightenment.org
Jan 20 01:10:14 <SpeedEvil> (last march)
Jan 20 01:10:14 <raster> a TODO list
Jan 20 01:10:16 <SpeedEvil> (gta01)
Jan 20 01:10:29 <SpeedEvil> oh - not gta01
Jan 20 01:11:01 <Vegar> ah
Jan 20 01:11:05 <Vegar> thanks, raster 
Jan 20 01:11:05 <raster> okies
Jan 20 01:11:10 <Vegar> didn't see that top right menu
Jan 20 01:11:12 <raster> time for a new battery image
Jan 20 01:13:39 <justin111> i <3 KDE4
Jan 20 01:13:57 <cesarb> raster: to prevent these hiccups, I'm adding code to the problematic drivers to "quiesce" them before the change
Jan 20 01:14:19 <cesarb> raster: the serial is the nastiest of them (draining FIFOs, faking a full FIFO...)
Jan 20 01:15:22 <raster> are you going to async drain and rely on driver interupts back to cpufreq to know when u can switch?
Jan 20 01:15:28 <raster> or going to busywait?
Jan 20 01:17:12 <cesarb> raster: busywait :D
Jan 20 01:17:16 <raster> ewww!
Jan 20 01:17:18 <raster> :-P
Jan 20 01:17:27 <raster> so we will hiccup
Jan 20 01:17:29 <raster> just cpu-wise
Jan 20 01:17:51 <raster> cpu will be locked waiting for stuff to quiesce
Jan 20 01:17:54 <raster> could take a few ms
Jan 20 01:18:04 <cesarb> raster: the cpufreq architecture doesn't allow me to do it in interrupt style, it would need another phase (some sort of pre-prechange notifier)
Jan 20 01:18:19 <raster> bad cpufreq
Jan 20 01:18:21 <raster> bad
Jan 20 01:18:30 <cesarb> raster: the idea is to first make it work
Jan 20 01:18:32 * raster spanks cpufreq
Jan 20 01:18:36 <cesarb> raster: then start trying to make it nicer
Jan 20 01:19:22 * cesarb also has to find or make some way of allowing drivers to say which is their minimum frequencies
Jan 20 01:19:40 <raster> well i guess thats fair enough
Jan 20 01:19:52 <raster> but i wouldnt consider it "done" without being abel to do it without hiccups
Jan 20 01:20:27 <cesarb> I could also make it _outside_ the cpufreq core (doing a "s3c2410 ultra-elite pre-pre-change notifier"), but that would be even more of a hack
Jan 20 01:20:28 <raster> (beyond what is hardware limitations - eg the clock has to quiesce for 20 or 30 cycles before stabilisiing at a new freq)
Jan 20 01:20:56 <cesarb> raster: 20 or 30 cycles? try 150us (which is the PLL settling time)
Jan 20 01:21:01 <raster> well cpufreq would be good
Jan 20 01:21:13 <raster> existin g cpufreq twiddling userspace stuff will then "just work"
Jan 20 01:21:24 <raster> cesarb:  no idea how much it is
Jan 20 01:21:33 <cesarb> raster: if I can make cpufreq work well enough that it can be used to change freqs while the user isn't looking (like when mostly idle at the interface), that would already be very good
Jan 20 01:21:42 <cesarb> raster: me neither ;-)
Jan 20 01:21:42 <raster> i was reading the datasheet at some time and noticed there was a clock stabilisation period
Jan 20 01:22:26 <SpeedEvil> It'd be so nice if some of PCLK could be taken from the 12MHz clock
Jan 20 01:22:44 <SpeedEvil> The serial and IIS for example
Jan 20 01:23:03 <cesarb> SpeedEvil: agreed
Jan 20 01:23:05 <raster> its going to be hard to know when to clockshift
Jan 20 01:23:07 <cesarb> SpeedEvil: the timer too
Jan 20 01:23:17 <raster> especially clockshift up
Jan 20 01:23:22 <justin111> will GTA02 ever have 3d accel
Jan 20 01:23:27 <SpeedEvil> justin111: yes
Jan 20 01:23:36 <raster> the existing governors dont do a bad job on desktop cpu's
Jan 20 01:23:40 <SpeedEvil> justin111: when the drivers will support it is an open question
Jan 20 01:23:47 <raster> justin111: no/very unlikely
Jan 20 01:23:48 <cesarb> raster: well, I'm just using the kernel hacker's way of avoiding these dillemas
Jan 20 01:24:13 <cesarb> raster: just make people use the "userspace" governor and the problem is solved :D
Jan 20 01:24:15 <raster> cesarb: by making it 'someone elses problem"
Jan 20 01:24:15 <raster> :)
Jan 20 01:24:33 <cesarb> raster: after all, it's now /userspace/'s problem :D
Jan 20 01:24:42 <raster> yeah
Jan 20 01:24:45 <raster> bastards
Jan 20 01:24:46 <raster> :-P
Jan 20 01:25:25 <CVirus> hehe
Jan 20 01:27:08 <cesarb> raster: no, seriously, I am _really_ proposing that neod or its sucessor take care of the frequency decisions. After all, it knows (or at least if you look at it just so _should_ know) what the user is supposed to be thinking of doing at each moment.
Jan 20 01:27:52 <cesarb> raster: for instance, it can know that the screen is off, there is no call or music going on, and the bluetooth is enabled, so something around 40000 would work
Jan 20 01:28:11 <raster> oh sure
Jan 20 01:28:29 <raster> but if screen is on and i'm staring at my launcher menu
Jan 20 01:28:32 <raster> what should it be?
Jan 20 01:28:32 <raster> :)
Jan 20 01:28:37 <SpeedEvil> 0
Jan 20 01:28:43 <raster> hhahaha
Jan 20 01:28:50 <SpeedEvil> It should be in suspend with the accel chip refreshing the display
Jan 20 01:29:08 <cesarb> SpeedEvil: I'm thinking of GTA01, my code doesn't even start to run on GTA02 ;-)
Jan 20 01:29:10 <SpeedEvil> If we're talking of the ideal.
Jan 20 01:29:22 <raster> i would say no to that
Jan 20 01:29:23 <raster> :)
Jan 20 01:29:31 <SpeedEvil> As fast as is needed to run the display without flicker
Jan 20 01:29:35 <raster> as at any moment i could press the srceen to try scroll or launch
Jan 20 01:29:36 <cesarb> SpeedEvil: (it has a "is this the exact CPU used on GTA01?" check)
Jan 20 01:29:51 <raster> and now i need to wait for an unsuspend to just begin to react to my user input
Jan 20 01:30:03 <cesarb> raster: after you press the screen, it has enough time to rev up before you notice something's odd
Jan 20 01:30:08 <SpeedEvil> raster: The fun part is getting suspend fast enough for that
Jan 20 01:30:09 <justin111> i just got 2 very diffrent answers
Jan 20 01:30:19 <justin111> spped says yes raster says no on 3d wtf
Jan 20 01:30:25 <cesarb> raster: it's not that slow
Jan 20 01:30:33 <raster> justin111:  the answer is no/unlikely
Jan 20 01:30:45 <SpeedEvil> justin111: there is a 2d/ 3d accel chip in GTA02
Jan 20 01:30:52 <SpeedEvil> According to released information.
Jan 20 01:31:08 <SpeedEvil> If that's changing - seriously, should the wiki be updated?
Jan 20 01:31:17 <raster> cesarb: an extra 50ms or 100ms is a long time in gui/interaction land
Jan 20 01:31:33 <raster> SpeedEvil:  the chip is there
Jan 20 01:31:36 <SpeedEvil> raster: as is an extra hour of battery life.
Jan 20 01:31:38 <raster> there are no drivers for the 3d
Jan 20 01:31:44 <raster> no opengl for it
Jan 20 01:31:51 <SpeedEvil> raster: It should of course be tunable.
Jan 20 01:32:00 <raster> sped your backlight is probably chewing most of the power anyway
Jan 20 01:32:00 <raster> :)
Jan 20 01:32:03 <SpeedEvil> I said the drivers were a different matter.
Jan 20 01:32:19 <SpeedEvil> raster: Sure - but 300mW of CPU that you can not use isn't really trivial.
Jan 20 01:32:44 <SpeedEvil> Well - probably less on GTA02 with a functional voltage and freq changing
Jan 20 01:33:25 <raster> in the general use case whihc is - if the menu is up and screen on theuser likely is interacting or is just about to ... you want to stay alive to respond ASAP
Jan 20 01:33:46 <SpeedEvil> raster: And I want to be able to tune it either way. - ideally.
Jan 20 01:34:14 <raster> sure
Jan 20 01:34:20 <SpeedEvil> raster: Way back - it was stated that the glamo docs would at some point be rewritten in a form that made it possible for others to work on driver stuff. 
Jan 20 01:34:26 <raster> but u need to chose the point at whihc to suspend
Jan 20 01:34:30 <SpeedEvil> raster: I assume that's not likely any time soon.
Jan 20 01:34:43 <raster> chosing that point  is hard if you leave things partly usable
Jan 20 01:34:47 <raster> eg screen is on
Jan 20 01:34:48 <SpeedEvil> raster: not if it's fast enough that the user accepts the delay.
Jan 20 01:35:14 <raster> SpeedEvil: we arent rewriting the docs
Jan 20 01:35:17 <raster> no time for that
Jan 20 01:35:26 <raster> and the docs are not able to be released without an nda
Jan 20 01:36:00 <raster> also the time required to write opengl libs for the glamo will likely be the lifetime of the gta02 as a product
Jan 20 01:36:11 <justin111> what would be better to run a HTTP server from mandriva or fedora 8 
Jan 20 01:36:19 <raster> at whihc point the value of the effort in writing them has pretty much gone to 0
Jan 20 01:36:20 <raster> :)
Jan 20 01:36:26 <raster> (well from our point of view)
Jan 20 01:36:27 <justin111> wait nvm it has a OS allready
Jan 20 01:36:36 <raster> of course if we use the glamo in our next phone - yes. it's worth it
Jan 20 01:37:06 <SpeedEvil> raster: Thanks :/
Jan 20 01:37:25 <raster> SpeedEvil: the specs are not simple
Jan 20 01:37:33 <raster> they are only spartanly documented for 3d
Jan 20 01:37:48 <raster> it will be a lot of work to write them.
Jan 20 01:37:51 <SpeedEvil> It's what - a binary blob with sketchy docs?>
Jan 20 01:37:51 <raster> it sucks - i know.
Jan 20 01:37:54 <raster> also note
Jan 20 01:38:05 <raster> the glamo can only do 3d at a MAX of 511x511
Jan 20 01:38:10 <raster> it cant even to 640x480
Jan 20 01:38:23 <cesarb> raster: 5_11_? why not 512?
Jan 20 01:38:29 <raster> no render-to-texture
Jan 20 01:38:34 <SpeedEvil> It can't do a static border round the edge?
Jan 20 01:38:37 <raster> 256x256 max tex size
Jan 20 01:38:38 <raster> etc.
Jan 20 01:39:05 <raster> cesarb: i am guessing they use 1 of the 3d buyffer pixels as a counter or flag pixel for that row/column
Jan 20 01:39:17 <cesarb> raster: well, for the neo, what matters most is the 2d accel, isn't it? you aren't making a hollywood os...
Jan 20 01:39:47 <raster> cesarb:  correct.
Jan 20 01:39:47 * SpeedEvil wishes FPGAs were cheap (energy and price)
Jan 20 01:39:52 <raster> our focus is on good 2d accel
Jan 20 01:40:03 <raster> as best we can
Jan 20 01:40:08 <raster> even then the glamo has issues
Jan 20 01:40:19 <raster> access to video ram is a measly 30mb/sec
Jan 20 01:40:34 <raster> so writing new pixels across is painfulyl slow
Jan 20 01:40:46 <SpeedEvil> What about video playback?
Jan 20 01:40:48 <raster> we will get DMA working along the way to alleviate that pain
Jan 20 01:40:56 <raster> xvideo is supported
Jan 20 01:41:06 <SpeedEvil> I mean the decompression support
Jan 20 01:41:08 <raster> but again - u are writing yuv pixels across this pissy but with the cpu
Jan 20 01:41:14 <raster> no async dma currently
Jan 20 01:41:28 <raster> xvmc in theory is possible- but currently not working
Jan 20 01:41:39 <raster> its a reasonable bit of work
Jan 20 01:42:16 <SpeedEvil> Is it a plan to get that working?
Jan 20 01:42:18 <raster> for now xvmc is a lice luxury to look at later
Jan 20 01:42:34 <cesarb> raster: well, there's ONE thing where you could use 3d effects on a phone
Jan 20 01:42:38 <raster> we do have normal xvideo support (yuv) and that will probably have to do
Jan 20 01:42:40 <cesarb> raster: rotating cube effects.
Jan 20 01:42:43 * cesarb runs and hides
Jan 20 01:43:03 <raster> the video bus upload/download is a major bottleneck as it keeps the cpu busy in waitstates writign at 30mb/sec
Jan 20 01:43:13 <raster> sucking cpu power like a hoover
Jan 20 01:43:33 * raster chooses to not take that bait
Jan 20 01:43:54 <balrog-kun> how much RAM does the glamo have onchip?
Jan 20 01:44:03 <raster> 8m
Jan 20 01:44:18 <justin111> raster what do you do at Om
Jan 20 01:44:31 <balrog-kun> X could keep a reasonable amount of images there
Jan 20 01:45:34 <SpeedEvil> raster: What's the priority of video decode assist? I.E. is it likely before the copyright on the docs for the glamo runs out? :)
Jan 20 01:46:04 <balrog-kun> even if you use DMA, you still have to be generating the data to send at the rate of 30 MB/s, imho the bus is not a real bottleneck
Jan 20 01:46:25 <SpeedEvil> 30MB/s is not much
Jan 20 01:46:39 <SpeedEvil> mplayer was getting QVGA*2*25Hz
Jan 20 01:46:41 <SpeedEvil> which is ...
Jan 20 01:46:44 <balrog-kun> the data would be comming either from the CPU beign generated at the same time it's being sent it to glamo, or from some media or RAM
Jan 20 01:46:59 <SpeedEvil> 38M
Jan 20 01:47:04 <balrog-kun> the media could be NAND or SD, they probably don't go much faster than 30 MB/s
Jan 20 01:47:06 <SpeedEvil> (on the 266Mhz)
Jan 20 01:47:41 <balrog-kun> so RAM remains as the only place that could be sending data at a much faster pace than the bus speed (30 MB/s)
Jan 20 01:47:48 <SpeedEvil> balrog-kun: no
Jan 20 01:47:54 <balrog-kun> so equally well the data could be just kept in the target ram
Jan 20 01:48:00 <SpeedEvil> balrog-kun: the current mplayer on GTA01 can generate 38M/s to the framebuffer.
Jan 20 01:48:10 <SpeedEvil> (from mpg or avi)
Jan 20 01:48:27 <balrog-kun> SpeedEvil: is that a result from testing?
Jan 20 01:48:34 <SpeedEvil> balrog-kun: yes
Jan 20 01:48:39 <raster> justin111: lead architect - graphics
Jan 20 01:48:54 <balrog-kun> SpeedEvil: but that's probably the maximum it can do on this cpu?
Jan 20 01:48:58 <cesarb> JFFS2 warning: (1416) jffs2_sum_write_sumnode: Not enough space for summary, padsize = -219
Jan 20 01:49:00 <cesarb> (on qemu)
Jan 20 01:49:03 <cesarb> what's that?
Jan 20 01:49:09 <SpeedEvil> balrog-kun: mplayer will - just about - achieve 320*240*25fps on an unoptimised mplayer on your average VCD rate AVI or MPG
Jan 20 01:49:10 <raster> balrog-kun: reasonable - yes. depends what you wil do. *IF* we move to a composited style environment where now all apps/windows/dialogs etc. are pixmaps - that will fill up fast
Jan 20 01:49:34 <SpeedEvil> balrog-kun: on a GTA01 at 266M
Jan 20 01:49:44 <balrog-kun> 38MB/s is comparable with the 30MB/s, not like an order of magnitude higher where you could speak of a bottleneck
Jan 20 01:49:44 <SpeedEvil> balrog-kun: though with no sound.
Jan 20 01:49:45 <raster> SpeedEvil: ummm copyright runs out on docs? :)
Jan 20 01:50:01 <raster> balrog-kun: the bus is soooo a bottleneck
Jan 20 01:50:15 <SpeedEvil> raster: Assuming it's not extended past its current 80 years or so.
Jan 20 01:50:35 <balrog-kun> cesarb: that's a message from kernel's jffs2 driver, it is probably not connected with qemu (but might be.. too)
Jan 20 01:50:51 <cesarb> balrog-kun: I added (on qemu) so people would not get worried ;-)
Jan 20 01:51:09 <balrog-kun> oh ok
Jan 20 01:51:27 <balrog-kun> cesarb: i get that or similar things a lot on the real hw too and don't get really worried :P
Jan 20 01:51:50 <raster> balrog-kun: i have done number crunshing and benchmarks - i know evas's performance test suite will see a 40-50% speedup in fps *IF* we implemented DMA. rememebr when you copy data across the bus *WITH THe CPU* you lock the cpu into wait states
Jan 20 01:51:56 <raster> waiting for the bus to accept data
Jan 20 01:52:07 <raster> that is cpu you cannot use for decoding the next frame of video
Jan 20 01:52:10 <raster> or whatever
Jan 20 01:52:39 <balrog-kun> raster: yes, but the DMA is on the s3c24xx side, not really a question of the bus which is between the chips as i understand
Jan 20 01:52:51 <Robot101> bkruse_home: hey ;D
Jan 20 01:52:56 <raster> the dma engine there can copy across that bus
Jan 20 01:53:01 <bkruse_home> Robot101: hello :]
Jan 20 01:53:06 <raster> thus freeign the cpu to do its work
Jan 20 01:53:10 <balrog-kun> raster: and DMA should work as you said
Jan 20 01:53:10 <Robot101> bkruse_home: we've been trying to talk with OM about Telepathy for a long time, but they've not been very good at responding to our mails
Jan 20 01:53:18 <balrog-kun> it's just a question of implementing it right?
Jan 20 01:53:24 <balrog-kun> in software
Jan 20 01:53:37 <raster> Robot101: trust me - we are itnerested/have talked about it
Jan 20 01:53:42 <raster> but we're a bit of mess internally atm
Jan 20 01:53:52 <Robot101> bkruse_home: we think it makes great sense (obviously :D), and we already have working backends for SIP, XMPP (Gtalk or Jingle), IRC, link-local XMPP, and libpurple AIM/ICQ/MSN/...
Jan 20 01:54:08 <bkruse_home> Robot101: that is not surprising, once we get  good clients (mokoiax will help with this) then the backends will be there...
Jan 20 01:54:09 <raster> until we have a phone stack that is reliable and works we are not really into junping into whole infrastructure changes
Jan 20 01:54:17 <bkruse_home> raster: completely agree.
Jan 20 01:54:24 <bkruse_home> raster: mess internally?
Jan 20 01:54:30 <bkruse_home> :/
Jan 20 01:54:50 <cesarb> 2.6.24 doesn't have these extremly annoying adc_read log spam :P
Jan 20 01:54:52 <raster> balrog-kun:  and i can generate much more than 30mb/xszec of video data to the screen\
Jan 20 01:54:58 <bkruse_home> Robot101: dbus implementation in pidgin rocks
Jan 20 01:55:00 <Robot101> raster: ah, right. hm.
Jan 20 01:55:07 <raster> Robot101:  trust me - it's on my radar
Jan 20 01:55:08 <bkruse_home> raster: thats sad to hear, do you work for om?
Jan 20 01:55:09 <Robot101> bkruse_home: telepathy rocks more. :)
Jan 20 01:55:19 <bkruse_home> Robot101: agreed :] i will implement for it
Jan 20 01:55:20 <balrog-kun> raster: on the Neo1973 CPU?
Jan 20 01:55:30 <raster> i want to see telephony integrated into a general communicatiosn stack and api
Jan 20 01:55:31 <bkruse_home> raster: mokoiax == start of voip movement on OM
Jan 20 01:55:32 <Robot101> bkruse_home: it's designed to keep the connections open as shared backends and then you can pick them up from any UI component
Jan 20 01:55:38 <raster> i dont want to see 3 IM apps
Jan 20 01:55:41 <raster> an sms app
Jan 20 01:55:47 <Robot101> bkruse_home: if you want any help with telepathy, we're happy to help
Jan 20 01:55:54 <bkruse_home> Robot101: perfect
Jan 20 01:55:55 <Robot101> bkruse_home: #telepathy as well
Jan 20 01:55:58 <raster> and god knows what else when everytthing could be integrated trhough your CHOISE of 1 or more ui's for messaging
Jan 20 01:56:06 <bkruse_home> agreed...
Jan 20 01:56:07 <bkruse_home> raster: I want do that as a second goal, integrate into the dialer app itself
Jan 20 01:56:07 <raster> same for gsm voice/voip etc.
Jan 20 01:56:17 <Robot101> bkruse_home: but IAX is something I think a lot of people could be happy to see in telepathy
Jan 20 01:56:21 <Robot101> raster: right :)
Jan 20 01:56:24 <raster> but frankly - we need gsm voice and sms and so on all workign reliably first
Jan 20 01:56:34 <raster> before integrating into a larger framework
Jan 20 01:56:41 <balrog-kun> it runs at 266 MHz or 400 MHz, assuming one byte generated by five instruction (not really realistic) you get ~50 MB/s already, only slightly saturating the bus
Jan 20 01:56:44 <raster> just need to keep the # of fires to fight down to a minimu7m
Jan 20 01:56:48 <bkruse_home> raster: well, the movement for getting it integrated into dialer would help the hole "integrated into" and would be an example for others, instead of just third party apps being ported...
Jan 20 01:57:03 <raster> bkruse_home:  yes i do - i'm the gatekeeper for pixels :)
Jan 20 01:57:07 <Robot101> I'm a little worried the phonekit APIs will head off in one direction which isn't necessarily compatible with telepathy, and will end up with one abstraction on top of another in a future iteration
Jan 20 01:57:08 <raster> (work for OM)
Jan 20 01:57:19 <bkruse_home> raster: perfect, so you think Michael is a cool guy?
Jan 20 01:57:25 <bkruse_home> the "community relations"?
Jan 20 01:57:32 <raster> balrog-kun: yes - on both the gta01 and gta02.
Jan 20 01:57:58 <SpeedEvil> robtaylor: the fundamental problem at the moment is that OM core dev team is way understaffed for what they are trying to do.
Jan 20 01:58:00 <raster> Robot101:  dont worry - i heard about telepathy last year in march @ bossa
Jan 20 01:58:01 <Robot101> even having some OMs would let us play with hooking up some tp frontent to the GSM hardware, maybe basing off the gnome phone manager tp-phony stuff hadess was doing
Jan 20 01:58:03 <SpeedEvil> rober
Jan 20 01:58:05 <raster> i know of it and what it does
Jan 20 01:58:06 <SpeedEvil> robo:
Jan 20 01:58:06 <raster> :)
Jan 20 01:58:23 <raster> balrog-kun: ok let me prepare some math for you
Jan 20 01:58:36 <Robot101> SpeedEvil: if only there were some companies who could support building solutions around telepathy... :P
Jan 20 01:58:56 <Robot101> we can do UI hacking and integration and stuff too
Jan 20 01:59:01 <SpeedEvil> Robot101: one major annoyance is that you can't do data over GSM voive.
Jan 20 01:59:01 <raster> i did ACTUAL benchmarks
Jan 20 01:59:10 <raster> real life - on the gta02
Jan 20 01:59:16 <SpeedEvil> Robot101: as GSM data is very expensive in many cases.
Jan 20 01:59:24 <raster> i did the benchmarks of rendering with the cpu in system memory
Jan 20 01:59:25 <Robot101> raster: right, I was sitting next to you extoling the virtues of telepathy at bossa... :)
Jan 20 01:59:25 * balrog-kun hasn't done any benchmarks yet
Jan 20 01:59:27 <raster> stuff like alpha blending
Jan 20 01:59:30 <raster> interpoalted scaling
Jan 20 01:59:35 <raster> yuv->rgb video 
Jan 20 01:59:36 <raster> etc.
Jan 20 01:59:47 <raster> Robot101: indeed u were :)
Jan 20 01:59:47 <Robot101> raster: did anyone do any E/D-Bus (E-Bus? :D) stuff as yet?
Jan 20 01:59:54 <balrog-kun> raster: all this done by the CPU, not the glamo, right?
Jan 20 01:59:59 <raster> rb e-dbus exists - no telepathy abstraction yet tho
Jan 20 02:00:02 <raster> :)
Jan 20 02:00:10 <raster> Robot101: as i said - on radar
Jan 20 02:00:14 <borg_> Robot101: you know of freesmartphones.org? there is a first dbus interface specification
Jan 20 02:00:14 <Robot101> cool
Jan 20 02:00:15 <raster> balrog-kun:  yes
Jan 20 02:00:22 * Robot101 beeps insistently on said radar... :)
Jan 20 02:00:36 <raster> balrog-kun:  wait - now. i hakced up the engine to "skip" the "memcpy()" from system ram to video ram
Jan 20 02:00:39 <raster> *IF* we had DMA
Jan 20 02:00:46 <raster> that is effectively what we woudl skip
Jan 20 02:00:55 <balrog-kun> yeah, let's assume we have DMA in place
Jan 20 02:00:57 <raster> the cpu would not have to spend cycles WAITING on a copy
Jan 20 02:00:59 <raster> it could be async
Jan 20 02:01:13 <raster> my benchark went from 13.55 to 20.23
Jan 20 02:01:19 <cesarb> raster: it could still wait if the bus gets too busy
Jan 20 02:01:30 <cesarb> raster: so the increase might not be all that
Jan 20 02:01:31 <raster> that difference between 13.55 and 20.23 *IS the cost fo copying across the video bus with the cpu
Jan 20 02:01:44 <SpeedEvil> cesarb: as a clarification - my PII/300 got 35
Jan 20 02:01:48 <Robot101> bkruse_home: but yeah, the perfect goal in my mind would be that the usual dialer or messaging app would sit atop Telepathy and could show IAX or SIP calling in the same way as built-in GSM
Jan 20 02:01:49 <raster> you likely will get most of that
Jan 20 02:01:57 <raster> as sure the dam engine will compete for memory cycles to access ram
Jan 20 02:02:07 <raster> but that will only soak up 30mb/sec of mem bandwidth
Jan 20 02:02:19 <raster> total mem bandwidht is 160m/sec (memcopy mem -> mem)
Jan 20 02:02:26 <cesarb> raster: agreed, you will likely get most of that, but not all of that ;-)
Jan 20 02:02:34 <cesarb> raster: wow. more than enough.
Jan 20 02:02:37 <raster> Robot101:  yup. i'd love to see that
Jan 20 02:02:41 <Robot101> bkruse_home: what were you planning to do with the media? you can re-use the telepathy stream engine with gstreamer/farsight to do RTP codec negotiation and codec setup
Jan 20 02:02:46 <raster> cesarb:  yup.
Jan 20 02:02:55 <raster> se so thats a 49% speedup in theory
Jan 20 02:03:01 <Robot101> bkruse_home: at the very simplest that could just be making one localhost UDP socket for each call
Jan 20 02:03:04 <raster> but in reality we will see about 40% speedup is my guess
Jan 20 02:03:06 <balrog-kun> but not 160m going out of the S3C24XX and going into the Glamo
Jan 20 02:03:07 <borg_> Robot101: http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/trunk/standards/otapi/?root=smartphones
Jan 20 02:03:15 <raster> ASSUMING 1. x is smart enough NOT to busywait on the dma
Jan 20 02:03:17 <cesarb> well, let's go AGAIN, this time with 2.6.22.5 instead of 2.6.24.veryrecent.
Jan 20 02:03:27 <borg_> Robot101: now is the time where you can help forming the specification
Jan 20 02:03:28 <raster> and 2. the x client is smart enough not to busywait on the xshmputimage coyp to x
Jan 20 02:03:33 <SpeedEvil> balrog-kun: 30*1.5 = 46M though
Jan 20 02:03:36 <raster> 2. is already done right in evas
Jan 20 02:03:40 <raster> i know - i made sure of it recently
Jan 20 02:03:41 <raster> :)
Jan 20 02:03:57 <Robot101> borg_: we don't really want to write another API, we've already got a real-time communications API, it's existed for 2 years, and it's called telepathy. we just need a couple of interfaces and we can cover all the GSM functionality too. we just added a call merge/split interface actually
Jan 20 02:04:18 <balrog-kun> SpeedEvil: if that's the absolute maximum and the bus'es limitation is 30 M/s then i'm totally ok with that
Jan 20 02:04:23 <raster> Robot101:  btw - going to bossa this year?
Jan 20 02:04:30 <SpeedEvil> balrog-kun: it's nowhere near absolute maximum
Jan 20 02:04:39 <cesarb> ok, this time for sure! *knocks on wood*
Jan 20 02:04:44 <SpeedEvil> balrog-kun: well - actually - it's close I suppose
Jan 20 02:04:54 <Robot101> raster: they didn't ask me to speak (thus far), meanies... I'm pondering it but I'm not quite sure if I can spare the time/effort
Jan 20 02:05:04 <SpeedEvil> balrog-kun: tehre is little point in pushing more than 90M/s across the bus.
Jan 20 02:05:04 <raster> Robot101: fair enough :)
Jan 20 02:05:15 <SpeedEvil> balrog-kun: (24 bit * 640*480*60Hz)
Jan 20 02:05:20 <Robot101> raster: I've already got a holiday booked that month so it might get a little silly if I went to .br too :D
Jan 20 02:05:28 <balrog-kun> SpeedEvil: and there's a question if that's even possible on the cpu side
Jan 20 02:05:29 <Robot101> will see nearer the time
Jan 20 02:05:31 <raster> Robot101:  fair enough
Jan 20 02:05:32 <raster> :)
Jan 20 02:05:48 <Robot101> depends how many more people go "aww, you not going?" :D
Jan 20 02:05:54 <balrog-kun> i mean, we could be talking of a "bottleneck" if all elements in the system could do much higher than 30MB/s, but that's not the case afaik
Jan 20 02:05:59 <Robot101> oh and some suprious business justification, yeah. :D
Jan 20 02:06:01 <raster> balrog-kun: the fact is - at 30m/sec if you need to copy 30m of data - your cpu will be stuck for 1 second doing NOTHING but a copy
Jan 20 02:06:07 <raster> it cannot calculate anythign else
Jan 20 02:06:23 <Robot101> borg_: http://telepathy.freedesktop.org/spec.html
Jan 20 02:06:24 <SpeedEvil> balrog-kun: Given that mplayer can hit 57 (extrapolated) on 400Mhz hardware - it's not a problem
Jan 20 02:06:29 <raster> sure u can context switch away
Jan 20 02:06:45 <raster> and then u just make the total time ende to end longer than 1 s as u spent intermediate cycles doing other things
Jan 20 02:06:54 <SpeedEvil> balrog-kun: assuming that GTA02 is 266/400ths faster
Jan 20 02:06:57 <raster> but 1 sec of cpu time will be used up just copying 30m of data
Jan 20 02:07:08 <raster> thats 1 sec of cpu time lost - forever. u can never do anytgni else
Jan 20 02:07:17 <borg_> Robot101: yes, i am looking on it, imo that is on another abstraction level
Jan 20 02:07:17 <balrog-kun> raster: well, we're not interested in what happens on the cpu side, only about the rate of the data that goes out of it
Jan 20 02:07:19 <SpeedEvil> and a CPU second of power
Jan 20 02:07:23 <raster> if the bus was so ultra-fast that it didnt matter - i'd be less worried
Jan 20 02:07:32 <raster> balrog-kun:  we ARE interested on the cpu side
Jan 20 02:07:54 <SpeedEvil> If you get DMA working, the bus doesn't speed up? the CPU busy-wait just goes away?
Jan 20 02:08:00 <SpeedEvil> ->raster
Jan 20 02:08:05 <raster> sure the 30m/sec will limit - put a maximum upper limit on the fps of any video output
Jan 20 02:08:09 <Robot101> borg_: but this suggests you have one thing that talks to the hardware, exposes some abstraction over d-bus, then another thing talks to it over d-bus and exposes a different abstraction over d-bus
Jan 20 02:08:20 <raster> SpeedEvil: bus wont speedup i dont think
Jan 20 02:08:20 <borg_> right
Jan 20 02:08:32 <raster> SpeedEvil: as best i know now we just lose the busywait
Jan 20 02:08:39 <balrog-kun> raster: not if there's a lower upper limit already put on the system by a different part
Jan 20 02:08:52 * SpeedEvil wonders how much 2d accel a 400Mhz CPU can do...
Jan 20 02:09:07 <raster> balrog-kun: the limit that keeps fps down will be the video bus
Jan 20 02:09:11 <SpeedEvil> Anyway - it's fixed now and won't change.
Jan 20 02:09:14 <raster> if u are lucky its screenrefresh
Jan 20 02:09:16 <Robot101> borg_: which seems pretty daft on a resource-constrained device. why would you want/need two? if you can provide the GSM functionality through the existing tp APIs, then just add any extra APIs to the service for stuff that wasn't covered (or add functionality to the tp spec to cover it)
Jan 20 02:09:16 <raster> eg 60fps
Jan 20 02:09:39 <raster> if uyour limit is screen refresh (60fp for example) @ 640x480
Jan 20 02:09:46 <raster> then you are indeed a very very very lucky person
Jan 20 02:09:55 <Robot101> borg_: then there's no confusion/choice when writing applications, if you want to control a call there's one way to do it, and hey, that way works for SIP or IAX calls too
Jan 20 02:09:57 <balrog-kun> agreed
Jan 20 02:10:02 <raster> SpeedEvil:  it actually can do a lot of accel
Jan 20 02:10:04 <borg_> Robot101: write to the freesmartphone mailinglist with examples
Jan 20 02:10:05 <ljp> raster: does the 02 use the same gsm chip?
Jan 20 02:10:08 <raster> SpeedEvil: given good enough code... :)
Jan 20 02:10:12 * SpeedEvil tries to remember when his DOOM hit 640*480 at 60FPS
Jan 20 02:10:13 <raster> ljp:  yes
Jan 20 02:10:14 <borg_> Robot101: how whould a conference call look like?
Jan 20 02:10:16 <balrog-kun> but that afaik won't happen because of the cpu limitations and other
Jan 20 02:10:30 <borg_> Robot101: how do i get things from the adress book of the sim card?
Jan 20 02:10:33 <SpeedEvil> raster: I was more wondering if some things might end up faster just deleting the accel chip.
Jan 20 02:10:47 <Robot101> borg_: a GSM conf call? set up one channel, hold it, set up another, call merge
Jan 20 02:10:51 <raster> SpeedEvil: frankly - vidoe would be faster
Jan 20 02:11:05 <raster> :/
Jan 20 02:11:20 <Robot101> borg_: SIM card entries can appear through the contact list interface
Jan 20 02:11:22 <SpeedEvil> I wonder how much the glamo adds to the BOM.
Jan 20 02:11:23 <raster> put it this way
Jan 20 02:11:30 <raster> some things are better on the glamo
Jan 20 02:11:33 <SpeedEvil> But it's a bit late to do such a major change.
Jan 20 02:11:44 <ljp> good, becuase i dont want to write another bloody phonevendor plugin
Jan 20 02:11:47 <raster> blits are 1. done by the gfx chip and async to any cpu overhead and faster than a cpu can do it
Jan 20 02:11:49 <raster> as with fills
Jan 20 02:11:58 <raster> and all the basic 2d stuff
Jan 20 02:12:03 <raster> if u want to get fancy
Jan 20 02:12:04 <raster> eg xrender
Jan 20 02:12:07 <raster> we are in trouble
Jan 20 02:12:10 <raster> big trouble
Jan 20 02:12:13 <borg_> Robot101: what is with sim card configuration, like changing pin
Jan 20 02:12:18 <raster> the glamo can only accel a fairly small subset of xrender
Jan 20 02:12:22 <Robot101> borg_: thats where you might add a new interface
Jan 20 02:12:25 <raster> so u'd be forced to software fallbacks
Jan 20 02:12:33 <SpeedEvil> raster: and probably not the accel subset your app'll pick.
Jan 20 02:12:50 <raster> and then u have that 30mb/sec straw to vidoe ram to make that gloriously painful as u copy pixels to and from video ram to operate on them with the cpu
Jan 20 02:12:52 <Robot101> borg_: but that's fine, telepathy is extensible with your own interfaces on objects, or you can just add some seperate API to the same process.
Jan 20 02:13:11 <raster> anythign that is xshmputimage heavy
Jan 20 02:13:12 <SpeedEvil> raster: Do you happen to have a current figure for how much it draws when just passively refreshing the screen?
Jan 20 02:13:25 <raster> ie anything that pumps lots of data to x will suffer on the gta02 much worse than gta01
Jan 20 02:13:35 <raster> things that do simple 2d blits (scroling) and fills, will win
Jan 20 02:13:39 <raster> in the end you about break even
Jan 20 02:13:48 <cesarb> great, I lost the USB when changing CPU frequencies :(
Jan 20 02:13:56 <raster> so u spent a lot of code, drivers, testing, hardware and money on going nowhere fast
Jan 20 02:13:56 <raster> :)
Jan 20 02:14:21 <SpeedEvil> raster: I'm currently developing silly hardware so know the feeling.
Jan 20 02:14:22 <raster> i'm hoping to have this not happen again in future devices
Jan 20 02:14:27 <balrog-kun> cesarb: "lost"?
Jan 20 02:14:27 <raster> as for power drain - no idea.
Jan 20 02:14:29 <raster> sorry :/
Jan 20 02:14:38 <borg_> Robot101: write something with examples to smartphones-standards@lists.linuxtogo.org
Jan 20 02:14:40 <cesarb> balrog-kun: as in, it's not even accepting descriptor reads anymore
Jan 20 02:14:57 <balrog-kun> oh
Jan 20 02:15:04 <borg_> Robot101: at the moment there is some gui writing a gsmd prototype for the freesmartphone api
Jan 20 02:15:05 <balrog-kun> cesarb: but that's without resetting?
Jan 20 02:15:07 <borg_> so do it fast ;)
Jan 20 02:15:10 <SpeedEvil> raster: (1.1Kg lifoff weight UAV that hits 1Km vertically over the takeoff spot and then vertically lands on the takeoff spot) Part selection before you write drivers is horrible.
Jan 20 02:15:13 <borg_> s/gui/guy/
Jan 20 02:15:24 <cesarb> balrog-kun: yeah
Jan 20 02:15:40 <cesarb> balrog-kun: I wanted to check the results of the timing code...
Jan 20 02:16:07 <balrog-kun> cesarb: i guess there may be more drivers out there not expecting HZ to change run-time :/
Jan 20 02:16:35 <SpeedEvil> cesarb: it notes that 
Jan 20 02:16:47 <SpeedEvil> cesarb: PCLK amy not be below 40(?) Mhz
Jan 20 02:16:58 <SpeedEvil> cesarb: do you drop into slow mode while changing freqs?
Jan 20 02:17:01 <borg_> Robot101: another thing is this telephony api by LiPS
Jan 20 02:17:08 <SpeedEvil> cesarb: the USB bodule
Jan 20 02:17:57 <SpeedEvil> s/b/m/
Jan 20 02:17:57 <apt> SpeedEvil meant: cesarm: the USB bodule
Jan 20 02:18:15 <cesarb> SpeedEvil: I changed to 202800 kHz
Jan 20 02:18:26 <cesarb> SpeedEvil: not much of a change
Jan 20 02:18:29 <SpeedEvil> Ah
Jan 20 02:18:38 <cesarb> SpeedEvil: that's just the first test
Jan 20 02:18:40 <justin111> so is this where OM dev goes on
Jan 20 02:18:51 <SpeedEvil> I wouln't expect PLL excursions to be _That_ large
Jan 20 02:19:18 <SpeedEvil> Does unloading and reloading the USB modules work?
Jan 20 02:19:26 <raster> SpeedEvil: yeah. very painful.
Jan 20 02:19:30 <SpeedEvil> justin111: to an extent
Jan 20 02:19:40 <balrog-kun> hard to say without having working usb i imagine :)
Jan 20 02:19:52 <SpeedEvil> raster: at least it won't fall on your head after powerdiving from 1Km :)
Jan 20 02:19:54 <raster> frankly in future - i want to see us have something that is technically capable of anything u see on the iphone
Jan 20 02:19:56 <raster> or itouch
Jan 20 02:19:59 <raster> or even psp
Jan 20 02:20:01 <raster> etc.
Jan 20 02:20:27 <raster> if then its just a matter of drivers and software - i'm a happy man
Jan 20 02:20:41 <raster> the problem is finding something open (or willing to be opened)
Jan 20 02:20:43 <borg_> Robot101: how do you register with a network? how do you get a list of possible providers?
Jan 20 02:20:46 <raster> or programmable openly
Jan 20 02:20:50 <cesarb> SpeedEvil: changing from my rusty old Zire 72 cable to one of the neo's own USB cables also didn't help
Jan 20 02:20:51 <raster> we will see about that
Jan 20 02:21:00 <raster> but for the forseeable future we have the glamo so beat into shape
Jan 20 02:21:15 <SpeedEvil> If it was me. I'd like to see GTA01 with faster CPU + camera + wifi +HH (with docs)
Jan 20 02:21:20 <raster>  maybe we can get smedia to add all the bits they missed into their next gen glamo chip and use that later
Jan 20 02:21:22 <SpeedEvil> But that's somewhat unlikely.
Jan 20 02:21:27 <raster> and so not have to redo yet more drivers
Jan 20 02:21:41 <raster> yeah
Jan 20 02:21:49 <raster> in some ways right now i think we'd have been better off with that
Jan 20 02:21:56 <Robot101> borg_: again, not currently covered. but it's not a total GSM API, it's just concerned with call control and messaging. but for those functionalities at least, using tp would be a big win.
Jan 20 02:21:57 <raster> even without camera
Jan 20 02:22:15 <raster> just gta01 + open gps, accelerometers, wifi and faster cpu with more flash
Jan 20 02:22:27 <SpeedEvil> raster: camera is tricky, yes. There are insanely small camera modules though.
Jan 20 02:22:29 <raster> i seriusly was thinking of pushing us to qvga
Jan 20 02:22:37 <SpeedEvil> raster: 5*5*2mm 2MP with AF
Jan 20 02:22:37 <borg_> Robot101: but the call control is just a pretty small thing in the whole freesmartphone.org api
Jan 20 02:22:46 <raster> as vga was just painful to fill the peixels of at sane speeds
Jan 20 02:22:48 <justin111> what USA carrier has compatible GSM freq's for neo
Jan 20 02:23:09 <raster> justin111: the gta01 or gta02?
Jan 20 02:23:14 <raster> gta02 will come in 2 versions
Jan 20 02:23:21 <SpeedEvil> raster: the VGA screen is insanely nice for static text. It's a lot of data to push though.
Jan 20 02:23:21 <justin111> gta02
Jan 20 02:23:21 <raster> 1. thats 1900mhz etc. and one that 850mhz
Jan 20 02:23:23 <Robot101> borg_: I think call control and messaging is quite a big thing for a phone actually... :D
Jan 20 02:23:30 <raster> sped indeed it is
Jan 20 02:23:33 <raster> i was really torn
Jan 20 02:23:40 <justin111> in 2 version let me guess CDMAndasGSm
Jan 20 02:23:43 <raster> the beauty of its dpi and static display was amazing
Jan 20 02:23:44 <borg_> Robot101: http://www.freesmartphone.org/mediawiki/index.php/Standards
Jan 20 02:23:47 <raster> it'd be a shame to lose it
Jan 20 02:23:55 <raster> but then the moment u had to move/animate/whatever anything
Jan 20 02:23:59 <borg_> Robot101: at first, it concerns only the open telephony api
Jan 20 02:23:59 <raster> .life becomes yukkie
Jan 20 02:24:13 <raster> justin111:  no 2 gsm versions\
Jan 20 02:24:13 <SpeedEvil> raster: For a 'games mode' I think dropping to QVGA is a better plan.
Jan 20 02:24:19 <raster> just different freqency support
Jan 20 02:24:39 <borg_> Robot101: http://www.freesmartphone.org/mediawiki/index.php/Standards/OpenPhoneServerAPI look at the bottom, your api is not listet as proposals to consider, so please write to the mailing list
Jan 20 02:24:39 <SpeedEvil> raster: the notion that you can tell 640*480 in normal use at 60Hz with fast motion dosn't really hold up.
Jan 20 02:24:43 <justin111> why cant it be all in one
Jan 20 02:24:52 <SpeedEvil> justin111: compromises
Jan 20 02:24:59 <borg_> Robot101: perhaps mickey just is not aware of it
Jan 20 02:25:06 <SpeedEvil> justin111: it's more expensive and larger board area to make a 4 band phoine.
Jan 20 02:25:37 <justin111> oh ojk
Jan 20 02:25:40 <cesarb> SpeedEvil: went down to 135000 kHz, noticed some flicker (perhaps because I don't have the fb code), AND the timer ran at exactly half of the correct speed :(
Jan 20 02:25:54 <Robot101> borg_: I spoke to him about it at GUADEC
Jan 20 02:26:03 <justin111> speed what are you guys working on
Jan 20 02:26:14 <borg_> Robot101: and what did he say? ;)
Jan 20 02:26:17 <raster> SpeedEvil: i know
Jan 20 02:26:18 <SpeedEvil> justin111: either that, or it was only dicovered after the GTA02 design was mostly frozen that GTA01 was triband - a specification mistake
Jan 20 02:26:43 <raster> SpeedEvil: BUT u cant chnage resolution on the fly smoothly to be able to go up and down from vga to qvga between frame updates
Jan 20 02:27:08 <raster> justin111: cost, time to market, existing RF layout etc.
Jan 20 02:27:19 <Robot101> borg_: he sounded pretty keen on the idea of the UIs being able to use common Telepathy APIs for calling and messaging stuff, so they can do SIP etc just as easily
Jan 20 02:27:21 <SpeedEvil> raster: Hmm. I don't in principle see why not. The framebuffer can be pointed at another bit of RAM very quickly.
Jan 20 02:27:25 <Robot101> borg_: not spoken much with him since then
Jan 20 02:27:46 <cesarb> SpeedEvil: I think it's more likely that the "it was discovered too late" version is the true one
Jan 20 02:27:52 <raster> SpeedEvil: sure - in THEORY - if that bit of ram was pre-filled with the current screen @ qvga
Jan 20 02:27:54 <cesarb> SpeedEvil: I don't think it would cost too much board area
Jan 20 02:28:01 <raster> but x itself won't handle this gracefully at all
Jan 20 02:28:07 <SpeedEvil> raster: no, it won't.
Jan 20 02:28:45 <SpeedEvil> raster: though I have considered ickyness. A hacked VNC client on a QVGA X
Jan 20 02:29:10 <raster> ouch!
Jan 20 02:29:22 <SpeedEvil> raster: Purely for personal use.
Jan 20 02:32:22 <SpeedEvil> cesarb: how are you talking to your slow neo?
Jan 20 02:32:49 <borg_> Robot101: so the question is, should we use both use more resources, should we extend your api with the sim card/gsm related stuff or should we use your api for call control and ours for the rest
Jan 20 02:32:57 <borg_> Robot101: what do you think is the best solution?
Jan 20 02:33:47 <SpeedEvil> Robot101: How large is the 'core' telepathy bit that's under discussion - disk/RAM
Jan 20 02:34:26 <Robot101> SpeedEvil: there is no core telepathy bit, fundamentally it's a D-Bus API
Jan 20 02:34:38 <Robot101> SpeedEvil: any backend that implements it can be used by a frontend that speaks it
Jan 20 02:34:54 <cesarb> SpeedEvil: http://wiki.openmoko.org/wiki/User:CesarB/cpufreq <- now with testing report
Jan 20 02:35:59 * cesarb must find out what's the problem with the timer4
Jan 20 02:36:09 <Robot101> SpeedEvil: but usually you'll want a bit called mission control, which seems to take ~2Mb RAM on my system
Jan 20 02:36:53 <Robot101> SpeedEvil: and the tp-glib library is the easiest way to implement/use the API, is 250k here
Jan 20 02:37:17 <Robot101> SpeedEvil: it's always been usable on embedded platforms from the start, the Nokia 770 was our first deployment
Jan 20 02:38:36 <Robot101> borg_: if there are APIs that make sense on a GSM "connection" object, they can be added as interfaces on the tp connection object
Jan 20 02:39:04 <Robot101> borg_: they can be put into the spec where appropriate, like something to configure forwarding might be relevant on other services besides GSM
Jan 20 02:39:08 <raster> the biggest thing about telepathy is really going to be how far it abstracts
Jan 20 02:39:25 <raster>  and how much u have to go behind its back to find things out from your gsm hw
Jan 20 02:39:33 <raster> or tell the gsm hw to do things
Jan 20 02:39:40 <raster> and/or if it makes sense
Jan 20 02:40:06 <Robot101> it's designed to hide the protocol specifics, but not hide the fact that protocols are different in terms of their capabilities
Jan 20 02:40:13 <borg_> Robot101: but you wont be able to use gsm the some way as sip then
Jan 20 02:40:17 <raster> if not u likely need another abstraction between gsm hw and telepathy and whatever lese u split out to
Jan 20 02:40:33 <Robot101> borg_: why?
Jan 20 02:40:35 <raster> Robot101: sure - but things like being able to find the name of your current gsm cell
Jan 20 02:40:44 <Robot101> so different types of channel, or interfaces are/aren't available depending on functionality
Jan 20 02:40:46 <raster> (eg sydney, or canary wharf etc.)
Jan 20 02:40:52 <borg_> Robot101: if you want to do the gsm handling stuff with your api, you have to choose a provider, connect to the network and so on
Jan 20 02:40:53 <raster> should that be in telepathy or somewhere else?
Jan 20 02:41:02 <raster> then lets go a step further
Jan 20 02:41:03 <Robot101> you can add extra interfaces to cover specifics
Jan 20 02:41:08 <borg_> Robot101: imo it makes sense to have another abstraction layer under it
Jan 20 02:41:10 <borg_> that does it
Jan 20 02:41:11 <Robot101> and hang them off the telepathy object
Jan 20 02:41:16 <raster> a lot of gsm chips can tell you ALL the cells you are in and their relative signal strenghts
Jan 20 02:41:39 <SpeedEvil> Including this one
Jan 20 02:41:41 <raster> u can do relatively coarse triangulation then - if u know where those cells are located
Jan 20 02:41:48 <SpeedEvil> at%EM3 IIRC
Jan 20 02:41:49 <raster> but should this be in telepathy
Jan 20 02:41:58 <raster> as we are movign away from messaging itself now
Jan 20 02:42:04 <SpeedEvil> raster: I haven't found out how to do triangulation from the data I've taken
Jan 20 02:42:08 <Robot101> yeah yeah yeah, so just write the magic GSM specific interfaces, and add them onto the Telepathy objects, but they don't need to into the telepathy spec itself
Jan 20 02:42:27 <raster> SpeedEvil: if u have 3 or more cells and signal strengths - thats the best u can do i think
Jan 20 02:42:33 <Robot101> org.freedesktop.Telepathy.Connection.GetInterfaces can include com.foo.misc.GsmStuff
Jan 20 02:42:34 <raster> after that u need to co-ords of the specific cell towers
Jan 20 02:42:38 <SpeedEvil> Robot101: especially as 'find the name of the current cell' might involve looking up a large database, perhaps over the net, perhaps with the aid of GPS
Jan 20 02:42:46 <Robot101> and a client that doesn't care about GSM can ignore it
Jan 20 02:42:50 <Robot101> but a client that does can use it
Jan 20 02:42:53 <SpeedEvil> raster: oh - I was hoping for timings in the data
Jan 20 02:42:57 <raster> robh sure
Jan 20 02:43:00 <raster> but does that belong in telepathy
Jan 20 02:43:06 <Robot101> it's not in telepathy
Jan 20 02:43:13 <raster> does its perhaps belong is a mroe specific abstraction fo geo-location 
Jan 20 02:43:20 <raster> that abstracts to gps chips
Jan 20 02:43:31 <Robot101> it's just implemented as a new interface that's on the same process as implements the telepathy stuff
Jan 20 02:43:31 <raster> or uses the gsm chipo as a coarse gsm or when gsm is not vailable etc.
Jan 20 02:43:45 <Robot101> you don't need to stack up abstractions just because telepathy isn't a complete abstraction
Jan 20 02:43:49 <raster> SpeedEvil:  i think u can get latency to the towers too
Jan 20 02:44:01 <Robot101> you can have one tp-gsmd which speaks tp for the bits tp does, and ?! for the rest
Jan 20 02:44:03 <raster> SpeedEvil: but again - not useful if u .... dont knwo where in the world those towers are
Jan 20 02:44:03 <raster> :)
Jan 20 02:44:06 <SpeedEvil> raster: I diddn't see that in any of the datafields returned
Jan 20 02:44:14 <raster> SpeedEvil: in theory u can
Jan 20 02:44:17 <SpeedEvil> raster: trivial in theory - if you can get latency
Jan 20 02:44:19 <raster> dont know about the gsm on the neo tho
Jan 20 02:44:24 <Robot101> and then a different tp-gsmd2 can present the same APIs for tp + GSM functionality
Jan 20 02:44:26 <Vegar> would it be possible to locate the towers if you move around a bit with a GPS?
Jan 20 02:44:27 <SpeedEvil> wander around with GPS + GSM tower logging on
Jan 20 02:44:30 <raster> this is just gsm in general
Jan 20 02:44:43 <raster> Vegar:  if u have gps - why bother. u know where u are!
Jan 20 02:44:43 <raster> :)
Jan 20 02:44:56 <raster> *IF the aim is to find out where YOU are
Jan 20 02:44:57 <Robot101> but there's no point writing a GSM call/messaging/yada abstraction API if you can just use the tp API for that, just an exercise in wasting memory and CPU marshalling/demarshalling data then
Jan 20 02:45:02 <SpeedEvil> However, I diddn't get anything sensible from graphing ranges from tower vs any of the fields returned from %EM
Jan 20 02:45:07 <Vegar> raster: for times when the US government decides to shut down GPS
Jan 20 02:45:13 <raster> Robot101: agreed
Jan 20 02:45:18 <cesarb> SpeedEvil: if you see a field for the "timing advance", that's what you are looking for
Jan 20 02:45:25 <SpeedEvil> cesarb: I did
Jan 20 02:45:32 <SpeedEvil> cesarb: it diddn't seem to have clear data
Jan 20 02:45:38 <raster> Vegar: then u need to triangulate with gsm towers
Jan 20 02:45:43 <SpeedEvil> cesarb: not obvious when plotted on a graph anyway
Jan 20 02:45:44 <raster> that requires u know where the towers are
Jan 20 02:45:59 <raster> i dont think telcos broadcast tower lat/long :)
Jan 20 02:45:59 <Robot101> the usual thing we look for before putting stuff into the TP spec is; is this something that's worth us abstracting because it can usefully happen on more than one protocol we do/can/will support
Jan 20 02:46:06 <Vegar> raster: assuming you were able to locate the towers before the GPS died
Jan 20 02:46:07 <cesarb> SpeedEvil: the timing advance is how much the radio has to delay or advance (hence the name) the transmission to fit in the center of the slot
Jan 20 02:46:23 <SpeedEvil> raster: if you know your course (GPS), and range-changes to the tower, you can derive position
Jan 20 02:46:29 <raster> Vegar: then i guess with enough data u could
Jan 20 02:46:31 <cesarb> SpeedEvil: it's the thing responsible for GSM's range limit (after some point you start going over other slot)
Jan 20 02:46:40 <SpeedEvil> cesarb: maybe I was trying too short ranges
Jan 20 02:46:44 <raster> SpeedEvil:  sure. i'm just for now assuming u dont know where u are
Jan 20 02:46:46 <raster> no gps data
Jan 20 02:46:59 <raster> and u have 3 or moe towers and relative latency/singal strengths
Jan 20 02:47:12 <raster> withotu tower locs u are still not going to know
Jan 20 02:47:19 <raster> given a vast location database like google maps
Jan 20 02:47:22 <SpeedEvil> raster: I'm assuming a collaborative effort that does the above and spits the extrapolated data back to a shared db
Jan 20 02:47:25 <raster> u could take cell tower names and look them up
Jan 20 02:47:31 <Robot101> like if it's something crazily specific to one protocol, like manually traversing service discovery and filling in x-forms on XMPP, it's not something worth standardising for us atm because it doesn't turn up on other protocols
Jan 20 02:47:37 <raster> and thus take a guess at where they might be
Jan 20 02:47:43 <Robot101> a lot of GSM functionality has parallels on other protocols though
Jan 20 02:47:49 <raster> and thus at least somehow get a location within a veyr large margin of error
Jan 20 02:47:59 <Robot101> like configuring "server-side" (network) forwarding can happen with SIP services
Jan 20 02:48:17 <Robot101> or being challenged for authentication tokens (PIN stuff) certainly happens elsewhere
Jan 20 02:48:32 <Robot101> GSM signal strength, or which cell can I see, not so much
Jan 20 02:48:53 <Robot101> but that doesn't mean tp-gsm can't just tack an extra GSM-specific interface onto its connection object, that's pretty straightforward
Jan 20 02:49:03 <SpeedEvil> robtaylor: voice-over-wifi isn't going to become less popular.
Jan 20 02:49:06 <SpeedEvil> robo:
Jan 20 02:49:16 <raster> hehehe
Jan 20 02:49:19 <cesarb> SpeedEvil: just thought of something, it's possible the timing advance only gets really accurate when you are using the slots for talking
Jan 20 02:49:26 <raster> no it isnt
Jan 20 02:49:35 <SpeedEvil> Robot101: especialy now that some have implemented GSM gateways
Jan 20 02:49:39 <cesarb> SpeedEvil: the slots used for sporadic communication aren't as precise
Jan 20 02:49:44 <raster> thats why eventually we do need to marry gsm based comms vs. IP based (and whatever else comes along)
Jan 20 02:50:06 <raster> BAH
Jan 20 02:50:15 <SpeedEvil> Robot101: where you talk IP to a virtual cell tower in the cellphone companies NOC.
Jan 20 02:50:15 <raster> i thought i'd changed sh to bash from dash
Jan 20 02:50:32 <raster> what insanity prompted ubuntu to use dash instead of bash
Jan 20 02:50:35 <SpeedEvil> Robot101: so you can 'roam' from GSM to wifi and back as from GSM cel-cell
Jan 20 02:50:42 <Robot101> SpeedEvil: yeah, UMA stuff
Jan 20 02:52:43 <cesarb> raster: it's faster, and due to Debian's policies everything works with both (Debian does a lot of bashism-bashing)
Jan 20 02:52:56 <SpeedEvil> Pity UMA doesn't work on the neo.
Jan 20 02:53:19 * balrog-kun wonders if the measured power draw for "powered off" in http://wiki.openmoko.org/wiki/Neo1973_GTA01_Power_Management#Measured_power_draw_on_phase_0_neo1973 is correct
Jan 20 02:53:21 <SpeedEvil> Well - barring firmware changes on the TI
Jan 20 02:53:22 <cesarb> raster: I, btw, use dash as my /bin/sh in Ubuntu, and don't have many problems compiling things (if OE accepted the last 2-3 patches of mine, there would be none)
Jan 20 02:53:29 <SpeedEvil> balrog-kun: yes it is
Jan 20 02:53:42 <SpeedEvil> balrog-kun: more or less - it was 0.1 on my meter set to 200mA
Jan 20 02:54:07 <balrog-kun> oh wait, that's mW and the other is in W :/
Jan 20 02:54:22 <SpeedEvil> balrog-kun: I may have committed mA/mW confusion in that page
Jan 20 02:54:34 <raster> cesarb: faster - hrrrm. havent tested myself on that front
Jan 20 02:54:41 <balrog-kun> it is probably correct, yeah
Jan 20 02:54:41 <raster> but man has it caused some pain before
Jan 20 02:54:42 <balrog-kun> time to go to sleep for me :)
Jan 20 02:54:50 <raster> right  now OE is that pain
Jan 20 02:55:37 <cesarb> raster: looking at my build overlay, only mtpaint and ruby are still broken. You should find patches from me for both at the OE tracker.
Jan 20 02:55:52 <raster> openmoko-browser2 is broken
Jan 20 02:55:59 <raster> justw switched  to bash and its fixed
Jan 20 02:57:34 <SpeedEvil> firefox is also broken :)
Jan 20 02:58:06 <raster> oooh woot
Jan 20 02:58:10 <raster> libgsmd broke
Jan 20 02:58:25 <raster> oh wait
Jan 20 02:58:36 <raster> its one of those "it brken this time - just run the build again" breaks
Jan 20 02:59:00 <raster> hmm
Jan 20 02:59:04 <raster> no
Jan 20 02:59:08 <SpeedEvil> what do I need to do to get it to build - it's complaining about nothing found for uboot
Jan 20 02:59:24 <raster> oooh
Jan 20 02:59:30 <raster> u need to update mokomakefile
Jan 20 02:59:42 <raster> final target for om changed form uboot to u-boot
Jan 20 02:59:43 <SpeedEvil> make update?
Jan 20 02:59:46 <SpeedEvil> Or something else?
Jan 20 02:59:54 <raster> make update-makefile
Jan 20 02:59:55 <raster> i think
**** ENDING LOGGING AT Sun Jan 20 02:59:57 2008