Re: Sunsetting PowerDevil's XRandrBrightness

2020-05-27 Thread Martin Steigerwald
Martin Steigerwald - 26.05.20, 14:35:39 CEST:
> Hi Kai.
> 
> Kai Uwe Broulik - 20.05.20, 21:31:07 CEST:
> > PowerDevil has two (three, if you count DDC) means of controlling
> > screen brightness:
> > 
> > * Writing to sysfs (/sys/class/backlight and /sys/class/leds)
> > * Using XRandr output property
> > 
> > XRandR is doing X calls and we have some lovely animated screen
> > brightness change. However, the UPower "backend" in PowerDevil is
> > quite a spaghetti class and having multiple ways to control LEDs
> > doesn't help.
> 
> Read your blog post and tried the command there:
> 
> % QT_LOGGING_RULES='powerdevil=true'
> /usr/lib/x86_64-linux-gnu/libexec/ org_kde_powerdevil
> 
> gave no output whatsoever.
> 
> However as I am using the "modesetting" driver I bet it won't use
> XRandR.
> 
> Also that is on Debian Sid where KDE Frameworks currently is still at
> 5.62. Sandro works on 5.70 currently. ThinkPad T520 with Intel
> Sandybridge graphics.

Actually I already had 5.69 from Debian experimental. 5.70 now coming in 
to unstable, so I can test again once it is available.

-- 
Martin




Re: Sunsetting PowerDevil's XRandrBrightness

2020-05-26 Thread Martin Steigerwald
Hi Kai.

Kai Uwe Broulik - 20.05.20, 21:31:07 CEST:
> PowerDevil has two (three, if you count DDC) means of controlling
> screen brightness:
> 
> * Writing to sysfs (/sys/class/backlight and /sys/class/leds)
> * Using XRandr output property
> 
> XRandR is doing X calls and we have some lovely animated screen
> brightness change. However, the UPower "backend" in PowerDevil is
> quite a spaghetti class and having multiple ways to control LEDs
> doesn't help.

Read your blog post and tried the command there:

% QT_LOGGING_RULES='powerdevil=true' /usr/lib/x86_64-linux-gnu/libexec/
org_kde_powerdevil

gave no output whatsoever. 

However as I am using the "modesetting" driver I bet it won't use 
XRandR.

Also that is on Debian Sid where KDE Frameworks currently is still at 
5.62. Sandro works on 5.70 currently. ThinkPad T520 with Intel 
Sandybridge graphics.

Best,
-- 
Martin




Re: Sunsetting PowerDevil's XRandrBrightness

2020-05-25 Thread Oded Arbel
On Kubuntu 20.04 with Plasma 5.18, I'm not use xrandr:

powerdevil: Backend loaded, loading core
powerdevil: Core loaded, initializing backend
powerdevil: Xrandr not supported, trying ddc, helper
powerdevil: [DDCutilBrightness] compiled without DDC/CI support
powerdevil: Falling back to helper to get brightness

It looks like it is using
/sys/devices/pci:00/:00:02.0/drm/card0/card0-eDP-1/intel_backlight

The device is a laptop with Optimus and using Intel HD 630 for the display.
--
Oded


Re: Sunsetting PowerDevil's XRandrBrightness

2020-05-21 Thread Kai Uwe Broulik

> One thing which this will trip over is, if device supports both XRandr
> and normal backlight control, then code will prefer to still use the
> XRandr, so not sure if we can "trust" data.

That's on purpose, since XRandR has the smooth brightness animation, I 
always prefer that one, if possible. :)


> Can we figure out some stats from e.g. bug reports and logs we have
> available?

Not sure, maybe. or KUserFeedback :D



Re: Sunsetting PowerDevil's XRandrBrightness

2020-05-21 Thread Bhushan Shah
Hi Kai,

On Wed, May 20, 2020 at 09:31:07PM +0200, Kai Uwe Broulik wrote:
> XRandR is doing X calls and we have some lovely animated screen brightness
> change. However, the UPower "backend" in PowerDevil is quite a spaghetti
> class and having multiple ways to control LEDs doesn't help.

I have one patchset work in progress to make upowerbackend not backend
anymore, I will post that up for review later this week I think.

> Can we get rid of the XRandrBrightness class and just use sysfs in every
> case?

You know what I will say! :D

But, yes +1000!

> XRandR Brightness doesn't work on Wayland, obviously, and the Intel
> driver which supported it is dead. Are there any other GPU drivers or models
> that use XRandR over sysfs? AMD, nvidia? I vaguely recall something but I
> don't know for sure.

Can we figure out some stats from e.g. bug reports and logs we have
available?

One thing which this will trip over is, if device supports both XRandr
and normal backlight control, then code will prefer to still use the
XRandr, so not sure if we can "trust" data.

You'd need something like this to short-circuit the XRandR backend and
verify that it still works with sysfs interface.

https://invent.kde.org/plasma/powerdevil/snippets/935

> (We're super early in the 5.20 cycle, so if we rip it out now, we still have
> four months to ignore any requests to put it back in ;)

I agree with this.

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature


Sunsetting PowerDevil's XRandrBrightness

2020-05-20 Thread Kai Uwe Broulik

Hi all,

PowerDevil has two (three, if you count DDC) means of controlling screen 
brightness:


* Writing to sysfs (/sys/class/backlight and /sys/class/leds)
* Using XRandr output property

XRandR is doing X calls and we have some lovely animated screen 
brightness change. However, the UPower "backend" in PowerDevil is quite 
a spaghetti class and having multiple ways to control LEDs doesn't help.


Can we get rid of the XRandrBrightness class and just use sysfs in every 
case? XRandR Brightness doesn't work on Wayland, obviously, and the 
Intel driver which supported it is dead. Are there any other GPU drivers 
or models that use XRandR over sysfs? AMD, nvidia? I vaguely recall 
something but I don't know for sure.


(We're super early in the 5.20 cycle, so if we rip it out now, we still 
have four months to ignore any requests to put it back in ;)


Cheers
Kai Uwe