**** BEGIN LOGGING AT Mon Dec 13 02:59:58 2010 Dec 13 06:13:27 ~moo Dec 13 06:13:27 * apt mooooooooo! I am cow, hear me moo, I weigh twice as much as you. I am cow, eating grass, methane gas comes out my ass Dec 13 06:16:27 ~mäh Dec 13 06:20:18 she doesn't know how to bah like a german sheep Dec 13 06:20:24 ~bah Dec 13 06:20:24 extra, extra, read all about it, bah is everyone's other favourite word (see heh) Dec 13 06:20:37 ~baah Dec 13 06:20:37 baaaaaaaah Dec 13 06:21:52 hehe Dec 13 06:22:48 ~bark Dec 13 06:22:49 * apt barks, like a rabid dog. Dec 13 06:22:55 ~howl Dec 13 06:22:55 AROOOOOOOO! Dec 13 06:23:13 she's good with animal voices, isn't she? Dec 13 07:15:01 ~miau Dec 13 07:18:24 mickeyl: good... we can solve then one of the other 'without udev' issues too... and start bluetoothd :) Dec 13 07:22:47 *burp* Dec 13 07:25:46 DocScrutinizer: apt is female? Dec 13 07:26:00 ~attack mrmoku Dec 13 07:26:00 * apt grabs a pen, screams like she's possessed, and begins chasing mrmoku Dec 13 07:26:07 ;) Dec 13 07:26:21 * mrmoku hides Dec 13 07:27:25 sometimes she's quite androgyne though Dec 13 07:27:32 ~rape mrmoku Dec 13 07:27:32 * apt takes mrmoku behind the WallMart and makes a few grunts and screams Dec 13 07:27:33 hehe Dec 13 07:27:39 not really ladylije Dec 13 07:27:48 no, not really Dec 13 07:28:00 hide in shame apt Dec 13 07:29:53 mrmoku: you got my "don't shoot your speakers" warning? Dec 13 07:30:40 DocScrutinizer: yeah Dec 13 07:30:44 k Dec 13 07:30:48 DocScrutinizer: GNutoo added it to our todo Dec 13 07:31:04 http://wiki.freesmartphone.org/index.php/Hardware/N900/TODO Dec 13 07:31:10 first point under URGENT :-) Dec 13 07:34:18 umm, LIS302 can not be "disabled". You can switch it off, via some low-power-mode bit in CTRL-X register Dec 13 07:34:39 ok Dec 13 07:35:55 and charging isn't really a good idea to implement completely in kernel. mickey|zzZZzz and mrmoku got a link to a API spec suggestion draft for bq24150 driver in kernel. Everything beyond (logic etc) needs to be userland Dec 13 07:37:00 I'll finish that spec if somebody has reviewed it and commented if it meets common sense of kernel API design Dec 13 07:40:07 ok Dec 13 07:40:37 well, mickey|zzZZzz already said he supports the approach, but I need some more open free critics on it Dec 13 07:44:48 (lis302dl accelerometer) the maemo driver is rather nice, if only they'd expose the parameter settings for thresholds, filters, and differential mode. Generally speaking you always should use differential mode aka HPF, to trigger IRQ on movement. *NEVER* poll! Dec 13 07:45:48 fb says that dos has birthday today, _again_? :) Dec 13 07:45:58 iirc he had b-day about a month ago :) Dec 13 07:46:54 well, I have two birthday dates, exactly one month apart Dec 13 07:47:37 ./openmoko-cdevel-2009-11-24:17:30 < mrmoku> dos1: happy birthday then :) Dec 13 07:47:52 ./openmoko-cdevel-2010-11-24:17:53 < mrmoku> dos1: happy birthday :) Dec 13 07:48:06 mrmoku: you were 23 minutes late this year ;0 Dec 13 07:48:20 I guess mrmoku has a set of fackng clever scripts :-P Dec 13 07:48:34 he probably wants more chicks wishing him luck on fb today :) Dec 13 07:49:10 ...and a broken NTP :-P Dec 13 07:49:29 :) Dec 13 07:49:54 and chrome supports scrolling up again with mouse wheel after upgrade, yay :) Dec 13 07:54:51 and JaMa has an awesome amazing archive :-D Dec 13 07:59:26 JaMa: do you really mean you and dos use facebook? :-O Dec 13 08:02:32 I have fb account, not sure if that's enough to say I'm using it :) Dec 13 08:03:22 but it's registered in my finch to talk with friends who finally stopped using ICQ (most popular IM here) Dec 13 08:05:43 I once disabled the icq transport and decided that those whom i'm not able to talk with anymore are not my friends, easy as that. Dec 13 08:07:04 well before fb, there was about 80% people with icq as only im Dec 13 08:07:22 now it's about 10% because the rest has fb and icq Dec 13 08:08:51 I mean i really do not think that's a good idea to talk with folks who are not caring the slightest to listen to me, so if they do not need me, fine i do not need them. Dec 13 08:09:28 JaMa: hehe Dec 13 08:09:41 DocScrutinizer: just a good calendar with repeating events Dec 13 08:38:06 so I gather you haven't implemented yet my universal concept of events, in opimd Dec 13 08:39:20 like 'send birthday greetings for dos1 to #openmoko-cdevel - every year 23 minutes later' ? Dec 13 08:39:23 no Dec 13 08:39:26 :P Dec 13 08:39:48 oh, the "23 min later" part is actually a bit tricky Dec 13 08:40:57 object.property("next_event", "now+1y+23min") Dec 13 08:42:31 object.property(self.new_event.clone, "now+1y+23min") Dec 13 08:43:21 and now make +23m modulo 1 day :) Dec 13 08:43:44 ayyy Dec 13 08:43:55 * mrmoku is quite happy *not* being an opimd developer right now ;) Dec 13 09:58:50 mickey|office: morning... will you do the bluetooth plugin? Dec 13 09:59:06 yes Dec 13 09:59:10 good morning Dec 13 09:59:12 good :) Dec 13 10:01:03 mickey|office: how does the alsa-plugin determine which mixer control to take for Get/SetVolume? Dec 13 10:04:09 mrmoku: iirc the scenario description contains the index of the main volume control Dec 13 10:04:51 idxMainVolume Dec 13 10:04:53 yep Dec 13 10:07:14 BunchOfMixerControls( FsoDevice.MixerControl[] controls, uint idxMainVolume = 0 ) Dec 13 10:07:28 that explains why it takes the headphone vol... it's the first one Dec 13 10:08:54 looks like there is now way to set it via config Dec 13 10:11:29 ok, i guess that was planned, but not completed yet :) Dec 13 10:11:40 shouldn't be hard to add though, right? Dec 13 10:20:08 right Dec 13 10:37:03 mickey|office: something like this? http://paste.pocoo.org/show/304230/ Dec 13 10:43:57 DocScrutinizer: still awake? Dec 13 10:44:25 already awake :-D Dec 13 10:44:29 :) Dec 13 10:44:43 what is the preferred way to adjust volume on n900? Dec 13 10:44:47 use the PCM volume? Dec 13 10:44:50 LOL Dec 13 10:44:55 or the appropriate volumes like headphone Dec 13 10:44:56 If only I knew Dec 13 10:45:05 hehe, ok Dec 13 10:45:59 the whole PA + mafw maemo setup is so... eeeew, and obscure, and not at all documented. I'm seriously lost on most aspects of the operation principles Dec 13 10:47:02 mrmoku: that looks pretty cool Dec 13 10:47:12 mickey|office: good, will commit then :) Dec 13 10:47:16 cool Dec 13 10:47:38 there's alsaped (ALSA Policy Enforcer Daemon), there seems to be a similar policy enforcer associated to PA, according to http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio_miniconf_slides.pdf. Dec 13 10:49:04 then you got PA, gstreamer, dunno what else. Honestly, it seems nobody really wrapped his head around it AND has bothered to write a mini HOWTO about it Dec 13 10:49:49 freesmartphone.org: 03mok 07cornucopia * r358a13172d14 10/fsodeviced/src/plugins/router_alsa/plugin.vala: Dec 13 10:49:49 freesmartphone.org: fsodeviced: make the index of main volume configurable for router_alsa Dec 13 10:49:49 freesmartphone.org: Signed-off-by: Klaus Kurzmann Dec 13 10:50:24 DocScrutinizer: ok :/ Dec 13 10:50:38 DocScrutinizer: guess we will try to do it different :) Dec 13 10:51:56 mrmoku: generally speaking, you always should use hw attenuators rather than sw calculations to attenuate the digital data. DAC as well as ADC work best at a -6..0dBm peak level Dec 13 10:54:24 attenuating the level at a digital domain will introduce more quantisation noise and distortion, both on the attenuation process itself as also during AD/DA conversion Dec 13 10:54:25 DocScrutinizer: that means leave PCM Volume at some sane level and use HP DAC instead, right? Dec 13 10:54:32 right Dec 13 10:54:42 ok, thanks Dec 13 10:55:08 GNUtoo|laptop: hi Dec 13 10:55:10 11:51 < DocScrutinizer> mrmoku: generally speaking, you always should use hw attenuators rather than sw calculations to attenuate the digital data. DAC as well as ADC work best at a -6..0dBm peak level Dec 13 10:55:15 11:53 < mrmoku> DocScrutinizer: that means leave PCM Volume at some sane level and use HP DAC instead, right? Dec 13 10:55:18 11:53 < DocScrutinizer> attenuating the level at a digital domain will introduce more quantisation noise and distortion, both on the attenuation process itself as also during AD/DA conversion Dec 13 10:55:22 11:53 < DocScrutinizer> right Dec 13 10:55:29 mrmoku, hi Dec 13 10:55:43 I tried radios Dec 13 10:55:49 and I failed Dec 13 10:56:01 radios like FM radio? Dec 13 10:56:04 TX and RX? Dec 13 10:56:05 yes Dec 13 10:56:07 yes Dec 13 10:56:09 ok Dec 13 10:56:13 I failed with both Dec 13 10:56:25 basically RX enabler is proprietary in maemo Dec 13 10:56:29 and the kernel says: Dec 13 10:56:35 mrmoku: why the repost Dec 13 10:56:37 ? Dec 13 10:56:43 DocScrutinizer: for GNUtoo|laptop Dec 13 10:56:47 oh Dec 13 10:57:01 because he wanted to go the PCM Volume way :) Dec 13 10:57:19 I2C driver for BCM2048 FM Radio Receiver Dec 13 10:57:24 bcm2048 3-0022: BCM I2C error! Dec 13 10:57:30 bcm2048 3-0022: Is Bluetooth up and running? Dec 13 10:57:35 bcm2048: probe of 3-0022 failed with error -5 Dec 13 10:57:35 heh Dec 13 10:58:04 but in another hand I saw in maemo wiki that if used unproperly the bcm2048 can destroy the speakers Dec 13 10:58:14 just what we were talking about Dec 13 10:58:23 mrmoku: in your above post, I missed the " use HP DAC instead " part. What do you mean by that? Dec 13 10:58:42 fmtx in another hand is enabled etc Dec 13 10:58:45 I can do Dec 13 10:58:47 fm on Dec 13 10:58:59 DocScrutinizer: Item: HP DAC [dB gain: 0.00, 0.00] Dec 13 10:59:27 and fm 100.0 65535 Dec 13 10:59:29 DocScrutinizer: is the mixer for stereout, no? Dec 13 10:59:34 I set fmtx in alsamixer Dec 13 10:59:37 and nothing happens Dec 13 10:59:43 hmm Dec 13 11:00:02 I tried messing with alsamixer for a very long time Dec 13 11:00:05 nothing came out Dec 13 11:00:25 aaah, yes. Some codecs have a digital attenuator based on a much better ADC/DAC, like 24bit ADC and result in digital PCM is only 16bit. So the codec has 8bit for a digital attenuation Dec 13 11:00:33 strangely v4l2-ctl had Signal strength/AFC : 0%/0 Dec 13 11:01:18 mrmoku: you got the datasheet for the codec? Dec 13 11:01:26 DocScrutinizer: no Dec 13 11:01:33 you *need* that Dec 13 11:01:47 otherwise you'll have no clue what you're actually doing Dec 13 11:03:20 http://wiki.maemo.org/N900_Hardware_Audio_Codec Dec 13 11:03:26 for a starting point Dec 13 11:03:33 * GNUtoo|laptop already read a codec datasheet and it was complicated Dec 13 11:03:51 tlvaic33 or something like that Dec 13 11:04:15 ah here it's nearly the same Dec 13 11:04:21 it's aic34 Dec 13 11:04:42 how is it connected? Dec 13 11:04:45 i2s + i2c? Dec 13 11:04:51 DocScrutinizer: this one? http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=tlv320aic31&fileType=pdf Dec 13 11:05:05 I guess yes Dec 13 11:05:37 GNUtoo|laptop: yep Dec 13 11:05:51 ok Dec 13 11:05:57 thanks Dec 13 11:06:32 I remember there was something about bus master/slave Dec 13 11:06:42 for i2s Dec 13 11:07:32 isn't it aic34 Dec 13 11:07:33 ? Dec 13 11:07:48 http://focus.ti.com/docs/prod/folders/print/tlv320aic34.html#technicaldocuments Dec 13 11:08:05 yep, it's the 34, not the 32 or 31 Dec 13 11:08:07 rx51.c has some aic34 occurences Dec 13 11:10:46 DocScrutinizer, btw do you have any clue for the FM chips? Dec 13 11:10:58 specially the transmitter Dec 13 11:11:19 http://focus.ti.com/lit/ds/symlink/tlv320aic34.pdf Dec 13 11:11:41 yes, sure Dec 13 11:12:32 http://wiki.maemo.org/N900_FM_radio_transmitter Dec 13 11:12:52 I've read that Dec 13 11:14:09 do you know how to: Dec 13 11:14:16 *be sure the FM transmitter is transmitting Dec 13 11:14:34 *mess with alsamixer to transmit what you're playing Dec 13 11:15:29 hmm, make sure: use radio to receive the transmission. Mess: no idea, but it should be straight forward Dec 13 11:16:25 for mess if it's straingtforward then I already know how to use it Dec 13 11:16:55 so maybe it's the v4l stuff Dec 13 11:16:59 I did Dec 13 11:17:02 fm on Dec 13 11:17:11 and: Dec 13 11:17:26 fm 100.0 65535 Dec 13 11:17:32 I bet it's not sufficent Dec 13 11:17:38 freesmartphone.org: 03mok 07cornucopia * rbd826254d53c 10/fsodeviced/src/plugins/router_alsa/plugin.vala: Dec 13 11:17:38 freesmartphone.org: fsodeviced: respect the fact mixer indices are uints Dec 13 11:17:38 freesmartphone.org: Signed-off-by: Klaus Kurzmann Dec 13 11:18:15 GNUtoo|laptop: according to schematics the FMTX is driven by the same audio lines as HP-AMP Dec 13 11:18:27 ah ok Dec 13 11:19:05 so enabling the FMTX will immediately start to transmit what you hear in headset Dec 13 11:19:33 and you can switch off headset output by powering down the AMP Dec 13 11:19:48 codec mixer settings aren't involved at all Dec 13 11:21:06 I fsckng wonder what FMTX_INT IRQ line to SOC might be for Dec 13 11:23:06 could be some "I've finished" signal, when using the scan-for-vacant-chan function, or sth. Or maybe when buffer for that radio-text TMI(?) runs empty and needs refresh from system Dec 13 11:37:45 hmmm anyway I should receive RDS Dec 13 11:37:48 and I don't Dec 13 11:50:34 I don't understand the code Dec 13 11:50:39 I don't see some .something Dec 13 11:50:43 as usual Dec 13 11:54:51 GNUtoo|laptop: for RDS you need to check how maemo apps are doing it, I guess. There's a plugin or sth, to have MP3 mediaplayer song info via RDS Dec 13 11:55:25 also N900 always has a station signature saying "N900" IIRC Dec 13 11:55:55 (only of maemo driver for FMTX and maemo userland is used) Dec 13 11:56:06 the RDS are sysnodes IIRC Dec 13 11:57:25 there are sys nodes Dec 13 11:57:40 /sys/class/i2c-adapter/i2c-2/2-0063/rds_pi Dec 13 11:57:42 /sys/class/i2c-adapter/i2c-2/2-0063/rds_pty Dec 13 11:57:43 /sys/class/i2c-adapter/i2c-2/2-0063/rds_ps_name Dec 13 11:57:45 /sys/class/i2c-adapter/i2c-2/2-0063/rds_radio_text Dec 13 11:57:46 /sys/class/i2c-adapter/i2c-2/2-0063/rds_enabled Dec 13 11:57:50 yes Dec 13 11:57:51 that Dec 13 11:58:04 and it's enabled Dec 13 11:58:12 and in the driver it's enabled by default Dec 13 11:58:24 and it says Dec 13 11:58:29 Si4713 Dec 13 11:58:36 or rather Dec 13 11:58:38 should say Dec 13 11:59:59 Hmm, now that I think about it, I now got a RDS enabled FM receiver: my devel-N900 :-P Dec 13 12:00:08 so I could finally check Dec 13 12:00:34 ok, thanks a lot!!! Dec 13 12:00:53 basically I think there is a power on somewhere that I'm missing Dec 13 12:58:05 mickey|office: hmm... you gpio_input cleanup somehow has broken the headset jack :) Dec 13 12:58:11 2010-12-13T12:52:34.845123Z [WARN] KernelAggregateInputDevice : Received release event before pressed event!? Dec 13 12:58:49 that's only a warning, isn't it? Dec 13 12:58:57 yeah Dec 13 12:59:01 it should work despite of that Dec 13 12:59:05 but before it was switching scenario Dec 13 12:59:09 does not do that anymore Dec 13 12:59:18 switching scenario? via oeventsd? Dec 13 12:59:27 hmm Dec 13 13:00:07 good question :P Dec 13 13:00:21 there is now rule for that, no Dec 13 13:00:32 then i don't see how that could work :) Dec 13 13:00:34 ahh Dec 13 13:00:53 I think we're doing that in phoneuid Dec 13 13:01:03 and that might just not work, because fsodeviced restarted Dec 13 13:01:06 so nvm for now :) Dec 13 13:01:11 *phew* :) Dec 13 13:01:21 * mrmoku will find some other bug ;) Dec 13 13:01:27 hehe, i'm sure you wil Dec 13 13:24:15 GNUtoo|laptop: studying the datasheet? :P Dec 13 13:24:46 mrmoku, no I was away Dec 13 13:25:42 GNUtoo|laptop: ahh ok :) Dec 13 13:25:52 mickey|office: so... maybe this one? Dec 13 13:25:52 [ 337.306579] i2c_omap i2c_omap.2: timeout waiting for bus ready Dec 13 13:25:56 dmesg is full of it Dec 13 13:28:56 mrmoku, hi Dec 13 13:29:05 is http://trac.freesmartphone.org/ticket/595 in latest shr-u? Dec 13 13:29:25 pespin: afaik no Dec 13 13:29:25 this may be why enjoy isn't working with headsets maybe Dec 13 13:29:36 JaMa, ok Dec 13 13:29:37 yeah, don't think so Dec 13 13:29:51 I'll try later Dec 13 13:29:54 * mrmoku too Dec 13 13:30:14 some days ago I tried them and they made enjoy work Dec 13 13:30:20 * JaMa won't then Dec 13 13:30:23 but I'm sure some upgrade killed them Dec 13 13:40:06 pespin: hmm... interesting... mplayer hangs when plugging in the headset... and continues when plugging it out Dec 13 13:40:58 mrmoku, I think something similar happened to me with enjoy when I tried the other day Dec 13 13:50:22 JaMa: looks like the headset scenario was not converted to 2.6.34 Dec 13 13:57:36 there was only one patch from Marco adding .34 version Dec 13 13:59:41 but only diff between .31/headset and .34/headset are quotes Dec 13 14:00:03 JaMa: yeah, and controls have a completely different order Dec 13 14:00:13 only stereoout and gsmhandset seem to be correct Dec 13 14:00:24 looks like he's not using neither headset nor bluetooth :P Dec 13 14:00:55 yes, like me :) Dec 13 14:01:09 * mrmoku has a broken headset anyway Dec 13 14:01:28 mrmoku, the ones in trac are working :) Dec 13 14:01:42 pespin: that fixes headset and gsmheadset Dec 13 14:01:45 at least last time i tried them Dec 13 14:01:48 pespin: still missing the others though Dec 13 14:01:55 mrmoku, ah ok ;) Dec 13 14:03:55 GNUtoo|laptop: btw. did you try to contact fidencio? Dec 13 14:05:51 mrmoku, no I thought you would do it Dec 13 14:07:05 GNUtoo|laptop: ahh, ok... guess he knows you better :) Dec 13 14:07:30 but I can try Dec 13 14:07:34 yes Dec 13 14:07:34 it's about scanner? Dec 13 14:07:46 no,it's about enjoy Dec 13 14:07:51 GNUtoo|laptop: hmm... he's not in #e Dec 13 14:07:52 I've pinged him at least twice since he send those to ML.. Dec 13 14:08:00 mrmoku, #oe Dec 13 14:08:07 ah Dec 13 14:08:22 is [AWAY] Dec 13 14:15:13 freesmartphone.org: 03mok 07cornucopia * rbe5f7df2996a 10/fsodeviced/conf/openmoko_gta/alsa-2.6.34/ (gsmheadset headset): Dec 13 14:15:13 freesmartphone.org: fsodeviced: fix headset and gsmheadset scenarios for gta02 on 2.6.34 Dec 13 14:15:13 freesmartphone.org: Thanks to Paulus for the fixed ones. Note other scenarios still look Dec 13 14:15:13 freesmartphone.org: wrong and need fixing, but at least stereout, gsmhandset, headset and Dec 13 14:15:13 freesmartphone.org: gsmheadset are supposed to work now. Dec 13 14:15:13 freesmartphone.org: Signed-off-by: Klaus Kurzmann Dec 13 14:28:55 freesmartphone.org: 03morphis 07utilities * r55e204e75899 10/palmpre/tsmd/src/ (tsmd.c tsmd.h): Dec 13 14:28:55 freesmartphone.org: palmpre: tsmd: correct formatting Dec 13 14:28:55 freesmartphone.org: Formatted with: Dec 13 14:28:55 freesmartphone.org: -bad -bap -bbb -bl -bli0 -bs -cbi4 -cli4 -i4 -l100 -lp -nbbo -nbc Dec 13 14:28:55 freesmartphone.org: -ncs -npcs -npsl -nut -pi0 -sai -saw -sbi4 Dec 13 14:37:48 freesmartphone.org: 03morphis 07utilities * r5334434a5e93 10/palmpre/tsmd/src/ (tsmd.c tsmd.h): palmpre: tsmd: add vim modeline to code files Dec 13 14:46:45 freesmartphone.org: 03morphis 07utilities * ref0c21d2de0b 10/palmpre/tsmd/src/tsmd.c: palmpre: tsmd: refactor logic for opening touchscreen device into own method Dec 13 14:46:47 freesmartphone.org: 03morphis 07utilities * ra7e17ea9520c 10/palmpre/tsmd/src/tsmd.c: Dec 13 14:46:47 freesmartphone.org: palmpre: tsmd: remove cy8mrln ioctl calls to setup touchscreen Dec 13 14:46:47 freesmartphone.org: The cy8mrln touchscreen is configured by the tslib plugin with calling the right ioctl's Dec 13 14:46:47 freesmartphone.org: with the right values. This is not necessary here. Dec 13 14:54:07 freesmartphone.org: 03morphis 07utilities * r2f5c2b56eefa 10/palmpre/tsmd/src/tsmd.c: palmpre: tsmd: work around compiler warnings Dec 13 15:17:59 freesmartphone.org: 03morphis 07utilities * r74217fb20fa7 10/palmpre/tsmd/src/tsmd.c: Dec 13 15:17:59 freesmartphone.org: palmpre: tsmd: implement interrupt functionality via SIGUSR1/SIGUSR2 Dec 13 15:17:59 freesmartphone.org: As we have to re-open the touchscreen device node from time to time to reset the Dec 13 15:17:59 freesmartphone.org: touchscreen we provide this functionality via the SIGUSR1/SIGUSR2 system signals. SIGUSR1 Dec 13 15:17:59 freesmartphone.org: stops the processing of touchscreen events and SIGUSR2 restarts it. Dec 13 15:34:12 freesmartphone.org: 03morphis 07utilities * re06f646b268c 10/palmpre/tsmd/src/tsmd.c: palmpre: tsmd: restore signal handler after signal was handled Dec 13 15:34:16 freesmartphone.org: 03morphis 07utilities * r9c51620cdadc 10/palmpre/tsmd/src/tsmd.c: palmpre: tsmd: use pause instead of a infinite busy wait loop Dec 13 15:44:06 reading the real radio source code Dec 13 15:44:25 radio-si4713.c and not si4713.c Dec 13 16:18:10 mickey|office: ping Dec 13 16:39:15 JaMa, can you bump new fsodeviced to feeds please? Dec 13 16:42:55 either I'm doing something wrong or the meego kernel repo is serious crap :/ Dec 13 16:45:45 probably good point of time to get dinner :) Dec 13 16:47:59 Heinervdm-Work, playya: ping Dec 13 17:02:58 freesmartphone.org: 03morphis 07cornucopia * rbc8675926621 10/fsodeviced/src/plugins/palmpre_touchscreen/plugin.vala: Dec 13 17:02:58 freesmartphone.org: fsodeviced: palmpre_touchscreen: implement as process guard for the tsm daemon Dec 13 17:02:58 freesmartphone.org: Not finished yet as we need some signal in the org.freesmartphone.Device.Display API when Dec 13 17:02:58 freesmartphone.org: the display changed its power state to get the right point of time when we have to tell Dec 13 17:02:58 freesmartphone.org: the tsm daemon to start/stop reading from the touchscreen interface. Dec 13 17:02:58 freesmartphone.org: Signed-off-by: Simon Busch Dec 13 18:04:24 wtf? wiki down? Dec 13 18:05:52 how long is wiki.openmoko.org been down? Dec 13 18:07:25 freesmartphone.org: 03mickey 07cornucopia * rbe9c74ee9e22 10/fsodeviced/ (4 files in 3 dirs): fsodeviced: n900_powercontrol: add skeleton Dec 13 18:28:19 mickeyl: ping Dec 13 18:28:25 pong Dec 13 18:36:13 freesmartphone.org: 03mickey 07cornucopia * r4ec6b60d73d5 10/fsodeviced/src/plugins/n900_powercontrol/plugin.vala: fsodeviced: n900_powercontrol: create Bluetooth resource and powercontrol that handles the sysfs dance upon activation Dec 13 18:38:12 morphis: pong Dec 13 18:38:44 mickeyl: is there currently any functionality in the FSO api to get the state of the display in a non-active way? Dec 13 18:39:07 I looked through org.freesmartphone.Device.Display but only found some Get/Set methods for the backlight Dec 13 18:40:09 what do you mean w/ non-active and what/when do you want to receive any notifications? Dec 13 18:40:32 the problem is the touchscreen management daemon we have for the palm pre Dec 13 18:40:44 currently it works as long as the display is on Dec 13 18:40:57 if it goes off the touchscreen reports wrong values Dec 13 18:41:11 so we are doing something wrong but don't know what Dec 13 18:41:21 and I don't have the time to debug this Dec 13 18:41:39 so my idea is write a fsodeviced plugin which sends a signal to the tsmd Dec 13 18:42:12 whenever the display turns on/off to tell it that it should turn off listining for events from the touchscreen and reopen it when the display is on again Dec 13 18:42:26 i see Dec 13 18:42:31 thats the idea Dec 13 18:42:36 ok, there are several ways to achieve that Dec 13 18:42:47 perhaps the simplest way would be to listen to idle notifications Dec 13 18:43:07 if that's not exact enough, then we need to teach org.freesmartphone.Device.Display some signals Dec 13 18:43:13 morphis: i don't think that this will work Dec 13 18:43:27 because you won't be fast enough Dec 13 18:43:34 Heinervdm: why not? thats what I am doing manually now Dec 13 18:44:00 but it should work with a delay Dec 13 18:44:14 and would be better than have a non working touchscreen Dec 13 18:44:26 the problem is that the null values are overwritten with wrong values Dec 13 18:44:44 when the screen comes back, right? Dec 13 18:44:49 and this is persistant as long as tslib is runnung Dec 13 18:45:01 no at the moment the screen turns off Dec 13 18:45:16 ok Dec 13 18:45:18 the ts reports events even if the screen is off Dec 13 18:45:34 an easy workaround would be to check for values >100 Dec 13 18:45:52 but then the null values will be overwritten too, right? Dec 13 18:45:56 or the other way around, only accept values <100 Dec 13 18:46:13 only set null values in case of <100 Dec 13 18:46:34 but i don't know if 100 is right on every device Dec 13 18:46:39 it's ok for mine Dec 13 18:47:27 hm ok Dec 13 18:47:43 but that can not be the right solution Dec 13 18:48:06 or is it? Dec 13 18:48:29 SHR: 03mail 07libphone-ui-shr * rb5dcb82eb9db 10/ (3 files in 2 dirs): message-list-view: highlight both incoming and outgoing new messages Dec 13 18:48:31 yes, we should recheck the potential how it changes in x and y direction Dec 13 18:49:03 and use this for the null values Dec 13 18:49:16 and don't correct null values on every read Dec 13 18:49:50 ah ok Dec 13 18:50:02 how much work it is? Dec 13 18:50:10 don't know Dec 13 18:50:29 i don't know if it is even possible Dec 13 18:51:14 will try that and my solution Dec 13 18:51:20 an other way would be to add a counter the normalization and if it hasen't changed for >1 sec then don't do it anymore Dec 13 18:51:38 re-opening the /dev/touchscreen node with tslib initialization should not take so much time Dec 13 18:51:48 yes Dec 13 18:54:18 mickeyl: so listening to the idle notifications should be the correct way? Dec 13 18:54:46 well Dec 13 18:54:55 the problem is that the idle notifications don't give a guarantee Dec 13 18:54:59 hm Dec 13 18:55:02 since they're not hardwired to the display Dec 13 18:55:04 (which is good) Dec 13 18:55:17 i guess it might be better to actually add signals to org.freesmartphone.Device.Display Dec 13 18:55:21 so you can listen to Dec 13 18:55:26 "willTurnOff" and Dec 13 18:55:31 "didTurnOff" Dec 13 18:55:31 etc. Dec 13 18:55:32 something like BacklightPower Dec 13 18:55:51 as signal which sends true/false Dec 13 18:56:08 whenever someones touches set/get backlight methods of org.freesmartphone.Device.Display Dec 13 19:01:52 let me do that now Dec 13 19:02:33 I already have some patches for it :) Dec 13 19:02:34 freesmartphone.org: 03mickey 07specs * rf1822b299c66 10/ (3 files in 3 dirs): add signal org.freesmartphone.Device.Display.BacklightPower() Dec 13 19:02:41 or this way :) Dec 13 19:03:14 freesmartphone.org: 03mickey 07specs * r384df6677e07 10/configure.ac: bump date Dec 13 19:07:49