Yo,

2013/5/25 Kai Uwe Broulik <kde@privat.broulik.de> I'm currently working on revamping the battery monitor and found that t= he
algorithm that is supposed to hide brightness slider in case backlight
controls are not supported in 4.11 doesn't work and always returns true=
leading the a sort of unchanged situation.
My new battery monitor tries to be a lot cleaner and so having proper
backlight support detection is important for that. Especially since it will=
have keyboard backlight support too, and having two useless sliders is bad.=
(Okay, keyboard backlight afaik is properly detected).

Much appreciated :)

=A0

My analysis shows:
Problem 1)
In powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp always doe= s
controls.insert(QLatin1String("LVDS1"), Screen);
no matter whether the checks a bit earlier have failed. In the action itsel= f
the isSupported() function checks whether brightnessControlsList is empty,<= br> which is never the case because it alawys contains LVDS1.

<= div>

I honestly don't remember why that code was th= ere, and probably it wasn't even me who wrote it. Anyway. Maybe the wor= k in KScreen might be useful to identify which output to pilot when dealing= with brightness, and might have the interesting consequence of piloting br= ightness on different outputs. Again, I never really took care of that area= specifically, so I might be completely out of track.

=A0

Problem is also, if the brightness controls are not available, PowerDevil s= pam
you with the "The profile foo tried to load action BrightnessControls = which is
a non-existent action.", so this message also needs fixing in this cas= e.

This is an interesting consequ= ence of the changed behavior of the brightness actions, which no longer loa= d upon brightness control being not supported, and the generator (or previo= us configs) not being aware of that. We have two possible fixes here:

=A0* Simply ignore the fact the config file= might have bogus action sections, and skip them over

=A0* = Fix the generators and make the loader aware of the fact some actions are p= resent, but not loaded.

I personally favor the second, and can prov= ide a fix for that. Thoughts?

=A0

Problem 2)
The power management engine just connects to the
/org/kde/Solid/PowerManagement/Actions/BrightnessControls object. And it se= ems
the connect call *always* returns true, even if the object doesn't even= exist.

Yes, unfortunately QDBusC= onnection::connect gives no information over the existence of the signal it= self, and we have to live with that...

=A0

So, the dataengine itself always says that backlight controls are available= ,
regardless of Problem 1. (And also it won't notice if the controls beco= me
unavailable in the mean time or if they become available after plasma start= ed
for some reason)

Any comment or suggestion?

The on= ly reliable way to monitor things on DBus is relying on service names. What= we can do is having the actions register a org.kde.Solid.PowerManagement.{= BrightnessControl, KeyboardBrightnessControl} service on the session bus an= d the engine monitor the existence of both of them. I personally quite favo= r the solution and the use case seems sound to me, so I'd go for that, = if you agree.

=A0

I did a few hacks and workarounds in the code mentioned above, it's ins= ide the
plasma/broulik/batterymonitor branch of kde-workspace. It does somewhat wor= k
but is definitly not something for production use or merging.

I'll definitely have a look.
=A0=

Greetings,
Kai Uwe
_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel