Brightness Control

[makilakixki1312]

Hi, I've been using GDM (I had to use Ubuntu 18.04 in my laptop for a while), and I found an enhancement that I would like to see in SDDM. In the login screen, using the "fn" keys, and with the top bar, it was possible to adjust screen brightness. I came to KDE, expecting the same functionality, and it wasn't possible. So, is there any workaround (editing the qml...)? Or it is just a feature that it needs to go in the source code?

[Pointedstick]

Why is this closed?

[plfiorini]

While I don't know why @egen0 closed the issue, I think this issue should be addressed to Plasma.

[makilakixki1312]

Not important, it is just a minor issue. The screen brightness control is an issue that only applies to laptop users, and it is just irrelevant. If you want I can reopen it. And as @plfiorini just said it is probably a plasma issue.

[Pointedstick]

@davidedmundson do you know if this is something we need to fix in Plasma, or is it ideally done in SDDM?

[makilakixki1312]

May I reopen the issue then?

[davidedmundson]

do you know if this is something we need to fix in Plasma, or is it ideally done in SDDM? Both.

Rewriting all the brightness stuff in sddm would be a waste, it's non trivial with all the backends.

From a plasma POV we need to load kglobalaccel and powerdevil, but not much else, which is a challenge. There's also no neat hook from SDDM to spawn these extra binaries and embedding that sort of stuff inside in a theme would be super weird.

If you solved the spawning process then we can have something like https://plus.google.com/117221897452321521192/posts/jkQJgnWeeg7 again

[makilakixki1312]

I will reopen the issue.

[plfiorini]

What's that Google+ link about?

[Pointedstick]

Thanks David!

[plfiorini]

What kind of hook do you need from SDDM? You could just create a new QML plugin for the Plasma theme that does all that.

[ratijas]

+1

I've been using SDDM in pass-though mode (auto login without asking password) for a while, so I didn't notice until now. But since I reinstalled my system from scratch, I was surprised that brightness controls don't work out of the box at the login screen. Note that everything is fine in Plasma session, and I could manually xbacklight even before installing anything beyond bare Xorg.

I understand that from technical point of view there are many moving parts, backends and plugins at play. But for a user, being impossible to turn down brightness unless you type in password and wait 'till your session loads — is a big huge WAT?! But it's too late to wonder why that's not a part of kernel or X11 protocol, so we'll have to live with what we've got.

Does anyone have a clear vision of a path forward? What can and should be done?

---

OS: ArchLinux 5.12.8-arch1-1 sddm: 0.19.0-6

[doankimhuy-it]

Any updates on this issue? I've switch to kde for some time and having to deal with high brightness at night work is a real pain.

[Krelyshy]

This is not Plasma's issue. In Plasma, the aforementioned keys work normally. However sddm seems to have no support for them, so you can not change the brightness on the lock screen, which is quite annoying for regular users.

[Etaash-mathamsetty]

still has not been addressed and the last release was 2 years ago lol

[slynobody]

oh boy. how narrow-minded could a person be to call this 'irrelevant'? Imagine teaching a child to use open source software instead of the stuff all the others use at home. Imagine him working into the night and he had turned the brightness down then to dont waste his eyes to early. Next day, when he wakes up he cannot login to his laptop because its to dark. and he has 'brightness' keys on the laptop. how could a open-source-lover tell his child why this works at apple but not here? This issue would be one of the first i would adress if i were you if you would like to see a open source community in the near future when this child is grown up and open source software had grown with him to not be some little, little niche thing like it was 15 years ago. what a mindset.

and please don't just delete this post because you think it is 'not relevant'. what is the difference to closed software then?

[Krelyshy]

Slynobody said it pretty well, 2 years later, and still, nothing has happened. SDDM is pretty great, except for those bugs and people making software less customizable, which could be in the end called bugs as well...

[ratijas]

Slynobody said it pretty well, 2 years later, and still, nothing has happened. SDDM is pretty great, except for those bugs and people making software less customizable, which could be in the end called bugs as well...

The frustration is understandable, and there's no question about the need of this feature. However, in open source world it is usually just a matter of someone stepping up and doing the job — or hiring someone else to do it for them.

For example, I would like to have brightness controls in SDDM, but 1) I realize this a very specific task which could take a while to figure out all those backends, and 2) I'm currently busy with other stuff in KDE land.

