On 08/02/2013 04:04, Carsten Haitzler (The Rasterman) wrote: > On Thu, 07 Feb 2013 21:15:28 +0100 Dominic Fandrey <kamik...@bsdforen.de> > said: >> 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); > > ... > > 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.
Will do. > 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. We don't have timerfd, so I suppose nothing works as expected. I may just grep the code for it and check whether I can substitute this stuff with kqueue calls if there aren't any in place. > >>> 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. Me neither, I guess I'm going to find out. > >>> 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. This will probably sit on my todo list until after I've completed the final draft of my thesis. > >>> 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". <Insert expressive, explicit, German language>. If there was a commonly supported format I could just build a trivial translator that forwards devd events into dbus. Do you by any chance have something like this? A documented list of dbus events e17 reacts to? > >> 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. :) I can see where the displayed numbers are updated. I cannot see where the needle is updated. I originally expected it to be the same event and figured the module just doesn't know the min/max values. That's why I dug in and found out it actually puts the correct values into some kind of list structure. Maybe I'll do this, too, after my thesis. (Kind of my lame excuse for everything right now). > >>> 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. Well, the /should/ work. The second one definitly shouldn't. /sys is a link to the FreeBSD kernel source code. Which is nice to have if you build 3rd party kernel modules for FreeBSD, but not at all what you expect/need. > >> 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. No, it comes back full bright instantly. > >>> 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. That's video drivers for you. The only one that really works is the nvidia blob. Everything else is a race to catch up with undocumented Linux kernel interface changes. >> - The screen turns black > > same as above. It happens when I regularly switch to the system console, too. >> - 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". I actually kinda like this. Enough of this. my queue of things to do with e17 is getting longer and longer. I already want to hook the pam.d code into enlightenment_sys so screen unlock actually works in FreeBSD (only root can auth via pam_unix). Thanks for looking into all this. Regards -- 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
