**** BEGIN LOGGING AT Thu Jun 07 02:59:59 2012 Jun 07 08:46:34 hi . e17/edbus connman are not compatible with connman >= 0.79 . SHR ships 0.79 . is there a rationale ? Jun 07 08:47:30 also I found I had to set Wifi to enabled inn ./var/Lib/connman/settings otherwise connman would deactivate the wifi under the hood (even when reenabled by another mean) Jun 07 08:47:43 prahal: seems like like someone updated connman but doesn't look at the needed version bei e17/edbus Jun 07 08:48:11 prahal: but connman is still as delivered by OpenEmbedded, no real integration in SHR is done yet Jun 07 08:48:24 so it can be true that you have to manual adjust some settings to get it working Jun 07 08:49:22 prahal: but it would be really great if you can provide patches to get it integrated well Jun 07 08:55:39 there are even patches to upgrade connman to 1.0 in oe-core Jun 07 08:59:35 yeah so maybe the e-guys have to catch up with connman API as at least 1.0 should have a stable (not changing) API Jun 07 09:00:05 prahal: if you have done some work to get connman working in SHR please let us know Jun 07 09:01:14 JaMa: hm, your image from yesterday gives me: "Failed to start LSB: Raise network interfaces. [FAILED]" Jun 07 09:01:38 and a "Failed to start Load Kernel Modules [FAILED]" Jun 07 09:01:59 maybe I should switch to sdcard to avoid huge flashing times Jun 07 09:03:38 current e_dbus from HEAD still supports only econnman0_7x and I don't plan another EFL bump soon, do we really need connman support from e_dbus? Jun 07 09:04:13 morphis: ah you need to flash also kernel from that site Jun 07 09:04:22 morphis: it's 3.2 Jun 07 09:04:40 morphis: if you've used default kernel from buildhost then it won't find modules in rootfs Jun 07 09:04:49 ok Jun 07 09:05:11 and could cause also that network interfaces.. as g_ether wasn't loaded Jun 07 09:05:16 ok Jun 07 09:05:18 I have to leave Jun 07 09:05:21 will try that later Jun 07 09:05:22 bye Jun 07 10:56:20 moinmoin folks Jun 07 11:05:19 freesmartphone.org: 03GNUtoo 07gnutoo/n900-alsa-scenarios-rework * r1624d2fb7ae7 10cornucopia/fsoaudiod/conf/nokia_n900/fsoaudiod.conf: Jun 07 11:05:19 freesmartphone.org: fsoaudiod: switch to fsodeviced scenario handling Jun 07 11:05:19 freesmartphone.org: The fsodeviced API is the one in use for switching scenario. Jun 07 11:05:19 freesmartphone.org: And the fsoaudiod one is incompatible... Jun 07 11:05:19 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 07 11:05:20 freesmartphone.org: 03GNUtoo 07gnutoo/n900-alsa-scenarios-rework * rb369cd013e59 10cornucopia/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): (log message trimmed) Jun 07 11:05:20 freesmartphone.org: fsodeviced: fix n900 scenario Jun 07 11:05:20 freesmartphone.org: Alsa control number and names changed with the last kernel change Jun 07 11:05:21 freesmartphone.org: and the scenarios weren't updated accordinly. Jun 07 11:05:21 freesmartphone.org: TODO: Jun 07 11:05:22 freesmartphone.org: * Microphone handling Jun 07 11:05:22 freesmartphone.org: * The volume must be checked. Jun 07 11:19:31 freesmartphone.org: 03GNUtoo 07gnutoo/n900-alsa-scenarios-rework * r47edc98ad518 10cornucopia/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): (log message trimmed) Jun 07 11:19:31 freesmartphone.org: fsodeviced: fix n900 scenario Jun 07 11:19:31 freesmartphone.org: Alsa control number and names changed with the last kernel change Jun 07 11:19:31 freesmartphone.org: and the scenarios weren't updated accordinly. Jun 07 11:19:32 freesmartphone.org: TODO: Jun 07 11:19:32 freesmartphone.org: * Microphone handling Jun 07 11:19:33 freesmartphone.org: * The volume must be checked. Jun 07 11:21:02 mrmoku, hi Jun 07 11:21:10 what does heatset means: Jun 07 11:21:22 headphone + microphone of the phone Jun 07 11:21:24 or: Jun 07 11:21:44 a real headset with an integrated microphone Jun 07 11:22:06 s/heatset/headset/g Jun 07 11:26:58 GNUtoo-desktop: what do you mean by "a real headset"? Usually headset are external headphones+mic, and handset is the integrated phone plus integrated mic. Jun 07 11:27:09 ok Jun 07 11:27:26 I'm making n900 scenarios Jun 07 11:27:32 *audio scenarios Jun 07 11:27:38 and there is a scenario named headset Jun 07 11:28:19 since the n900 supports both ways, I wondered what to add there Jun 07 11:28:28 GNUtoo-desktop: afaict that's an external one. Jun 07 11:28:43 because you can put dumb headphones Jun 07 11:28:47 and use the internal mic Jun 07 11:28:58 or put a real nokia headset with integrated mic Jun 07 11:29:25 GNUtoo-desktop: the internal is called handset (as you hold it with your hand). I do not think we ever used a scenario where the external headphones were used with an internal mic, so we do not have a name for it. Jun 07 11:29:41 ahh ok Jun 07 11:29:54 then I guess I should extend SHR for that Jun 07 11:29:58 to add a new name Jun 07 11:30:03 and the detection of it Jun 07 11:30:21 but for now I think using internal mic even with real headset is safer Jun 07 11:30:34 since it work for both Jun 07 11:31:12 no Jun 07 11:32:24 user expectations are to use the headset mic when any is there. after all you're carrying the device in your pocket or anywhere, wehn using headset. Nobody will hold the device internal mic next to mouth when using a headset Jun 07 11:33:02 ok Jun 07 11:33:10 but we don't have a working forwarder anyway Jun 07 11:33:17 I must talk to the only user I guess Jun 07 11:33:54 alas headset mic is particularly affected by buzz Jun 07 11:34:09 on gta02 Jun 07 11:34:15 it's for n900 Jun 07 11:39:58 OT: ( PaulFertser?) what's defined as "context switch" in linux? Jun 07 11:41:09 (technically) Jun 07 11:42:18 maybe even s/in linux/on $arch/ Jun 07 11:42:23 ? Jun 07 11:43:24 meh, probably I should google Jun 07 11:44:10 guess I'll find out it means "loading new lookup tables to memory mapping" Jun 07 11:47:37 hmm http://en.wikipedia.org/wiki/Context_switch Jun 07 11:47:49 should've known Jun 07 11:48:11 DocScrutinizer05, on n900 is there is no control for having a mic that capture far enough? Jun 07 11:48:32 GNUtoo-desktop: please rephrase Jun 07 11:48:37 ok Jun 07 11:49:33 if you use headphones on some phones, the mic control is made such as it can capture your voice even if you're a bit far from the phone Jun 07 11:49:44 like not 1mm Jun 07 11:49:54 that's probably AGC Jun 07 11:49:54 but rather some centimeters to a meter Jun 07 11:49:57 ok Jun 07 11:50:33 usually the modem should do AGC internally Jun 07 11:50:50 ok Jun 07 11:50:53 (Automatic Gain Control) Jun 07 11:51:12 yes I know it's automatic gain control Jun 07 11:51:31 however I didn't see a slider, only a switch and the switch didn't change anything Jun 07 11:51:33 for sure you *could* plug in some AGC to ALSA/gstreamer/PA/whatever Jun 07 11:52:15 hmm, I dunno if there's any hw gain control 'slider' for N900 microphone Jun 07 11:52:23 ok Jun 07 11:53:08 I guess reading the datasheet for ac32foo or whatever the mixer chip will tell if there's any Jun 07 11:53:27 ok Jun 07 11:53:57 *usually* you got a switch for +20dBm preamp, plus a usual attenuator 'slider' Jun 07 11:54:38 plus of course all the switches for muxing (aka selecting input line), for powering up micbias, etc Jun 07 11:54:47 muting Jun 07 11:54:51 whatnot else Jun 07 11:54:54 ok Jun 07 11:56:45 GNUtoo-desktop: general advice for setting input sensitivity / gain: max volume (shouting at mic with distance = zero) shall not result in clipping Jun 07 11:57:15 for the rest you usually want to rely on AGC Jun 07 11:57:22 ok Jun 07 11:57:29 I guess I've to try meego again Jun 07 11:57:48 what's the current meego replacement? Jun 07 11:58:26 no idea, sorry Jun 07 11:58:31 ok Jun 07 11:58:51 join #nemomobile, ask stskeeps Jun 07 11:59:02 freesmartphone.org: 03GNUtoo 07gnutoo/n900-alsa-scenarios-rework * r3def2f2e2281 10cornucopia/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): (log message trimmed) Jun 07 11:59:02 freesmartphone.org: fsodeviced: fix n900 scenario Jun 07 11:59:02 freesmartphone.org: Alsa control number and names changed with the last kernel change Jun 07 11:59:02 freesmartphone.org: and the scenarios weren't updated accordinly. Jun 07 11:59:02 freesmartphone.org: TODO: Jun 07 11:59:02 freesmartphone.org: * The volume must be checked. Jun 07 11:59:03 freesmartphone.org: * A different scenario for headset and headphones must be made Jun 07 11:59:42 yep, that's absolutely correct Jun 07 12:00:34 in scenario world, headset and headphone differ massively Jun 07 12:01:17 in ACI a headset is simply a headphone plus a wired mic Jun 07 13:05:57 JaMa: the upgrade is planned http://www.mail-archive.com/enlightenment-users@lists.sourceforge.net/msg17100.html Jun 07 13:06:16 for connman Jun 07 13:07:51 now I am looking after an issue with bitbake -k connman (ie libxb_1.8.1 failing due to missing xproto.xml : no such file or directory /OE/shr-core/tmp-eglibc/sysroots/om-gta04//OE/shr-core/tmp-eglibc/sysroots/om-gta04//usr/share/xcb/xproto.xml Jun 07 13:09:03 sound as simple as adding xproto-native to the depends . Still the added deps does not trigger xproto ... (at the same time I learn bitbake stuff ... might be I have to clean from the do_compile target Jun 07 13:15:43 oh you do not plan an efl upgrade on shr side ... ok then we have only one gui to setup connman the e17 module which use edbus bindings bound to connman 0.78 Jun 07 13:24:58 we decided to stick with efl releases.. so I'll try to keep 1.2 as long as possible :) Jun 07 14:32:47 so we need connman 0.78 (as otherwise we have a 0.79 backend with no frontend to manage it Jun 07 14:34:06 what I still wonder (still building connman dependencies) is if fsogsmd-connman needs to be reverted back to an older state to work with 0.78 instead of 0.79 Jun 07 14:35:22 so all I can tell for now is that to stop connman from turning wifi off I had to set wifi to enabled in /var/lib/connman/settings Jun 07 14:35:36 the backend properly enumerate the wifi AP on the dbus Jun 07 14:35:49 with this . Jun 07 15:16:06 Hi! can someone please hint me how to get two basic things done? 1) The slide-in bar with "close" button 2 shr-settings not crashing with EOFError: EOF read where object expected Jun 07 15:17:25 "import elementary" causes the crash Jun 07 15:45:22 MMlosh: python-elementary installed ? Jun 07 15:45:36 yes, even tried reinstalling Jun 07 15:46:03 Traceback (most recent call last): Jun 07 15:46:03 File "", line 1, in Jun 07 15:46:03 File "/usr/lib/python2.7/logging/__init__.py", line 43, in Jun 07 15:46:03 import threading Jun 07 15:46:24 the actual issue seems to be in python-logging.. Jun 07 15:48:33 hi GNUtoo-desktop Jun 07 15:48:43 we should write that definition down in our wiki ;-) Jun 07 15:48:55 $ python Jun 07 15:49:03 then import threading Jun 07 15:49:06 works ? Jun 07 15:49:19 prahal, no, that was it's output Jun 07 15:50:07 GNUtoo-desktop: if you ask _me_ I would say headset is the second one (headphone with integrated microphone) Jun 07 15:50:07 directly running python from command line ? Jun 07 15:50:12 y Jun 07 15:50:39 unfortunately, I have to go.. I'll be back in ~2.5h I am sorry about that Jun 07 15:56:15 mrmoku, hi sorry I was away from this computer Jun 07 15:56:23 mrmoku, do you know how to handle my problem? Jun 07 15:56:46 I guess we must look how nemo does it first tough Jun 07 15:57:54 someone talked about the gta04 headset jack detection ... what was the end of the talk ? Jun 07 16:00:30 prahal, there are issues Jun 07 16:00:40 I think paulk will write a mail Jun 07 16:15:45 GNUtoo-desktop: thanks Jun 07 16:16:00 are those hw or kernel/alsa ? Jun 07 16:16:12 because the latter I could help Jun 07 16:30:13 prahal, you know alsa? Jun 07 16:51:52 prahal: the gta04 headset detection hw is a bit.... :-x Jun 07 16:52:18 well, actually I think it's the plug-detection hw Jun 07 16:57:35 GNUtoo-desktop: somewhat , alread worked on hda-intel stuff Jun 07 16:58:05 and looked on the surface the alsa soc stuff Jun 07 16:59:22 I saw a rework of jack detection is in the make ... I am readinfg things about it (by david henningsson Jun 07 16:59:30 prahal, yes I saw that too Jun 07 16:59:53 prahal, maybe you could help me improve the gta04 forwarder? Jun 07 17:00:03 like by adding echo cancelation and such? Jun 07 17:01:06 it give me the opportunity to provide my feedback on Acer One mics ... the stuff I worked on alsa hda-intel . Maybe I can send him the baby with the bath :) one stuff less to look after Jun 07 17:02:29 I only learned about the alsa driver infrastructure ... not really skilled about signal processing algos . But if it is a matter of pluging existing code why not Jun 07 17:04:27 prahal, also do you know if multiplexing is possible with bluetooth(for instance with something like dmix) by using only alsa? Jun 07 17:08:53 no I cannot tell .( Jun 07 17:10:53 prahal, do you have an n900 btw? Jun 07 17:11:30 my next step will be to go higher in the stack ... ie look at alsa plugins (the fso one DocScrutinizer explained yesterday) ... I am mostly focused on issues I encountered (and all the bluez+headset work I have done was with pulseaudio so I am spoiled in this regard Jun 07 17:12:06 ok Jun 07 17:14:26 no I had the 770 but the map between the screen and the lcd cut itself with time ... before I found about that I had broke the thing beyond repair .... sad Jun 07 17:15:32 * DocScrutinizer05 finally proceeds to pay those 2 N900 he ordered Jun 07 17:15:38 about gta04 there is a weird thing with repeated touch on the same spot (after like 15 times the position is erratic Jun 07 17:16:29 this happens when one press the up arrow in the termnal :) Jun 07 17:16:47 hm? Jun 07 17:16:49 I believe it ends up making a middle click Jun 07 17:16:59 yes possibly because debouncing was disabled in the kernel Jun 07 17:17:01 aaah Jun 07 17:17:27 yeah, doubleclick being a possible explanation Jun 07 17:17:51 and debouncinng was disabled because during idle there was an issue Jun 07 17:18:05 there were high imprecision during idle Jun 07 17:18:13 hm? Jun 07 17:18:30 what means idle in this context Jun 07 17:19:06 I think the idle task Jun 07 17:19:20 sorry, I don't get it Jun 07 17:22:08 but I think there's something broken in design of r-ts driver Jun 07 17:23:33 you should: a) wait for a short between outer and inner plane (detected by touchpanel hw, via pulldown of one plane via ozher plane - then the hw triggers an IRQ on that event) Jun 07 17:24:27 b)run an actual digitizing cycle, by applying V+ V- to one plane, and probe voltage on other plane. Then swap planes and do same for the other ordinate Jun 07 17:25:22 c) finally do another detection if planes still touch, and send results of digitizing the touch position only if this second test results true Jun 07 17:26:17 if second test results in panels don't touch, you got a bogus touchpoint value that needs to get discarded Jun 07 17:28:41 similar procedure for touch-dwon / touch-up events. Just run several touch tests and only send pen-up or pen-down if at least N of the tests in sequence result in same state Jun 07 17:29:36 and finally: only send any touchpoint values (X,Y) when the previously described pen-down test resulted in pen-down = true Jun 07 17:30:24 and all that is before you do *any* filtering for jitter etc Jun 07 17:32:14 also debouncing as in my previous explanation is done in kernel space, by keeping local static timestamps and scheduling kernel worker threads Jun 07 17:32:39 DocScrutinizer05: building a n900 render farm? ;) Jun 07 17:33:53 mrmoku: I actually had that idea long ago, when wondering what to do with those N*10E3 devices still at stock Jun 07 17:34:37 but I had to learn they are the property of FIC factory, not of OM Jun 07 17:34:41 ;-P Jun 07 17:34:43 DocScrutinizer05: how much does one pay for one? Jun 07 17:35:05 I guess they were binned long ago Jun 07 17:35:21 stash area in factory is expensive Jun 07 17:35:48 they got binned... Jun 07 17:36:21 NFC actually though Jun 07 17:37:33 I think originally OM got charged 30%..50% of sales price by FIC Jun 07 17:39:02 I might be completely wrong though - sales never was very verbose with any numbers Jun 07 17:39:49 even inside OM we usually not even had numbers for devices shipped/sold Jun 07 17:40:45 I recall this one legendary monday meeting where Sean(?) explained we hit break-even last month Jun 07 17:41:00 not that this was a permanent state ;-) Jun 07 17:44:04 heh Jun 07 17:49:05 what's N*10E3 Jun 07 17:53:20 :shrug: Jun 07 17:53:30 2000, 5000, dunno Jun 07 17:54:07 I'm not even recalling batch sizes Jun 07 17:54:30 or maybe I do, sth like 3500 / batch? Jun 07 17:55:16 really, don't ask me (i'm not supposed to know those numbers anyway ;-D) Jun 07 17:56:15 you know, i'm R&D, not production and for sure not sales Jun 07 17:57:09 I was even blessed to never have to visit fab in Suzhou Jun 07 18:53:50 prahal, I am back.. I managed to get ilume-softkey displayed, which makes life bearable. But gps is not available anymore.. Jun 07 19:10:46 MMlosh, what device/distro? Jun 07 19:11:10 GNUtoo-desktop, GTA02, freshly downloaded shr core.. (if that was a bad choice, I'll fix that) Jun 07 19:11:27 the official one? Jun 07 19:11:35 I guess Jun 07 19:12:12 (I haven't been looking this direction for a year or so) Jun 07 19:12:15 then bugreport... Jun 07 19:12:28 if it contains the word staging too you can bugreport Jun 07 19:12:48 how do I find out? Jun 07 19:13:07 I took files from http://build.shr-project.org/shr-core/images/om-gta02/ Jun 07 19:13:08 what was the download address? Jun 07 19:13:11 ok Jun 07 19:13:17 so plain SHR-core Jun 07 19:13:20 then bugreport Jun 07 19:13:29 I had no idea there are variations Jun 07 19:15:23 http://www.shr-project.org/trac/wiki/Stabilizing Jun 07 19:35:24 GNUtoo-desktop, currently I don't care for telephony.. I'd love to see non-delaying navit Jun 07 19:41:44 MMlosh, ok, you did the bugreport for navit? Jun 07 19:41:57 *you're the one who did the bugreport for navit? Jun 07 19:42:05 no, that's not me Jun 07 19:42:31 anyway what's broken with navit? Jun 07 19:42:50 when I am arriving at the destination, it thinks I am haflway there Jun 07 19:42:59 that's what I got ~1year ago Jun 07 19:43:00 ah? Jun 07 19:43:09 then retry Jun 07 19:43:16 I'd love to Jun 07 19:43:22 fsoraw -l shows no gps Jun 07 19:43:22 but? Jun 07 19:43:26 ah ok Jun 07 19:43:30 it's fixed in master Jun 07 19:43:40 try older images then Jun 07 19:43:43 not speaking about "import enlightenment" throwing a fail Jun 07 19:43:52 ? Jun 07 19:44:37 the funny fact about that is: I had perfectly working navit.. I backed up everything from nand, flashed newer version, discovered the lagbug, reverted everything, It did not work anymore Jun 07 19:45:00 I suspect gps measure rate could have been adjusted and navit does not keep up.... or something Jun 07 19:45:37 GNUtoo-desktop, importing enlightenment in python imports "logger" and that fails with unexpected end of file Jun 07 19:46:26 ok,please bugereport Jun 07 19:47:21 *elementary (not enlightenment) Jun 07 19:47:42 which means no python+E17 application works.. Jun 07 19:48:14 Other than that, the device is surprisingly fast. Especially suspend and resume feel vastly improved. Jun 07 19:48:37 ok Jun 07 20:00:33 huh, is usb ethernet sometimes reporting as usb0 and sometimes as eth2 also a known issue, GNUtoo-desktop ? Jun 07 20:00:55 no Jun 07 20:00:59 not known Jun 07 20:01:02 I've always usb0 Jun 07 20:19:23 MMlosh: depends on MAC your device picks Jun 07 20:19:36 iirc Jun 07 20:19:55 swcu050g.pdf 14.2.2.5 Jun 07 20:20:06 duh Jun 07 20:20:12 wut? Jun 07 20:20:44 prahal: sounds like one of those 2000+p. TI TRMs Jun 07 20:21:51 * DocScrutinizer05 idly wonders if his rotten brain will eventually come up with a link of swcu050 to a real chip name Jun 07 20:22:26 OMAP3430? TWL4030? Jun 07 20:23:01 nah, omap3430 is spruf98 Jun 07 20:23:27 prahal: ? help me out? Jun 07 20:28:01 sorry phone call in between lines :) Jun 07 20:28:16 headset detection on tps65950 Jun 07 20:28:40 ie gta04 ... I exported gpio 2 which is supposed to show the state Jun 07 20:28:49 and no go ... might not be wired Jun 07 20:29:56 prahal, talk to paulk-desktop Jun 07 20:30:12 paulk-desktop: ping Jun 07 20:30:16 prahal, hi! Jun 07 20:30:44 is your device gta04? Jun 07 20:30:55 or is it another tps65950 device? Jun 07 20:31:30 is headset detection wired to gpio2 as seem to be required for tps65950 ? gta04 Jun 07 20:31:45 detection is done via the ADC Jun 07 20:31:57 there is no GPIO and no IRC Jun 07 20:32:16 just an ADC chan connected to the MIC pin Jun 07 20:32:49 s/IRC/IRQ/ Jun 07 20:32:59 HSMIC Jun 07 20:33:08 yeah Jun 07 20:33:45 the best idea is probably to get the adc value every second Jun 07 20:33:51 but: Jun 07 20:34:05 - you need the MICBIAS current turned on while getting the value Jun 07 20:34:18 - you need to turn it off after the measurement to save power Jun 07 20:34:36 - if you are recording, you don't want to mess with the MICBIAS setting Jun 07 20:35:10 - reading the ADC value makes a funny sound for half a second while recording Jun 07 20:36:13 paulk-desktop, I don't remember but reading the ADC value is in kernel space right? Jun 07 20:36:18 might be triggered on playback only Jun 07 20:36:24 GNUtoo-desktop, not in 3.2/3.3 Jun 07 20:36:30 it's now kernel-space only Jun 07 20:36:39 but can be exported easily if you write stuff for it Jun 07 20:36:51 sysfs I guess Jun 07 20:36:58 by recording you mean the internal mic Jun 07 20:37:29 prahal, no, it won't affect the internal mic Jun 07 20:37:35 but if you record from the headset Jun 07 20:37:51 ah ok Jun 07 20:37:59 I must resolder my headset first Jun 07 20:38:14 prahal: (and no go ... might not be wired) on gta04? I might check if you want me to Jun 07 20:39:50 paulk-desktop: that scheme to detect headset/headphones pug in via constant pilling of micbias current won't fly for a couple of reasons Jun 07 20:40:32 at least it conflicts while recording Jun 07 20:40:35 so it's not ok to use it Jun 07 20:42:13 and it conflicts with keeping device in suspend/zeroclock as much as possible, it introduces delay to detection on longer polling periods and would eat quite some power for both cpu and micbias on shorter poll intervals Jun 07 20:44:14 DocScrutinizer05, ok, I understand it's not a good solution on the power consumption side Jun 07 20:44:50 however iirc the I->U converter in micbias line shouldn't backfire into mic audio on doing a A/D conversion, and maybe we even could configure the related A/D input pin to trigger an IRQ when mic pin gets shorted to GND which it will during plugin action Jun 07 20:45:47 but then I seem to recall somebody had a 220R in parallel somewhere there, which was mere WTF for me Jun 07 20:46:27 anyway such 220R is removed *easily* :-D Jun 07 20:47:29 mhh ok Jun 07 20:47:41 does setting the IRQ trigger line require hardware changes? Jun 07 20:47:49 I realize I can't check right now as the server with the TRM on it is down it seems Jun 07 20:48:40 and I don't have any local copy of that gta04 TRM/UM on this new PC Jun 07 20:49:31 so sorry I can't help any much further, without wild handwaving and every other word of my posts being "IIRC" Jun 07 20:50:24 ok Jun 07 20:50:55 unless you got another URL where to get gta04 UM pdf Jun 07 20:51:39 I think it's on gta04.org, isn't it? Jun 07 20:53:08 the site is down (as handelds and goldelico Jun 07 20:53:40 ah, that's the issue! Jun 07 20:53:45 I'll upload a copy then Jun 07 20:54:04 mhh if I have one around Jun 07 20:56:19 http://aldrin.paulk.fr/~paulk/GTA04A4-1_System_Manual_Complete.pdf Jun 07 20:56:24 thanks Jun 07 20:57:10 damn friggin freezes of konqueror Jun 07 20:57:27 already just started opening 4s befor I posted that Jun 07 20:57:36 :D Jun 07 20:57:41 while I clicked the link immediately after "thanks" Jun 07 21:00:52 prahal, the actual problem why "import elementary" fails is "import threading" having issues, that's the place where the EOF error appears Jun 07 21:02:10 MMlosh: threading import thread .. could you try to "import thread" directly ? Jun 07 21:03:00 prahal, I can "import thread" Jun 07 21:03:05 I can't "import threading" Jun 07 21:03:35 well, either you find a way to configure one of the pins of tps65950 (HSMIC.M, maybe HSMIC.P) to create some event reporting to CPU when pulled to GND Jun 07 21:03:50 you have /usr/lib/python2.7/threading.py Jun 07 21:03:54 yes Jun 07 21:04:02 or you set MICSENSE A/D input to trigger IRQ when pulled up Jun 07 21:04:30 odds are neither of both will work or be feasible Jun 07 21:04:54 sorry what was the error when importing threading ? Jun 07 21:05:22 bbl, I'll rollback after Jun 07 21:05:25 >>> import threading Jun 07 21:05:25 Traceback (most recent call last): Jun 07 21:05:25 File "", line 1, in Jun 07 21:05:25 EOFError: EOF read where object expected Jun 07 21:05:37 thanks for the hints DocScrutinizer05 Jun 07 21:05:43 YW Jun 07 21:06:33 obviously you need to keep micbias enabled all the time to detect plugin-events this way, but this shouldn't cause too much power drain Jun 07 21:07:12 MMlosh: strace -f - e trace=file python -c "import threading" . might help to track which file is truncated Jun 07 21:07:53 prahal, oops, can't check anymore.. reinstallation of threading fixed it Jun 07 21:08:35 good ... anyway it was random corruption of a file (probably due to a hard power off ) so very local Jun 07 21:08:59 prahal, I did no hard power offs Jun 07 21:09:04 and flashed the image today Jun 07 21:10:16 ? then either the image was generated with a file corruption ... or there was a bad sector which when reallocate wipe out part of a file Jun 07 21:10:38 yeah.. Jun 07 21:13:29 prahal, the bad sector sounds kind of likely, considering the device was shelved for a year Jun 07 21:43:14 still no nschle85 Jun 07 21:49:13 DocScrutinizer05, Aha... I got the "MAC" thing now.. Depends on whether my host device sees uboot/qi or shr first. right? Jun 07 22:00:56 mrmoku, ping Jun 07 22:01:03 mrmoku, how do I save a scenario? Jun 07 22:01:07 like to create that: Jun 07 22:01:21 /etc/freesmartphone/conf/GTA04/alsa-3.4/stereoout Jun 07 22:02:44 SaveScenario didn't work Jun 07 22:02:51 I don't want to do everything by hand.... Jun 07 22:03:43 ah sorry Jun 07 22:03:45 wrong dir Jun 07 22:04:34 it works...sorry Jun 07 22:08:46 MMlosh: quite possibly Jun 07 22:09:36 prahal, also: fixing threading seems to fix the gps trouble.. the resource is now available as it should.. and getting fix impressively quickly Jun 07 22:10:49 MMlosh: I just recall we had a time where MAC been picked by random, and eventually we changed to fixed MAC which reulted in a change from USB to eth Jun 07 22:10:57 resulted* Jun 07 22:11:20 sth like that Jun 07 22:11:23 I am definitely not observing random mac.. that would create new interface each time Jun 07 22:11:57 :nod: Jun 07 22:14:20 sorry I don't recall any details - it's like 4 years ago. Anyway the pointer is into right direction, HTH ;-D Jun 07 22:16:03 maybe it's not exactly MAC but vendor:device tuple that decides on it Jun 07 22:16:32 it seems we changed that also eventually, at OM Jun 07 22:16:47 this issue is back (usb0 and random MAC) on gta04 shr Jun 07 22:16:58 but fixed on gta02 shr Jun 07 22:17:02 now I have re-plugged and it's still eth2 Jun 07 22:17:41 ie gta02 sometimes pick usb0 or eth2 (might well be what you guessed , ie uboot/qi or shr Jun 07 22:17:59 the issue should only happen at boot Jun 07 22:18:41 syslog of PC is your friend Jun 07 22:19:10 though for gta04 it would be easy to fix on user side ... ie append mac address to kernel command line Jun 07 22:21:33 freesmartphone.org: 03GNUtoo 07cornucopia * r7fb09638264c 10/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): (log message trimmed) Jun 07 22:21:33 freesmartphone.org: fsodeviced: fix n900 scenario Jun 07 22:21:33 freesmartphone.org: Alsa control number and names changed with the last kernel change Jun 07 22:21:33 freesmartphone.org: and the scenarios weren't updated accordinly. Jun 07 22:21:33 freesmartphone.org: TODO: Jun 07 22:21:34 freesmartphone.org: * The volume must be checked. Jun 07 22:21:34 freesmartphone.org: * The non-used control should be disabled Jun 07 22:21:35 freesmartphone.org: 03GNUtoo 07cornucopia * r450370343959 10/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): Jun 07 22:21:35 freesmartphone.org: fsodeviced: n900 scenarios fixing: disable not-used Switch and Volume controls. Jun 07 22:21:36 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 07 22:22:29 freesmartphone.org: 03GNUtoo 07cornucopia * rb5202e7eb41e 10/fsodeviced/conf/nokia_n900/alsa-default/ (headset stereoout): Jun 07 22:22:29 freesmartphone.org: fsodeviced: n900 scenarios fixing: fix main volume. Jun 07 22:22:29 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 07 22:28:39 nschle85, ping Jun 07 22:28:48 s/ping/hi/ Jun 07 22:28:49 GNUtoo-desktop meant: nschle85, hi Jun 07 22:28:57 GNUtoo-desktop: pong Jun 07 22:29:21 I've pushed some scenario rework Jun 07 22:29:26 on master Jun 07 22:29:39 GNUtoo-desktop: for N900 ? Jun 07 22:30:13 it's not perfect(lack good microphone support and many things for telephony tough) Jun 07 22:30:14 yes Jun 07 22:31:10 ill rebuild a new image, thank you but at the moment my image does not bring up pin dialog Jun 07 22:31:30 why are you focus on the PIN? Jun 07 22:31:52 GNUtoo-desktop: to get gsm network workin Jun 07 22:32:06 why not disabling the PIN then? Jun 07 22:33:15 GNUtoo-desktop: i dont like workarounds and as i saw last time it was missing some libs so rebuilded from scratch but i did not investigated whats wrong now Jun 07 22:34:00 nschle85, look we have a lot of things missing for n900, then do you prefer spending time on fixing the PIN or on something else more important Jun 07 22:34:20 GNUtoo-desktop: pin was always working Jun 07 22:34:40 let me look Jun 07 22:35:10 GNUtoo-desktop: so please dont look i have to see whats wrong with my image Jun 07 22:35:15 ok Jun 07 22:35:20 let me try then Jun 07 22:35:31 I'm booting with a SIM to see Jun 07 22:35:36 but I've no PIN on it Jun 07 22:36:22 GNUtoo-desktop: the last problem i was sending you (ldd phonuid or something like that) Jun 07 22:36:54 all that works for me Jun 07 22:37:12 GNUtoo-desktop: so it seems i have a problem with my image Jun 07 22:37:39 and telephony works too(with very bad sound) Jun 07 22:37:43 GNUtoo-desktop: but what can i test now with your fixed scenario files Jun 07 22:37:46 ? Jun 07 22:38:50 audio during calll ? and ringtone ? Jun 07 22:39:07 normal audio Jun 07 22:39:13 like playing music etc... Jun 07 22:39:22 through speaker and headphones Jun 07 22:40:11 hmmm Jun 07 22:40:15 I got an idea Jun 07 22:41:01 hmmm Jun 07 22:41:20 no, I tought that fsoaudiod used 100% CPU but it doens't at the beginning Jun 07 22:43:45 GNUtoo-desktop: hmm i thought scenario files are only relevant during a call Jun 07 22:44:11 when you plug the headphones the scenario switch from stereoout to headset Jun 07 22:44:19 btw do you have a nokia headset? Jun 07 22:44:22 scenarios are relevant only for all audio Jun 07 22:44:28 or only standard headphones? Jun 07 22:45:02 GNUtoo-desktop: i have to look but i guiess i have nokia headset too Jun 07 22:45:45 DocScrutinizer05: but setting a scenario is done during calls i thought Jun 07 22:45:46 ok Jun 07 22:45:46 and actually it *should* switch to all-off scenario as soon as no process using any audio device Jun 07 22:46:15 but I bet that's implemented in any other weird way Jun 07 22:46:19 not sure about that Jun 07 22:46:24 usually there is DAPM Jun 07 22:46:29 and it's done in kernel space Jun 07 22:46:41 because else you end up like nexus S Jun 07 22:46:53 huh? Jun 07 22:47:02 where morphis did an userspace plugin to keep it on all the time not to loose the status of the alsamixer Jun 07 22:47:10 which is very bad for power management.... Jun 07 22:47:21 GNUtoo-desktop: can you send me please some information about the broken audio forwarder please ? i dont know which service does forward between modem and alsa Jun 07 22:47:32 fsoaudiod Jun 07 22:47:41 I think it uses too much CPU Jun 07 22:47:45 that's exactly the point why you want to load a scenario every single time any app opens a audiodevice Jun 07 22:48:06 and return to all-off scenario when no audiodevice is open Jun 07 22:48:09 cornucopia/fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata Jun 07 22:48:44 DocScrutinizer05, that's the role of the kernel, not the userspace Jun 07 22:48:46 GNUtoo-desktop: is fsoaudiod still active in fso ? iheard about it to be removed from fso Jun 07 22:49:07 nschle85, it is not active for audio routing currently Jun 07 22:49:08 uhuh Jun 07 22:49:37 so only for forwarding for the following devices: Jun 07 22:49:38 n900 Jun 07 22:49:42 gta04 A3 and below Jun 07 22:50:15 GNUtoo-desktop: so fsoaudiod is working on N900 ? Jun 07 22:50:39 yes however the sound is unbreeable Jun 07 22:50:45 buffer underruns everywhere Jun 07 22:50:51 sorry I failto see how audio stuff is a genuine kernel task Jun 07 22:50:55 or overrun when recording Jun 07 22:51:13 DocScrutinizer, trough DAPM Jun 07 22:51:14 GNUtoo-desktop: ok, but thats what to be fixed Jun 07 22:51:24 pfff, so what? Jun 07 22:51:45 DAPM is just... DAPM. Not any rationale Jun 07 22:51:50 but the current environment is working with that bug Jun 07 22:51:53 ? Jun 07 22:52:48 DocScrutinizer, I really don't see how to do it in userspace if not by using pulseaudio Jun 07 22:53:00 nschle85, yes Jun 07 22:53:12 nschle85, if you use autorev and rebuild now it should Jun 07 22:53:22 actually DAPM is a botch workaround to make mixer aware of open devices because there wasn't any proper concept to handle it in userspace Jun 07 22:53:40 DocScrutinizer05, ok Jun 07 22:54:03 and I don't see how polypaudio comes in here now. What is it PA is allegedly doing that ALSA can't? Jun 07 22:54:34 beeing a central deamon and not a lib it can track if there is a process accesing ....ah you're right Jun 07 22:54:41 the alsa lib can too Jun 07 22:54:57 s/can/could/ Jun 07 22:54:57 GNUtoo-desktop meant: the alsa lib could too Jun 07 22:55:15 well, that's exactly what ACI is all about Jun 07 22:55:35 making $whatever aware of any open audio devices Jun 07 22:55:59 actually it's what alsaexechooklib is about Jun 07 22:56:21 ok Jun 07 22:57:05 :q Jun 07 22:57:07 oops Jun 07 22:57:13 GNUtoo-desktop: DocScrutinizer05: so ill go to bed now , tomorrow ill fix my n900 image to get connected to gsm network. bye Jun 07 22:57:32 any app opening a alsa device that has exechook plugin in its stack will cause $whatever to receive signal from exechook about audiodevice being opened and tus $whatever loads the appropriate scenario and stacks the previous one Jun 07 22:58:08 the problem is that I don't have time to work on ACI Jun 07 22:58:10 on closing the audiodevice $whatever gets another signal, and restores stacked previous scenario Jun 07 22:59:07 and on last audiodevice closing, $whatever restores scenario "idle" which includes shutting down any amp power control Jun 07 23:00:58 all this working without any patches to apps, to mess around with scenario switching Jun 07 23:01:50 you simply configure the right audiodevice (aka stack of plugins associated with a unique alsa audiodev name) for your app Jun 07 23:03:18 there seems to be no way to downgrade a package (ie I cannot tell opkg to install a version ... --force-downgrade looks good but ...) Jun 07 23:03:59 and even if you got to run a completely braindamaged app that has a hardcoded "alsa:default" as audiodevice, you can still get it working by #> ALSA_DEFAULT_DEVICE=alsadev-for-fuckedup-app fuckedup-app Jun 07 23:05:47 you simply define a default device like >> default! { slave: $ALSA_DEFAULT_DEVICE } ;# <--fix syntax Jun 07 23:06:29 you can't specify hardcoded slave, as all plugin definitions for alsa are "global" Jun 07 23:08:09 but environment is local for each process, so defining slave:$ALSA_DEFAULT_DEVICE will redirect alsa:default to whatever you set into that $env-var for that particular process, and only for that process Jun 07 23:12:43 ( the problem is that I don't have time to work on ACI) you don't actually need much work on it Jun 07 23:13:14 libaslaexechook already exists Jun 07 23:13:51 you create some device definitions in standard alsa way, in .asoundrc Jun 07 23:14:18 which have the right command in exechook Jun 07 23:14:42 the command invokes your script that "loads scenario" Jun 07 23:15:13 basically that's all you need for a version0.1 Jun 07 23:15:56 the nice part is all this works completely independent of fso Jun 07 23:16:22 and doesn't need *any* patches to any audio-app Jun 07 23:17:31 so if you don't have time to work on sophisticated fsoaudiod stuff, simply go for ACI, and drop all fso audio handling Jun 07 23:18:55 I don't think ACI require less time Jun 07 23:19:01 mrmoku, tried and never finished Jun 07 23:19:24 mrmoku tried to inplement version2.3 Jun 07 23:19:48 the nice thing about ACI is it scales perfectly Jun 07 23:20:14 you can start with bare bones functionality version0.001 Jun 07 23:20:23 and still get something operational Jun 07 23:20:27 if it doesn't take time try convincing morphis.... Jun 07 23:20:48 and you add nifty intelligence scriptline by scriptline Jun 07 23:21:06 ok Jun 07 23:22:24 actually, implementing a v0.1 ACI was simpler back when scenarios were plain alsactl syntax Jun 07 23:23:21 nowadays I have NFC how to load a particular scenario, so you need to create some that allow a method to load them via cmdline Jun 07 23:23:55 my suggestion: use amixer syntax Jun 07 23:24:12 ok Jun 07 23:24:37 split scenarios into distinct unrelated paths, like earpiece and mic, for handset Jun 07 23:25:24 iirc mrmoku did something like that for a lot of paths already Jun 07 23:56:17 well well connman back to 0.79 in my local chroot , available through my local feed ... but there is no way to downgrade ! Jun 07 23:57:10 in the process I found how to revert by batch of commits so all time is not lost Jun 07 23:58:21 well there is one ... ie to provde a full uri instead of name + version ... not very friendly Jun 08 00:00:11 how great even that does not work (without removing first Jun 08 00:03:12 grrr even this documented way fail Jun 08 00:09:38 finally ... cp locally then it works :/ convoluted **** ENDING LOGGING AT Fri Jun 08 02:59:58 2012