gamma and brightness control not implemented? #1274
Comments
|
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 I would use this feature |
|
+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. |
|
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
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. |
|
Ok, good to hear about that! |
|
+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. |
|
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. |
The Raspberry Pi 4 implements gamma support in a different method to earlier models. Attempting to use the pre-existing gamma mailbox message on Pi 4 will result in incorrect gamma settings being used (black stays black, but everything else will become lighter & washed-out). It's unclear when the Pi foundation will fix the firmware and/or document the new gamma method, so for now our best option is to disable gamma on Pi 4. Ref: raspberrypi/firmware#1274 Tested on Pi 3 & 4
The Raspberry Pi 4 implements gamma support in a different method to earlier models. Attempting to use the pre-existing gamma mailbox message on Pi 4 will result in incorrect gamma settings being used (black stays black, but everything else will become lighter & washed-out). It's unclear when the Pi foundation will fix the firmware and/or document the new gamma method, so for now our best option is to disable gamma on Pi 4. Ref: raspberrypi/firmware#1274 Tested on Pi 3 & 4
The Raspberry Pi 4 implements gamma support in a different method to earlier models. Attempting to use the pre-existing gamma mailbox message on Pi 4 will result in incorrect gamma settings being used (black stays black, but everything else will become lighter & washed-out). It's unclear when the Pi foundation will fix the firmware and/or document the new gamma method, so for now our best option is to disable gamma on Pi 4. Ref: raspberrypi/firmware#1274 Tested on Pi 3 & 4
The Raspberry Pi 4 implements gamma support in a different method to earlier models. Attempting to use the pre-existing gamma mailbox message on Pi 4 will result in incorrect gamma settings being used (black stays black, but everything else will become lighter & washed-out). It's unclear when the Pi foundation will fix the firmware and/or document the new gamma method, so for now our best option is to disable gamma on Pi 4. Ref: raspberrypi/firmware#1274 Tested on Pi 3 & 4
|
+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. |
|
It's like staring into a fluorescent light bulb. |
I forget to answer this. Yes: RK3399 |
he worked at broadcom until 2019 then |
I registered on purpose to add me to the request. Maybe we only are a few people requesting that because of:
Using the pi in a old television at night even with ambiental light, with the white backgrounds of websites is a torture. |
|
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 |
|
Fully feeling this at the moment. Git hub is a beautifully clean site in the day, but redhift/f.lux etc are all essential for my sleep on other devices, and hopping over here has on the pi with monitor done my insomnia no favours. Absolutely loving the 4. It really does feel like a desktop device, but will have to vnc in from an android/ios device until there is a native resolution for pi-os or variants. Small screens make me squinty but poor sleep is probably worse for my eyes. Please bump this up as a priority. If anyone does come up with a package once gamma is wihin contro... I propose camomile as a name :) |
|
It's implemented for the full KMS driver (not FKMS) As the KMS driver has been adopted by default under Bullseye, I don't see any point in looking to implement it under FKMS. |
|
Thank you 6by9, but could you explain how to use it? |
|
Use |
Same. My Case:
Thank you. |
|
I believe the fix is for KMS, not FKMS. On Bullseye, KMS is the default, not FKMS. |
|
Yes it's KMS only but it has been disabled again recently: raspberrypi/linux@6584a4e |
|
This is insane! It is really important to be able to adjust your gamma. I guess I won't be using it as my main machine. |
|
I've NEVER, in 40 years of this sort of thing, bothered with changing gamma. Am I insane? Anyway, we have some investigation to do with regard to setting up the HW to use gamma correction, there's some weirdness in when you can set it. Once we have figured out the problem, it will be reintroduced. |
|
A work-around might be found using DDC if your monitor supports it. A quick Edit and off topic a bit, but people are here wondering so: |
|
In case you are wondering, people do use gamma. Visual perception is highly individual - as are other senses... There are super-tasters, and there are people who toss a pound of salt on everything they eat. I happen to like it to create a pleasing, linear-looking display, need it to get the subpixel-rendered fonts not make me noxious, and absolutely require it for things like photography... And if I get up in the middle of the night, I often adjust the gamma to match lower-brightness settings.... Pretty please! |
|
It's been tried once, when it proved to be non-trivial. Getting a functional gamma control is on the list of things to do, but supporting the huge variety of displays out there is more urgent. |
|
That makes sense. Just want to make sure people know it is not a whim - there are many people not using rpis as main machines because of that. |
|
@JamesH65 If you've been doing this for 40 years, then you may actually have "missed the memo about this" https://www.scientificamerican.com/article/q-a-why-is-blue-light-before-bedtime-bad-for-sleep/ Light is a funny thing, and apparently not only a subjective thing but a mind-affecting thing. There's a whole group of people for example who get seasonal affective disorder, and the cure (or at least the band-aid) is... a broad-spectrum light (interestingly, literally the opposite of what we're discussing here, lol). As a person who has struggled with various sleep issues his whole life, the introduction of things like Windows' "Night Light" and macOS' "Night Shift" (all likely inspired by https://justgetflux.com which has existed for some time) was a game-changer for me. Been occasionally using an RPi4 for dev work because I want to be on the ARM bleeding-edge. ;) Having gotten used to the blue-light-removing features across my other devices when evening hits, the lack of it here was likely even more jarring. I get that there are technical (possibly including hardware) challenges to implementing it, though. |
|
+1, add another user who wants this. I hope it can get addressed. |
|
We know this is wanted by some people, but right now don't have the time to investigate the issue. When we do have time, it will be investigated,. but right now we have a tremendous workload of many more important things to sort out. |
|
I guess I will wait until it's fixed before considering using an RPI with a monitor. |
|
+1 for the issue. |
|
+1 |
|
OT: no disrespect intended, but I can buy a refurbished 4+GHz intel I7 box with 8GB for the same price as the the current (2022) raspberry-pi, shortages and gamma be damned. Just an observation. |
|
So, buy that Intel box until the worldwide chip supply crisis affecting absolutely everyone, is over? Our resellers sell at the RRP. Neither of which have anything to do with gamma control, so really not sure why you mentioned it here. |
|
Locking until there is something to report. |
and others
I'd like to use xrandr to change the colour of the display and the brightness below what the screen offers, for example:
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.
The text was updated successfully, but these errors were encountered: