maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)
-   -   [ANNOUNCE]Alarm UI replacement (https://talk.maemo.org/showthread.php?t=87823)

freemangordon 2013-01-10 10:33

Re: [ANNOUNCE]Alarm UI replacement
 
@reinob - no need to apologize, you're amongst the last i'd feel offended from :).

however, if you're going to look at h-h code, you'd better use the CSSU one (https://gitorious.org/community-ssu/hildon-home)

reinob 2013-01-10 12:43

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by freemangordon (Post 1313201)
however, if you're going to look at h-h code, you'd better use the CSSU one (https://gitorious.org/community-ssu/hildon-home)

I had a quick look and it seems that it's all actually handled by libhildon-plugins-notify-sv.so (nsv_plugin_play_event).

But that library seems to be closed.
Interesting strings in it:

nsv_profile_get_volume
nsv_profile_get_system_volume
nsv_util_valid_rootfs_sound_file
nsv_util_valid_sound_file
register_alarm_clock
register_alarm_calendar
pb_playback_* (libplayback-1)

It may also be a problem in the way it interacts with pulseaudio (pa_* -- libpulse, libpulse-mainloop-glib, libsndfile).

If anybody (freemangordon?) has the chance/time/skills to decompile libhildon-plugins-notify-sv.so, we might get to the end of this..

peterleinchen 2013-01-10 22:13

Re: [ANNOUNCE]Alarm UI replacement
 
Let me chime in here and cross link to the h-h bug thread (see this and ff posts).

After aspersing sh (also bb-power) and some fruitful discussions with iDont (many thanks to him), I am very convinced that freemangordon is right and we suffer from that ppoll/pselect armel bug.
Meanwhile I made a "possible workaround" (again THX iDont):
I put all my widget commands (that were suspicious to not give back output and hereby blocking h-h, which in fact causes alarm to popup but not sound) into single excutable sh scripts.
Then I changed code in DCEW to
Code:

timeout -t 7 -s 1 /home/user/DCEW/command.sh
This should timeout the called command and hereby ends it and unblock h-h. But this is still in testing (maybe for weeks) and there is no positive test report to be expected.Only time counts ;)

So maybe all others experiencing this alarm bug (especially don and mr_pingu) could you try my approach also, please? (precondition: bb-power or timeout)

But I would be glad to get that lib decompiled and found that bug inside. Nevertheless I saw a command that just did not terminate and this for sure will block h-h.

don_falcone 2013-01-11 07:30

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by peterleinchen (Post 1313493)
ppoll/pselect


Sounds plausible from what've read about it. AFAIK, both glibc and kernel need to be changed, and glibc already received a patch (2.5.1-1eglibc27+0m5+cssu0 which i have). I guess at least a kernel (pre-kp52/cssu3) got one too?

peterleinchen 2013-01-12 22:53

Re: [ANNOUNCE]Alarm UI replacement
 
Damn! :(

I got h-h hanged again today.
So, it seems my workaround with wrapping all widget commands into sh scripts and call them with timeout does not work (which I do not understand).
We should continue this specific bug here, right?


--edit
This one is solved, see above mentioned link and ff.

peterleinchen 2013-01-25 23:10

Re: [ANNOUNCE]Alarm UI replacement
 
Sorry, started to post in CSSU devel thread ...

Quote:

Originally Posted by freemangordon (Post 1303185)
osso-systemui-alarm - (Alarm dialog) - this is just a newer version(0.3.3), nothing has changed compared to 0.3.2, just some source code cleanup.

Please test and report if something is not as it should be.

Hey freemangordon,

your guinea pig maybe has something new?

But it could also be caused again by hildon-home (you remember? ;)). I cannot remember 100% if I had that behaviour before using your lib, but I think so that it happened to me before ...

I had an alarm ringing this morning (yeah, ringing with sound), popup came up asking to snooze or stop. But as I wanted to snooze: no chance. No reaction on stop either. Even pressing beside that pop up did not do anything. Nor pushing the power button helped.
So I let it ring out and relied on my N9 to wake me up :(

After waking up I could push snooze and popup came up again after 5 minutes. Then I pushed stop and it vanished.

Then I checked my logs and they showed that at waking up the hildon-home was not frozen (at least not with "read(xx, <unfinished>". But after I was able to push stop, the h-h was frozen. And it got unlocked by my script some time later.

Any idea why the pop up did not react?

--edit
rechecked my logs
Quote:

--do Thu Jan 24 08:06:51 CET 2013
sleeping 891 (900) Thu Jan 24 08:07:01 CET 2013
done Thu Jan 24 08:21:51 CET 2013
--
do Thu Jan 24 08:21:51 CET 2013
BOOM Thu Jan 24 08:22:00 CET 2013
sleeping 881 (900) Thu Jan 24 08:22:10 CET 2013
done Thu Jan 24 08:36:50 CET 2013
--
and after rethinking that shows that most probable the h-h was not frozen at ring time (08:15), but got instantly at the pop up came up. I think, h-h got waked up to show the alarm ui pop up, hereby trying to update the widgets (event: on desktop change) and BOOM: hanging. So no reaction anymore possible to the popup. And that also explains why the snoozes did not ring.
And also
So looks like a h-h problem again, hmm?

But what I do not get (yet) is why did the pop up not respond first (but rang), but on second snooze pop (not ringing)?
I checked manually the "hanging" status at 08:20.
Quote:

-rw-r--r-- 1 user users 27 Jan 24 08:20 /tmp/hhh.scr
and that showed
Quote:

read(32, <unfinished ...>
So it should have still been unresponsive, or?

--another edit
Oops, sorry.
Think this post belongs to this thread: [ANNOUNCE] Alarm-UI replacement.
So I copied this post and pasted it here. Let us continue in this thread.

--edit
For all who are following:
I could verify this today morning. Pop up comes up, alarm IS ringing, but buttons do not respond (you need to cut power or let it ring out). After that there is no snooze function (pop up yes, but no ring tone).
It is definitely the widgets hanging. :(
Possible solution to this is to set the loop time to less than snooze time (e.g. 4 minutes).
For sure I do not know how to get the pop up to respond to stop/snooze the alarm.

So I think we may "forward" this behaviour to here.

pichlo 2013-08-07 14:36

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by reinob (Post 1293265)
One day I was in the lift (aka "elevator"), looking at my display, when suddenly an alarm popped-up (on the display, still no sound, usually takes a second or two to start ringing). Given that I was actively looking at the display, when I saw the alarm pop-up I instantly tapped on "close". The alarm UI closed, but then the ring started sounding, with no UI to turn it off.

I've just seen this one too, only with CSSU-Thumb.

Edit: osso-systemui-alarm version 0.3.3+0cssu0

DfLo1913 2013-08-07 17:09

Re: [ANNOUNCE]Alarm UI replacement
 
Cant find it in the repos. I would to download the thumb version. Thanks

pichlo 2013-08-08 10:37

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by DfLo1913 (Post 1365586)
Cant find it in the repos. I would to download the thumb version. Thanks

http://wiki.maemo.org/Community_SSU/Thumb#Installation

Thumb uses separate repos. If merlin1991 doesn't ring a bell then follow the link above.

freemangordon 2013-08-24 14:58

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by reinob (Post 1313251)
I had a quick look and it seems that it's all actually handled by libhildon-plugins-notify-sv.so (nsv_plugin_play_event).

But that library seems to be closed.
Interesting strings in it:

nsv_profile_get_volume
nsv_profile_get_system_volume
nsv_util_valid_rootfs_sound_file
nsv_util_valid_sound_file
register_alarm_clock
register_alarm_calendar
pb_playback_* (libplayback-1)

It may also be a problem in the way it interacts with pulseaudio (pa_* -- libpulse, libpulse-mainloop-glib, libsndfile).

If anybody (freemangordon?) has the chance/time/skills to decompile libhildon-plugins-notify-sv.so, we might get to the end of this..

There is x86 binary, I run IDA against it, it is not impossible to RE it and fix the problem, but I wonder if it really makes sense.


All times are GMT. The time now is 09:15.

vBulletin® Version 3.8.8