**** BEGIN LOGGING AT Tue Sep 28 02:59:57 2010
Sep 28 06:46:54 <PaulFertser> Ok, i resorted to using vala from git as it doesn't segfault. Looks like downloads.openmoko.org should be updated with that version.
Sep 28 06:47:13 <PaulFertser> And ahem compiling valac on FR is a pain, it's too RAM-hungry.
Sep 28 06:51:19 <PaulFertser> radekp: i think his jitterless idea was basically to take measurements at exactly the right time while there's no screen update going. But as we have no VSync interrupt, it was problematic. I do not remember what gena2x has invented to workaround that.
Sep 28 06:51:23 <PaulFertser> :)
Sep 28 07:10:02 <radekp> PaulFertser: ahh thanks :)
Sep 28 07:11:41 <PaulFertser> radekp: i might be wrong but that's what i remember.
Sep 28 07:11:47 <PaulFertser> Just fyi :)
Sep 28 07:13:30 <radekp> PaulFertser: anyway i am able to play freecell - so i dont consider it "serious" bug :)
Sep 28 07:46:10 <daniele_athome> morning!
Sep 28 07:49:24 <JaMa> moin
Sep 28 08:10:46 <alexxy> JaMa: ping
Sep 28 08:10:58 <alexxy> JaMa: can you add btrfs-tools to feed?
Sep 28 08:11:20 <alexxy> also seems better to use standalone module for kernel
Sep 28 08:11:26 <alexxy> instead of in kernel one
Sep 28 08:48:16 * lindi- enjoyes replying to 3-year old emails :)
Sep 28 08:48:56 <lindi->  s/enjoyes/enjoys/ even
Sep 28 09:34:03 <creeper_> hi
Sep 28 10:16:18 <[Rui]> mrmoku: need a bit of your help
Sep 28 10:16:37 <mrmoku> [Rui]: yup?
Sep 28 10:17:28 <[Rui]> I need help in order to theme a genlist, as you do that in phonelog.c maybe you can help me pinpoint the problem
Sep 28 10:18:12 <mrmoku> ok
Sep 28 10:18:43 <mrmoku> [Rui]: link to the code?
Sep 28 10:19:14 <mrmoku> or pastebin of code and edc...
Sep 28 10:20:14 <[Rui]> elmdentica, on e's/svn http://trac.enlightenment.org/e/browser/trunk/elmdentica/
Sep 28 10:20:58 <[Rui]> in the edc I copied and pasted the default genlist group from elementary, renamed it to elmdentica. it's in data/themes/default.edc
Sep 28 10:21:59 <[Rui]> in src/elmdentica.c (near the end) I have an elm_layout object, followed by the genlist creation.
Sep 28 10:22:10 <[Rui]> genlist is filled in add_status(...
Sep 28 10:24:33 <[Rui]> the result I get is a genlist with invisible content. the content appears to be there, as it has a scrollbar with enough scrolling area to cover the contents that should be visible
Sep 28 10:28:17 <mrmoku> hmm... looking
Sep 28 10:29:21 <[Rui]> I suppose I'm missing something in my code.
Sep 28 10:31:57 <[Rui]> I think that the problem is associating the new genlist style
Sep 28 10:32:18 <[Rui]> which I though was done with itc1.item_style = "elmdentica";
Sep 28 10:32:26 <[Rui]> perhaps there's more to it.
Sep 28 10:36:34 <mrmoku> [Rui]: hmm
Sep 28 10:37:55 <mrmoku> [Rui]: I guess you're missing the elm_theme_overlay_add maybe?
Sep 28 10:39:29 <[Rui]> what? didn't know that... something like elm_theme_overlay_add(NULL, "elmdentica"); ?
Sep 28 10:39:51 <mrmoku> no, point it to default.edj
Sep 28 10:40:01 <[Rui]> I suppose it's null, as it's use in libphoneui-shr uses NULL (perhaps because no theme is created on the fly?)
Sep 28 10:40:13 <[Rui]> the path... hms...
Sep 28 10:41:48 <[Rui]> mrmoku: I could kiss you! :)
Sep 28 10:41:56 <mrmoku> :)
Sep 28 10:41:57 <[Rui]> thanks!
Sep 28 10:41:59 <mrmoku> yw
Sep 28 10:42:12 <mrmoku> there is elm_theme_overlay_add and elm_theme_extension_add
Sep 28 10:42:19 <mrmoku> dunno which one you prefer
Sep 28 10:42:31 <mrmoku> IIRC one comes before the system theme
Sep 28 10:42:33 <mrmoku> and one after
Sep 28 10:42:40 <mrmoku> might not matter in your case
Sep 28 10:42:52 * mrmoku lunch
Sep 28 10:43:00 <mrmoku> [Rui]: btw. kiss your baby instead :P
Sep 28 10:43:03 <[Rui]> don't know what's the difference
Sep 28 10:43:22 <[Rui]> have a nice lunch...
Sep 28 10:43:33 <mrmoku> I think when looking for a part of a theme it first checks overlay, then the system one and last extension
Sep 28 10:43:37 <mrmoku> not very sure though
Sep 28 10:44:21 <[Rui]> well, now I have another mistery, text is condensed into a . at the left *sigh* :)
Sep 28 11:09:50 <mrmoku> [Rui]: maybe adding the correct elipsis to the text section of elm.text helps?
Sep 28 11:26:59 <daniele_athome> mrmoku, first you use extension_add to override theme
Sep 28 11:27:12 <daniele_athome> and then overlay_add to specify additional/overridden groups
Sep 28 11:27:16 <[Rui]> mrmoku: it only happens because I change it from TEXT into TEXTBLOCK
Sep 28 11:27:21 <[Rui]> mrmoku: what do you mean with elipsis?
Sep 28 11:27:32 <daniele_athome> finally, for each object you use elm_object_theme_set()
Sep 28 11:27:39 <daniele_athome> or whatever
Sep 28 11:31:07 <[Rui]> daniele_athome: so much to do?
Sep 28 11:31:37 <daniele_athome> [Rui], the extension_add needs to be called just once for each .edj file
Sep 28 11:31:53 <daniele_athome> overlay_add needs to be called once for each custom/overridden group
Sep 28 11:32:07 <daniele_athome> not so much afterall :)
Sep 28 11:32:48 <[Rui]> ok, if overlay_add is once for each custom/overridden group, why does it take edje file as argument, as mrmoku said?
Sep 28 11:33:09 <[Rui]> was it a mistake? should I use extension_add with file path, then?
Sep 28 11:36:16 <daniele_athome> [Rui], yes, extension_add is for edje files
Sep 28 11:36:20 <daniele_athome> overlay_add is for group names
Sep 28 11:36:59 <daniele_athome> [Rui], i can confirm, i'm looking at the code right now
Sep 28 11:38:28 <[Rui]> ok
Sep 28 11:39:57 <[Rui]> with extention_add and overlay_add, both with file_path as argument, I get the same results, now my changes to the group work.
Sep 28 11:40:31 <[Rui]> but since extension_add should the be the right one, I'll go with it, now to hack the group definition... shudder, so many lines of edc code
Sep 28 12:45:46 <JaMa> alexxy: why is standalone module better? ie if you plan to use it for rootfs?
Sep 28 13:13:14 <alexxy> well because in kernel implntation in 2.6.32 is buggy
Sep 28 13:13:25 <alexxy> or you need to patch kernel 
Sep 28 13:13:43 <alexxy> i.e. it cannot handle -ENOSPC
Sep 28 13:34:14 <CIA-59> SHR: 03Martin.Jansa 07shr-wizard * r18690ac56e30 10/python/shr-wizard.py: shr-wizard.py: launch shr_elm_softkey on background and move .e/e/appshadow/* to volatile before removing it
Sep 28 13:40:39 <rohezal> hi weiss
Sep 28 13:40:55 <rohezal> some guy from the xorg mailing said
Sep 28 13:40:56 <rohezal> as such though the freerunner has a stretchblit in its gfx hardware. its
Sep 28 13:40:57 <rohezal> primitive and can only do a small subset of what xrender needs.
Sep 28 13:41:08 <rohezal> it would be realy great for emulation
Sep 28 13:41:35 <rohezal> the gameboy has 160*144 pixel so it isnt useful to scale it on cpu side
Sep 28 13:41:48 <rohezal> it would be much faster to scale it on the glamo
Sep 28 13:42:21 <rohezal> the gameboy advanced has 240*160 pixel this is a factor 2 to 320*240
Sep 28 13:42:44 <anarsoul> 480x320 :)
Sep 28 13:42:53 <rohezal> it would realy speed things up if you could scale them to 480*320 and it would realy help :)
Sep 28 13:43:32 <rohezal> The technical specifications of the original Game Boy Advance are, as provided by Nintendo: Resolution: 240 × 160 pixels
Sep 28 13:43:37 <rohezal> at least wikipedia says so
Sep 28 13:43:51 <rohezal> Weiss: do you know how to use the hardware scale blit?
Sep 28 13:44:39 <Weiss> rohezal: I can look it up in the docs (later)
Sep 28 13:44:54 <rohezal> thank you :)
Sep 28 13:45:26 <rohezal> btw. I did something useful, I ported the gnuboy to the gamerunner distro. thank you for all your help you gave me :)
Sep 28 13:46:37 <Weiss> cool :D
Sep 28 17:33:06 <GarthPS> JaMa: Hi ! do you have an idea about why ti tries to fetch http://build.shr-project.org/sources/automoc_anonsvn.kde.org_.home.kde.trunk.kdesupport_1180721_.tar.gz
Sep 28 17:33:06 <GarthPS>  when my recipe said SRC_URI = "svn://anonsvn.kde.org/home/kde/trunk/kdesupport;module=automoc;proto=svn" ?
Sep 28 17:33:46 <GarthPS> of corse it gives  a 404: Not Found
Sep 28 17:33:55 <JaMa> GarthPS: that's normal way how SCM recipes work
Sep 28 17:34:09 <JaMa> GarthPS: tries distro mirror and when not found then checkout from upstream repo
Sep 28 17:34:13 <GarthPS> SCM ?
Sep 28 17:34:19 <JaMa> VCS?
Sep 28 17:34:23 <GarthPS> ah ok
Sep 28 17:34:27 <JaMa> cvs/svn/git/bzr/..
Sep 28 17:34:36 <GarthPS> yeah
Sep 28 17:42:57 <GarthPS> JaMa: what do I have to do here http://tinderbox.openembedded.org/public/logs/task/8154894.txt  ?
Sep 28 17:43:29 <GarthPS> (I am trying a custom recipe for automoc)
Sep 28 17:45:03 <Heinervdm> GarthPS: i would delete the folder in downloads/svn and try again
Sep 28 17:48:24 <GarthPS> Heinervdm, JaMa: thx! :)
Sep 28 18:06:49 <PaulFertser> Hi, can anyone tell me what's the AT commands timeout in fsogsmd nowadays?
Sep 28 18:20:25 <GarthPS> Does this have omething to do with recente Qt update ? http://tinderbox.openembedded.org/public/logs/task/8156333.txt
Sep 28 18:22:32 <JaMa> GarthPS: doesn't look like related
Sep 28 18:24:02 <GarthPS> JaMa: but with this defined in my recipe I should not have this error EXTRA_OECMAKE = "-DQT_QTCORE_INCLUDE_DIR=${OE_QMAKE_INCDIR_QT}/QtCore"
Sep 28 18:24:12 <GarthPS> no ?
Sep 28 18:26:40 <GarthPS> JaMa: forget my last phrase. this is not the right issue...
Sep 28 18:28:46 <GarthPS> it is still a bad Q_WS_X11 definition
Sep 28 18:29:31 <GarthPS> (nothing new under the sun)
Sep 28 18:35:24 <PaulFertser> Ahem
Sep 28 18:35:53 <PaulFertser> I recompiled fsogsmd and libfsotransport but well 120s timeout is still there, is it right?
Sep 28 18:52:14 * GarthPS again few hours lost with this crap automoc-native...
Sep 28 18:57:51 <JaMa> something is eating binaries on my uSD :/ first Xorg was gone now vim...
Sep 28 18:59:32 <PaulFertser> Ctulhu ftagn
Sep 28 18:59:47 <Heinervdm> PaulFertser: the timeout when closing GSM?
Sep 28 19:01:09 <PaulFertser> Heinervdm: the timeout for any command
Sep 28 19:01:18 <PaulFertser> 2010-09-28T15:59:33.455676Z [DEBUG] libfsotransport <0710:2>: Wrote '+CGREG?'. Waiting (120s) for answer...
Sep 28 19:01:22 <PaulFertser> etc
Sep 28 19:01:38 <Heinervdm> hmm, no idea
Sep 28 19:01:59 <PaulFertser> I was promised the GSM would work reliably and it still doesn't.
Sep 28 19:02:00 <Heinervdm> but it look like mickey has a long todo when he returns
Sep 28 19:02:08 <PaulFertser> A single stupid timeout ruins everything
Sep 28 19:02:26 <Heinervdm> a normal call is working for me in SHR
Sep 28 19:02:27 <PaulFertser> And moreover sometimes i have to restart everything (the easiest is to stop dbus first, then start all over).
Sep 28 19:02:48 <PaulFertser> That happens mostly if i get a timeout during RESUME :|
Sep 28 19:03:17 <JaMa> Heinervdm: btw have you found something about that issue with shortening numbers when importing contacts from SIM?
Sep 28 19:03:20 <PaulFertser> Heinervdm: it works for me too. But that's my only cell phone and so it receives enough testing and suspend/resume cycles for some strange odd creepy things to surface.
Sep 28 19:03:34 <JaMa> Heinervdm: I've rsynced that shr-t test to feed so maybe someone will ask soon
Sep 28 19:03:41 <Heinervdm> JaMa: there was no such an issue
Sep 28 19:03:52 <Heinervdm> JaMa: the error was nokia
Sep 28 19:04:03 <JaMa> Heinervdm: but because it happens only with special chars I don't see as show stopper, ah :/
Sep 28 19:04:41 <JaMa> Heinervdm: can you post an reply to that thread just in case?
Sep 28 19:04:57 <Heinervdm> JaMa: hmm, i don't remeber the details anymore
Sep 28 19:05:04 <JaMa> http://lists.openmoko.org/nabble.html#nabble-td5307993
Sep 28 19:05:25 <JaMa> or [Rui] ^^
Sep 28 19:05:33 <[Rui]> hu ?
Sep 28 19:06:11 <JaMa> [Rui]: IIRC you had that issue, or no?
Sep 28 19:06:42 <[Rui]> yes, neither close, and sometimes neither forward... I'd had to press back until it couldn't, and then forward again.
Sep 28 19:06:43 <Serdar> hi guys
Sep 28 19:06:49 <[Rui]> after a random number of times, it proceedeed
Sep 28 19:07:12 <Serdar> what do you guys think about the name: hackable mobile devices?
Sep 28 19:07:26 <Serdar> I will register it the next days
Sep 28 19:07:29 <[Rui]> awesome, I love it :)
Sep 28 19:07:32 <JaMa> Serdar: good name
Sep 28 19:08:05 <Serdar> nobody rosponded to my mail except nikolaus
Sep 28 19:08:09 <[Rui]> Now N900 is a likely viable alternative for SHR I'm considering buying one... I don't know.
Sep 28 19:08:30 <Heinervdm> Serdar: i think that name would be fine
Sep 28 19:08:31 <Serdar> Rui: for N900 look at nitdroid
Sep 28 19:09:05 <[Rui]> Serdar: don't like Android way of doing things :(
Sep 28 19:09:27 <[Rui]> I guess what I want is a really portable netbook which can make calls :)
Sep 28 19:09:42 <[Rui]> Android is really all about getting a fancy phone. not for me anymore :)
Sep 28 19:10:34 <Serdar> portable netbook?
Sep 28 19:10:42 <Serdar> what's with openpandora?
Sep 28 19:10:53 <Serdar> I've seen one on GamesCom this year
Sep 28 19:31:35 <mrmoku> Serdar: but that one is missing GSM, no?
Sep 28 19:32:14 <Serdar> yes
Sep 28 19:33:12 <Serdar> that's correct
Sep 28 20:35:02 <rohezal> Weiss: found something aboutthe strech blit operation?
Sep 28 22:02:00 <Weiss> rohezal: 2D engine has stretch capability.. got the doc in front of me now
Sep 28 22:02:08 <rohezal> YES
Sep 28 22:02:11 <Weiss> it's a similar command sequence to what we have already for the 2D blit
Sep 28 22:02:16 <rohezal> the first good news today
Sep 28 22:02:24 <rohezal> girlfriend was in hospital today
Sep 28 22:02:27 <Weiss> :o
Sep 28 22:02:33 <rohezal> the fukcing server is a nightmare
Sep 28 22:02:38 <rohezal> well she is a hard guy
Sep 28 22:02:45 <rohezal> went out of the hospital after one hour
Sep 28 22:02:48 <rohezal> or something
Sep 28 22:02:53 <rohezal> and drove her mom to work
Sep 28 22:03:09 <rohezal> the doctors shouted she should stay but hey, shes a hard guy ;)
Sep 28 22:04:09 <rohezal> it's a similar command sequence to what we have already for the 2D blit
Sep 28 22:04:17 <rohezal> back to topic: how can i use it^^?
Sep 28 22:05:23 <Weiss> do you follow how the 2D blit works?
Sep 28 22:07:36 <rohezal> hmm
Sep 28 22:07:44 <rohezal> only from userland
Sep 28 22:07:51 <rohezal> xcopyarea from xlib
Sep 28 22:08:13 <rohezal> for transparent blitting using different graphic context with xor and nand
Sep 28 22:08:22 <rohezal> but i dont know the hardware side
Sep 28 22:09:21 <Weiss> it seems to be the same as a 2D blit except: 1. put 0x4 in _COMMAND3; 2. put source rectangle width/height in _PAT_FG and _PAT_BG respectively; 3. put some "error terms" in _SRC_FG to _MASK4 (six values). the meanings of these values are not specified here..
Sep 28 22:09:37 <Weiss> referring to glamo-regs.h and glamo-kms-exa.c in xf86-video-glamo
Sep 28 22:14:15 <rohezal> hmmm
Sep 28 22:14:21 <rohezal> ok i dont know if i can do it
Sep 28 22:14:31 <rohezal> i can write c but i dont have experience with asm
Sep 28 22:14:45 <rohezal> and never worked on a driver
Sep 28 22:14:48 <rohezal> hard stuff
Sep 28 22:14:49 <rohezal> hmmmm
Sep 28 22:15:04 <Weiss> there's no asm involved - the DRM kernel already takes care of talking to the hardware
Sep 28 22:15:12 <Weiss> you just need to give it the right command sequence
Sep 28 22:15:48 <Weiss> more pain is probably involved in getting X to cooperate with your command sequence (that's where DRI comes in)
Sep 28 22:16:01 <rohezal> wow
Sep 28 22:16:05 <Weiss> or you could do it with the X server shut down, which is slightly easier
Sep 28 22:16:17 <rohezal> oh god
Sep 28 22:16:27 <rohezal> well the software i would like to use
Sep 28 22:16:30 <rohezal> is sdl based
Sep 28 22:16:37 <rohezal> so it need X i think
Sep 28 22:17:44 <rohezal> so the needed steps are: 
Sep 28 22:18:21 <rohezal> write the commands for gpu in the drm file
Sep 28 22:18:32 <rohezal> then tell X via DRI how to use the commands
Sep 28 22:19:02 <rohezal> wait isnt there a problem?
Sep 28 22:19:16 <rohezal> i mean there is no X command for scaling
Sep 28 22:19:31 <rohezal> hmmm ok
Sep 28 22:19:45 <rohezal> is it possible to use a custom command and run x simultany
Sep 28 22:20:18 <rohezal> i would like to do this: after the frame is rendered in low resolution, push it to the gpu and scale it
Sep 28 22:20:27 <rohezal> the frame is in a known location in the ram
Sep 28 22:20:53 <rohezal> can X run during this time, since the gamerunner distro starts X?
Sep 28 22:21:00 <rohezal> at startup
Sep 28 22:23:14 <Weiss> rohezal: http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html might help
Sep 28 22:23:30 <rohezal> ok :)
Sep 28 22:23:38 <rohezal> thx im a total noob in this area
Sep 28 22:23:59 <Weiss> with DRI, you use an X protocol extension to get the kernel's handle for a pixmap, then you send rendering commands which reference that handle to the kernel, which sanitises the commands then sends them to the GPU
Sep 28 22:24:42 <Weiss> without X, you wouldn't need to ask X for that handle because it would have belonged to you all the time. you would probably have asked the kernel at some point to use a certain pixmap for the screen
Sep 28 22:24:47 * Weiss zzz... more tomorrow
Sep 28 22:35:01 <rohezal> good night weiss :)
Sep 28 22:36:31 <rohezal> but hey thats great, i just push an pixmap to the screen, ask x for the handle and modify the pixmap via dri... but when x uses it again will x know what changed? does the kernel tell x the image is the double size?
**** ENDING LOGGING AT Wed Sep 29 02:59:57 2010