| freemangordon | dsc_: it is removed after restart only if you didn't abuse it before restart by typing something in the chat window | 00:00 |
|---|---|---|
| dsc_ | right | 00:00 |
| dsc_ | yes thats wrong | 00:00 |
| dsc_ | will fix | 00:00 |
| dsc_ | and also do what you said Re: groupchats | 00:00 |
| freemangordon | ok, cool | 00:00 |
| freemangordon | great | 00:00 |
| freemangordon | perhaps still make a new release before that, because of the segfault fix | 00:01 |
| dsc_ | reading the diffs | 00:01 |
| freemangordon | ok | 00:01 |
| dsc_ | well, I said I will do what you said Re: groupchats but I have not thought of all the "situations" (states) it could possibly go into | 00:04 |
| dsc_ | so will verify we can actually do that | 00:04 |
| freemangordon | yeah, makes sense | 00:05 |
| freemangordon | I think it should be ok, but I could have missed some corner case | 00:05 |
| dsc_ | i think so too | 00:06 |
| dsc_ | (that it will work) | 00:06 |
| freemangordon | dsc_: one more thing: I am not sure how 'own' scrollback messages are stored in rtcom db, but they appear in addressbook 'recent contacts' | 00:20 |
| Wizzup | this is probably something for us to figure out | 00:21 |
| Wizzup | (fmg) | 00:21 |
| freemangordon | yeah, maybe | 00:22 |
| freemangordon | I'll trace what log_event does | 00:22 |
| Wizzup | this depends on the recent contacts query | 00:22 |
| freemangordon | oh, remote_alias is nullptr for message sent from the device | 00:23 |
| dsc_ | sqlite> select * from GroupCache; | 00:23 |
| dsc_ | 8|3|idle/irc/dscqemu0-##maemotest|8|8|0 | 00:23 |
| dsc_ | interesting | 00:23 |
| freemangordon | Wizzup: could that remote_alias make the difference | 00:23 |
| * freemangordon checks | 00:24 | |
| dsc_ | new build btw | 00:39 |
| freemangordon | dsc_: wait | 00:40 |
| freemangordon | (if not late :) ) | 00:40 |
| freemangordon | I have another fix, just have to make the commit | 00:41 |
| dsc_ | more contributions are always good :) | 00:41 |
| dsc_ | and yes you are too late | 00:42 |
| freemangordon | ok, I have to test it anyways :) | 00:43 |
| dsc_ | so we can look into how to get rid of the config stuff in lib/tp.cpp | 00:47 |
| dsc_ | its a bit strange to me, pragmatic solution to save persistent data related to TelepathyChannels: | 00:47 |
| dsc_ | - auto-join | 00:48 |
| dsc_ | - last message received (prevent duplicates) | 00:48 |
| dsc_ | - render things in the overview, needed in some situations | 00:48 |
| dsc_ | perhaps for all 3 points we can find solutions in favor of getting rid of `AccountChannel*` | 00:48 |
| dsc_ | e.g: how to save auto-join in rtcom somehow | 00:48 |
| freemangordon | I don;t think that belongs to rtcom | 00:49 |
| freemangordon | this is application setting | 00:49 |
| dsc_ | true | 00:49 |
| dsc_ | what `AccountChannel*` does is create a temp. obj that represents a channel, in the case Tp has not given us this channel yet | 00:51 |
| dsc_ | architecturally, it is a bit suspicious | 00:52 |
| freemangordon | well, I was wondering why it is needed | 00:52 |
| dsc_ | as lib/tp.cpp should only involve Tp stuff | 00:52 |
| freemangordon | dsc_: https://github.com/maemo-leste/conversations/commit/b55dc99772b7b0e06c95fb2c56103d19d12ba83e | 00:54 |
| freemangordon | I'll appreciate if you make a new release | 00:54 |
| dsc_ | nice | 00:54 |
| freemangordon | thanks! | 00:56 |
| dsc_ | :) | 00:56 |
| Wizzup | ok, I think locally fixed most of the voicecallmgr problems with sphone apart from the randomly no audio issue | 01:42 |
| Wizzup | going to try to look into that now | 01:42 |
| Wizzup | uvos__: so I checked amixer and during calls with voicecall manager and the controls seem to be identical in calls where there is audio and calls where there is no audio | 02:02 |
| Wizzup | so userspace seems to be doing what it should be doing | 02:03 |
| Wizzup | I did not see any errors when asking pulseaudio to switch UCM or not | 02:03 |
| Wizzup | I tried to manually change alsamixer controls and pulseaudio UCM - switch back and forth, and that didn't make it work either | 02:03 |
| Wizzup | so I'm at a loss, I don't think voicecallmanager is doing anything wrong here | 02:04 |
| Wizzup | voicecall-manager (daemon) debug output is also identical when it works and when it doesn't work | 02:06 |
| Wizzup | I guess I'll compare kernel regs next | 02:08 |
| Wizzup | uvos__: /sys/kernel/debug/asoc/Mapphone Audio/cpcap-codec.0 is also identical when it works / doesn't work | 02:19 |
| Wizzup | uvos__: what I can tell right now is that from the relevent regs the CPCAP_REG_TXI (0x0814) seems to be different | 02:33 |
| Wizzup | 0814: 00c2 when it's only one side (remote side can't hear me) and 0814: 0cc2 when it's both sides | 02:33 |
| Wizzup | apparently the /sys/kernel/debug/regmap/spi0.0/registers file is no longer writable so I can't test whether that is it for sure but it mist be | 02:36 |
| Wizzup | so CPCAP_BIT_MB_ON1R and CPCAP_BIT_MB_ON1L are somehow not set | 02:44 |
| Wizzup | this is called the MIC1R Bias and MIC1L Bias in alsamixer | 02:45 |
| Wizzup | tmlind: you might have some ideas too perhaps | 02:46 |
| Wizzup | (this is 6.1) | 02:47 |
| Wizzup | also since when is the registers file no longer writeable? | 02:50 |
| Wizzup | my regtool says as much too: | 03:09 |
| Wizzup | python regtool.py cmp regs_both_works.txt regs_onesideonly.txt | 03:09 |
| Wizzup | Difference in CPCAP_REG_TXI.CPCAP_BIT_MB_ON1L: 1 != 0 | 03:09 |
| Wizzup | Difference in CPCAP_REG_TXI.CPCAP_BIT_MB_ON1R: 1 != 0 | 03:09 |
| Wizzup | hm looks like the define is REGMAP_ALLOW_WRITE_DEBUGFS and I don't see a CONFIG_ option for it | 03:16 |
| Wizzup | uvos__: also very unrelated but if we don't display the dialer buttons in sphone we can't send dtmf | 03:18 |
| Wizzup | any reason not to have those buttons at least clickable within a call? | 03:18 |
| Wizzup | (well visible and clickable) | 03:19 |
| tmlind | Wizzup: there's some kernel kconfig debug option for enabling regmap write | 06:05 |
| tmlind | Wizzup: i think it's the REGMAP_ALLOW_WRITE_DEBUGFS that you have to define manually | 06:07 |
| uvos__ | Wizzup: no reason, its just that the dialer and the call manager are different plugins entirely that thus far share no code | 08:59 |
| uvos__ | tmlind: no you have to chainge a define in the code | 08:59 |
| uvos__ | tmlind: ah yes exactly | 09:00 |
| uvos__ | Wizzup: the registers where never writeable | 09:01 |
| uvos__ | Wizzup: at least not in the time span i have been working with this | 09:01 |
| arno11 | dsc_: freemangordon: conversations update to 0.7.15 (from 0.7.10): it takes only 1 or 2 sec max to show the UI on N900 now, great ! | 09:02 |
| uvos__ | i think its pretty uff for a running applcation to take 2 seconds just to show a window | 09:03 |
| uvos__ | but you kown :P | 09:03 |
| arno11 | :P | 09:04 |
| uvos__ | Wizzup: the main reason why i never implemented dtmf is because on d4 dtmf is exposed via alsa, which is wrong place for it to be | 09:05 |
| uvos__ | Wizzup: and for me to implement / test dtmf in sphone i need some platform where dtmf works correctly via ofono's interface | 09:05 |
| sicelo | uvos__: you likely have "some platform where dtmf works correctly via ofono's interface" :-p | 09:39 |
| uvos__ | sicelo: ok "some platform where dtmf works correctly via ofono where i wont die of brodom wating for sphone to compile" :P | 10:06 |
| uvos__ | anyhow i will implement the ui bits for dtmf, thats not so hard | 10:19 |
| uvos__ | maybe Wizzup can deal with the backend side | 10:19 |
| uvos__ | Wizzup: unfortionaly this means that the non-working audio in vcm and the non-wroking audio in 6.6 are unrelated | 10:21 |
| uvos__ | i was hopeing those where the same problem :| | 10:21 |
| freemangordon | arno11: which UI? main? I would say the better test would be the time needed to show chat | 11:06 |
| Wizzup | uvos__: they might be related but thye are not the same problem | 11:29 |
| Wizzup | uvos__: so in 6.6 for example 0618 is set correctly | 11:29 |
| Wizzup | uvos__: I wrote a python script to bring the audio regs in sync with certain text dump of the regs, but I guess I just modified the define yeah | 11:30 |
| Wizzup | uvos__: oh you wrote unrelated :) | 11:31 |
| Wizzup | yes | 11:31 |
| Wizzup | well, 6.6 is the next step | 11:31 |
| arno11 | freemangordon: i meant UI: it tooks 10 sec before last update... | 12:47 |
| arno11 | chat UI is still around 3-4 sec | 12:47 |
| arno11 | *main UI | 12:47 |
| arno11 | arghh sorry that's unclear | 12:48 |
| arno11 | 10 sec for main UI before update | 12:48 |
| arno11 | now 1 or 2 sec | 12:48 |
| arno11 | chat UI is 3-4 sec | 12:49 |
| dsc_ | so regarding chat clearing/removal, i will keep this functionality as-is for a few days so that people can use/test it | 13:52 |
| dsc_ | p2p needs fixing there, other than that its good | 13:53 |
| dsc_ | if we then still want something else, I would like to start a discussion on Github | 13:53 |
| freemangordon | will you fix p2p? | 13:54 |
| dsc_ | because merging those 2 features into 1 *may* introduce some corner cases that need to be explored, and I would like to discuss them in a more formal way on Github where we have markdown etc. | 13:54 |
| dsc_ | freemangordon: yes, today | 13:54 |
| freemangordon | dsc_: I think we shall merge and *iff* there are corner cases we shall fix | 13:55 |
| freemangordon | there is no 'delete chat' functionality in fremantle, still ,I don;t remember anyone saying it is missing | 13:56 |
| dsc_ | perhaps, lets see what e.g uvos/arno think | 13:56 |
| Wizzup | I don't ever clear chats fwiw so I am not a good tester | 13:56 |
| freemangordon | I do | 13:56 |
| Wizzup | and I agree what fremantle does seems sensible to me | 13:56 |
| dsc_ | Wizzup: you have not tried the feature yet at all | 13:56 |
| dsc_ | hence I request to first look at it ;) | 13:56 |
| freemangordon | from time to time I clear chat history to clean-up db and free some RAM | 13:56 |
| freemangordon | dsc_: again, for p2p chat, 'delete chat' makes no sense | 13:57 |
| freemangordon | for group chats, "delete chat" is "leave group", no? | 13:58 |
| Wizzup | dsc_: from how rtcom works and I have my preference :) | 13:58 |
| Wizzup | I did look at the code | 13:58 |
| Wizzup | tmlind: uvos: so any suggestion how to debug the CPCAP_REG_TXI.CPCAP_BIT_MB_ON1L and CPCAP_REG_TXI.CPCAP_BIT_MB_ON1R regs not being set? | 14:01 |
| Wizzup | but only in some cases | 14:01 |
| Wizzup | I didn't see any difference in amixer settings or dapm settings | 14:02 |
| Wizzup | I could try to add some printk statements to kernel code or something | 14:02 |
| dsc_ | freemangordon: yes I agree but there are some implications that is hard to discuss on IRC; what should happen in the overview when X is done | 14:02 |
| dsc_ | X being clearing, or removal, whatever | 14:02 |
| dsc_ | we can discuss it on IRC, but I would prefer an issue so I have time to think about presenting some situations/cases | 14:03 |
| dsc_ | and we can solve those edge-cases there | 14:03 |
| freemangordon | dsc_: ok, understand | 14:37 |
| freemangordon | so, please fix p2p functionality (which includes no "delete chat" for p2p) | 14:37 |
| freemangordon | and then we'll continue on GH issue tracking | 14:38 |
| arno11 | dsc_: btw i tried clear/delete functionalities, works fine on my device, very useful in case of unwanted/spam SMSes | 14:49 |
| arno11 | and probably useful to free up some RAM, specialy on N900 :P | 14:51 |
| arno11 | and again launch time is very good now | 14:53 |
| Wizzup | it can get better still if we add some dbus thing iirc | 14:53 |
| Wizzup | then h-d will just focus the conversations window | 14:53 |
| arno11 | ah cool | 14:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!