**** BEGIN LOGGING AT Sun Jul 03 02:59:57 2011 Jul 03 07:51:42 moin Jul 03 08:06:18 mickey|office: hmm... I probably broke ppp _with_ password now Jul 03 08:07:35 mickey|office: what is the correct way to specify a char* parameter in .vapi to not make vala assert on it being null? Jul 03 08:08:03 using ref or out makes it a gchar** which obviously is wrong Jul 03 08:08:18 and works for it being null only Jul 03 08:09:17 hi Jul 03 08:09:26 moin dcordes_ Jul 03 09:03:33 morphis_: moin and ping Jul 03 09:04:44 gahh... how stupid :P Jul 03 09:08:53 mrmoku: good morning :) Jul 03 09:09:02 mrmoku: and pong Jul 03 09:09:14 morphis_: think I found the real fix now :P Jul 03 09:09:24 for the ppp thing? Jul 03 09:09:26 so probably never mind and a good morning anyway :) Jul 03 09:09:26 yup Jul 03 09:09:29 string? Jul 03 09:09:36 not out... not ref... ? Jul 03 09:10:27 to tell vala it might be null Jul 03 09:10:38 string? value Jul 03 09:10:42 yup Jul 03 09:10:44 makes it a nullable type Jul 03 09:10:51 so, yes Jul 03 09:10:58 I saw your commit Jul 03 09:11:04 yup, the ppp problem comes from vala asserting on the passed in user/pw being null Jul 03 09:11:06 but I don't see why it should be out Jul 03 09:11:11 ah ok Jul 03 09:11:13 desperation :P Jul 03 09:11:15 and string? does not work? Jul 03 09:11:24 did have that idea right now Jul 03 09:11:32 so I'm building and trying now Jul 03 09:11:57 ah ok Jul 03 09:12:25 it should work with ? otherwise there is something broken in vala Jul 03 09:19:40 hm, Pre 3 is scheduled for mid-july Jul 03 09:19:48 maybe I should wait with buying the HP Veer Jul 03 09:44:55 PaulFertser, DocScrutinizer: for the record... the correct fix is to add ? to string... to tell vala that the string might be null Jul 03 09:45:07 * mrmoku should have known that as he knew about ? :/ Jul 03 09:46:28 mrmoku: :)) Jul 03 09:46:55 freesmartphone.org: 03mok 07cornucopia * r187abf0a3fac 10/fsogsmd/ (src/ppp/plugin.vala vapi/ppp.vapi): Jul 03 09:46:55 freesmartphone.org: fsogsmd: ppp: fix the fix for empty username/password in the ppp plugin Jul 03 09:46:55 freesmartphone.org: The correct fix is of course to use string? to tell vala Jul 03 09:46:55 freesmartphone.org: that it is ok for the string to be null. Jul 03 09:46:55 freesmartphone.org: Signed-off-by: Klaus Kurzmann Jul 03 09:49:43 morphis_: is it ok to bump cornucopia to current? Jul 03 09:49:50 (in oe.dev) Jul 03 09:49:52 yes Jul 03 09:49:56 ok Jul 03 10:05:40 <[Rui]> hi Jul 03 10:05:52 <[Rui]> mickey|daddy: sleeping much? :) Jul 03 10:07:35 Sleeping is cool! \m/ Jul 03 10:13:44 <[Rui]> PaulFertser: hehe Jul 03 10:13:59 <[Rui]> too bad I'm having a phone that only works a little then goes to hell :( Jul 03 10:19:47 [Rui]: what are the symptoms? Jul 03 10:20:36 <[Rui]> mrmoku: suddenly, calls stop having sound. workaround: use speaker Jul 03 10:20:40 <[Rui]> then suddenly, not even that Jul 03 10:20:42 [Rui]: one thing you might consider looking at is the battery... some time back I had a very unstable phone due to a broken battery Jul 03 10:20:45 ahh Jul 03 10:20:59 hmm... I thought we fixed that Jul 03 10:21:04 <[Rui]> mrmoku: maybe you did Jul 03 10:21:14 <[Rui]> but the last image is almost 1mo old :) Jul 03 10:21:33 I'm building one right now Jul 03 10:21:44 <[Rui]> might as well try it :) Jul 03 10:21:45 with fixed gprs for the without-password-case Jul 03 10:21:56 <[Rui]> heh Jul 03 10:22:46 and the real fix for audio problems on calls would probably to implement doc's ACI and replace oeventsd with something better Jul 03 10:23:08 anyway... have to pickup my brother for lunch Jul 03 10:23:09 bbl Jul 03 10:24:39 <[Rui]> I have been so undermotivated lately... I missed my yearly FOSDEM refresh :) Jul 03 10:24:51 <[Rui]> see ya Jul 03 11:57:12 dos1, hi Jul 03 12:08:22 is dos1 hidding? Jul 03 12:10:11 hi mrmoku Jul 03 12:12:36 GNUtoo: hi Jul 03 12:13:33 dos1, do you want to work on something? Jul 03 12:13:36 for the n900 Jul 03 12:14:04 GNUtoo: what do you have in mind? Jul 03 12:14:14 http://wiki.freesmartphone.org/index.php/Hardware/N900/TODO#Less_urgent_TODO Jul 03 12:14:22 I just updated this todo Jul 03 12:15:18 (except pure N900-integration work, I was thinking about finishing fso-ofono wrapper, so we could use apps from Meego in SHR - or maybe replace ofono with FSO on Meego images) Jul 03 12:15:42 what about working on modem? Jul 03 12:16:10 there is a fso-ofnon warapper? Jul 03 12:16:26 apps from meego require 3d Jul 03 12:16:48 but replacing ofono with fso in meego could be good Jul 03 12:16:56 that would give us more devs Jul 03 12:17:05 on other platforms Jul 03 12:17:23 such as palm pre, htc dream, nexusone ,htc hd2 etc... Jul 03 12:17:37 but only palm-pre has non-free 3d Jul 03 12:17:43 so that is a bit limiting Jul 03 12:19:37 I guess thats the biggest problem with non-android OSs on android handsets is the lack of 3D blobs Jul 03 12:19:55 GNUtoo: yeah, i was writing fso-ofono some time ago Jul 03 12:20:20 though for sure now it's not really up-to-date :P Jul 03 12:21:34 ok Jul 03 12:22:37 i was working on it exactly year ago :D Jul 03 12:22:44 ah ok Jul 03 12:23:06 it never got pubilshed? Jul 03 12:23:39 jonwil, hi, we(SHR) don't depend on non-free 3d so it's less an issue for us Jul 03 12:24:36 GNUtoo: yup, but i can push it to some git repo Jul 03 12:24:48 or to a branch Jul 03 12:25:00 it's only one python script Jul 03 12:25:18 which implements ofono dbus API and uses FSO calls Jul 03 12:25:27 ok Jul 03 12:25:33 How do you guys solve the 3D issue then or do you not do 3D at all? Jul 03 12:26:16 jonwil, we use enlightenment which doesn't require 3d(fast enough) and even has software compositing(can be used on palmpre 2 for instance) Jul 03 12:26:57 nice :) Jul 03 12:27:08 there is a video of the palm pre 2 Jul 03 12:27:13 with software compositing Jul 03 12:27:18 and it's very very fast Jul 03 12:27:27 http://pare.sylvain.perso.sfr.fr/video/ppp+swcompositiong.ogg Jul 03 12:27:43 on the n900 it slows down things tough Jul 03 12:27:59 the palm pre 2 is a 1GHz armv7 CPU Jul 03 12:28:07 *has Jul 03 13:00:58 GNUtoo: how good is the palm pre 2 with telephony? Jul 03 13:01:11 I've no palm pre 2 Jul 03 13:01:20 so I don't really know yet Jul 03 13:01:22 ok Jul 03 13:01:30 but I think it's pretty complete Jul 03 13:01:35 the video looks good Jul 03 13:01:38 check if sms have been implemented tough Jul 03 13:01:53 if you want to buy a new device Jul 03 13:01:58 consider all possible devices Jul 03 13:02:06 http://wiki.freesmartphone.org/index.php/HardwareComparison Jul 03 13:02:15 thx Jul 03 13:02:20 basically the palm pre seem to have a lot of quirks Jul 03 13:02:29 like issues with NEON Jul 03 13:02:30 not unlike the openmoko... :/ Jul 03 13:02:31 etc... Jul 03 13:02:41 software issues Jul 03 13:02:50 wifi is problematic Jul 03 13:03:29 ok Jul 03 13:03:49 if wifi is fixed it would be great Jul 03 13:03:58 I'll have to fix wifi when I get the pre-2 Jul 03 13:06:35 ok Jul 03 13:06:48 I have a HTC TouchPro where I run h:1, wifi is also problematic Jul 03 13:07:07 sometimes works with android though, so there should be a way Jul 03 13:17:58 yes Jul 03 13:18:04 I was working on it right now Jul 03 13:18:16 [ 427.261413] wl1251: elp work Jul 03 13:18:16 [ 427.261474] wl1251: chip to elp Jul 03 13:18:30 on android wifi Jul 03 13:19:43 on palm-pre I think we need to use a more recent compat-wireless Jul 03 13:19:48 hi GNUtoo Jul 03 13:19:54 or to backport patches Jul 03 13:19:55 hi Jul 03 13:20:12 mrmoku, what are you working on currently? Jul 03 13:20:51 I finished fixing my fix of ppp Jul 03 13:20:55 ok Jul 03 13:20:59 I saw the oe commit Jul 03 13:21:05 next thing I wanted to look at is aci Jul 03 13:21:12 what's that? Jul 03 13:21:18 to get fsoaudiod/alsa to gta02 and n900 Jul 03 13:21:28 is the gsmvoice plugin finished Jul 03 13:21:31 aci = DocScrutinizer51's alsa hook thingie Jul 03 13:21:32 ok Jul 03 13:21:37 ah ok Jul 03 13:21:50 no probably gsmvoice plugin still needs tweaking Jul 03 13:21:57 ok Jul 03 13:22:02 so maybe I should have a look Jul 03 13:22:04 but for tweaking having good alsa handling ready would be helpfull Jul 03 13:22:13 ah ok Jul 03 13:22:18 then go ahread Jul 03 13:22:22 <[Rui]> hu again Jul 03 13:22:25 hi Jul 03 13:22:45 <[Rui]> mrmoku: did your image finish building yet? Jul 03 13:22:45 GNUtoo: I think it needs some discussion between you, DocScrutinizer51, morphis and me how to do it exactly Jul 03 13:22:49 [Rui], I talked with morphis Jul 03 13:22:50 [Rui]: let me check Jul 03 13:22:59 <[Rui]> GNUtoo: about what? Jul 03 13:23:16 about the modems like the geeksphone one and the galaxy S Jul 03 13:23:23 they all have an msm modem in common Jul 03 13:23:30 <[Rui]> btw, I think SMS are being stored in opim and sim at the same time Jul 03 13:23:32 so all what is needed is to adapt msmcommd Jul 03 13:23:37 <[Rui]> GNUtoo: nice! Jul 03 13:23:37 [Rui]: yup, finished and synced Jul 03 13:23:44 <[Rui]> mrmoku: where to? Jul 03 13:23:54 [Rui], that is not easy tough Jul 03 13:23:56 but.... Jul 03 13:24:00 I've a geeksphone one Jul 03 13:24:07 I'm waiting for the battery Jul 03 13:24:11 <[Rui]> so I receive SMS until I get the message: "your sms list is full" Jul 03 13:24:12 and that speaks msmcommd Jul 03 13:24:20 morphis will buy an hp veer Jul 03 13:24:24 that also speaks msmcomm Jul 03 13:24:24 http://build.shr-project.org/shr-unstable/images/om-gta02/shr-lite-eglibc-ipk--20110703-om-gta02.rootfs.tar.gz Jul 03 13:24:37 [Rui]: I just build the lite image... want the fat one too? Jul 03 13:24:38 *speaks msmcomm protocol Jul 03 13:24:46 <[Rui]> mrmoku: lite is enough :) Jul 03 13:24:51 the thing is that the transport is different Jul 03 13:24:56 and the messages are a bit different Jul 03 13:25:01 across phones Jul 03 13:25:14 hmm Jul 03 13:25:21 bbi alias should build the fat one too Jul 03 13:25:51 ERROR: '/OE/shr-unstable/openembedded/recipes/gstreamer/gst-plugins-good_0.10.28.bb' failed Jul 03 13:25:54 grr Jul 03 13:26:20 <[Rui]> any idea ab out the sms issue? Jul 03 13:26:32 eek Jul 03 13:27:17 <[Rui]> I know this must be happening because it happened once, and you guys told me to just load the sim in another phone and clear the sms list, which I did, and now it's happened again Jul 03 13:27:54 /bin/grep: /OE/shr-unstable/tmp/sysroots/armv4t-oe-linux-gnueabi/usr/lib/libgnome-keyring.la: No such file or directory Jul 03 13:27:57 /bin/sed: can't read /OE/shr-unstable/tmp/sysroots/armv4t-oe-linux-gnueabi/usr/lib/libgnome-keyring.la: No such file or directory Jul 03 13:28:00 heh Jul 03 13:28:30 [Rui]: probably mickey|office was perfectly right when advising not to turn off sim buffering Jul 03 13:29:11 <[Rui]> mrmoku: hms? Jul 03 13:30:15 <[Rui]> and I'm getting old sms as if it were new ones Jul 03 13:30:19 [Rui]: what exactly is your sms problem symptom? Jul 03 13:30:20 ahh Jul 03 13:30:44 <[Rui]> mrmoku: two things: one, it starts complaining that the messages list is full (on sim) Jul 03 13:30:58 <[Rui]> mrmoku: two: I'm getting old sms messages as if I got them anew Jul 03 13:31:16 [Rui]: (one) is that true or false info? Jul 03 13:31:27 <[Rui]> mrmoku: I guess it's true, on SIM Jul 03 13:32:17 actually I'm no expert on SIM and how the flow goes Jul 03 13:32:21 err SMS Jul 03 13:32:35 just that fsogsmd and opimd are involved :P Jul 03 13:32:45 <[Rui]> my suspiction: sms on sim is full Jul 03 13:32:56 and that it's difficult for me to reproduce/test Jul 03 13:33:07 <[Rui]> so operator must somehow know it's not properly delivering the sms, so keeps sending Jul 03 13:33:21 <[Rui]> until retry limit, that is Jul 03 13:33:30 yeah, and calypso does not acknowledge because SIM is full Jul 03 13:33:47 nevertheless sim buffering is turned off and opimd got the message Jul 03 13:33:54 <[Rui]> yup Jul 03 13:34:02 [Rui]: could you check that sim buffering as actually turned off in your config? Jul 03 13:34:05 (fsogsmd.conf) Jul 03 13:34:26 s/as/is/ Jul 03 13:34:49 <[Rui]> /etc/dbus-1/system.d/fsogsmd.conf ? Jul 03 13:34:56 no Jul 03 13:35:04 <[Rui]> /etc/freesmartphone/conf/openmoko_gta/fsogsmd.conf ? Jul 03 13:35:07 /etc/freesmartphone/conf/openmoko_gta/fsogsmd.conf Jul 03 13:35:08 yeah Jul 03 13:35:32 <[Rui]> # Whether SMS should be buffered via SIM or delivered directly Jul 03 13:35:32 <[Rui]> sim_buffers_sms = false Jul 03 13:35:40 ok Jul 03 13:36:15 which makes it quite unclear why the SIM can be filling with messages... Jul 03 13:37:09 <[Rui]> well, the new installation (with a restored pim.db) complained immediately about the full list Jul 03 13:37:29 <[Rui]> speaking of install, going to install your new lite image Jul 03 13:41:02 <[Rui]> damn, my old nokia 2760 doesn't recognize my sim... Jul 03 13:41:05 <[Rui]> but it used to. Jul 03 13:44:21 DocScrutinizer51: I'm wondering what dwimd does to battery consumption Jul 03 13:46:47 <[Rui]> ok, did it by scrubbing sim and contacts :) Jul 03 13:46:55 <[Rui]> confirmed, recent messages in sim Jul 03 13:47:19 ok Jul 03 13:49:36 <[Rui]> maybe sim_buffers_sms is no longer honoured Jul 03 14:05:44 <[Rui]> seems to be working now. 1 call received... Jul 03 14:06:06 <[Rui]> but so it did previously, so let's see :) Jul 03 14:14:26 good Jul 03 15:08:48 heyho Jul 03 15:14:01 playya_: heyho Jul 03 15:19:20 mrmoku: that's indeed a concern with such a concept Jul 03 15:20:21 a few smart optimizatons are possible though Jul 03 15:32:53 mickey|daddy: ping Jul 03 17:14:29 freesmartphone.org: 03morphis 07aurora * ra09e8ca649f8 10/aurora-systemmanager/systemmanager/controller.vala: aurora-systemmanager: refactor suspend handling in a own method Jul 03 17:14:30 freesmartphone.org: 03morphis 07aurora * r960f46838bd3 10/aurora-applications/app-phone/PinRequestPage.qml: aurora-applications: there is no global theme instance anymore Jul 03 17:14:34 freesmartphone.org: 03morphis 07aurora * rb0ff30b8f6c8 10/aurora-daemon/aurora/extensions/agents.py: aurora-daemon: distribute call status events Jul 03 17:19:36 DocScrutinizer: started to read backlog of our ACI conversations... Jul 03 17:19:48 yo Jul 03 18:09:09 DocScrutinizer: one question... let's there there is an incoming call and the ringtone is being played with -Dringtone... you pick up and the phone app requests the gsm_earpiece and mic_gsm paths Jul 03 18:09:22 DocScrutinizer: then there is another incoming call while you're still on the phone Jul 03 18:09:29 DocScrutinizer: what happens? Jul 03 18:10:13 mrmoku: the modem will output a short "beep" by itself to the earpiece. Jul 03 18:10:22 PaulFertser: do all modems do that? Jul 03 18:10:38 I mean is that some kind of standard thing? Jul 03 18:10:45 is that a firmware thing or? Jul 03 18:11:00 mrmoku: I don't know as my provider doesn't allow concurrent calls inbound Jul 03 18:11:03 mrmoku: i'd guess that's likely, but i have no real proof. We should ask n900 guys to know how their modem performs. Jul 03 18:11:11 pabs3: modem firmware, yes. Jul 03 18:11:42 ok Jul 03 18:12:08 so with osmocombb you could get different behaviour, maybe a user-chosen tone instead of a beep Jul 03 18:13:07 pabs3: i do not see how making this configurable might be beneficial. Jul 03 18:15:52 Currently all i get from this feature is a PAIN. Someone calls me while i'm talking with the other person and oeventsd switches profile, so i'm unable to continue _both_ these talks until i release both and call back :/ Jul 03 18:16:36 LOL Jul 03 18:17:30 oeventsd switches to play_ringtone ? NICE :-P Jul 03 18:17:52 If i wasn't such a weirdo, that would really offend my peers i guess. Jul 03 18:18:03 * pabs3 wonders if GSM allows the phone to have multiple calls running at once, Jul 03 18:18:26 mrmoku: that's exactly what fsoaudiod is all about. The call setup has to be higher prio than the ringtone_playback one Jul 03 18:18:29 pabs3: yes, you can join the calls to have a "conference". Jul 03 18:19:53 mrmoku: I.E alsa virtual devices gsm_earpiece and mic_gsm don't allow allocation of ringtone Jul 03 18:20:46 as, according to PaulFertser, this would tear those pathes down, and they shall be higher prio than ringtone path Jul 03 18:22:24 freesmartphone.org: 03mok 07cornucopia * r78e2520b157b 10/fsogsmd/ (src/ppp/plugin.vala vapi/ppp.vapi): Jul 03 18:22:25 freesmartphone.org: fsogsmd: ppp: mark username and password as out params Jul 03 18:22:25 freesmartphone.org: With newer vala this seems to be necessary as without Jul 03 18:22:25 freesmartphone.org: it it will assert on one of those two being null. Jul 03 18:22:25 freesmartphone.org: fixes GPRS on GTA02 :-) Jul 03 18:22:25 freesmartphone.org: Signed-off-by: Klaus Kurzmann Jul 03 18:22:26 freesmartphone.org: 03mok 07cornucopia * r57762e0edf9c 10/fsoaudiod/ (4 files in 3 dirs): Jul 03 18:22:26 freesmartphone.org: Merge branch 'gsmvoice_alsa_cmtspeechdata+buffer_threads' Jul 03 18:22:27 freesmartphone.org: Conflicts: Jul 03 18:22:27 freesmartphone.org: fsogsmd/src/ppp/plugin.vala Jul 03 18:22:28 freesmartphone.org: fsogsmd/vapi/ppp.vapi Jul 03 18:22:28 freesmartphone.org: Signed-off-by: Klaus Kurzmann Jul 03 18:23:08 (actually it probably conflicts only for gs,_earpiece, though it doesn't really have to: you as well can merge the both pathes pcm_to_earpiece (for ringtone) and gsm_to_earpiece (for call audio) Jul 03 18:23:08 DocScrutinizer: yeah, my question would have been how to get -Dringtone to do that little beep in the earpiece while being on a call Jul 03 18:23:22 but as that's obviously done by the modem directly... Jul 03 18:23:35 see last line Jul 03 18:24:07 pcm_to_earpiece used to mix arbitrary sound into gsm_to_earbiece Jul 03 18:24:16 s/b/p/. Jul 03 18:24:59 that's the idea (well one of the basic ideas) behind ACI Jul 03 18:25:15 the both pathes don't conflict Jul 03 18:25:40 you can playback to earpiece from GSM and from PCM-D/A same time Jul 03 18:25:53 so the pathes merge Jul 03 18:26:04 rather than conflict Jul 03 18:26:18 hmm... that would mean the ringtone get's played to the earpiece then? Jul 03 18:26:49 and it's some upper level piece of code's job to not play the ringtone while on call? Jul 03 18:26:58 if your ringtone playback process uses a virtual device that is defined to play to earpiece then yes Jul 03 18:27:00 but a beep instead Jul 03 18:27:24 not though for pcm_to_speaker which clearly conflicts and would fail to open Jul 03 18:27:28 would gsm_speaker and pcm_speaker conflict? Jul 03 18:27:31 ahh ok :) Jul 03 18:27:58 gsm_to_speaker and pcm_to_speaker merge nicely as well Jul 03 18:28:32 *_to_earpiece doesn't usually merge with *_to_earpiece Jul 03 18:28:47 depends on particular details Jul 03 18:28:55 which then means I get the ringtone (which obviously usually is pcm_to_speaker) while I have gsm_to_speaker enabled... Jul 03 18:28:58 hmm Jul 03 18:29:11 if there are conflicting function blocks in mixer, as defined for the particular path Jul 03 18:31:26 it's fsoaudiod's duty to make sure play_rintone_to_speaker (which is one instance of pcm_to_speaker) conflict with gsm_to_speaker - though maybe the pathes do not really conflict on a path-definition-level Jul 03 18:33:13 you may have another virtual device play_notification_to:speaker that is also an instance of pcm_to_speaker but does NOT conflict with gsm_to_speaker Jul 03 18:33:34 hope I did a good job completely puzzling you ;-D Jul 03 18:33:42 indeed :P Jul 03 18:34:07 bear with me, still in resume mode Jul 03 18:34:25 sure... as you have to bear with me too in understanding all that :) Jul 03 18:34:32 np Jul 03 18:35:41 how do we know the volume control of the current route? you suggested $VAR... and then reset the complete route with $VAR replaced by the changed volume, right? Jul 03 18:36:03 yup Jul 03 18:36:16 along that path Jul 03 18:36:33 and muting is always setting volume to 0 ? or are'nt there cases where we have an extra mute switch? Jul 03 18:37:39 I found the extra mute switch seems to not work for unmute, so you have to set volume to the level you want anyways, via amixer. maybe a bug in alsamixer API Jul 03 18:37:59 dunno, have to look into that, but basically setting volume to 0 is fine Jul 03 18:38:25 I have a strange problem, maybe someone here can help me: Jul 03 18:38:36 - I have a program which accesses the framebuffer directly Jul 03 18:38:49 - I want to suspend the device with echo mem > /sys/power/state Jul 03 18:39:14 DocScrutinizer: ok and makes it easier too Jul 03 18:39:15 - After executing the echo mem > /sys/power/state the calls hangs until I kill it with CTRL+C Jul 03 18:39:29 - After the kill the device goes into suspend Jul 03 18:39:49 lol Jul 03 18:40:17 I bet that's a funny one Jul 03 18:40:27 - when I am using directfb to access the framebuffer, the suspend works but the application is dieing after the device resumse Jul 03 18:40:34 DocScrutinizer: for sure ... Jul 03 18:41:21 the dieing part is easy: framebuffer isn't preserved during suspend Jul 03 18:41:43 I.E. the framebuffer ram content gets garbled Jul 03 18:41:58 ok Jul 03 18:42:03 so going to suspend means the famebuffer resource gets invalid Jul 03 18:42:38 blowing chunks is best the fb-driver can do after resume Jul 03 18:42:48 my take on it Jul 03 18:42:59 so I should take a look on the framebuffer driver Jul 03 18:43:05 yup Jul 03 18:43:18 it's not suspend-safe I guess Jul 03 18:43:32 the problem is in webOS it's working without any problems with the same kernel Jul 03 18:43:38 so they have a workaround somewhere Jul 03 18:43:47 :nod: Jul 03 18:44:09 but whats the problem with the hanging "echo mem > /sys/power/state"? Jul 03 18:44:37 saving fb conrent to usual ram, then deallocating/closing fb prior to suspend? Jul 03 18:44:58 don't ask me about that funny part Jul 03 18:45:42 hm Jul 03 18:45:51 * Simply return 0 and let fbmem continues to send out fb notifications, but Jul 03 18:45:59 damn it Jul 03 18:46:00 maybe the suspend finds there's still a active process in kernel io (the very echo >) and thus suspends suspend until the IO gets terminated. Sth along that line Jul 03 18:46:06 * fb0 should not be blanked in WebOS as it needs to be available at all times. Jul 03 18:46:12 * Simply return 0 and let fbmem continues to send out fb notifications, but Jul 03 18:46:18 * no actions will be performed Jul 03 18:46:25 thats whats said in the kernel source Jul 03 18:47:00 so it's never blanking the framebuffer, so it will have the same content after resume? Jul 03 18:47:00 sounds related Jul 03 18:47:37 I'm not sure about the fb-ram_not_refreshed_during_suspend part Jul 03 18:48:10 but the ram should stay the same while suspend? Jul 03 18:48:15 s/suspend/suspended/ Jul 03 18:48:17 morphis meant: but the ram should stay the same while suspended? Jul 03 18:48:33 on FR we found video-ram to get first pixel errors after several seconds, in suspend. IIRC Jul 03 18:49:23 ok Jul 03 18:49:39 it was pretty good to keep content partially intact for several minutes Jul 03 18:49:51 but basically it degraded Jul 03 18:50:07 can't reacll all the circumstances of that finding Jul 03 18:50:32 and webOS pre hw is a completely different thing Jul 03 18:50:41 so no clue at all about it Jul 03 18:51:09 in 'general linux' fb probably is declared tainted by resume Jul 03 18:51:18 ok Jul 03 18:51:57 unless your driver handles suspend requests by allocating memory and buffering the video ram there Jul 03 18:53:09 in the early years of APM you had to unmount the gfx driver to handle suspend/resume properly, as the drivers usually didn't know how to deal with suspend requests Jul 03 18:56:19 morphis: (^C) isn't it like suspend sends a sigstop to all processes? Jul 03 18:56:40 DocScrutinizer: the kernel does this? Jul 03 18:57:35 that would explain why the IO > /sys/power/state never finishes, and that maybe blocks suspend as it waits for IO to finsih Jul 03 18:58:15 something funny has to happen there, I have no really good explanation :-) Jul 03 18:59:00 *sigh* Jul 03 18:59:18 the whole suspend idea is so completely nuts for handheld Jul 03 18:59:24 DocScrutinizer: but it only hangs when the framebuffer is used Jul 03 18:59:29 :) Jul 03 18:59:33 ooh Jul 03 18:59:46 so it's even more screwed Jul 03 19:00:40 try (sleep 5; echo mem > /sys/power/state) >/dev/null 2>&1 Jul 03 19:00:52 will check this Jul 03 19:01:12 hm, the webOS userland software says something about blanking/unblanking the framebuffer Jul 03 19:01:48 even Jul 03 19:01:52 try (sleep 5; echo mem > /sys/power/state) >/dev/null 2>&1 & Jul 03 19:03:43 try (sleep 5; echo mem > /sys/power/state; echo 100 >/sys/leds/vibrator/brightness) >/dev/null 2>&1 & Jul 03 19:04:10 and see if vibrator kicks in *after* resume Jul 03 19:04:39 will check this Jul 03 19:04:50 so you could replace it with e.g. a dbus-send to notify system about it just resumed Jul 03 19:04:58 currently running the webOS userland to get a full strace log Jul 03 19:05:16 o/ Jul 03 19:05:19 bbl Jul 03 19:07:03 hm, it looks like webOS is doing the caching it self "Linux Fb1: Num Buffers: 3" Jul 03 19:09:38 :nod: Jul 03 19:18:31 hi all Jul 03 19:23:41 angelox: heyho Jul 03 19:24:08 hi morphis,did you see my last messages yesterday ? i pinged you too much :) sorry for that! Jul 03 19:25:15 angelox: no, but about which topic was your question? Jul 03 19:26:40 morphis: wasn't a question,i discovered(i say that because i got nervous to discover that :) ) a variable to export to make Aurora use tslib's calibration file and work fine on n900,since out-of-the-box touchscreen doesn't work fine... Jul 03 19:27:08 ok Jul 03 19:27:16 you use /etc/pointercal for it? Jul 03 19:28:00 for calibration,yes Jul 03 19:28:18 but i'm not sure where should i put that variable.. Jul 03 19:28:31 maybe /etc/profile.d/tslib.sh Jul 03 19:30:26 but,btw,i don't know if you did any commit,so i don't know if that variable i said is important :) Jul 03 19:33:10 which one is it? Jul 03 19:34:06 1 minute please... Jul 03 19:34:14 let me open my history :) Jul 03 19:36:32 morphis: export QWS_MOUSE_PROTO="Tslib:/dev/input/touchscreen0" Jul 03 19:37:14 i got nervous because i didn't know that tslib didn't work and Tslib work on variable :) Jul 03 19:37:50 angelox: ok, that should go into the qte.sh profile script Jul 03 19:38:57 the strange is: i don't have no more that script on profile.d on my new image,maybe some do_rootfs error,i don't know Jul 03 19:41:13 no Jul 03 19:42:47 the problem is fixed with the my last push Jul 03 19:45:18 oh ok,so that variable isn't needed? Jul 03 19:48:35 it is Jul 03 19:48:44 but you need to create a own qte.sh Jul 03 19:48:49 for the n900 Jul 03 19:48:54 which we need to include in oe Jul 03 19:49:39 hmm ok Jul 03 19:49:46 thank you for explanation :) Jul 03 19:49:49 i'll do it Jul 03 19:51:09 ok Jul 03 19:51:35 DocScrutinizer: in your vision of ACI... would something like gsm_to_speaker be 'exposed' to be usable via aplay -D gsm_to_speaker ? Jul 03 19:59:02 morphis: sorry,n900 doesn't need that variable as default qte.sh already uses it i saw. Jul 03 19:59:21 angelox: ok Jul 03 20:02:40 angelox: but arora-fb-image is booting fine on the n900? Jul 03 20:04:09 morphis: yes,only daemon wasn't working,it didn't open aurora,but i don't know right now after git pull,i'll build an image and test it,thank you! Jul 03 20:07:02 mrmoku: that's actually imleme^H^H configuration dependant Jul 03 20:07:30 mrmoku: my current notion and feeling tends to say yes Jul 03 20:08:17 though obviously exactly this particular "device" doesn't make much sense for aplay -D ;-) Jul 03 20:08:48 DocScrutinizer: yeah, thats why I chose that particular one :) Jul 03 20:09:27 DocScrutinizer: and what does -Ddefault ? Jul 03 20:09:42 I'd nevertheless prefer some dialer or whatever did a "aplay -D gsm_to_speaker /dev/zero" to open a null device that has only purpose to trigger setup of the mixer path Jul 03 20:10:29 hmm... I'd prefer doing that with a dbus call to fsoaudiod Jul 03 20:10:59 (default) actually I deprecate using default at all. But it needs some sane route nonetheless, I suggest pcm_to_speaker assigned to alias !pcm.default Jul 03 20:11:30 ok Jul 03 20:11:50 (dbus) would mean you revert to having a special management for GSM in fsoaudiod Jul 03 20:11:57 on *all* platforms Jul 03 20:12:16 even on those that have a sane alsa device for modem audio Jul 03 20:12:55 there is no difference if I do aplay -D gsm_to_speaker or fsoaudiod.SetDevice gsm_to_speaker Jul 03 20:14:42