firmware
firmware copied to clipboard
raspberrypi
gamma and brightness control not implemented?
I'd like to use xrandr to change the colour of the display and the brightness below what the screen offers, for example:
$ xrandr --output HDMI-1 --brightness 0.7
$ xrandr --output HDMI-1 --gamma 2:2:2
but these commands do nothing and give no error. The redshift tool (package redshift on debian) also uses methods to get a more red and less bright display, same result.
I am wondering if it's just that they are not implemented in the driver? Is it planned? Thanks
System Raspberry Pi 4 with raspbian, experimental driver enabled (dtoverlay=vc4-fkms-v3d in /boot/config.txt). I also tested without the experimental driver and it's the same result.
# cat /etc/rpi-issue
Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage2
# vcgencmd version
Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)
# uname -a
Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
Having had a quick look at the source for xrandr, brightness also alters the gamma curve, so you've only actually requested one feature.
Implementing gamma control requires suitable hardware in the composition pipe in order to operate. There are some parts of the display pipeline that can be switched between the various output channels - I'd need to check whether gamma falls into that category or not.
Tweaking gamma is not a critical feature of the display pipeline, therefore it won't be a high priority to add the plumbing.
Thank you for taking the time to look at it.
For people using the computer at night it's an important feature, but I understand that there are much less people caring about their eyes compared to those who want to have opengl or other features :)
Hope someone get it implemented, because it not only affect desktop experience... while gaming, some game are unplayable because of the gamma... for example, open jedy academy... ive recently compile it and the brightness control its unresponsive, while on rpi3 under mesa that didnt happened
+1 ...new RP4's are tough on the eyes at night!! f.lux, redshift, xrandr....none of them are working :(
I'm bumping this since the situation of not being able to tweak gamma still hasn't changed. Like john2exonets stated already: It is really tough on the eyes.
So we now have a grand total of 5 people asking for this feature. Compared to the number of devices sold and priorities, the situation still hasn't really changed since my comment on the 14th October
Tweaking gamma is not a critical feature of the display pipeline, therefore it won't be a high priority to add the plumbing.
Bumps (particularly only two days after the last bump post) add nothing to the discussion, but do spam those involved. If you're really that bothered, then adding emojis shows your interest without spamming everyone.
I wouldn't (have a reason to) be that bothered if that part wasn't proprietary. Still I don't think this is the place to discuss that OSS vs. proprietary matter on a fundamental scale since this wouldn't do anything about it.
Yet I still felt the urge to state/underline that it is indeed tough on the eyes. So this is really not ment to just spam on this issue but rather the only thing a user could do about its ergonomic nature in the context of closed source software.
I'm gonna add my interest in this feature via emoji when already stated by someone else next time but didn't think of adding emoji being an actual thing rather than just a stylistic choice.
Yes, it would be a useful feature to have, BUT, its not the only option. All monitors have a brightness setting, and most some ability to change colour balance. You can always use that. No need for access to closed source firmware (and TBH, if people with 10 years experience working on the firmware cannot quickly add it, then someone out there isn't going to be able to quickly add it either, even with source access)
I don't know why rpi foundation work with broadcom SOCs if they are unable (or just won't) to supply key source code of their SOC firmware. Also, hw brightness/gamma control it's not just a fancy feature about eyes care. Many games are difficult to set the gamma properly on software. They looks too dark.
@Askmewho I think the rather strange situation of having a RPI with important features being kept proprietary is the price of keeping the hardware that affordable. Maybe it is even possible to release a fully open board, but certainly not for the rather low cost you get an RPI for.
Take the Pyra/Pandora for example. AFAIK it is mostly open source, but expensive as hell.
You are right @pjh64 , but how open/closed its rk3399 firmware compared to rpi4 soc for example?
If you can suggest a SoC with the same feature set, and an entire development team that knows the SoC inside out, and a SoC manufacturer who is willing to talk to us about what features we need and supply them, then that would be possible. But I suspect you won't be able to find one that fits the bill.
Broadcom fits the bill. And of course, Eben works for Broadcom, so has a huge amount of input on what goes in the chips.
We are also trying to move away from the GPU firmware and provide all features accessible from ARM space. But it's a long process because of the huge amount of work that the GPU firmware actually does (I think it's about a millions line of code or something bonkers like that) The KMS driver is a huge step towards that, but that still leaves the codecs, the ISP, and probably a load of other stuff I cannot be bothered to think about right now.
Just been reminded - the KMS driver (available now on Pi3, in a few months on Pi4) is fully open source and will allow you to directly access the underlying systems to add your own gamma support, if it's not in there already by default. Note, not talking about the FKMS driver which still uses the GPU firmware.
+1 for the issue. I know it isn't top priority and thanks for the hard work.
kms support is in upstream kernel for pi0-3. Pi4 support has been submitted but not fully merged yet. https://lore.kernel.org/dri-devel/cover.6c896ace9a5a7840e9cec008b553cbb004ca1f91.1582533919.git-series.maxime@cerno.tech/T/#m0275b55e1518be1fb2154d3c95e13c1b7de1f347
ok, yeah. I've tried the overlay for full KMS on 5.4 kernel and it does break my sound with pulseaudio, and while extremely unstable, it did not add gamma correction capabilities neither as far as I can tell. Thanks
Pi4 uses a PWL to configure gamma curves. DRM uses a lookup table. You're therefore looking at fun and games around curve fitting if you want vaguely accurate results, and that becomes a faff. It's currently explicitly disabled on vc4-kms-v3d for Pi4.
Implementing it is still on the list of tasks, but there are higher priorities.
+1 to making standard Linux utilities that change gamma for eye/sleep protection (Ubuntu's "Night Light", the "gammy" utility, and many more) work on an RPi[4]. As a dev with a sleep disorder who finally has access to a desktop-class ARM computer (I'm currently actually running Ubuntu Server with a GUI and GPU acceleration thanks to https://github.com/wimpysworld/desktopify), this would be huge.
If you can suggest a SoC with the same feature set, and an entire development team that knows the SoC inside out, and a SoC manufacturer who is willing to talk to us about what features we need and supply them, then that would be possible. But I suspect you won't be able to find one that fits the bill.
Broadcom fits the bill. And of course, Eben works for Broadcom, so has a huge amount of input on what goes in the chips.
We are also trying to move away from the GPU firmware and provide all features accessible from ARM space. But it's a long process because of the huge amount of work that the GPU firmware actually does (I think it's about a millions line of code or something bonkers like that) The KMS driver is a huge step towards that, but that still leaves the codecs, the ISP, and probably a load of other stuff I cannot be bothered to think about right now.
I forget to answer this. Yes: RK3399
com fits the bill. And of course, Eben works for Broadcom,
he worked at broadcom until 2019 then
So we now have a grand total of 5 people asking for this feature. Compared to the number of devices sold and priorities, the situation still hasn't really changed since my comment on the 14th October
I registered on purpose to add me to the request. Maybe we only are a few people requesting that because of:
- a lot of people doesn't know the existence of that programs
- other people doesn't have or know, account here.
Using the pi in a old television at night even with ambiental light, with the white backgrounds of websites is a torture.
For those that would have the redshift or similar, at the moment maybe you will interest an alternative. In the xfce4 settings there are a "Brightness" option. The process is "pibright", it works. Not sets the brightness of the display itself, but it darks the signal.
So I made a launcher in the notification area, If you start typing pibri... in the first textbox (of the "Launcher Name"), the panel itself suggests to insert the brightness icon. So this at the moment is the best solution for me. I hope you too.
Now my eyes are relaxed...
Gamma control is nearly there for vc4-kms-v3d. https://github.com/mripard/rpi-linux/tree/rpi/vc4-gamma still needs a few clean ups before it'll be merged though.
There is a restriction in the hardware that means that the pipeline has to be shutdown and restarted on a gamma change, so the display will blank. Not much we can do about that one unfortunately.
I wasn't anticipating making changes to the firmware to support gamma, and due to the requirement for a pipeline restart I suspect that it is more effort and risk than it is worth.
No brightness control or sleep function on raspberry pi? What's the deal?
The deal is that gamma control is high on the list of things to do but not completed yet - I thought @6by9 made that clear.
The deal is that gamma control is high on the list of things to do but not completed yet - I thought @6by9 made that clear.
I was more asking why the pi foundation didn't have this and sleep supported a long time ago.
I guess the danger in making a “desktop class” Pi is that suddenly people expect desktop-class things.
As is the M.O. with open source, I’m sure someone would be grateful if you wanted to take a crack at it with a PR