simgunz / redshift-plasmoid

Adjusts and configures screen luminosity depending on your surroundings, using Redshift.
http://simgunz.org/projects/redshift-plasmoid/
GNU General Public License v3.0
51 stars 3 forks source link

Redshift not correctly autostarting (for me) #1

Closed qwerty12 closed 12 years ago

qwerty12 commented 12 years ago

OS: Arch Linux KDE version: 4.8.3 Redshift Plasmoid version: 0.4

redshiftrc: [General] autolaunch=true dayTemp=6400 latitude=51.5 longitude=-0.1 smooth=true

Hi,

First of all, thanks for the applet! However, its Autolaunch option fails to correctly work on my system. It's 00:56 here in London and it's been ~8 minutes since I've started KDE so I would expect Redshift to kick in now. However, it has not done so. The result of "ps aux | grep redshift": faheem 3675 0.0 0.0 63688 4384 ? S 00:49 0:00 /usr/bin/redshiftautostart

If I run redshiftautostart manually while running "dbus-monitor --session", I see: signal sender=:1.47 -> dest=(null destination) serial=3 path=/; interface=org.kde.redshift; member=readyForStart which I assume what is supposed to happen.

Finally: Clicking the Redshift applet while it is like this causes KDE to crash with a message about ksmserver - it seems that m_process->pid() returns 0 and sending SIGUSR1 to it doesn't go down well...

EDIT: Clicking the redshift toggle about 10 times yielded in nothing happening; however, as soon as I turned off "Smooth transition" Redshift started the moment I clicked OK. On a fresh KDE session start (with autolaunch on), it seems I have to toggle the "Smooth transition" (regardless of whether it was already on or off) setting for Redshift to start

simgunz commented 12 years ago

The autostart is the most problematic point of this program and actually I expected this kind of issues.

Redshift start when you edit any of the configuration option (it is not related to smooth transition). This happen because redshift is restarted everytime you click OK on the configuration panel.

The problem is: if redshift is started too early during the login phase the process redshift is launched but it doesn't change the color of the monitor. To prevent this I used a tricky solution.

When redshift is ready to start it send a signal, this signal is catched by redshiftautostart that reply with a ready signal.

redshiftautostart is launched late (after the panel) in the login process.

If redshift is ready to start too early (before redshiftautostart is launched) the signal is not catched, and redshift does not start. In this case when redshiftautostart is launched it send (in any case) a readySignal and redshift is launched.

If redshiftautostart is launched too early, redshift is launched but the monitor color doesn't change.

Your situation is weird, infact the redshift process should be there when you do ps aux (even if the monitor color is not changed).

I'll do some test on this and I let you know.

I'll also put a check before sendind SIGUSR1 to prevent KDE to crash.

Thanks for the report.

qwerty12 commented 12 years ago

Thank you very much for your detailed reply. Using qDebug in RedshiftController::setReadyForStart() and dbus-send to manually send the readyCheck signal I was able to verify that the communication between redshiftautostart and the applet is OK.

However, and this is the reason why m_process->pid() is 0, RedshiftController::dataUpdated() is actually never called on my system. By manually inserting readConfig(); into RedshiftController's constructor, Redshift actually starts upon KDE starting.

simgunz commented 12 years ago

Check it out the 0.4.1 version. Your issue should be solved.

"If redshiftautostart is launched too early, redshift is launched but the monitor color doesn't change." This last problem still persist

qwerty12 commented 12 years ago

Thank you, redshift does now start automatically for me