On Thu, 07 Feb 2013 21:15:28 +0100 Dominic Fandrey <kamik...@bsdforen.de> said:
> On 07/02/2013 09:16, Carsten Haitzler (The Rasterman) wrote: > > On Sun, 03 Feb 2013 07:05:59 +0100 Dominic Fandrey <kamik...@bsdforen.de> > > said: > > > >> The clock module misses day changes that happened while the system > >> was in suspend. It currently says on my syste: > >> 07:02 Sat, 2 Feb, 2013 > > > > how did you suspend? did you use e to suspend? > > Yes, I have an XF86Sleep keycode. The e17 release came preconfigured > to act upon it. > > > > >> In the calendar view it uses the correct date: > >> 07:02 Sun, 3 Feb, 2013 > >> > >> System is FreeBSD stable/9 amd64 with enlightenment-0.17.1. > >> Locale is en_GB.UTF-8 and timezone is CET. > > > > in fatc after some puzzling.. the clock module is correct. > > > > 1. it listens to e's own E_EVENT_SYS_RESUME event which e detects *IF* it > > was the one to do the suspending. on suspend e pulls out a spinning timer > > that repeats ever 0.1 sec... if this is interrupted for > 0.2 sec between > > spins, it "guesses" that the system was suspended between spins and > > produces a resume event. this resume event then re-evaluates data... in > > fact it re-evaluates the whole clock, and thus date. > > It shows the correct time after, but doesn't update the date. Or at least > doesn't redraw it. The correct date can be seen when I click the clock > to get the calendar view. I should point out that the clock module is present > twice, once as a digital clock + date view and once as an analogue clock. > > I can send you a screenshot with the correct and wrong dates right next > to each other. i'm staring at the code.. and on resume is totally rebuilds the clock. it calls e_int_clock_instances_redo(EINA_TRUE); which causes every clock instance to have its theme reset, today string (that date string) re-evaluated etc. etc. i know that this re-evaluate works, because i can sit here and do "date -s XXXX" and change time AND date, year etc. and my clock instantly updates (because o the timerfd stuff above). it';s the EXACT same function called (the redo() above) when the timerfd triggers saying the date/time changed. its the exact same callback hooked to the resume event. all i can suggest is putting in a printf in this function and checking your logs - if it did it on resume, then you're good. if it didn't - then for some odd reason the resume event is not making it. the only other user of the resume event is efm and its event handler return true (don't steal it) so it has to propagate logically - if its generated. the e_sys resume func override comp sets up is called after generating the resume event so i can't see how comp can fade in and there not be a resume event generated. so all i can say right now is: 1. code inspection tells me this should work. 2. playing with my date tells me the date+time update code DOES work. (sitting at desktop here so suspend/resume is not something i'm messing with right now. 3. all i can guess is that either the resume event is somehow not being delivered to clock or even generated - but how this is possible given e's code beats me - unless some 3rd party module steals the event and doesnt pass it on... so putting in some printfs to test will be a good idea. 4. maybe.. just maybe... it is all being called right, BUT it's either being called just before suspend due to some kernel "hiccup" that detects a resume just prior to going into suspend when the date is still the old one (and your time update is simply a matter of the seconds/minutes timeout rolling around and updating anyway, but just the time, not the date), or its a kernel oddity that during initial resume, the system clock hasn't quite updated yet and when the resume handler triggers just after resume it gets the old date and some small amount of time later the os updates it, but the clock is none the wiser. > > 2. it even listens for filesystem changes to /etc/localtime - it didnt look > > at /etc/timezone though, so i added that, but it has a fs monitor to detect > > tz changes so this all seems correct here. of course on os's that support > > file monitoring this will be totally event based. > > kqueue(2) has been around since FreeBSD 4.1, which is to say 2000. no idea if we support it or not. > > 1 small thing missing for > > alternate timzeon sources. fixed. > > 3. it has support for timerfd's that report system date changes via date -s > > () > > - of course this works on linux... you're probably totally out of luck on > > bsd there as i have no idea if it has any such mechanism to detect date > > changes. > > I suppose the FreeBSD way to do this would be to add a kevent for a timer. > Too bad we didn't build it future linux compatible 13 years ago. patches accepted. > > modern linux kernels do. clock module code handles it... BUT.. it forgot to > > settime on it to activate the timerfd so it actually reports the change... i > > fixed that too. :) > > > > so if tis date change after a resume from suspend i can only guess that > > > > 1. u didnt suspend via e.. which means it wont detect resume. use e to do > > this and u'll be fine. > > I am using e to suspend. > > Anyway the clever way to do find out what's going on on a FreeBSD system > is just listening to /var/run/devd.pipe. Event based, very easy to work > with. > !system=ACPI subsystem=Resume type=\ notify=0x03 > Tells you, that the system just woke up from S3. > > I expect modern Linux systems have acquired something > similar since the hald debacle. they haven't. there is no standard mechanism to get events like this that i know of, so it's guessed. the only way is that the pm subsystem can RUN some commands on suspend then on resume - these commands CAN then broadcast some events - eg via dbus, but all of this is "different per distro". > I'd actually like to do that myself. But as far as I can see all the > OS dependent stuff in modules is #ifdef'ed. It would be nice if there > was a user interface part and a small well defined backend interface > for each module, so you can have a separate backend for each OS, made > by people who don't need to know the e internals, but know the system > they are working on. > > E.g. it wasn't difficult to figure out that the cpufreq module > actually correctly detects the available frequency range. But I haven't > the slightest why the pointer is stuck at minimum, even though it displays > the correct number and knows the correct minimum and maximum frequencies. the needle is moved by sending messages to the object. the messages contain numbers indicating frequencies. :) > > 2. e's resume detection is broken.. but that means you'll have all sorts of > > other problems with backlight, compositor etc. that wont fade backlight > > back in or fade compositor effects in as they both rely on this resume > > events for that... > > Hmm, the e17 backlight thing does nothing for me. I hooked some key events > up that call xbacklight, which works fine. Which is kinda strange, I'd have > expected e17 to use the same interfaces as xbacklight. it does - it asks xrandr to vary backlight, if that fails it falls back to execcing a setuid root binary that pokes around /sys/* sysfs files (via eeze) to write to file nodes. > I haven't run into any issues with compositing and resume. so screen fades back in (like it fades out on suspend)? if so - e is detecting resume fine in its "hackish" way. > > same with the "suspending" dialog box too (comp replaces that with > > screen fade out/in). > > I'd prefer the box. The way it is right now: > - The screen fades into black this is e17. > - The screen flickers back to full brightness this smells like its xorg and/or your kernel futzing about. > - The screen turns black same as above. > - The screen shows the system console your system suspend mechanism is doing this - likely changing vt away from x11. probably explains the above backlight flickering too. probably doing this so "get rid of accelerated gpu drviers that may not handle suspend". > - And finally the system reaches suspend > > I could really live without that moment when the screen just turns > bright again. as above. probably part of the os suspend path. e definitely doesn't do this. all it does is: 1. do some pixel fun with some images/rects on top of everything to cause the screne to appear to fade out. 2. ALSO it scales backlight down to 0 at the same time as #1. 3. when this is done, it calls the suspend command via enlightenment_sys (setuid root) and after that it's "up to the os". > The brief display of the system console is not nearly as disconcerting. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users