gamma and brightness control not implemented?

[myier]

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

[6by9]

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.

[myier]

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

[Thovthe]

+1 I would use this feature

[john2exonets]

+1 ...new RP4's are tough on the eyes at night!! f.lux, redshift, xrandr....none of them are working :(

[pjh64]

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.

[6by9]

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.

[pjh64]

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.

[JamesH65]

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.

[pjh64]

@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?

[JamesH65]

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.

[JamesH65]

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.