**** BEGIN LOGGING AT Mon Jun 14 02:59:57 2010
Jun 14 07:00:51 <JaMa> another EFL bump almost in feed
Jun 14 07:03:30 <mrmoku> JaMa: bumpididoo :)
Jun 14 07:06:16 <JaMa> this time bumped by koen :)
Jun 14 07:10:36 <CIA-59> freesmartphone.org: 03Frederik.Sdun 07utilities * r90cf682fafb7 10/palmpre/preboot/src/main.vala: preboot: fix kexec parameters
Jun 14 07:39:48 <PaulFertser> mrmoku: hi
Jun 14 07:40:28 <PaulFertser> mrmoku: since the majority of shr users are now using fsogsmd... Do you get any complaints about disfunctional +CLCC?
Jun 14 07:47:50 <mrmoku> PaulFertser: not that I'm aware of... but I'm not really back into business yet :/
Jun 14 07:49:46 <PaulFertser> mrmoku: i do not know what to say. This problem really makes my "user experience" uncomfortable.
Jun 14 07:50:43 <PaulFertser> mrmoku: and also there's indeed a problem with loosing incoming sms messages.
Jun 14 08:02:28 <PaulFertser> mrmoku: that's sick. Just reproduced the issue with a message lost forever.
Jun 14 08:04:42 <mrmoku> PaulFertser: how to reproduce?
Jun 14 08:05:56 <PaulFertser> mrmoku: http://trac.freesmartphone.org/ticket/566
Jun 14 08:06:25 <PaulFertser> mickey|wm: hey :)
Jun 14 08:06:31 <PaulFertser> mickey|wm: i'd say that's "major" issue indeed.
Jun 14 08:07:08 <mrmoku> PaulFertser: so just receiving a message while phone is suspended?
Jun 14 08:07:14 <mrmoku> that would be major indeed :/
Jun 14 08:07:20 <PaulFertser> mrmoku: yes, and sim_buffer_sms
Jun 14 08:07:35 <PaulFertser> = false. Well, you got the ide.
Jun 14 08:08:24 <mrmoku> PaulFertser: yeah, we have that false in shr-u
Jun 14 08:08:37 <PaulFertser> mrmoku: what bothers me is that there're so many shr-u users around and that's me who's reporting critical bugs. :/
Jun 14 08:08:44 * mrmoku tries
Jun 14 08:11:09 <mrmoku> PaulFertser: hmm... it wakes up... vibrates... gives the incoming message sound... and shows me the message
Jun 14 08:11:13 <mrmoku> there must be more to it
Jun 14 08:11:41 <PaulFertser> mrmoku: of course, but i'm not able to figure that out probably because logging is unsufficient.
Jun 14 08:11:57 <PaulFertser> mrmoku: libfsotransport <Serial /dev/ttySAC0@115200 (fd 30)>: read 109 bytes 
Jun 14 08:12:01 <PaulFertser> ^^ what are those ?
Jun 14 08:12:28 <PaulFertser> If it was an unknown unsol, it would have been reported in the log.
Jun 14 08:14:58 <PaulFertser> mrmoku: it looks like disabling sim storage is not always effective.
Jun 14 08:15:34 <PaulFertser> mrmoku: and my SIM storage is full.
Jun 14 08:16:52 <mrmoku> PaulFertser: hmm... mine is empty... so that at least is a difference
Jun 14 08:18:01 <PaulFertser> mrmoku: i'm not sure it's really full, probably i've 2 slots free... Anyway, i for sure see some messages that never got into opimd in there.
Jun 14 08:20:30 <PaulFertser> mrmoku: read 34 bytes, then read 75 bytes just after i send the message (now my phone is not suspended)
Jun 14 08:20:40 <mrmoku> PaulFertser: maybe mickey|wm was right saying that unbuffered SMS are unreliable?
Jun 14 08:20:41 * PaulFertser wished he could get those bytes without restarting anything.
Jun 14 08:20:51 <PaulFertser> mrmoku: what are those bytes?
Jun 14 08:20:56 <mrmoku> no idea
Jun 14 08:42:02 <PaulFertser> mrmoku: and i do have an idea. Strace rules.
Jun 14 08:44:02 <PaulFertser> mrmoku: http://trac.freesmartphone.org/ticket/566#comment:1
Jun 14 08:47:28 <mrmoku> hmm
Jun 14 08:51:32 <PaulFertser> mrmoku: do you have that +CMT: ,<length> too? Or is your calypso reporting it without comma?
Jun 14 08:53:57 <PaulFertser> Mine does, so probably the comma is not the reason.
Jun 14 09:01:14 <mrmoku> PaulFertser: have to start fsogsmd with strace to see?
Jun 14 09:01:20 <mrmoku> or is it in the normal log
Jun 14 09:01:23 <mrmoku> ?
Jun 14 09:01:29 <PaulFertser> mrmoku: of course no, i connected strace to a running pid
Jun 14 09:02:05 <PaulFertser> mrmoku: the comma is not relevant anyway, never mind. I guess we'll have to wait for mickey|wm to solve the riddle.
Jun 14 09:02:22 <mrmoku> ok
Jun 14 09:34:17 <PaulFertser> mickey_office: hey :)
Jun 14 09:34:59 <PaulFertser> mickey_office: at the moment i have 100% reproducible "lost sms" issue, see the ticket. Do you probably want me to do any other tests in this state?
Jun 14 09:41:35 <mickey_office> PaulFertser: morning. can't think of anything atm., head is full with contract work. I'll process that later this week
Jun 14 09:41:42 <mickey_office> i _think_ i have an idea, btw.
Jun 14 09:41:53 <mickey_office> it is probably the missing flow control that did not make its way from ogsmd to fsogsmd
Jun 14 09:42:10 <mickey_office> ah well, no, on stracing you have seen the message, right?
Jun 14 09:42:28 <PaulFertser> mickey_office: right, but i'm not sure how to tell what's not right with it.
Jun 14 09:43:21 <PaulFertser> mickey_office: anyway, take your time, no hurry :) but that's a major issue, imho.
Jun 14 09:44:28 <PaulFertser> mickey_office: i can probably try to decode 07.10 frame again to understand if the unsol comes on the channel you expect.
Jun 14 09:56:42 <mickey_office> PaulFertser: right, can't hurt.
Jun 14 10:40:31 <leviathan> phh: the nand driver, qualcomm wrote is unusable
Jun 14 10:41:22 <leviathan> is it possible to get the datasheets for the NAND chip somewhere
Jun 14 10:41:28 <leviathan> so that I can do a own
Jun 14 10:43:27 <beniwtv> Hi all, after upgrading SHR today I get error messages from phoneuid that libecore_evas-ver-svn-06.so.0 is missing. Any ideas? The installed library seems to be called libecore_evas-ver-pre-svn-06.so.0 instead.
Jun 14 10:48:31 <mrmoku> beniwtv: there was an EFL bump... and I saw that JaMa bumped PR for all depending packages... dunno if he built it too though
Jun 14 10:48:40 <mrmoku> beniwtv: did you get an upgraded libphone-ui-shr package?
Jun 14 10:48:45 <JaMa> beniwtv: yes.. phoneuid should get PR bump (I've probably missed this one)
Jun 14 10:49:00 <mrmoku> JaMa: phoneuid?
Jun 14 10:49:03 <mrmoku> why that?
Jun 14 10:49:51 <JaMa> mrmoku: you're right libphone-ui-shr should be bumped
Jun 14 10:49:58 <mrmoku> and you did that
Jun 14 10:50:00 * mrmoku saw that
Jun 14 10:50:35 <mrmoku> dunno if it is built though
Jun 14 10:50:39 <beniwtv> JaMa, mrmoku: ok, that would explain it :)
Jun 14 10:51:06 <JaMa> beniwtv: when did you update&upgrade?
Jun 14 10:51:14 <JaMa> beniwtv: it's in feed only for 10 mins or so
Jun 14 10:51:58 <beniwtv> JaMa, will try again now
Jun 14 10:52:04 <JaMa> and works here
Jun 14 10:52:43 <ThibG> larsc, ping
Jun 14 10:54:42 <beniwtv> JaMa: Yep, last upgrades did it, thanks :)
Jun 14 10:56:15 <JaMa> good
Jun 14 10:57:40 <larsc> ThibG: pong
Jun 14 10:57:59 <ThibG> larsc, so, the mmc_host_disable calls in suspend and remove are needed
Jun 14 10:58:34 <ThibG> since mmc_suspend_host and mmc_remove_host call mmc_host_lazy_disable at some point
Jun 14 10:59:06 <larsc> hm
Jun 14 11:00:08 <larsc> thats sounds more like they shouldn't call it. but sure, you'll have to workaround it
Jun 14 11:10:55 <ThibG> btw, the irq was freed before calling mmc_host_remove, in _remove
Jun 14 11:11:40 <mrmoku> JaMa: which one is the correct one? libgps or libgps19 ?
Jun 14 11:12:51 <mrmoku> JaMa: http://shr.pastebin.com/4FHZuvUZ
Jun 14 11:13:16 <mrmoku> conflict on elementary theme too
Jun 14 11:34:41 <JaMa> mrmoku: libgps19
Jun 14 11:34:51 <JaMa> mrmoku: and ver-pre-svn-06 for elementary
Jun 14 11:34:57 <JaMa> mrmoku: should be fixed with next sync
Jun 14 12:24:32 <leviathan> GNUtoo|laptop: hi
Jun 14 12:24:42 <GNUtoo|laptop> hi leviathan 
Jun 14 12:25:11 <leviathan> in the new fso version the suspend thing is fixed
Jun 14 12:25:14 <leviathan> right=
Jun 14 12:25:15 <leviathan> ?
Jun 14 12:26:23 <mickey_office> somewhat
Jun 14 12:26:34 <leviathan> ok
Jun 14 12:26:38 <mickey_office> the delay seems to help to detect when it suspends
Jun 14 12:26:45 <mickey_office> the real fix will come with GNUtoo|laptop's proc node
Jun 14 12:26:51 <leviathan> hm, ok
Jun 14 12:27:17 <GNUtoo|laptop> leviathan, it's nearly finished , it took time because __init was not started first in wakelock.c
Jun 14 12:27:24 <GNUtoo|laptop> so I assumed it was,wrongly
Jun 14 12:27:48 <leviathan> hmm, ok
Jun 14 12:30:06 <mrmoku> JaMa: yeah, the elementary conflict is fixed
Jun 14 12:35:30 <JaMa> mrmoku: good, thanks for test
Jun 14 12:36:15 <mrmoku> JaMa: thanks for fixing :)
Jun 14 15:21:38 <PaulFertser> ThibG: do you think debian users would be happy without wifi driver anyway?
Jun 14 15:22:17 <ThibG> don't know. I, personally, don't use it anyway
Jun 14 15:24:00 <lindi-> ThibG: i use it a lot
Jun 14 15:24:23 <lindi-> ThibG: i won't be spending much time testing a kernel unless I can get wifi :/
Jun 14 15:24:36 <lindi-> wifi was one of the main reasons I waited for gta02
Jun 14 15:24:48 <ThibG> never managed to use it with mokonnect, and on Debian, nothing was here to tell FSO to enable the wifi (with the exception of some command-line utility I don't remember the name)
Jun 14 15:25:16 <ThibG> hm, maybe the wifi driver can be provided as an extra out-of-tree driver
Jun 14 15:25:17 <lindi-> ThibG: i don't see why i'd want to use any openmoko specific applications for it though
Jun 14 15:25:27 <lindi-> ThibG: "ifup wlan=<name of network>" here
Jun 14 15:25:58 <ThibG> I have fso running on my Debian installation, it somehow disable the device unless told otherwise...
Jun 14 15:26:05 <misc> ThibG: mdbus work on debian to enable wifi, mine is using wifi 
Jun 14 15:26:05 <ThibG> (ifup doens't work)
Jun 14 15:26:07 <lindi-> ThibG: yeah it tends to do that
Jun 14 15:26:20 <lindi-> ThibG: that's why I've run away from fso :)
Jun 14 15:26:26 <misc> well, that's for powersaving reason
Jun 14 15:26:41 <misc> once you tel to enable, it do not shutdown 
Jun 14 15:27:43 <ThibG> I think it's still better to have all but wifi in the official Debian kernel, and have a separate package in pkg-fso
Jun 14 15:27:46 <PaulFertser> misc: mdbus2 is much-much better
Jun 14 15:27:54 <PaulFertser> misc: and fsoraw works nice for the purpose
Jun 14 15:28:04 <lindi-> ThibG: well yes that sounds like an improvement
Jun 14 15:28:17 <lindi-> ThibG: especially if it's possible to build the ar6000 module againt the headers
Jun 14 15:29:29 <misc> PaulFertser: no mdbus2 on debian ( at least not I found ), but I will look if I stumble on it :)
Jun 14 15:35:01 <ThibG> (fsoraw was the thing)
Jun 14 15:35:17 <ThibG> lindi-, should not be a problem, I guess
Jun 14 15:42:03 <lindi-> ThibG: well whole .32 is a problem afaik :)
Jun 14 15:42:13 <ThibG> hm?
Jun 14 15:42:43 <lindi-> ThibG: lots of unsolved bugs last time I heard
Jun 14 15:42:53 <ThibG> hm ok
Jun 14 15:43:02 <ThibG> just tried glamo-mci for now
Jun 14 15:43:05 <lindi-> ThibG: the touchscreen issue comes to my mind first
Jun 14 15:45:09 <PaulFertser> misc: i hope debian folks will package it. I use everything from the sources.
Jun 14 15:45:39 * misc also hope 
Jun 14 15:46:44 <PaulFertser> misc: give 'em a hint then ;)
Jun 14 17:36:29 <PaulFertser> mickey|wm: (lost message) there's no obvious difference between stracing a working and non-working cases, the output is almost identical (i guess the only difference comes from the timestamp and the last char of the message i intentionally vary).
Jun 14 17:39:47 <CIA-59> freesmartphone.org: 03mickey 07cornucopia * r13bd55ce62b6 10/libfsotransport/fsotransport/ (delegate.vala parser.vala): 
Jun 14 17:39:47 <CIA-59> freesmartphone.org: libfsotransport: parser: require delegates to be cleared before setting to another value
Jun 14 17:39:47 <CIA-59> freesmartphone.org: This will catch the case when you try to use one parser for multiple channels
Jun 14 17:41:14 <mickey|wm> PaulFertser: ok
Jun 14 17:42:04 <PaulFertser> mickey|wm: but it definetely looks like once i got into the "bad state", there was no way out, and exactly the same test worked after fsogsmd restart.
Jun 14 17:43:09 <mickey|wm> strange
Jun 14 17:46:00 <PaulFertser> mickey|wm: indeed, and i got only "read xx bytes" in the log, no "unknown URC" or anything. I'm saying that not to push you, just fyi.
Jun 14 17:49:33 <PaulFertser> And everything else (calls, sim communication etc) keeps working.
Jun 14 17:56:50 <mickey|wm> sure, np
Jun 14 17:58:10 <shazkhan> mickey|wm no more on #linaro?
Jun 14 17:59:14 <mickey|wm> still there, but not during the next 90 minutes as I will be watching a game :)
Jun 14 18:02:44 <shazkhan> k
Jun 14 18:22:43 <ThibG> larsc, there is disabled code to read data as it comes to the glamo (and don't wait for an IRQ for that), what should be done with that?
Jun 14 18:54:41 <larsc> well, best would be to get it to work
Jun 14 18:55:06 <larsc> i had problems that the data was corrupted when read out early
Jun 14 18:55:49 <ThibG> doesn't that approach "lock" the CPU while reading?
Jun 14 18:55:56 * ThibG is not familiar with kernel dev
Jun 14 19:01:54 <ThibG> I'll will have a look, then
Jun 14 19:04:48 <larsc> well, the glamo reads data faster from the mmc then we can transfer data from the glamo to the main memory
Jun 14 19:05:18 <ThibG> ok
Jun 14 19:05:37 * Wonka facepalms
Jun 14 19:13:52 <ThibG> (but this function is more complex than anything else in the driver, and somehow duplicates code :()
Jun 14 19:30:15 <larsc> i think we could really increase stability and maintain throuhput if it was possible to have to request run concurrently. that way we could copy the result of one request to the main memory and at the same time let the glamo read data from the card.
Jun 14 19:30:45 <larsc> right now we copy from the card to the glamo memory and then after that is done we copy from the glamo memory to the main memory
Jun 14 19:31:08 <larsc> thats why the glamo mmc needs to run at high speeds to get a good throuhput
Jun 14 19:31:58 <larsc> on the other hand we need quite a bit of time to copy from glamo to main memory
Jun 14 19:32:48 <larsc> so in theroy the mmc clock could run much slower and we still would be able to keep the glamo<-->cpu databus busy
Jun 14 19:33:11 <ThibG> ok
Jun 14 19:33:26 <ThibG> seems like the glamo <---> cpu bandwith is quite huge :p
Jun 14 19:34:07 <larsc> no
Jun 14 19:34:18 <larsc> 7MB/s or something like that
Jun 14 19:34:24 <DocAvalanche> yep
Jun 14 19:34:32 <larsc> it's the biggest bottelneck on the freerunner
Jun 14 19:34:48 <ThibG> (it was ironic)
Jun 14 19:34:49 <DocAvalanche> and basically renders glamo worthless
Jun 14 19:35:03 <ThibG> 7MB/s huh, ok
Jun 14 19:35:32 <larsc> well thats the theory
Jun 14 19:35:43 <larsc> i could get more then 4MB/s out of it
Jun 14 19:35:49 <larsc> at least not much more
Jun 14 19:36:17 <DocAvalanche> ~glamo
Jun 14 19:36:18 <apt> i heard glamo is http://www.google.com/search?q=site%3Alists.openmoko.org+glamo+raster
Jun 14 19:36:48 <Wonka> hrm... if one could read data from mmc into glamo ram and then render that without copying it to cpu (and back!) first...
Jun 14 19:37:06 <DocAvalanche> *COULD*
Jun 14 19:37:22 <DocAvalanche> I guess that's been the idea
Jun 14 19:37:37 <H_u_m> Hi
Jun 14 19:37:41 <ThibG> Wonka, video playback?
Jun 14 19:37:52 <DocAvalanche> otherwise it's quite unclear why glamo has (unused) audio output
Jun 14 19:38:03 <Wonka> ThibG: yep
Jun 14 19:38:26 <DocAvalanche> mega obvious usecase
Jun 14 19:38:38 <DocAvalanche> alas moot for gta02
Jun 14 19:38:55 <DocAvalanche> for several reasons
Jun 14 19:39:42 <DocAvalanche> audio beinf just one of them
Jun 14 19:39:46 <H_u_m> if glamo has audio output it could have mp3 decoding in hw
Jun 14 19:39:50 <Wonka> big big fail...
Jun 14 19:40:13 <DocAvalanche> it *has* audio output - - - unconnected
Jun 14 19:40:19 <H_u_m> btw did you see http://wiki.openmoko.org/wiki/Video_Player#Some_hints_on_encoding_for_Neo
Jun 14 19:40:32 <ThibG> going back to glamo_mci_read_worker, the "from_ptr += sg->length >> 1;" looks rather suspect to me
Jun 14 19:40:54 <Wonka> yeah, decode mp3 on glamo and either output it into nonconnected pins or get even more data data to pull over the glamo<-->cpu connection...
Jun 14 19:41:00 <ThibG> what's the cause of this low bandwidth?
Jun 14 19:42:04 <larsc> ThibG: it is correct
Jun 14 19:43:15 <ThibG> larsc, if I understand well, you're copying sg->length bytes, and then, moving the pointer by only half of it...?
Jun 14 19:43:32 <larsc> ThibG: from_ptr is uint16_t
Jun 14 19:43:38 <ThibG> oh, yes, ok
Jun 14 19:43:47 <larsc> but imo it should be changed to void
Jun 14 19:43:49 <GNUtoo|laptop> H_u_m, hi you've got tips for having decent video qualiy on glamo?
Jun 14 19:43:55 <GNUtoo|laptop> such as -vo glamo
Jun 14 19:44:18 <GNUtoo|laptop> because for me when I go too far from the keyframe I've got garbage
Jun 14 19:45:13 <H_u_m> GNUtoo|laptop: maybe too many pixels, try 150k pixel or below
Jun 14 19:45:34 <GNUtoo|laptop> ok
Jun 14 19:45:37 <GNUtoo|laptop> how do I do that?
Jun 14 19:45:39 <H_u_m> try mplayer -speed 0.5 or use { or [ to slow down
Jun 14 19:46:19 <GNUtoo|laptop> 150k pixels map to a resolution?
Jun 14 19:47:08 <DocAvalanche> I seem to remeber storage corruptio issues with glamo
Jun 14 19:47:27 <Wonka> GNUtoo|laptop: you need to find some resolution with 150000 pixels or below
Jun 14 19:47:28 <H_u_m> it depends on the source video, which resolution you should choose
Jun 14 19:48:03 <DocAvalanche> which is a rather funny topic, given you got quite some dials to turn wrt ram timing etc in glamo
Jun 14 19:48:03 <GNUtoo|laptop> ok
Jun 14 19:48:21 <H_u_m> 320*240=76800 640*240=153600
Jun 14 19:48:21 <GNUtoo|laptop> I'll try 320x240
Jun 14 19:48:45 <GNUtoo|laptop> >>> 320*240
Jun 14 19:48:46 <GNUtoo|laptop> 76800
Jun 14 19:48:54 <GNUtoo|laptop> so should be ok
Jun 14 19:49:46 <H_u_m> yes, i pre-rotate when re-encoding a video
Jun 14 19:49:49 <Wonka> what http://unadventure.wordpress.com/2008/06/08/accelerating-in-my-pocket/ says maps to about 3.6M pixel per second
Jun 14 19:50:18 <H_u_m> that would be about 640*240*24
Jun 14 19:50:21 <ThibG> hm, I can't see anything wrong, then :/ (I guess sg->length can't be an odd number, unless it's the last chunk?)
Jun 14 19:51:49 <ThibG> (or can't be an odd number at all)
Jun 14 19:54:58 <larsc> it's unlikely for mmc card transfers
Jun 14 20:49:39 <CIA-59> freesmartphone.org: 03Frederik.Sdun 07msmcomm * r0c636212f8bc 10/scripts/msg-doc-to-dot.py: scripts: add small script to confert message specs into dot graphs
Jun 14 20:50:00 <playya_> oops. con_v_ert
Jun 14 21:02:20 <rohezal> hi guys I'm looking for some tutorials / dokumentation for the glamo. Anyone a link? Important points: can the glamo blit images? means you copy one image in his ram and spread over and over the background. Its very useful for sprites. And we dont have to use the 7 MB/s only one time for data transfer.
Jun 14 21:03:02 <rohezal>  Other point: can you store several images in the SD RAM of the glamo and switch fast between them? Like some pages of book. In fact I think im asking if the glamo can use multiple framebuffers. And if its true: how can you write code to use them?
Jun 14 21:04:08 <Weiss> both possible, and should be fast.. especially the former
Jun 14 21:04:36 <Weiss> for examples, take a look at http://git.bitwiz.org.uk/?p=glamo-dri-tests.git;a=tree and http://git.bitwiz.org.uk/?p=xf86-video-glamo.git;a=tree
Jun 14 21:05:17 <Weiss> (blitting is already accelerated via Xorg, but you're at the mercy of Xorg's decisions about what to move where and when, which are not always perfect (or even good..))
Jun 14 21:06:08 <CIA-59> freesmartphone.org: 03Frederik.Sdun 07utilities * r1fa86a60c074 10/palmpre/preboot/src/main.vala: preboot: use framebuffer engine
Jun 14 21:06:13 <Weiss> reading from SD and doing graphics operations without sending the data to/from the main memory is something I've been wanting to try for a long time
Jun 14 21:06:36 <Weiss> it'd require some hacky stuff in the kernel, but it's totally possible
Jun 14 21:07:23 <H_u_m> rohezal: Did you see http://wiki.openmoko.org/wiki/Smedia_Glamo_3362#Known_Features ?
Jun 14 21:08:22 <Weiss> all the above can be done by putting together example code which already exists.. but if you want more, you could find out about signing the OM NDA to get access to the datasheets - hopefully that's still possible
Jun 14 21:09:08 <rohezal> yes but i was not sure if i can believe the wiki. and i didnt find anything how to use the glamo hardware futures
Jun 14 21:09:27 <rohezal> where can I sign?
Jun 14 21:09:42 <rohezal> is it easy? need I some abilitys / certificates to do so?
Jun 14 21:10:32 <rohezal> and: are there some tutorials for writting code for the glamo? can I just use SDL? is it possible with qtopia? or QX and the qtopia kernel?
Jun 14 21:10:53 <lindi-> rohezal: it's all X
Jun 14 21:11:48 <rohezal> ok i have few expierence with graphical programming
Jun 14 21:11:54 <rohezal> mostly qt and GLut
Jun 14 21:12:07 <gena2x> rohezal: why do you need glamo?
Jun 14 21:12:08 <rohezal> using X means no SDL right?
Jun 14 21:12:16 <rohezal> 2 things: a fast book reader
Jun 14 21:12:20 <gena2x> rohezal: no
Jun 14 21:12:23 <rohezal> eyepiece is terrible slow
Jun 14 21:12:30 <gena2x> rohezal: not right
Jun 14 21:12:35 <rohezal> ohhh
Jun 14 21:12:46 <rohezal> SDL can use the glamo? cool :)
Jun 14 21:13:07 <rohezal> I want a book reader that slices a page (png) in diffrent parts. and put the parts into frame buffer of the glamo
Jun 14 21:13:08 <gena2x> rohezal: SDL can use X which can use glamo
Jun 14 21:13:17 <GNUtoo|laptop> hi, -vo glamo seem broken with 2.6.32 oe3
Jun 14 21:13:19 <rohezal> and switch between parts by just swapping the buffers
Jun 14 21:13:21 <GNUtoo|laptop> should I bugreport
Jun 14 21:13:28 <GNUtoo|laptop> or is glamo totally unsuported
Jun 14 21:13:29 <rohezal> so we dont have to push the whole image over the 7MB/s bus
Jun 14 21:13:30 <gena2x> rohezal: which distibution are you using?
Jun 14 21:13:39 <rohezal> qtmoko 28
Jun 14 21:13:50 <rohezal> and game runner 0.2
Jun 14 21:14:25 <rohezal> wait... qtmoko24 
Jun 14 21:14:27 <rohezal> i mean^^
Jun 14 21:15:02 <gena2x> rohezal: never tried reading books on neo
Jun 14 21:15:50 <gena2x> rohezal: but i _think_ slow speed of book reading can be caused not by glamo or X or SDL, but by font renderering
Jun 14 21:16:23 <gena2x> rohezal: (for example) with antialiasing which uses floating point math
Jun 14 21:16:34 <rohezal> its not a real bock
Jun 14 21:16:35 <rohezal> no ocr
Jun 14 21:16:39 <rohezal> just images in a pdf
Jun 14 21:17:04 <gena2x> rohezal: you may check that is cause of slowness
Jun 14 21:17:28 <rohezal> yes but i got several pdf in this format
Jun 14 21:17:31 <rohezal> ocr isnt possible
Jun 14 21:17:34 <gena2x> rohezal: first, compile your application with debugiing info.
Jun 14 21:17:57 <gena2x> rohezal: then run oprofile and see which part is causing slowness
Jun 14 21:18:06 <rohezal> thats the problem. i can code (doing bachelor thesis of computer science)
Jun 14 21:18:10 <rohezal> but i have no idea
Jun 14 21:18:15 <rohezal> how to code for the freerunner
Jun 14 21:18:21 <rohezal> i setted up the toolchain from the board
Jun 14 21:18:23 <lindi-> rohezal: why would freerunner be any different?
Jun 14 21:18:28 <rohezal> and compiled one application
Jun 14 21:18:32 <rohezal> it worked
Jun 14 21:18:43 <gena2x> rohezal: freerunner is absolutely similar to all other linux computers
Jun 14 21:18:48 <rohezal> but I dont know how to use the graphic card. i just know qt and GLut 
Jun 14 21:18:52 <gena2x> rohezal: no difference
Jun 14 21:18:59 <rohezal> ok
Jun 14 21:19:03 <gena2x> rohezal: in qtmoko, where is no X
Jun 14 21:19:12 <rohezal> so I can just use SDL and the SDL blit function and everything will work?
Jun 14 21:19:13 <gena2x> rohezal: only framebuffer
Jun 14 21:19:19 <rohezal> the sprites will be stored on the GPU?
Jun 14 21:19:41 <rohezal> but qtmoko has QX... maybe im wrong but i thought its some kind of x?
Jun 14 21:19:57 <gena2x> rohezal: yes, but you have to start it manually
Jun 14 21:20:40 <gena2x> rohezal: i don't know how and if SDL works on framebuffer. also i don't know if this is accelerated.
Jun 14 21:21:03 <rohezal> ok so forget about qt moko
Jun 14 21:21:18 <rohezal> I would use QX anyway if possible
Jun 14 21:21:29 <gena2x> rohezal: developing for shr is a bit less usual
Jun 14 21:21:39 <rohezal> someone knows if QX is like normal X? the vlc player works on it^^
Jun 14 21:21:57 <gena2x> rohezal: and qtmoko is based on debian, so it is a bit easier to develop and to find info.
Jun 14 21:22:33 <rohezal> well shr... i think everyone hates me for saying this but shr is too slow. probably its the 640x480 resolution but qt moko is way faster and i realy like its ergonomic
Jun 14 21:23:00 <gena2x> rohezal: shr is only slow because they do no want remove debugging info from kernel.
Jun 14 21:23:05 <rohezal> qtmoko 320x240 shr 640x480 i hoe im right^^
Jun 14 21:23:30 <gena2x> rohezal: you can use other kernel and shr will be fast
Jun 14 21:23:52 <rohezal> ohh ok
Jun 14 21:23:58 <gena2x> rohezal: both are 640x480
Jun 14 21:24:02 <rohezal> realy?
Jun 14 21:24:11 <rohezal> oh man ... 
Jun 14 21:24:19 <rohezal> thats maybe one problem...
Jun 14 21:24:25 <rohezal> i read the wiki and the mailing lists
Jun 14 21:24:35 <rohezal> but there is no central place for dokumentation
Jun 14 21:24:59 <gena2x> rohezal: where is no need in special documentation
Jun 14 21:24:59 <rohezal> maybe its me... im quite used to get everything from my teachers so i dont have to search
Jun 14 21:25:46 <rohezal> ok so the basic questions are answered: for blitting and use multiple frame buffers that are stored in the glamo ram use simply X and SDL
Jun 14 21:26:27 <rohezal> is there a memory area that is mapped to the glamo? for writing into its sd ram? or can I simply use SDL for uploading different images to its ram?
Jun 14 21:26:48 <Weiss> not entirely sure how well SDL+X accelerates stuff, but it's worth a try..
Jun 14 21:27:08 <Weiss> for getting Glamo VRAM, you can use the libdrm functions
Jun 14 21:29:03 <gena2x> rohezal: this is true, but i bet you do not need it. if you want just to try to have fast pdf rendering IMO, first try differnt viewers, second do oprofile to find out why it is slow, and then decide how to handle that slowness
Jun 14 21:29:56 <rohezal> wait VRAM?
Jun 14 21:30:07 <rohezal> it thought the chip has his own ( MB Ram
Jun 14 21:30:09 <rohezal> 8 MB
Jun 14 21:30:18 <rohezal> soldered to it and does not use the main memory
Jun 14 21:30:25 <cz_jc> I thought it was mmapped too
Jun 14 21:30:27 <ThibG> larsc, trying to install Debian with the read_worker code
Jun 14 21:30:36 <ThibG> no error so far
Jun 14 21:30:42 <Weiss> yep, I mean that 8Mb..
Jun 14 21:31:15 <rohezal> oki :I)
Jun 14 21:31:18 <rohezal> :)
Jun 14 21:31:21 <lindi-> rohezal: mupdf is a fast PDF viewer
Jun 14 21:31:35 <gena2x> without usable UI :)
Jun 14 21:31:40 <Weiss> the kernel (via DRM) manages the memory and lets you allocate blocks
Jun 14 21:31:45 <lindi-> gena2x: true
Jun 14 21:31:55 <lindi-> gena2x: but it just begs for somebody to write an UI :)
Jun 14 21:32:11 <rohezal> doesnt matter i dont need guy^^ i just need to skip pages and go to a choosen page
Jun 14 21:32:15 <rohezal> guy = gui
Jun 14 21:32:16 <rohezal> lol
Jun 14 21:32:24 <Weiss> SD is a bit harder... there's a buffer (~16K or something), and the MMC driver sends a request to read a certain block into it. then you could read it out of there
Jun 14 21:32:26 <rohezal> someone knows if QX is normal X?
Jun 14 21:32:34 <gena2x> lindi-: but can rotate your document for _any_ angle :) yeah, got idea.
Jun 14 21:33:34 <lindi-> rohezal: then mupdf is for you
Jun 14 21:33:51 <lindi-> from authors of ghostscript, written from scratch, in C
Jun 14 21:34:11 <gena2x> i think yes, but you may check this yourself, run it and do ps aux|grep X
Jun 14 21:36:04 <Weiss> rohezal: note you'll still need to render the PDF, which is slow because of FP maths..  how about some system where you pre-process a book on your desktop, and put files on SD?
Jun 14 21:36:49 <lindi-> http://iki.fi/lindi/fpdf
Jun 14 21:36:52 <gena2x> guys, just do oprofile, it is simple and kills all guesses :)
Jun 14 21:37:03 <lindi-> my solution from the age when I had a 486 laptop
Jun 14 21:37:22 <lindi-> I used zgv with svgalib instead of xzgv back then though
Jun 14 21:38:26 <gena2x> lindi-: oh, you damn old hacker. how it's pity for me that i only know about windows while i had 486, how much time were lost...
Jun 14 21:40:13 <gena2x> lindi-: with all this win3.11, nt4, win95, win96, win2000, knowledge of icons location, which expired so fast...
Jun 14 21:40:26 <rohezal> i have some pdfs that are only jpg files in a container
Jun 14 21:40:33 <rohezal> i can extract the images
Jun 14 21:41:00 <rohezal> i just want to split one image to the glamo for "scrolling"
Jun 14 21:41:11 <rohezal> because its about 1600x1200 or something
Jun 14 21:43:11 <rohezal> btw. DRM != Digital Right Management or?
Jun 14 21:43:13 <rohezal> ^^
Jun 14 21:43:29 <Weiss> Direct Rendering Manager
Jun 14 21:43:33 <rohezal> ok :)
Jun 14 21:43:48 <cz_jc> rohezal, lol I thought the same when I saw git log initially
Jun 14 21:43:57 <cz_jc> rohezal, needles to say, I got scared a bit :D
Jun 14 21:44:28 <gena2x> oh, i am still scared of 'kms'
Jun 14 21:44:40 <Weiss> so am I :)
Jun 14 21:45:18 <gena2x> because it is KERNEL mode setting
Jun 14 21:45:25 <gena2x> it is so windows...
Jun 14 21:46:42 <ThibG> ?
Jun 14 21:48:13 * Weiss wants to do more 3D work, but it distracted by modesetting stuff which never works 100%
Jun 14 21:48:17 <H_u_m> is it possible to buy a new case for neo?
Jun 14 21:48:43 <gena2x> and dbus looks like slowed, terrrible windows messages...
Jun 14 21:50:44 <cz_jc> Weiss, because when you deal with chinese products, the trivial becomes the focus.. only to get you never finishing your stuff
Jun 14 22:00:54 <gena2x> H_u_m: where should be some broken freerunners, i guess you may try to post on community ml for this.
Jun 14 22:01:12 <H_u_m> sry & thx
Jun 14 22:45:18 <ThibG> installed Debian, did not hit any error (be ware that glamo-mci is the only loaded glamo module, though)
**** ENDING LOGGING AT Tue Jun 15 02:59:57 2010