calise-testing Mailing List for Calise
Status: Beta
Brought to you by:
smilzoboboz
Menu
▾
▴
calise-testing — Developement versions test results and discussion
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(22) |
Jul
(52) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-20 15:48:50
|
Well...nice to hear it! ahahah i'm not surprised :D Let's hope we'll get more luck with other de, but i guess we won't... Btw, i 'm a free man again ahahha at least, until last days of august...ah this is a sweet breath of freedom! 2012/7/18 Developement versions test results and discussion < cal...@li...> > Il 17/07/2012 18:50, Developement versions test results and discussion > ha scritto: > > I know calise daemon version uses really very low cpu, and power usage > > too is pretty low obviously. > > I only hate useless things (i'm using arch specially for this), and > > this is one of them. It may be not be much heavy, in terms of wasted > > resources and power usage, but it's anyway useless :D > > Well, let's hope that the call to dbus is there, and that it is the > > same for all power managers (uhm something like that in linux? It > > can't be possible, sorry!) > > Let me know if you need me to do some tests and other things so! (as i > > said, since 21 i'll be a free man again :D ) > > Bye, thanks! > > Sadly I can confirm that at least XFCE doesn't emit any signal when > applying power-saving modes. > That said, only a indirect method based on inactivity time (reading > xfconf for the amount of time) can achieve that. The whole thing is > pretty hard to set up (I mean, really hard), so right now I lowered a > bit the priority level of the feature request. > > Now let's see if for other DE things are different... > > Btw, other indirect methods (like DPMS won't work either). > > PS: Of course the best way to achieve power-manager recognition is to > have *it* run calise pause/resume dbus methods (so, funny enough, a > patch for the DE is the best way to go) > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-18 08:44:36
|
Il 17/07/2012 18:50, Developement versions test results and discussion ha scritto: > I know calise daemon version uses really very low cpu, and power usage > too is pretty low obviously. > I only hate useless things (i'm using arch specially for this), and > this is one of them. It may be not be much heavy, in terms of wasted > resources and power usage, but it's anyway useless :D > Well, let's hope that the call to dbus is there, and that it is the > same for all power managers (uhm something like that in linux? It > can't be possible, sorry!) > Let me know if you need me to do some tests and other things so! (as i > said, since 21 i'll be a free man again :D ) > Bye, thanks! Sadly I can confirm that at least XFCE doesn't emit any signal when applying power-saving modes. That said, only a indirect method based on inactivity time (reading xfconf for the amount of time) can achieve that. The whole thing is pretty hard to set up (I mean, really hard), so right now I lowered a bit the priority level of the feature request. Now let's see if for other DE things are different... Btw, other indirect methods (like DPMS won't work either). PS: Of course the best way to achieve power-manager recognition is to have *it* run calise pause/resume dbus methods (so, funny enough, a patch for the DE is the best way to go) |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-17 16:50:50
|
I know calise daemon version uses really very low cpu, and power usage too is pretty low obviously. I only hate useless things (i'm using arch specially for this), and this is one of them. It may be not be much heavy, in terms of wasted resources and power usage, but it's anyway useless :D Well, let's hope that the call to dbus is there, and that it is the same for all power managers (uhm something like that in linux? It can't be possible, sorry!) Let me know if you need me to do some tests and other things so! (as i said, since 21 i'll be a free man again :D ) Bye, thanks! 2012/7/17 Developement versions test results and discussion < cal...@li...> > Il 17/07/2012 16:36, Developement versions test results and discussion > ha scritto: > > Another little thing: it could be a nice idea to have calised paused > > while the screen gets turned off (or it turns back because of power > > management settings)...it is useless that calised goes on making > > capture while the screen is locked in a "black state", if you > > understand what i mean here. This is somehow similar to my other > > feature request, or well, it is related, but it is not the same thing > > i think. > > Hope it can be done :) > > Bye! Have a good time during this holidays!! > > Yup, it's related. Actually it's more or less the same thing: know if > same sort of signal is emitted by either XFCE power-manager, GNOME power > manager, KDE power-manager and/or others (if that's the case, I hope, > but I'm sure it's utopia, that they all send the same signal). > Anyway here you are, opened a feature request (id 3545122): > > https://sourceforge.net/tracker/?func=detail&aid=3545122&group_id=535571&atid=2175086 > With that calise will be really effective. > > For now, just consider that (about per-capture power usage on a average > netbook): > > webcam ~2Wh > cpu (max) ~10Wh > capture duration ~1.5s > cpu usage during capture <2% > > 2Wh * (1.5s / 3600) + ((10Wh / 100) * 2) * (1.5s / 3600) = > 0.92*10^(-3) ~= 1 mWh > > NOTE: every value is slightly higher than what is. > > It's pretty low... (hope I didn't make mistakes). So don't worry that > much about power usage, of course, if you're able to pause calised and > then resume do it, but even if you don't, power usage won't change that > much. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-17 16:39:34
|
Il 17/07/2012 16:36, Developement versions test results and discussion ha scritto: > Another little thing: it could be a nice idea to have calised paused > while the screen gets turned off (or it turns back because of power > management settings)...it is useless that calised goes on making > capture while the screen is locked in a "black state", if you > understand what i mean here. This is somehow similar to my other > feature request, or well, it is related, but it is not the same thing > i think. > Hope it can be done :) > Bye! Have a good time during this holidays!! Yup, it's related. Actually it's more or less the same thing: know if same sort of signal is emitted by either XFCE power-manager, GNOME power manager, KDE power-manager and/or others (if that's the case, I hope, but I'm sure it's utopia, that they all send the same signal). Anyway here you are, opened a feature request (id 3545122): https://sourceforge.net/tracker/?func=detail&aid=3545122&group_id=535571&atid=2175086 With that calise will be really effective. For now, just consider that (about per-capture power usage on a average netbook): webcam ~2Wh cpu (max) ~10Wh capture duration ~1.5s cpu usage during capture <2% 2Wh * (1.5s / 3600) + ((10Wh / 100) * 2) * (1.5s / 3600) = 0.92*10^(-3) ~= 1 mWh NOTE: every value is slightly higher than what is. It's pretty low... (hope I didn't make mistakes). So don't worry that much about power usage, of course, if you're able to pause calised and then resume do it, but even if you don't, power usage won't change that much. |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-17 14:36:19
|
Another little thing: it could be a nice idea to have calised paused while the screen gets turned off (or it turns back because of power management settings)...it is useless that calised goes on making capture while the screen is locked in a "black state", if you understand what i mean here. This is somehow similar to my other feature request, or well, it is related, but it is not the same thing i think. Hope it can be done :) Bye! Have a good time during this holidays!! 2012/7/13 Federico Di Pierro <nie...@gm...> > Well, if i do not use the netbook, i guess no, it is not a problem to have > the backlight level reduced :) > With xfce-power-manager i have the presentation mode that i can use when > i'm watching film or studying or working, other times i want it to reduce > screen brightness to save power. > Well, so, let's hope a global dbus signal is emitted ;) > > > 2012/7/13 Developement versions test results and discussion < > cal...@li...> > >> Il 12/07/2012 20:47, Developement versions test results and discussion >> ha scritto: >> > Hi! >> > I 'm using xfce4-power-manager, and i use to have my screen brightness >> > lowered after 20s of inactivity. >> > Well, i'd like that calised won't interfere with this option (i don't >> > know if this can be done, so i'm only asking), because as now, after >> > 20s my backlight is actually reduced, but then calised makes a capture >> > and reset the brightness...(indeed it works when, after a minute, my >> > screen gets turned off). >> > I haven't idea how this can be achieved... >> > Hope this can be easily integrated, but i don't think so :) >> > Thanks for your time! >> >> Actually a good one, I don't know if before reducing screen backlight >> level a global dbus signal is emitted, if so then it can be implemented >> (not easy but I should give a try). >> If no dbus signal is emitted I can do nothing since I'm not able to know >> *when* the dim happens. >> >> Btw, isn't somehow disturbing having the backlight level reduced every >> 20sec? >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Calise-testing mailing list >> Cal...@li... >> https://lists.sourceforge.net/lists/listinfo/calise-testing >> > > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-14 11:11:05
|
Il 14/07/2012 12:56, Developement versions test results and discussion ha scritto: > It's gonna be very long! > (btw yes, i'm using it as root with calised.timer :) ) > ->calised --dump-settings | grep screen > screen: True > ->echo $DISPLAY > :0.0 > ->dbus-send --system --print-reply --type=method_call > --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager > org.freedesktop.ConsoleKit.Manager.GetSeats > method return sender=:1.1 -> dest=:1.185 reply_serial=2 > array [ > object path "/org/freedesktop/ConsoleKit/Seat1" > ] > ->dbus-send --system --print-reply --type=method_call > --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Seat1 > org.freedesktop.ConsoleKit.Seat.GetActiveSession > method return sender=:1.1 -> dest=:1.186 reply_serial=2 > object path "/org/freedesktop/ConsoleKit/Session1" > ->dbus-send --system --print-reply --type=method_call > --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Session1 > org.freedesktop.ConsoleKit.Session.GetX11Display > method return sender=:1.1 -> dest=:1.187 reply_serial=2 > string ":0.0" > > I don't understand anything of these lines :D Confirmed, since every value returned it correct, then it's a bug on how screen capture is managed. I'll branch and start debugging ASAP. |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-14 10:56:50
|
It's gonna be very long!
(btw yes, i'm using it as root with calised.timer :) )
->calised --dump-settings | grep screen
screen: True
->echo $DISPLAY
:0.0
->dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager
org.freedesktop.ConsoleKit.Manager.GetSeats
method return sender=:1.1 -> dest=:1.185 reply_serial=2
array [
object path "/org/freedesktop/ConsoleKit/Seat1"
]
->dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Seat1
org.freedesktop.ConsoleKit.Seat.GetActiveSession
method return sender=:1.1 -> dest=:1.186 reply_serial=2
object path "/org/freedesktop/ConsoleKit/Session1"
->dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Session1
org.freedesktop.ConsoleKit.Session.GetX11Display
method return sender=:1.1 -> dest=:1.187 reply_serial=2
string ":0.0"
I don't understand anything of these lines :D
2012/7/14 Developement versions test results and discussion <
cal...@li...>
> Il 13/07/2012 19:50, Developement versions test results and discussion
> ha scritto:
> > Ok. To be sure, i restarted now calised.
> > I'm in my xfce4 session, and no one of the choices you gave me is true.
> > "date -d @1342201920.59
> > ven 13 lug 2012, 19.52.00, CEST"
> > calised -d:
> > current backlight step: 8147
> > capture timestamp (epoch): 1342201920.59
> > secs before next day state: 7032.40669298
> > day cycle state: sunset
> > suggested backlight step: 8147
> > ambient brightness: 54.6666666667
> > secs between captures: 65.608
> > brightness percentage: 67.7187477963
> > screen brightness (avg): 0
>
> Ok, then seems to be a bug.
> Try doing:
>
> calised --dump-settings | grep screen
>
> and
>
> echo $DISPLAY
>
>
> If the first is set to True and $DISPLAY is not empty then:
>
> $ dbus-send --system --print-reply --type=method_call
> --dest=org.freedesktop.ConsoleKit
> /org/freedesktop/ConsoleKit/Manager
> org.freedesktop.ConsoleKit.Manager.GetSeats
>
> use object path (usually "/org/freedesktop/ConsoleKit/Seat1") to replace
> (eventually) the one in the row below:
>
> $ dbus-send --system --print-reply --type=method_call
> --dest=org.freedesktop.ConsoleKit
> */org/freedesktop/ConsoleKit/Seat1*
> org.freedesktop.ConsoleKit.Seat.GetActiveSession
>
> as for just before use object path (usually
> "/org/freedesktop/ConsoleKit/Session1") to replace (eventually) the one
> below:
>
> $ dbus-send --system --print-reply --type=method_call
> --dest=org.freedesktop.ConsoleKit
> */org/freedesktop/ConsoleKit/Session1*
> org.freedesktop.ConsoleKit.Session.GetX11Display
>
> These are dbus queries that calise sends to know if and, if true, what
> X11 display is active.
> There can be a bug for these since I've set the first of them to run
> once (I thought "seat" won't change).
> Actually accessing any X11 display from outside is "pain in the ass",
> really, even root has to substand X policies and magics...
>
> Thank you for reporting (btw, you're using as root on system startup
> right?).
>
> PS: Just seen your comment on webupd8 calise post: «man, who cares about
> graphical user interfaces, just gimmie the text!!!»
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Calise-testing mailing list
> Cal...@li...
> https://lists.sourceforge.net/lists/listinfo/calise-testing
>
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-13 22:02:46
|
Il 13/07/2012 19:50, Developement versions test results and discussion
ha scritto:
> Ok. To be sure, i restarted now calised.
> I'm in my xfce4 session, and no one of the choices you gave me is true.
> "date -d @1342201920.59
> ven 13 lug 2012, 19.52.00, CEST"
> calised -d:
> current backlight step: 8147
> capture timestamp (epoch): 1342201920.59
> secs before next day state: 7032.40669298
> day cycle state: sunset
> suggested backlight step: 8147
> ambient brightness: 54.6666666667
> secs between captures: 65.608
> brightness percentage: 67.7187477963
> screen brightness (avg): 0
Ok, then seems to be a bug.
Try doing:
calised --dump-settings | grep screen
and
echo $DISPLAY
If the first is set to True and $DISPLAY is not empty then:
$ dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit
/org/freedesktop/ConsoleKit/Manager
org.freedesktop.ConsoleKit.Manager.GetSeats
use object path (usually "/org/freedesktop/ConsoleKit/Seat1") to replace
(eventually) the one in the row below:
$ dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit
*/org/freedesktop/ConsoleKit/Seat1*
org.freedesktop.ConsoleKit.Seat.GetActiveSession
as for just before use object path (usually
"/org/freedesktop/ConsoleKit/Session1") to replace (eventually) the one
below:
$ dbus-send --system --print-reply --type=method_call
--dest=org.freedesktop.ConsoleKit
*/org/freedesktop/ConsoleKit/Session1*
org.freedesktop.ConsoleKit.Session.GetX11Display
These are dbus queries that calise sends to know if and, if true, what
X11 display is active.
There can be a bug for these since I've set the first of them to run
once (I thought "seat" won't change).
Actually accessing any X11 display from outside is "pain in the ass",
really, even root has to substand X policies and magics...
Thank you for reporting (btw, you're using as root on system startup
right?).
PS: Just seen your comment on webupd8 calise post: «man, who cares about
graphical user interfaces, just gimmie the text!!!»
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-13 17:50:26
|
Ok. To be sure, i restarted now calised. I'm in my xfce4 session, and no one of the choices you gave me is true. "date -d @1342201920.59 ven 13 lug 2012, 19.52.00, CEST" calised -d: current backlight step: 8147 capture timestamp (epoch): 1342201920.59 secs before next day state: 7032.40669298 day cycle state: sunset suggested backlight step: 8147 ambient brightness: 54.6666666667 secs between captures: 65.608 brightness percentage: 67.7187477963 screen brightness (avg): 0 2012/7/13 Developement versions test results and discussion < cal...@li...> > Il 12/07/2012 20:39, Developement versions test results and discussion > ha scritto: > > It seems that as version : > > calised --version > > calised GIT-20e0c6f > > i'm having this problem again : screen brightness (avg): 0 > > Is this normal? > > thanks! > > bye! > > No, it's not expected or, better, let's explain: > according to what I wrote (get screen brightness function) if any user > is active on the screen it should return screen brightness value, > otherwise 0. > > So, screen brightness has be 0 if: > - no one is logged yet it returns 0 (system startup) > - active user is on tty[1-6] (non X11, even if there's a X11 screen on > another -not currently used- tty) > - screen is blanked (power saving) > > I need to know what were you doing (-eventually- of the things above) or > what was screen condition during that capture. > > Also to know when, exactly, dumped capture has been taken, you can use > "capture timestamp (epoch)" from "--dump" output: > > date -d @capturetimestamp > > eg: > > date -d @1342177408.67 > > > Thanks for reporting. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-13 11:50:50
|
Well, if i do not use the netbook, i guess no, it is not a problem to have the backlight level reduced :) With xfce-power-manager i have the presentation mode that i can use when i'm watching film or studying or working, other times i want it to reduce screen brightness to save power. Well, so, let's hope a global dbus signal is emitted ;) 2012/7/13 Developement versions test results and discussion < cal...@li...> > Il 12/07/2012 20:47, Developement versions test results and discussion > ha scritto: > > Hi! > > I 'm using xfce4-power-manager, and i use to have my screen brightness > > lowered after 20s of inactivity. > > Well, i'd like that calised won't interfere with this option (i don't > > know if this can be done, so i'm only asking), because as now, after > > 20s my backlight is actually reduced, but then calised makes a capture > > and reset the brightness...(indeed it works when, after a minute, my > > screen gets turned off). > > I haven't idea how this can be achieved... > > Hope this can be easily integrated, but i don't think so :) > > Thanks for your time! > > Actually a good one, I don't know if before reducing screen backlight > level a global dbus signal is emitted, if so then it can be implemented > (not easy but I should give a try). > If no dbus signal is emitted I can do nothing since I'm not able to know > *when* the dim happens. > > Btw, isn't somehow disturbing having the backlight level reduced every > 20sec? > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-13 11:19:41
|
Il 12/07/2012 20:47, Developement versions test results and discussion ha scritto: > Hi! > I 'm using xfce4-power-manager, and i use to have my screen brightness > lowered after 20s of inactivity. > Well, i'd like that calised won't interfere with this option (i don't > know if this can be done, so i'm only asking), because as now, after > 20s my backlight is actually reduced, but then calised makes a capture > and reset the brightness...(indeed it works when, after a minute, my > screen gets turned off). > I haven't idea how this can be achieved... > Hope this can be easily integrated, but i don't think so :) > Thanks for your time! Actually a good one, I don't know if before reducing screen backlight level a global dbus signal is emitted, if so then it can be implemented (not easy but I should give a try). If no dbus signal is emitted I can do nothing since I'm not able to know *when* the dim happens. Btw, isn't somehow disturbing having the backlight level reduced every 20sec? |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-13 11:10:30
|
Il 12/07/2012 20:39, Developement versions test results and discussion
ha scritto:
> It seems that as version :
> calised --version
> calised GIT-20e0c6f
> i'm having this problem again : screen brightness (avg): 0
> Is this normal?
> thanks!
> bye!
No, it's not expected or, better, let's explain:
according to what I wrote (get screen brightness function) if any user
is active on the screen it should return screen brightness value,
otherwise 0.
So, screen brightness has be 0 if:
- no one is logged yet it returns 0 (system startup)
- active user is on tty[1-6] (non X11, even if there's a X11 screen on
another -not currently used- tty)
- screen is blanked (power saving)
I need to know what were you doing (-eventually- of the things above) or
what was screen condition during that capture.
Also to know when, exactly, dumped capture has been taken, you can use
"capture timestamp (epoch)" from "--dump" output:
date -d @capturetimestamp
eg:
date -d @1342177408.67
Thanks for reporting.
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-12 18:47:24
|
Hi! I 'm using xfce4-power-manager, and i use to have my screen brightness lowered after 20s of inactivity. Well, i'd like that calised won't interfere with this option (i don't know if this can be done, so i'm only asking), because as now, after 20s my backlight is actually reduced, but then calised makes a capture and reset the brightness...(indeed it works when, after a minute, my screen gets turned off). I haven't idea how this can be achieved... Hope this can be easily integrated, but i don't think so :) Thanks for your time! |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-12 18:40:04
|
It seems that as version : calised --version calised GIT-20e0c6f i'm having this problem again : screen brightness (avg): 0 Is this normal? thanks! bye! 2012/7/7 Federico Di Pierro <nie...@gm...> > It seems they aren't instead: > a.queryCtrl(12) > (9963788, 'White Balance Temperature, Auto', 0, 1, 1, 1, 1) > a.queryCtrl(28) > (9963804, 'Backlight Compensation', 1, 2, 1, 1, 1) > Is this fine? > Thanks! > > 2012/7/7 Developement versions test results and discussion < > cal...@li...> > >> Il 07/07/2012 16:28, Developement versions test results and discussion >> ha scritto: >> > Thanks...i'm really thinking about removing that stupid line in my >> > kernel line, it seems it creates lots of problems (not only with >> > calise, but 11484 steps are in absolute, too much, there must be >> > something wrong...), so i'll now try to see if it is fixed, but then >> > i'm going to revert that change to default. >> > Thanks! >> >> I don't think 11484 steps are too much, think, "progressive" in >> digital-world can only mean a lot of "digital" steps. And I think it's >> good. >> With 0->9 (10) steps configuration like mine you would have liked to >> have even billions of steps... I mean, 20 steps will fit, with 10 the >> user feels too much the backlight change. >> >> Btw, after "failed" step 7 before you probably have the two controls (12 >> and 28) set to 0. Use my module as in the previous mail to set them back >> to original values (otherwise you would have no-white balance and no >> backlight-compensation when using cheese or other webcam software). >> NOTE: pause calised before that. >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Calise-testing mailing list >> Cal...@li... >> https://lists.sourceforge.net/lists/listinfo/calise-testing >> > > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-12 17:37:19
|
Ok, i tested it now. It works with the .service unit file you include in your package (without .timer), but it adds something like 12seconds to boot time :) I'm now registering at mediawiki and may be i'll include the .timer soon, and any hints if i come up with them. Thanks for your wonderful software ;) 2012/7/12 Developement versions test results and discussion < cal...@li...> > Il 12/07/2012 13:36, Developement versions test results and discussion > ha scritto: > > I've now looked at new wiki page, congratulations, it is very well > > explained and clear. Btw, i noticed startup script -> systemd is left > > empty...as soon as i got time (may be today at about 19) i'll update > > it, with .timer script and other hints (if i come up with them :) ). > > I've had no time yet to upgrade to latest git and to test if calised > > can be ran immediately after dbus (consider that on systemd you can't > > run something immediately after something else, because of > > parallelization of processes. You only can specify that a service must > > be started after another, but this doesn't mean it will be started > > immediately after, hope i've been clear enough :) -> at least, as far > > as i know...may be i'm missing something ) > > Btw i'll try today afternoon, yet about 19 o'clock. > > I think you had a good idea about post-install text, that's clear > > enough. Look at wiki bro! :) > > Bye! > > Yup, you've been clear, btw I already know how systemd works (I tried it > some time ago but I was too much used with initd and I actually don't > care about bootup time) that said, is more or less what "@" do in initd, > only that it's based on that (and it's way better than initd...). > From what I've seen on the .service it seems to me that that > "type=dbus" (or whatever it was) means "start after dbus". > > Now, don't worry about systemd wiki or else, when you'd have time you'll > do it (I would have done myself but I cannot test if what I write is > correct); as said before that's "optional". > > And again, every idea about the program and/or the wiki it's always > welcome. > > Thanks for your interest > Bye > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-12 12:37:43
|
Il 12/07/2012 13:36, Developement versions test results and discussion ha scritto: > I've now looked at new wiki page, congratulations, it is very well > explained and clear. Btw, i noticed startup script -> systemd is left > empty...as soon as i got time (may be today at about 19) i'll update > it, with .timer script and other hints (if i come up with them :) ). > I've had no time yet to upgrade to latest git and to test if calised > can be ran immediately after dbus (consider that on systemd you can't > run something immediately after something else, because of > parallelization of processes. You only can specify that a service must > be started after another, but this doesn't mean it will be started > immediately after, hope i've been clear enough :) -> at least, as far > as i know...may be i'm missing something ) > Btw i'll try today afternoon, yet about 19 o'clock. > I think you had a good idea about post-install text, that's clear > enough. Look at wiki bro! :) > Bye! Yup, you've been clear, btw I already know how systemd works (I tried it some time ago but I was too much used with initd and I actually don't care about bootup time) that said, is more or less what "@" do in initd, only that it's based on that (and it's way better than initd...). From what I've seen on the .service it seems to me that that "type=dbus" (or whatever it was) means "start after dbus". Now, don't worry about systemd wiki or else, when you'd have time you'll do it (I would have done myself but I cannot test if what I write is correct); as said before that's "optional". And again, every idea about the program and/or the wiki it's always welcome. Thanks for your interest Bye |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-12 11:36:24
|
I've now looked at new wiki page, congratulations, it is very well explained and clear. Btw, i noticed startup script -> systemd is left empty...as soon as i got time (may be today at about 19) i'll update it, with .timer script and other hints (if i come up with them :) ). I've had no time yet to upgrade to latest git and to test if calised can be ran immediately after dbus (consider that on systemd you can't run something immediately after something else, because of parallelization of processes. You only can specify that a service must be started after another, but this doesn't mean it will be started immediately after, hope i've been clear enough :) -> at least, as far as i know...may be i'm missing something ) Btw i'll try today afternoon, yet about 19 o'clock. I think you had a good idea about post-install text, that's clear enough. Look at wiki bro! :) Bye! 2012/7/11 Developement versions test results and discussion < cal...@li...> > Il 11/07/2012 22:30, Developement versions test results and discussion > ha scritto: > > I have no time now to write in your wiki, but i already had a look at > > it! As soon as 0.4 is released, i'll read it again! very nice btw! > > Systemd .service mustn't be executable. May be, make the install > > script outputs something like : > > "Don't forget to run systemctl enable calised.service (you named it > > calised,service or calise.service? i do not remember!) if you want > > calised to be start as root with systemd!" > > And in archlinux italian forum i wrote the .timer too, because systemd > > makes use of aggressive parallelization of processes, and calised is a > > slow process (because it needs access to webcam) and make it run > > during the boot process (while lots of processes are started, and > > there is intense I/O activity) make the whole boot time increase of > > 7-8'' or more. (at least for me.) > > Plus, i don't know when webcam can be accessed without any error > > (after the right module has been loaded, for those who have an > > initramfs, i've not it, so i can't tell you), and this thing can > > create others problem. > > So, if you think i'm right, and if you followed me (hope so, sorry if > > i couldn't explain me very well), please add the .timer file and > > everything will be ok. > > In that case, change the output i said before in: > > "Don't forget to run systemctl enable calised.service or > > [reccommended] calised.timer (25seconds after startup, more > > information man systemd.timer) if you want calised to be start as root > > with systemd!" > > Hope this can be helpful :) > > One of the bugs I fixed today should have been the one that caused the > process to not start well if called before ConsoleKit loads. So, at > least on my machine (with initscripts), calised can run just after dbus > is loaded (if you can try with systemd, that will be *really* helpful, > of course, after you tested put your "timer" back in). > Now, the timer it's a good thing but I won't include it in the package > because the amount of time it's totally arbitrary, better should be > writing a small page on the wiki about "running as system-wide service" > at startup with either systemd or initd with all the hints and > suggestions to have the perfect setup. Obviously including the "timer" > thing and so on. > > My idea for post-install text was that: > > initd and systemd startup scripts addedd > > then everyone is free to search archlinux wikipages about daemons to > know how to add them. Yes, I know, I *hate* post-install text (don't > know why but that's it). > > About boot time, for sure, calised, during the "startup", performs quite > a lot of heavy operations. I mean it's more or less the same of loading > cheese (actually way less) at system startup. > > About the wiki, I'll split it up to several pages very soon, a big page > with everything is *bad* (it's like writing a single function program). > > Don't worry if you haven't enough time to test systemd script, the > systemd/initd issue it's only archlinux related, so I can release 0.4.0 > anyway. I mean, I cannot make a startup script for every distribution, > that's the packager duty (and as archlinux calise packager I'm getting > it done). > > Thank you very much for your cooperation. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-11 21:28:07
|
Il 11/07/2012 22:30, Developement versions test results and discussion
ha scritto:
> I have no time now to write in your wiki, but i already had a look at
> it! As soon as 0.4 is released, i'll read it again! very nice btw!
> Systemd .service mustn't be executable. May be, make the install
> script outputs something like :
> "Don't forget to run systemctl enable calised.service (you named it
> calised,service or calise.service? i do not remember!) if you want
> calised to be start as root with systemd!"
> And in archlinux italian forum i wrote the .timer too, because systemd
> makes use of aggressive parallelization of processes, and calised is a
> slow process (because it needs access to webcam) and make it run
> during the boot process (while lots of processes are started, and
> there is intense I/O activity) make the whole boot time increase of
> 7-8'' or more. (at least for me.)
> Plus, i don't know when webcam can be accessed without any error
> (after the right module has been loaded, for those who have an
> initramfs, i've not it, so i can't tell you), and this thing can
> create others problem.
> So, if you think i'm right, and if you followed me (hope so, sorry if
> i couldn't explain me very well), please add the .timer file and
> everything will be ok.
> In that case, change the output i said before in:
> "Don't forget to run systemctl enable calised.service or
> [reccommended] calised.timer (25seconds after startup, more
> information man systemd.timer) if you want calised to be start as root
> with systemd!"
> Hope this can be helpful :)
One of the bugs I fixed today should have been the one that caused the
process to not start well if called before ConsoleKit loads. So, at
least on my machine (with initscripts), calised can run just after dbus
is loaded (if you can try with systemd, that will be *really* helpful,
of course, after you tested put your "timer" back in).
Now, the timer it's a good thing but I won't include it in the package
because the amount of time it's totally arbitrary, better should be
writing a small page on the wiki about "running as system-wide service"
at startup with either systemd or initd with all the hints and
suggestions to have the perfect setup. Obviously including the "timer"
thing and so on.
My idea for post-install text was that:
initd and systemd startup scripts addedd
then everyone is free to search archlinux wikipages about daemons to
know how to add them. Yes, I know, I *hate* post-install text (don't
know why but that's it).
About boot time, for sure, calised, during the "startup", performs quite
a lot of heavy operations. I mean it's more or less the same of loading
cheese (actually way less) at system startup.
About the wiki, I'll split it up to several pages very soon, a big page
with everything is *bad* (it's like writing a single function program).
Don't worry if you haven't enough time to test systemd script, the
systemd/initd issue it's only archlinux related, so I can release 0.4.0
anyway. I mean, I cannot make a startup script for every distribution,
that's the packager duty (and as archlinux calise packager I'm getting
it done).
Thank you very much for your cooperation.
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-11 20:30:44
|
I have no time now to write in your wiki, but i already had a look at it! As soon as 0.4 is released, i'll read it again! very nice btw! Systemd .service mustn't be executable. May be, make the install script outputs something like : "Don't forget to run systemctl enable calised.service (you named it calised,service or calise.service? i do not remember!) if you want calised to be start as root with systemd!" And in archlinux italian forum i wrote the .timer too, because systemd makes use of aggressive parallelization of processes, and calised is a slow process (because it needs access to webcam) and make it run during the boot process (while lots of processes are started, and there is intense I/O activity) make the whole boot time increase of 7-8'' or more. (at least for me.) Plus, i don't know when webcam can be accessed without any error (after the right module has been loaded, for those who have an initramfs, i've not it, so i can't tell you), and this thing can create others problem. So, if you think i'm right, and if you followed me (hope so, sorry if i couldn't explain me very well), please add the .timer file and everything will be ok. In that case, change the output i said before in: "Don't forget to run systemctl enable calised.service or [reccommended] calised.timer (25seconds after startup, more information man systemd.timer) if you want calised to be start as root with systemd!" Hope this can be helpful :) 2012/7/11 Developement versions test results and discussion < cal...@li...> > Il 11/07/2012 19:46, Developement versions test results and discussion > ha scritto: > > Yes, i knew it :) > > thanks! > > ps: what's new in today update? (i know i ask you this everytime > > sorry!i'm only curious ) > > and sorry if i did not answer you, but after i wrote the first mail, i > > did a calised --restart and i haven't encountered that problem yet. > > bye! > > Today I updated frequently because I'm going to release 0.4.0 very soon > (probably tomorrow). > Version GIT-1d41599 should be (future) release 0.4.0. I fixed (or at > least tried to) every critical or feature blocking bug.* > > I'll ask (if you have time) to check if systemd script implementation is > ok (it hasn't to be executable, right?). > > Now, about changes, I'll love anyone asking me that, so don't be shy > asking things or reporting bugs, if I have time I'll answer. > git shortlog dump (Wed Jul 11 2012): > > 08:16:05 | few optimizations and capture anti-lock method > implementation > 10:44:02 | addedd init and systemd scripts, changed calised command > priority, fixed minor imprecision in setup.py and changed version > (pre-release) > 17:16:21 | init_script pidof-related bugfix > 17:26:11 | QtGui export-data bugfix > 18:18:17 | final init_script bugfix, now works > 21:01:11 | fixed issue 3542639, workaround for issue 3541919 > > Poorly speaking I "fixed this and that", prepared everything for release > and so on. > > Btw, I'm (slowly, need more that 24h per day) updating the wiki (as > 0.4.0 is released, also the wiki will be). I don't remember the changing > policies I put (probably registration is needed) but everyone should be > able to change any page. > If you have suggestions please report to me, if you think something > needs to be modified, modify it. > Of course if you want to complete/add sections you're absolutely welcome! > If you lost it and you don't want to search it on the forums: > http://calise.sourceforge.net/mediawiki/ > > > * I still have iss3541919 branch active on git but complete fix will > came with 0.4.1 or farther. Right is threated as critical error. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-11 20:03:13
|
Il 11/07/2012 19:46, Developement versions test results and discussion
ha scritto:
> Yes, i knew it :)
> thanks!
> ps: what's new in today update? (i know i ask you this everytime
> sorry!i'm only curious )
> and sorry if i did not answer you, but after i wrote the first mail, i
> did a calised --restart and i haven't encountered that problem yet.
> bye!
Today I updated frequently because I'm going to release 0.4.0 very soon
(probably tomorrow).
Version GIT-1d41599 should be (future) release 0.4.0. I fixed (or at
least tried to) every critical or feature blocking bug.*
I'll ask (if you have time) to check if systemd script implementation is
ok (it hasn't to be executable, right?).
Now, about changes, I'll love anyone asking me that, so don't be shy
asking things or reporting bugs, if I have time I'll answer.
git shortlog dump (Wed Jul 11 2012):
08:16:05 | few optimizations and capture anti-lock method implementation
10:44:02 | addedd init and systemd scripts, changed calised command
priority, fixed minor imprecision in setup.py and changed version
(pre-release)
17:16:21 | init_script pidof-related bugfix
17:26:11 | QtGui export-data bugfix
18:18:17 | final init_script bugfix, now works
21:01:11 | fixed issue 3542639, workaround for issue 3541919
Poorly speaking I "fixed this and that", prepared everything for release
and so on.
Btw, I'm (slowly, need more that 24h per day) updating the wiki (as
0.4.0 is released, also the wiki will be). I don't remember the changing
policies I put (probably registration is needed) but everyone should be
able to change any page.
If you have suggestions please report to me, if you think something
needs to be modified, modify it.
Of course if you want to complete/add sections you're absolutely welcome!
If you lost it and you don't want to search it on the forums:
http://calise.sourceforge.net/mediawiki/
* I still have iss3541919 branch active on git but complete fix will
came with 0.4.1 or farther. Right is threated as critical error.
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-11 17:47:08
|
Yes, i knew it :) thanks! ps: what's new in today update? (i know i ask you this everytime sorry!i'm only curious ) and sorry if i did not answer you, but after i wrote the first mail, i did a calised --restart and i haven't encountered that problem yet. bye! 2012/7/11 Developement versions test results and discussion < cal...@li...> > Il 09/07/2012 19:26, Developement versions test results and discussion > ha scritto: > > Yes, i know you already knew it. > > But only to be sure, it happens sometimes that calised stops doing its > > work. > > calised -d will say that sleep time between captures is a normal > > number, but then, after those seconds, it won't start a capture. > > calised -c works instead. > > No errors in log...if i reboot everything is ok. It only happens > > sometimes, and probably i should restart calised to have it work again. > > What is it related to? > > :) thanks! > > More or less I've been able to reproduce your bug report. Until it's > fixed you can do > > calised --restart > > as workaround, keeps everything (service, pid, tempfiles and log) but > restarts only the "capture" thread. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-11 17:22:42
|
Il 09/07/2012 19:26, Developement versions test results and discussion
ha scritto:
> Yes, i know you already knew it.
> But only to be sure, it happens sometimes that calised stops doing its
> work.
> calised -d will say that sleep time between captures is a normal
> number, but then, after those seconds, it won't start a capture.
> calised -c works instead.
> No errors in log...if i reboot everything is ok. It only happens
> sometimes, and probably i should restart calised to have it work again.
> What is it related to?
> :) thanks!
More or less I've been able to reproduce your bug report. Until it's
fixed you can do
calised --restart
as workaround, keeps everything (service, pid, tempfiles and log) but
restarts only the "capture" thread.
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-09 18:24:27
|
Il 09/07/2012 19:26, Developement versions test results and discussion
ha scritto:
> Yes, i know you already knew it.
> But only to be sure, it happens sometimes that calised stops doing its
> work.
> calised -d will say that sleep time between captures is a normal
> number, but then, after those seconds, it won't start a capture.
> calised -c works instead.
> No errors in log...if i reboot everything is ok. It only happens
> sometimes, and probably i should restart calised to have it work again.
> What is it related to?
> :) thanks!
Well, too few infos...
First of all make sure you have latest git master: GIT-e7176e3
Then, next time this happens, let me have the complete log (you can
redirect the command below to file):
cat `calised --dump-settings | grep logfile | aw'{print $NF}'`
and maybe also:
calised --dump-all
Hope we're able to find why this happens.
|
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-09 17:26:36
|
Yes, i know you already knew it. But only to be sure, it happens sometimes that calised stops doing its work. calised -d will say that sleep time between captures is a normal number, but then, after those seconds, it won't start a capture. calised -c works instead. No errors in log...if i reboot everything is ok. It only happens sometimes, and probably i should restart calised to have it work again. What is it related to? :) thanks! |
|
From: Developement v. t. r. a. d. <cal...@li...> - 2012-07-07 15:13:27
|
It seems they aren't instead: a.queryCtrl(12) (9963788, 'White Balance Temperature, Auto', 0, 1, 1, 1, 1) a.queryCtrl(28) (9963804, 'Backlight Compensation', 1, 2, 1, 1, 1) Is this fine? Thanks! 2012/7/7 Developement versions test results and discussion < cal...@li...> > Il 07/07/2012 16:28, Developement versions test results and discussion > ha scritto: > > Thanks...i'm really thinking about removing that stupid line in my > > kernel line, it seems it creates lots of problems (not only with > > calise, but 11484 steps are in absolute, too much, there must be > > something wrong...), so i'll now try to see if it is fixed, but then > > i'm going to revert that change to default. > > Thanks! > > I don't think 11484 steps are too much, think, "progressive" in > digital-world can only mean a lot of "digital" steps. And I think it's > good. > With 0->9 (10) steps configuration like mine you would have liked to > have even billions of steps... I mean, 20 steps will fit, with 10 the > user feels too much the backlight change. > > Btw, after "failed" step 7 before you probably have the two controls (12 > and 28) set to 0. Use my module as in the previous mail to set them back > to original values (otherwise you would have no-white balance and no > backlight-compensation when using cheese or other webcam software). > NOTE: pause calised before that. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Calise-testing mailing list > Cal...@li... > https://lists.sourceforge.net/lists/listinfo/calise-testing > |