| uvos | freemangordon: looking at charge-mode source | 00:06 |
|---|---|---|
| uvos | i dont see how the display could be on but charge mode be not refeshing the display | 00:06 |
| uvos | maybe the issue is somewhere else (cpcap got stuck somehow?) | 00:07 |
| uvos | not sure atm | 00:07 |
| uvos | cant repoduce it either | 00:09 |
| freemangordon | uvos: are there some logs I can look at? | 07:18 |
| freemangordon | ugh, seems rsyslogd is not running while in charge mode :( | 07:38 |
| Wizzup | norayr: uvos: yeah, I also want to see this fixed, as I agree it's a nice device, I -just- finished my travelling for at least a month I hope, so it should be more stable now | 10:58 |
| Wizzup | I also brought two atrix and two droid2, next to two droid3's | 10:58 |
| Wizzup | (two so that I can more easily test andriod + leste in parallel) | 10:58 |
| Wizzup | I can have someone send some to uvos this week if it helps, too (I got a few extra of each at home) | 10:59 |
| Wizzup | uvos: just let me know what you want, if any ^^ | 10:59 |
| Wizzup | freemangordon: hm, syslog should be in 'boot' runlevel, does charge mode not stack on top of boot runlevel? | 10:59 |
| Wizzup | oh, also two razr's btw | 11:16 |
| uvos__ | there is no boot runlevel | 11:56 |
| uvos__ | there is sysinit | 11:56 |
| uvos__ | i presume you mean that? | 11:56 |
| uvos__ | yes charge-mode stacks ontop of sysinit | 11:56 |
| uvos__ | if you enable logs in charge-mode and look at serial outuput the output from charge mode will be there | 11:57 |
| uvos__ | thats what i do | 11:57 |
| uvos__ | it dosent log to syslog, it also generally dosent log very mutch, its just 300 or so lines of c after all | 11:58 |
| Wizzup | gentoo calls it boot, maybe devuan calls it differently, I'd ave to check | 11:58 |
| uvos__ | sysinit | 11:58 |
| Wizzup | yes like you said :) | 11:58 |
| freemangordon | well, serial log is not very useful for post-mortem analysis :) | 11:58 |
| freemangordon | the problem is that I don;t see the normal boot log too | 11:59 |
| freemangordon | kern.log/dmesg.log | 11:59 |
| Wizzup | you could add rsyslog to sysinit runlevel | 12:00 |
| Wizzup | it might work | 12:00 |
| buZz | dangit, my second d4 is too empty to boot for charging | 12:22 |
| buZz | guess i'll hook it to external charger again :) | 12:23 |
| sicelo | buZz: you have a bad battery | 12:35 |
| buZz | oh, totally, i have none butt bad batteries :P | 12:36 |
| buZz | but* | 12:36 |
| uvos__ | not nesscarly bad battery | 12:38 |
| uvos__ | any battery will die below the bootable thresh if you just leave it in the device long enough while off | 12:38 |
| buZz | which new battery was the one that fit well, provided you mod the connections? | 12:40 |
| buZz | oh btw, i saw that 'sfeed' is getting debian upstream packaging soon | 12:43 |
| buZz | so if our version isnt 'maemo-ified' we could remove it to get a newer version, in some time | 12:43 |
| sicelo | isn't sfeed a terminal thing? those don't need any porting for maemo | 12:45 |
| buZz | sicelo: its in maemo-leste-extras now, and yeah its terminal/ncurses | 12:46 |
| norayr | we are on beowulf, we won't get newer debian stuff soon. | 12:56 |
| norayr | it goes to sid first | 12:56 |
| buZz | yeah i know, it'll take some time | 12:56 |
| buZz | i'm just saying its coming :) | 12:56 |
| norayr | then it maybe will come to unstable | 12:56 |
| buZz | https://ftp-master.debian.org/new/sfeed_1.6-1.html | 12:57 |
| norayr | good, but i am afraid it'll take 5 years if not more. | 12:57 |
| buZz | hehe, we'll see | 12:57 |
| buZz | you know, its pretty annoying that sphone changes the volume settings without looking at what they were before | 13:30 |
| buZz | i need to re-up 'hifi' and 'voice' after every call , if i want to actually hear people on speakerphone on the -next- call | 13:30 |
| freemangordon | buZz: actually PA shall do that | 13:32 |
| buZz | shall? | 13:32 |
| freemangordon | unless I am missing something | 13:32 |
| freemangordon | hmm? | 13:32 |
| freemangordon | tehre are things like "stream-restore" | 13:32 |
| buZz | i dont know, i put 'hifi' and 'voice' in alsamixer (on alsa, not PA) to 60 | 13:32 |
| buZz | then make a call | 13:32 |
| buZz | then -after- the call ,they will be set lower again | 13:33 |
| freemangordon | what I am saying is to not blame sphone :) | 13:33 |
| buZz | i'm not sure why not? | 13:33 |
| buZz | all other applications dont seem to change my volumes :) | 13:33 |
| freemangordon | because it is not sphone's job to restore stream volumes | 13:33 |
| buZz | yet it does do mixer things , to enable speakerphone | 13:34 |
| freemangordon | well, unless it is doing something stupid | 13:34 |
| freemangordon | right, but I think it does that through UCM | 13:34 |
| freemangordon | (or whatever the name is) | 13:34 |
| buZz | ah, maybe its ofono? org.ofono.CallVolume | 13:35 |
| freemangordon | no idea | 13:35 |
| Wizzup | pa should have a restore feature yeah | 13:35 |
| buZz | either way, it would be nicer to not have to change volume all the time :) | 13:36 |
| Wizzup | buZz: file a bug and explain how to reproduce maybe | 13:40 |
| buZz | yeah i'll pinpoint it a bit, i'll try some more | 13:46 |
| uvos__ | sphone dosent change any volumes | 13:46 |
| uvos__ | sphone dosent deal with volume at all | 13:47 |
| uvos__ | yes pa restores volumes | 13:47 |
| uvos__ | this works at lest when switching outputs from hp to speaker | 13:47 |
| uvos__ | maybe it buggs out when swiching profiles | 13:47 |
| buZz | yeah i guess it does, not sure why, i'll make some testcases later | 13:53 |
| buZz | the lack of disconnect sound is also kinda weird :P | 13:59 |
| buZz | (i'm getting bombarded in voicecalls atm) | 13:59 |
| uvos__ | sure something to add to sphone i ques | 13:59 |
| uvos__ | *gues | 14:00 |
| buZz | hmhm | 14:00 |
| buZz | i always thought that sound came from baseband or the operator :) | 14:00 |
| uvos__ | me too | 14:00 |
| uvos__ | like the ringing | 14:00 |
| uvos__ | i gues not | 14:00 |
| uvos__ | or maybe we are closing the audio connection to the modem to soon or something | 14:01 |
| buZz | oh maybe, yeah | 14:01 |
| buZz | btw, notifications of sms and missed calls works great now :D thanks | 14:25 |
| buZz | i wonder if the 'lock screen' could show them aswell | 14:26 |
| buZz | and i assume 'eventually' we'll feature those notifications on the notificationLED aswell | 14:26 |
| Wizzup | they should, it just depends n the notification that is being sent | 14:27 |
| Wizzup | the lock screen and led are one and the same problem I think | 14:27 |
| Wizzup | uvos__: I think in 1-2 days I will have time for the droid3 stuff, I | 14:32 |
| Wizzup | I'm charging both now | 14:32 |
| norayr | fingers crossed | 14:37 |
| uvos__ | https://github.com/maemo-leste/bugtracker/issues/641 | 15:03 |
| uvos__ | not sure why it dosent work this way | 15:04 |
| uvos__ | maybe im missunderstanding something | 15:04 |
| Wizzup | modest seems to just call mce for the pattern | 15:06 |
| Wizzup | so maybe we don't honour that pattern yet | 15:06 |
| Wizzup | of course that doesn't cover the tklock part | 15:06 |
| uvos__ | Wizzup: yeah | 15:22 |
| uvos__ | Wizzup: kinda looks like a workaround in modest | 15:22 |
| uvos__ | since this dosent work | 15:22 |
| uvos__ | hildon-home taking care of the patterns would be way better too | 15:23 |
| uvos__ | since calling mce directly is broken | 15:23 |
| uvos__ | since mce has no idea how manny notifications are active | 15:23 |
| uvos__ | so if 2 applications want to use the same pattern it breaks | 15:23 |
| uvos__ | since both applications will set the pattern to on | 15:23 |
| uvos__ | and then once one sets it to off | 15:24 |
| uvos__ | the pattern will be gohne even though there still is a notificaton that should be causing a pattern | 15:24 |
| Wizzup | I am not sure if h-h can make that problem go away, but yes, we might want to check if our notifications honours the led patterns or not | 15:30 |
| uvos__ | sure | 15:30 |
| uvos__ | h-h konows how manny notifications are open | 15:31 |
| uvos__ | it can disable the pattern after the last one is closed with the appropriate type | 15:31 |
| Wizzup | right, but I think something else (unlock of device) disables the pattern | 15:31 |
| uvos__ | so it absoultly can fix this problem, and it looks like the code is there | 15:31 |
| Wizzup | hm | 15:31 |
| uvos__ | but its not working | 15:31 |
| Wizzup | do you also send along the kind of notification it is, like a chat notification, or sms? | 15:32 |
| Wizzup | or email | 15:32 |
| Wizzup | (obv not email) | 15:32 |
| uvos__ | Wizzup: yes | 15:33 |
| uvos__ | sphone dose anyways | 15:33 |
| uvos__ | i assume this is waht you are asking | 15:33 |
| Wizzup | yes | 15:34 |
| Wizzup | like modest uses: | 15:34 |
| Wizzup | #define MODEST_NOTIFICATION_CATEGORY "email-message" | 15:34 |
| Wizzup | /* Create notification */ | 15:34 |
| Wizzup | notification = hildon_notification_new (from, | 15:34 |
| Wizzup | data->subject, | 15:34 |
| Wizzup | "qgn_list_messagin", | 15:34 |
| Wizzup | MODEST_NOTIFICATION_CATEGORY); | 15:34 |
| Wizzup | I think that has a special effect in the lock screen, that string | 15:34 |
| Wizzup | along with a few others | 15:34 |
| uvos__ | yeah i know | 15:35 |
| Wizzup | ok :) | 15:35 |
| uvos__ | i dont know why its not on the lockscreen | 15:35 |
| Wizzup | notify_notification_set_hint_int32 (NOTIFY_NOTIFICATION (notification), | 15:35 |
| Wizzup | "dialog-type", 4); | 15:35 |
| uvos__ | maybe something is wrong with it | 15:35 |
| Wizzup | no idea that '4' is here | 15:35 |
| uvos__ | but in principal it tries to do this | 15:35 |
| Wizzup | right | 15:35 |
| Wizzup | it might make sense to just compare it with modest and see | 15:35 |
| Wizzup | maybe there's some silly property | 15:35 |
| uvos__ | yeah | 15:35 |
| uvos__ | right i dont set the dialog type maybe its that | 15:37 |
| Wizzup | I don't know what the number 4 is, maybe it's a special hildon one | 15:43 |
| Wizzup | I also see this type 4 in hildon-notify/tests/test-dbus-action.c | 15:44 |
| uvos__ | ok ill look into it | 15:45 |
| Wizzup | so libhildondesktop/hd-notification.c has hd_notification_get_dialog_type to get the type and if omitted, defaults to 0 | 15:46 |
| uvos__ | mostly i just have to mess around with notify-send untill it works | 15:46 |
| uvos__ | i dont use tklock on my main device at all so it wasent something i tested before | 15:46 |
| Wizzup | in hd-systems-notifications in hildon-home I see: | 15:46 |
| Wizzup | if (dialog_type == 4) { | 15:46 |
| Wizzup | so maybe this is just a red herring | 15:46 |
| Wizzup | but maybe observe modest over dbus and see what it requests exactly I guess | 15:46 |
| uvos__ | btw i fixed proximitry recently | 15:48 |
| uvos__ | not sure if anyone noticed :P | 15:48 |
| uvos__ | no more locking by hand in call | 15:48 |
| Wizzup | I couldn't use my droid 4 in the US :) | 15:51 |
| Wizzup | so no, didn't notice yet, but will definitely test now :) | 15:51 |
| Wizzup | I think the d4 now shuts down so fast during booting that I can't get it to charge | 16:07 |
| Wizzup | will investigate in 1-2 hours | 16:07 |
| freemangordon | this is the query that tklock does | 16:40 |
| freemangordon | https://github.com/maemo-leste/osso-systemui-tklock/blob/master/visual-tklock.c#L336 | 16:40 |
| Wizzup | Who writes to this database? | 17:19 |
| freemangordon | hildon-home | 17:33 |
| freemangordon | (IIRC) | 17:33 |
| freemangordon | https://github.com/maemo-leste/hildon-home/blob/master/src/hd-notification-manager.c#L566 | 17:36 |
| freemangordon | https://github.com/maemo-leste/hildon-home/blob/master/src/hd-notification-manager.c#L730 | 17:36 |
| Wizzup | yeah, looking now | 17:36 |
| freemangordon | https://github.com/maemo-leste/hildon-home/blob/master/src/hd-notification-manager.c#L1329 | 17:37 |
| Wizzup | I was thinking this too, maybe persistence is the thing | 17:37 |
| freemangordon | sure | 17:37 |
| Wizzup | that makes sense I guess | 17:37 |
| freemangordon | it needs "persisitent" hint | 17:37 |
| Wizzup | I don't think sphone sets that | 17:38 |
| freemangordon | most-probably not | 17:38 |
| Wizzup | I grep'd | 17:38 |
| Wizzup | :) | 17:38 |
| uvos | so ./notify-send -i general_missed -h string:category:email-message test is sufficant to do everything | 20:44 |
| uvos | including activateing the mce pattern | 20:44 |
| uvos | and playing the sound | 20:44 |
| uvos | however.... this means everything is hardcoded in notification-groups.conf | 20:45 |
| uvos | includeing what application gets the dbus call on an action | 20:45 |
| uvos | makeing it compleatly unsuable as a genreal solution | 20:45 |
| uvos | if there is a way to make hildon home do these things using just notification hints (even hildon specific ones) i cant find it | 20:47 |
| freemangordon | and what is the general solution? | 20:47 |
| uvos | well that any application can set the stuff via hints | 20:47 |
| freemangordon | also, how do you solve cross-reboot notification? | 20:48 |
| uvos | ie instead of D-Bus-Call= hh uses the dbus call specified in the notifcation action | 20:48 |
| uvos | and so on | 20:48 |
| uvos | same with pattern (could just be a hint) | 20:48 |
| uvos | etc | 20:48 |
| freemangordon | this is not covered in the specs either, no? | 20:48 |
| uvos | well notification servers can support custom hints | 20:48 |
| uvos | so every field in notification-groups.conf could just be a hint | 20:49 |
| uvos | i dont see how this changes how reboot works at all | 20:49 |
| freemangordon | so, we can as well add .d support in notification-groups.conf parser | 20:49 |
| freemangordon | so every application that wants to can register itself | 20:49 |
| uvos | but its a contrivance | 20:49 |
| uvos | there is not reason for that the notification allready contains all information hh could need | 20:49 |
| uvos | there is no need for it to load it form somewhere else | 20:49 |
| freemangordon | not dbus call that shall be made | 20:50 |
| freemangordon | in xdg specs I don' | 20:50 |
| freemangordon | t see cross-reboot support at all | 20:50 |
| uvos | i dont follow at all, the dbus call contains lots of fileds, manny of witch of the xdg ones duplicate the fields in notification-groups.conf | 20:51 |
| uvos | there are some extra fields in notification-groups.conf | 20:51 |
| uvos | but the xdg spec allows custom fileds in the dbus call | 20:51 |
| uvos | so you could just add them if the application wants them | 20:51 |
| freemangordon | what application? | 20:52 |
| freemangordon | do I get it right that you want the application to provide dbus callback address? | 20:52 |
| uvos | any application that wants a LED-Pattern could for instance add LED-Pattern=PatternCommunicationEmail as a hint | 20:52 |
| uvos | to the dbus call | 20:52 |
| uvos | as per xdg | 20:52 |
| uvos | as a vendor extension | 20:52 |
| freemangordon | ok, but who shall be called back after a reboot? | 20:53 |
| freemangordon | if the user click on the notification? | 20:53 |
| uvos | works fine in other servers too, so actions get a dbus call to call in the xdg spec allready | 20:53 |
| uvos | and you can save that and try it upon reboot | 20:53 |
| freemangordon | save what? | 20:53 |
| freemangordon | I don;t follow | 20:54 |
| freemangordon | IIRC you need the dbus address of the calling application for the callback | 20:54 |
| freemangordon | which is no more after a reboot | 20:54 |
| uvos | not quite | 20:54 |
| uvos | sec | 20:54 |
| uvos | well my d4 locked up | 20:55 |
| uvos | again | 20:55 |
| uvos | apperantly nofiy send is good way to make it happen | 20:55 |
| freemangordon | :) | 20:56 |
| Wizzup | anything in pstore? | 20:56 |
| freemangordon | uvos: see org.freedesktop.Notifications.ActionInvoked | 20:57 |
| freemangordon | for example | 20:57 |
| freemangordon | whom you will send that signal to after a reboot? | 20:57 |
| uvos | works with kde- somehow | 20:57 |
| uvos | anyhow worst come to worst | 20:58 |
| uvos | you can just send D-Bus-Call= as a hint too | 20:58 |
| uvos | i gues maybe the kde notification server uses introspection to get the method to be called via the handler? | 20:58 |
| freemangordon | and how is that different to having notification-groups.d where each application can register itsef? | 20:59 |
| freemangordon | maybe it is more elegant | 20:59 |
| freemangordon | but to me it is same thing don in a different way | 20:59 |
| freemangordon | for sure we can pass all the data as hints | 20:59 |
| uvos | it avoids the problem that the application is global | 20:59 |
| uvos | ie i can have only one applicaition serve email-message | 21:00 |
| freemangordon | ah, I see | 21:00 |
| freemangordon | ok, lemme think about that a bit, I may implement something soon | 21:00 |
| uvos | lets see if we can do this at least for ED-Pattern= | 21:01 |
| uvos | ie what sphone needs at a minimum | 21:01 |
| uvos | btw i dont get where the sound comes from | 21:01 |
| uvos | its not in notification-groups.conf | 21:02 |
| uvos | but somehow hh knows what sound to play from just ./notify-send -i general_missed -h string:category:email-message test | 21:02 |
| uvos | must be "hardcoded" somewhere else | 21:02 |
| freemangordon | https://github.com/maemo-leste/hildon-plugins-notify-sv/blob/master/lib/nsv-profile.c | 21:03 |
| freemangordon | I guess this is it | 21:04 |
| uvos | freemangordon: so im going to nix power: cpcap-battery: Do not issue low signal too frequently from the kernel for now right? | 21:29 |
| freemangordon | to release? | 21:30 |
| uvos | for devel | 21:30 |
| uvos | yeah | 21:31 |
| freemangordon | next 2 patches as well | 21:31 |
| freemangordon | sec | 21:31 |
| freemangordon | uvos: https://github.com/maemo-leste/droid4-linux/commits/maemo-5.18.y-cpcap | 21:31 |
| freemangordon | keep in mind I force-pushed | 21:31 |
| uvos | freemangordon: i know but power: cpcap-battery: Do not issue low signal too frequently is broken right | 21:31 |
| uvos | or did you change it? | 21:31 |
| freemangordon | yes, i fixed and force-pushed | 21:32 |
| uvos | ok | 21:32 |
| freemangordon | in maemo-5.18.y-cpcap branch | 21:32 |
| freemangordon | in maemo-5.18.y it is broken | 21:32 |
| uvos | ok | 21:34 |
| freemangordon | so you have to tag 7f7253af8bce280b7e863a7e09c854f1f1bf2416 and release | 21:34 |
| uvos | right im doing it atm | 21:34 |
| freemangordon | ok, great | 21:34 |
| freemangordon | today I installed kexecboot on the second d4 I have here, tomorrow will try to measure off draw with and without modem shutdwon patch | 21:35 |
| uvos | ok | 21:36 |
| uvos | mesureing power consumption with a dmm is a bit tricky, you need to keep the leads short or the device becomes unstable | 21:37 |
| freemangordon | I see | 21:37 |
| freemangordon | well, I hope a fully charged battery to help | 21:38 |
| freemangordon | also, I plan to use 10A range | 21:38 |
| freemangordon | so no much added resistance | 21:38 |
| uvos | if you have the resolution there | 21:39 |
| freemangordon | I think I have | 21:39 |
| freemangordon | the other option is 200mA, fused :) | 21:40 |
| freemangordon | won't fly | 21:40 |
| uvos | yeah | 21:40 |
| freemangordon | or, maybe I can connect some small resistance and measure the voltage | 21:41 |
| freemangordon | after all I don;t need precise measurement, but if there is a difference | 21:41 |
| freemangordon | 0.1 or even 0.2 Ohm should do the job | 21:42 |
| freemangordon | or not | 21:43 |
| freemangordon | anyway, will see tomorrow | 21:43 |
| uvos | where you running the devel kernel when the charge-mode problem occured? | 21:47 |
| uvos | if so then the awnser is obvious what that was, cpcap oopsed and then ofc charging-sdl could not update itself anymore | 21:48 |
| uvos | @freemangordon | 21:48 |
| freemangordon | no, it was the kernel you're going to build | 21:48 |
| uvos | oh | 21:48 |
| uvos | *ok | 21:48 |
| freemangordon | going afk, ttyl | 21:49 |
| Wizzup | ttyl | 21:51 |
| Wizzup | uvos: does the charge mode still support pressing the power down button to boot to leste? | 22:48 |
| uvos | sure | 23:02 |
| uvos | but only when its over a voltage tresh | 23:02 |
| Wizzup | ah, ok | 23:09 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!