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