Also, what was that about making software less customizable? 🤔

[Krelyshy]

Oh, sorry about the software customization... that's another frustration from a KDE problem regarding powering the pc off from the lock screen. I am going to try and learn about SDDM but I am currently heavily occupied as well.

[Etaash-mathamsetty]

I think its a good time for someone to fork this and rename it kddm or something

[plfiorini]

I think its a good time for someone to fork this and rename it kddm or something

Why would someone need to fork SDDM and do the job on the same code base but elsewhere when they can just submit it upstream as a pull request?

The reason why some stuff doesn't get done in SDDM is lack of spare time and money. Since the project is totally unfunded, it relies on the spare time of its developers, which is pretty scarce. It's not like we don't want to do things on purpose.

That being said: It is also worth noting that the infrastructure needed for brightness control (usually an helper program with privileges to access the brightness control files) is usually already there in most desktop environments, so it's easier to implement it there.

@davidedmundson What would you need from SDDM to implement this feature in the Plasma theme?

[MenacingPerson]

I think #776 and a few others are good examples as to why a fork is needed. PRs simply don't get accepted.

[Etaash-mathamsetty]

I think its a good time for someone to fork this and rename it kddm or something

Why would someone need to fork SDDM and do the job on the same code base but elsewhere when they can just submit it upstream as a pull request?

The reason why some stuff doesn't get done in SDDM is lack of spare time and money. Since the project is totally unfunded, it relies on the spare time of its developers, which is pretty scarce. It's not like we don't want to do things on purpose.

That being said: It is also worth noting that the infrastructure needed for brightness control (usually an helper program with privileges to access the brightness control files) is usually already there in most desktop environments, so it's easier to implement it there.

@davidedmundson What would you need from SDDM to implement this feature in the Plasma theme?

And that's exactly why a fork is needed, nobody is really accepting pr's and i am sure there are many others who do have the spare time to develop a fork of this project

[Pointedstick]

Then those people should ask for commit rights for this project and do the work here.

[Etaash-mathamsetty]

Then those people should ask for commit rights for this project and do the work here.

yes that's a much better idea

[Pointedstick]

Cool. So who wants commit rights? @plfiorini are you willing to grant them to some of the interested people?

[Etaash-mathamsetty]

Cool. So who wants commit rights? @plfiorini are you willing to grant them to some of the interested people?

Since nobody wants them, I guess I will take commit rights then?

[davidedmundson]

@davidedmundson What would you need from SDDM to implement this feature in the Plasma theme?

That's the problem. Doing it in the theme we can do right with no SDDM changes. Anyone could do it trivially in an evening.

What we're missing is a concept of a hook that provides all our KDE-level integration whilst remaining theme agnostic in a way that doesn't clash with other desktop usage.

Options are:

• we say it's a theme task
• have a platform integration hook that just loads a random plugin in a given directory inside the greeter (kinda like QPlatformTheme)
• have a greeter lib and us fork the greeter?

[davidedmundson]

I guess I will take commit rights then?

Cool, I will more than happily give commit rights to anyone actively working on SDDM.

But asking first isn't how any open source project works. You don't need commit rights to do meaningful code review, or manage tickets. One always starts off doing that.

[Etaash-mathamsetty]

I guess I will take commit rights then?

Cool, I will more than happily give commit rights to anyone actively working on SDDM.

But asking first isn't how any open source project works. You don't need commit rights to do meaningful code review, or manage tickets. One always starts off doing that.

Yeah that's ofc true, I knew that before asking. I was just wondering what the requirements would be, or what I would have to do first. Now I know

[wgunruh]

I would not mind if I could put sddm on bright when it came up. I can always adjust that when I log in. At present it is very dark, which makes it very hard to log in if I am in a bright light (eg sunlight). To argue that this would only affect a minority of users is really silly. I suspect that most Linux individual users are on laptops.

[klhughes]

This likely only applies to a subset of people, those with laptops with AMD CPUs not using systemd.

I noticed that in /etc/init.d/brightness the settings for initial screen brightness does not include an option for AMD. However, there is a notation for where to add additional entries. For my laptop, I added the # AMD section:

