**** BEGIN LOGGING AT Wed Nov 28 02:59:59 2012
Nov 28 11:33:45 <slyon> GNUtoo-desktop, hey!
Nov 28 11:33:51 <slyon> GNUtoo-desktop, you got my mail?
Nov 28 11:34:37 <slyon> GNUtoo-desktop, it works for me now
Nov 28 11:36:55 <GNUtoo-desktop> slyon, ah?
Nov 28 11:37:07 <GNUtoo-desktop> how?
Nov 28 11:37:17 <GNUtoo-desktop> because I was still trying to make it works
Nov 28 11:37:26 <GNUtoo-desktop> and I even asked in #vala some minutes ago
Nov 28 11:37:32 <GNUtoo-desktop> like 1 min ago
Nov 28 11:37:38 <slyon> I've asked in vala as well. but got no response
Nov 28 11:37:45 <slyon> but is doesn't seem to be a vala problem
Nov 28 11:37:53 <slyon> basically we have 2 instances of Gta04.RouterAlsa
Nov 28 11:38:16 <GNUtoo-desktop> one per card?
Nov 28 11:38:19 <slyon> i guess once comes from gta04_quirks/plugin.vala and the other one from audio/plugin.vala
Nov 28 11:38:22 <slyon> no
Nov 28 11:38:33 <GNUtoo-desktop> ok
Nov 28 11:38:48 <slyon> 1st one is initialized correctly
Nov 28 11:38:51 <slyon> 2nd one not
Nov 28 11:38:55 <slyon> but 2nd one is used
Nov 28 11:39:03 <slyon> therefore all variables are NULL
Nov 28 11:39:19 <GNUtoo-desktop> ok
Nov 28 11:39:23 <slyon> now i've made the variables static, so they get initialized by 1st instance and can be used by the 2nd
Nov 28 11:39:50 <GNUtoo-desktop> ok
Nov 28 11:40:52 <GNUtoo-desktop> slyon, then we could do that:
Nov 28 11:41:04 <GNUtoo-desktop> add a config for audio/plugin.vala
Nov 28 11:41:12 <GNUtoo-desktop> that says to load it or not
Nov 28 11:41:17 <GNUtoo-desktop> like for gta02
Nov 28 11:41:26 <GNUtoo-desktop> gta02 has a resource plugin
Nov 28 11:41:30 <GNUtoo-desktop> whth exactly that
Nov 28 11:41:34 <GNUtoo-desktop> *with
Nov 28 11:42:08 <morphis> heyho boys
Nov 28 11:42:32 <GNUtoo-desktop> [fsodevice.openmoko_powercontrol]
Nov 28 11:42:32 <GNUtoo-desktop> ignore_wifi = true
Nov 28 11:42:34 <morphis> slyon: saw your code for Gta04.RouterAlsa recently
Nov 28 11:42:35 <GNUtoo-desktop> hi
Nov 28 11:42:42 <morphis> why this code duplication?
Nov 28 11:43:04 <slyon> hey morphis 
Nov 28 11:43:18 <GNUtoo-desktop> because you weren't available on IRC, he tried to detect the GTA04 A3/A4 this way
Nov 28 11:43:29 <slyon> morphis, i duplicated the code, because i didn't want to hack gta04 stuff into router_alsa
Nov 28 11:43:54 <GNUtoo-desktop> in other words we had no other ideas
Nov 28 11:44:13 <GNUtoo-desktop> I think he tried but failed at overriding stuff
Nov 28 11:44:16 <morphis> yeah, but wasn't the only thing you needed to pass an different path to the scenarios?
Nov 28 11:44:21 <slyon> morphis, you said it's not possible to inherit from another plugin, so i had to copy it
Nov 28 11:44:24 <GNUtoo-desktop> yes it is
Nov 28 11:44:32 <GNUtoo-desktop> oops 
Nov 28 11:44:35 <slyon> yes
Nov 28 11:44:41 <morphis> slyon: ok, we have a new problem here that be have different types of the same device
Nov 28 11:44:43 <GNUtoo-desktop> I meant:
Nov 28 11:44:46 <GNUtoo-desktop> morphis, yes it is
Nov 28 11:45:00 <morphis> slyon: but the only thing is that you need to path another path for the scenarios?
Nov 28 11:45:09 <morphis> s/to path/to pass/
Nov 28 11:45:10 <apt> morphis meant: slyon: but the only thing is that you need to pass another path for the scenarios?
Nov 28 11:45:11 <GNUtoo-desktop> morphis, not only
Nov 28 11:45:19 <slyon> morphis, yes path to scenarios AND path to alsa.conf
Nov 28 11:45:26 <GNUtoo-desktop> morphis, we need to detect A3 and if A3 is detected, to pass the path
Nov 28 11:45:35 <morphis> ok, that should be done this way
Nov 28 11:45:39 <GNUtoo-desktop> else to pass another path
Nov 28 11:45:50 <morphis> let me explain what I am thinking about
Nov 28 11:45:53 <GNUtoo-desktop> ok
Nov 28 11:46:13 <morphis> you need some small plugin only for the device detection
Nov 28 11:46:24 <morphis> it should be a loaded first by fsodeviced
Nov 28 11:46:39 <slyon> it's already there: gta04_quirks/info
Nov 28 11:46:43 <morphis> ok
Nov 28 11:46:57 <morphis> you have to load it before the router plugin
Nov 28 11:47:04 <slyon> jep
Nov 28 11:47:12 <GNUtoo-desktop> (and it's even already used by libhoneui)
Nov 28 11:47:59 <morphis> the deviced detection plugin then detects the type and then uses FsoFramework.DataSharing.setValueForKey("model", "gta04a3") to store the device model
Nov 28 11:48:43 <morphis> then we will add model specific config options
Nov 28 11:48:57 <morphis> like [fsodevice.router_alsa@gta04a3]
Nov 28 11:49:09 <morphis> which then sets the correct path
Nov 28 11:49:56 <morphis> this only needs adjustments to the SmartKeyFile class
Nov 28 11:50:14 <morphis> to look for a model specific override
Nov 28 11:50:41 <morphis> you can can have [fsodevice.router_alsa] for general things and [fsodevice.router_alsa@gta04a3] for specific
Nov 28 11:50:50 <slyon> morphis, that sounds nice
Nov 28 11:50:59 <GNUtoo-desktop> yes, a bit like I did for the libphoneu
Nov 28 11:51:03 <slyon> yes
Nov 28 11:51:13 <GNUtoo-desktop> only that we used _ instead of @
Nov 28 11:51:23 <slyon> but then we'd still need my work in slyon/gta04-hwrouting
Nov 28 11:51:38 <slyon> to have extra_path variable in router_alsa
Nov 28 11:51:50 <slyon> but thats only a small and generic change
Nov 28 11:52:28 <morphis> yes
Nov 28 11:52:58 <GNUtoo-desktop> should I change _ to @ in libphone-ui?
Nov 28 11:53:00 <morphis> you need to adust all the stringValue/... methods in FsoFramework.SmartkeyFile class to take the model into account
Nov 28 11:53:17 <morphis> GNUtoo-desktop: yes, it separates more cleanly from plugin name
Nov 28 11:53:24 <GNUtoo-desktop> ok
Nov 28 11:55:19 <morphis> slyon: can you do this?
Nov 28 11:55:52 <slyon> morphis, i think so
Nov 28 11:55:59 <morphis> ok, that would be great
Nov 28 11:56:10 <slyon> morphis, but there is only one stringValue method in SmartKeyFile
Nov 28 11:56:26 <slyon> ah it's *Value
Nov 28 11:56:28 <morphis> slyon: yes, but you have to implement it for doubleValue etc. as well
Nov 28 11:56:31 <morphis> yes
Nov 28 11:57:39 <slyon> morphis, and how can i then access "model"?
Nov 28 11:57:49 <slyon> after setting it by setValueForKey("model", "gta04a3")
Nov 28 11:58:22 <morphis> with valueForKey("model")
Nov 28 12:00:35 <slyon> ok. i'll have to look into it in detail
Nov 28 12:00:42 <slyon> but i think i got the glue
Nov 28 12:01:06 <morphis> it's just a wrapper around a static hashtable
Nov 28 12:02:33 <slyon> ok. i don't really see what i have to change in stringValue/...
Nov 28 12:02:46 <slyon> they seem to be pretty generic. how do i have to integrate it with "model"?
Nov 28 12:06:51 <slyon> morphis, ok... I've to check if "model" is set in stringValue/... and if it's set i have to read section@model instead of section. Right?
Nov 28 12:10:14 <slyon> but what to do with e.g. hasSection
Nov 28 12:10:35 <slyon> probably look for section@model as well..
Nov 28 12:17:35 <morphis> slyon: whenever you try to retrieve a value you should wether there is a overring section with this value, when it is  then you take the override
Nov 28 12:18:31 <slyon> morphis, alright.
Nov 28 12:18:49 <slyon> thanks
Nov 28 12:18:56 <slyon> this looks really clean
Nov 28 12:19:19 <morphis> :)
Nov 28 12:45:59 <JaMa> slyon: morphis: wrt ARM tunes.. what about (3), it's the same as old feed without any increased build time
Nov 28 12:47:14 <morphis> JaMa: didn't you say that the patch was rejected as it was to complicate?
Nov 28 12:53:16 <JaMa> that's (4) IIRC
Nov 28 12:53:53 <JaMa> yes (3) is like (2) just with cortexa8 used for tuna as it is now
Nov 28 12:56:36 <morphis> hm so we would still use cortexa8 feeds for tuna
Nov 28 12:56:44 <morphis> and not cortexa9?
Nov 28 12:57:11 <JaMa> until now we were building armv7a-vfp-neon with -mtune=cortexa8 for tuna
Nov 28 12:57:14 <slyon> JaMa, basically i don't care about tuna... but the idea of OE is to have device specific optimizations, which we would throw away in this case for tuna
Nov 28 12:57:27 <JaMa> with this fixed we can build different feed for tuna and rest
Nov 28 12:57:39 <JaMa> so it's possible to change that tune include in tuna.conf
Nov 28 13:01:05 <morphis> I would like to get the best performance as possible so we should build for tuna as cortexa9
Nov 28 13:01:14 <morphis> but I doubt  if it's worth for SHR to care about tuna at all
Nov 28 13:02:32 <JaMa> ok, I'll update tuna include in tuna.conf and selection of DEFAULTTUNE needs to be distro decision, so we can use cortexa8 for all machines in shr.conf and cortexa9 for tuna for webos
Nov 28 13:03:38 <morphis> yes
Nov 28 13:03:48 <morphis> do we build for tuna in SHR atm?
Nov 28 13:04:03 <JaMa> ah no.. not possible because tune-cortexa9 does not include tune-cortexa8 so it wont understand cortexa8 if I replace included tune-*
Nov 28 13:04:11 <JaMa> but I can probably include both tune-cortex*
Nov 28 13:04:19 <JaMa> morphis: yes we do
Nov 28 13:06:11 <morphis> JaMa: doesn't including both mess up the tune flags?
Nov 28 13:06:27 <morphis> JaMa: maybe we should drop building tuna to get some power and disk space for other machines
Nov 28 13:06:39 <morphis> as I doubt anybody really has interest in tuna for SHR
Nov 28 13:06:43 <morphis> GNUtoo-desktop: ^^?
Nov 28 13:07:43 <slyon> JaMa, btw: was there any specific reason the add root=... back to the GTA04 cmdline?
Nov 28 13:08:08 <slyon> as with this we can only boot from partition 2. so it should come from uboot to stay flexible
Nov 28 13:35:07 <JaMa> slyon: CMDLINE from recipe always wins.. I've just merged CMDLINE from recipe to defconfig
Nov 28 13:35:22 <JaMa> slyon: so if you use bitbake -c savedefconfig it should result in the same defconfig
Nov 28 13:35:44 <slyon> JaMa, so i have to remove it from recipe and defconfig?
Nov 28 13:36:49 <JaMa> morphis: shouldn't mess up flags, just adds more available DEFAULTTUNE settings only tricky part is conf/machine/include/arm/arch-armv7a.inc included twice, but that could work
Nov 28 13:36:52 <slyon> (but actually i tested it and it worked... so it seems to have taken my cmdline)
Nov 28 13:37:16 <JaMa> slyon: you can check defconfig (and .config) used in kernel build after -c configure
Nov 28 13:37:23 <JaMa> it will have CMDLINE from recipe
Nov 28 13:39:00 <slyon> JaMa, ok. but anyway we need to remove root=... eitherway. are you OK with that?
Nov 28 13:40:26 <JaMa> slyon: yes
Nov 28 13:42:33 <slyon> ok
Nov 28 14:09:28 <GNUtoo-desktop> morphis, hi
Nov 28 14:10:24 <GNUtoo-desktop> morphis, maybe I'll do tuna, but later
Nov 28 14:10:57 <GNUtoo-desktop> currently I'm in favor of droping it in the buildhost until it get better supported
Nov 28 14:12:55 <JaMa> buildhost is not affected
Nov 28 14:13:09 <JaMa> buildhost is building "danny"
Nov 28 14:13:11 <GNUtoo-desktop> ah yes I remember
Nov 28 14:13:17 <GNUtoo-desktop> let me refrase:
Nov 28 14:13:39 <GNUtoo-desktop> currently I'm in favor of droping it in the buildhost, when it will be on non-danny branch, until it get better supported
Nov 28 14:14:18 <JaMa> why not keep it with cortexa8 DEFAULTTUNE?
Nov 28 14:14:29 <JaMa> even on non-danny branch?
Nov 28 14:14:43 <GNUtoo-desktop> less performance
Nov 28 14:14:58 <GNUtoo-desktop> less the-oe-way
Nov 28 14:16:46 <JaMa> I've image built without any -mtune and I don't see any difference peformance wise
Nov 28 14:18:51 <GNUtoo-desktop> ok
Nov 28 14:19:05 <GNUtoo-desktop> even with mplayer
Nov 28 14:19:06 <GNUtoo-desktop> ?
Nov 28 14:23:07 <JaMa> haven't tested mplayer
Nov 28 14:24:01 <slyon> GNUtoo-desktop, slyon/gta04-hwrouting should be working now. but i cant test on device, as i've to leave for university. bye!
Nov 28 14:24:44 <slyon> morphis, maybe you can review what i did in slyon/gta04-hwrouting and send me feedback by mail?
Nov 28 14:24:54 <morphis> slyon: yes, will do
Nov 28 14:25:00 <slyon> thanks, bye!
Nov 28 16:03:24 <JaMa> morphis: hmm including arm-armv7a.inc twice breaks stuff :/
Nov 28 19:12:18 <paulk-desktop> is there any 3.0 kernel for gta04 ?
Nov 28 19:19:17 <GNUtoo-x60> paulk-desktop, hi, why do you want 3.0?
Nov 28 19:19:25 <paulk-desktop> GNUtoo-x60, hi
Nov 28 19:19:48 <paulk-desktop> basically because Android is a lot kernel-dependent
Nov 28 19:20:02 <paulk-desktop> I tried 3.4 with ICS and I have endless errors
Nov 28 19:20:10 <GNUtoo-x60> ah ok
Nov 28 19:20:13 <paulk-desktop> for ICS, it should be 3.0
Nov 28 19:20:20 <paulk-desktop> and there is even an omap3 android tree
Nov 28 19:21:39 <paulk-desktop> so I'm wondering how big the gta04 changes are
Nov 28 19:21:52 <paulk-desktop> because maybe it would be easier to just backport gta04 stuff
Nov 28 19:22:15 <GNUtoo-x60> possible
Nov 28 19:22:21 <GNUtoo-x60> paulk-desktop, you have serial?
Nov 28 19:22:24 <paulk-desktop> yes
Nov 28 19:23:05 <GNUtoo-x60> ok
Nov 28 19:23:35 <GNUtoo-x60> the problem is that the changes get smaller with the higher revisions
Nov 28 19:23:40 <GNUtoo-x60> because some stuff is merged
Nov 28 19:24:15 <paulk-desktop> I'll take 3.2
Nov 28 19:24:26 <paulk-desktop> and look from the commit introducing gta04 support
Nov 28 19:24:44 <GNUtoo-x60> ok
Nov 28 19:25:12 <GNUtoo-x60> I think the board file is not sufficent to get it wokring fully
Nov 28 19:25:27 <GNUtoo-x60> even if you count alsa board files as board files
Nov 28 19:25:56 <GNUtoo-x60> what about bumping android version?
Nov 28 19:26:17 <GNUtoo-x60> at what revision is the last Stable CM?
Nov 28 19:26:47 <GNUtoo-x60> btw the endless errors are with what exactly?
Nov 28 19:27:02 <GNUtoo-x60> because it worked fine with recent kernel and replicant 2.3
Nov 28 19:27:45 <paulk-desktop> GNUtoo-x60, no it didn't work fine
Nov 28 19:27:56 <paulk-desktop> suspend/resume was totally broken
Nov 28 19:28:34 <GNUtoo-x60> ok, but I already pointed you to the .c file that controls that
Nov 28 19:28:36 <GNUtoo-x60> is there more?
Nov 28 19:28:42 <GNUtoo-x60> like in framework etc...
Nov 28 19:28:59 <GNUtoo-x60> by suspend-resume you mean the resume to GUI
Nov 28 19:28:59 <GNUtoo-x60> ?
Nov 28 19:29:07 <GNUtoo-x60> because if so android is a bit strange
Nov 28 19:29:22 <paulk-desktop> yes
Nov 28 19:29:38 <GNUtoo-x60> there is a kernel<->userspace for that
Nov 28 19:29:53 <GNUtoo-x60> there are usually 3 options in the kernel:
Nov 28 19:29:57 <GNUtoo-x60> -> do nothing
Nov 28 19:30:02 <GNUtoo-x60> -> chvt in-kenrel
Nov 28 19:30:08 <GNUtoo-x60> -> sysfs interface
Nov 28 19:30:15 <GNUtoo-x60> for earlysuspend screen access
Nov 28 19:30:18 <GNUtoo-x60> or something like that
Nov 28 19:30:29 <GNUtoo-x60> it should be documented in SHR porting guide I think
Nov 28 19:30:35 <GNUtoo-x60> let me find it
Nov 28 19:35:21 <GNUtoo-x60> paulk-desktop, ./kernel/power/Kconfig:	config NO_USER_SPACE_SCREEN_ACCESS_CONTROL
Nov 28 19:36:05 <GNUtoo-x60> maybe look there
Nov 28 19:36:17 <paulk-desktop> ok
Nov 28 19:37:06 <GNUtoo-x60> paulk-desktop, inside an android kernel like tuna for instance
Nov 28 19:42:07 <GNUtoo-hplaptop> paulk-desktop, also note that that the sysfs interface is usually used on android
Nov 28 19:44:39 <paulk-desktop> ok
Nov 29 00:06:05 <DocScrutinizer05> suspend/resume with OMAP? sounds like a broken-by-design concept
Nov 29 00:07:48 <DocScrutinizer05> suspend/resume with android sounds fishy as well, I don't think any android device is doing that
Nov 29 00:08:32 <DocScrutinizer05> actually the whole suspend idea was a botch needed due to the fact that S3C24xx did no proper zeroclock
Nov 29 00:09:54 <DocScrutinizer05> and it created some nasty problems with switching unsolicited messages from modem and wake-from-inbound-call
Nov 29 00:10:08 <DocScrutinizer05> in gta02
**** ENDING LOGGING AT Thu Nov 29 02:59:59 2012