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. > 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. > 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. > 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. 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. > 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. I haven't run into any issues with compositing and resume. > 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 - The screen flickers back to full brightness - The screen turns black - The screen shows the system console - And finally the system reaches suspend I could really live without that moment when the screen just turns bright again. 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