do_invoke() {
        local rv=0 rc
        # ACPI (without explicit label)
        do_$1 '' \
            /sys/class/backlight/acpi_video0/brightness \
            /sys/class/backlight/acpi_video0/max_brightness
        rc=$?
        test $rc -lt $rv || rv=$rc
        # Intel
        do_$1 intel \
            /sys/class/backlight/intel_backlight/brightness \
            /sys/class/backlight/intel_backlight/max_brightness
        rc=$?
        test $rc -lt $rv || rv=$rc
        # AMD
        do_$1 amd \
            /sys/class/backlight/amdgpu_bl0/brightness \
            /sys/class/backlight/amdgpu_bl0/max_brightness
        rc=$?
        test $rc -lt $rv || rv=$rc
        return $rv
}

Upon reboot, the brightness at the sddm login screen is at 100%.

[Krelyshy]

I have an i5 system.

[klhughes]

@Krelyshy, does your installation use sysvinit or systemd? I can attempt to offer a solution for you based on your answer.

[wgunruh]

I have intel I7 system with intel graphics, not AMD. I use systemd

[Krelyshy]

@Krelyshy, does your installation use sysvinit or systemd? I can attempt to offer a solution for you based on your answer.

@klhughes I have openSUSE with systemd

[medmedin2014]

@Pointedstick It would be great if the project would be absorbed/forked under the umbrella of KDE project in order to get more Plasma support and specific integration. A greeter is the first thing a user will use in any operating system, and not having the ability to decrease brightness at night (or increase it during the day) and waiting for a whole KDE session to load to do it seems acceptable but not ideal.

[andreas-thalhammer]

I have the same problem. KDE Plasma works like a charm out-of-the-box. Linux, the kernel, also has something to control brightness built-in: since I use the amdgpu module as my main graphics card (kernel mode setting, KMS), I have /sys/class/backlight/amdgpu_bl0/*brightness*, i.e. cat /sys/class/backlight/amdgpu_bl0/actual_brightness shows the actual brightness setting (0 to 255, in my case, i.e. 15% equals a value of 38). For me, the issue with not being able to adjust the brightness starts earlier than SDDM: I have a very rudimentary configuration (Gentoo Linux, custom kernel) without a boot splash screen (dracut without plymouth), so I see the kernel text messages on startup, and then those from systemd, and then I see that SDDM is loading and taking over. When I start the laptop in a very dark environment (at night), where last I used the laptop was in a bright environment (e.g. a bright day with direct sunlight), the high brightness setting hurts my eyes – but way before SDDM!

So, I though, having control over brightness via /sys might be the solution. But it is not, because the Linux console doesn't have direct access to the Fn key! So I cannot map (in my case:) Fn+F5 for brightness down and Fn+F6 for brightness up (like it is written down on those keys on the keyboard on my laptop, a Lenovo Legion), because those keys are unmappable. (See e.g. State of Fn-Key under Linux.) Otherwise a keymap modification or a self made daemon or something might be possible...

What I can do is set the brightness to a default value on every boot-up, as suggested e.g. by using an udev rule. But this has two problems, as it would a) not honour the previous setting, which is in most cases absolutely the desired brightness, and b) still not give the user control via the designated keys (that's why they're there!). BTW, restoring the brightness is done by systemd-backlight automatically, in my case systemd-backlight@backlight:amdgpu_bl0.service. The service is started and it regularly restores the previous brightness successfully. This worked out-of-the-box as well, I did not have to configure anything (remember: Gentoo Linux!)...

TL;DR I'm just here to point out that it's not entirely SDDM's fault. SDDM could easily just rely on the brightness control already in place by the time it is run, but this would only work if the Linux kernel itself, or a system daemon, would map the key bindings to sysfs...

Does anyone know if and how that could be accomplished? Maybe one of those backlight utilities? After a quick internet search I found acpilight through this Arch Linux discussion, but I don't know how to map the keys to have any effect, or how to run apcilight on a systemd-based Linux in the first place.

Using acpi_listen I get the following for Fn+F5 and Fn+F6:

video/brightnessup BRTUP 00000086 00000000
video/brightnessdown BRTDN 00000087 00000000

This is, I guess, also how PowerDevil is using the Fn keys. It's now just a matter of getting this into an early light-weight system daemon so it would work right after early boot, preferably without introducing security issues...