Page MenuHomePhabricator

e_backlight_fake: Software backlight
Needs ReviewPublic

Authored by thierry1970 on Feb 26 2019, 1:57 PM.

Details

Reviewers
devilhorns
Summary

Allows devices that do not support the backlight to have software brightness.

Diff Detail

Repository
rE core/enlightenment
Branch
feature/backlight_fake (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 9858
Build 8086: arc lint + arc unit
thierry1970 created this revision.Feb 26 2019, 1:57 PM
thierry1970 requested review of this revision.Feb 26 2019, 1:57 PM

Code cleanup

Replacement of "CARD16" by "unsigned short".

thierry1970 updated this revision to Diff 19892.Mar 2 2019, 8:49 AM

Correction of value overflow (proposed by pascal@ordissimo.com).

thierry1970 retitled this revision from e_backlight_fake: backlight logiciel. to e_backlight_fake: Software backlight.Mar 6 2019, 11:21 PM
raster added a subscriber: raster.May 14 2020, 3:50 AM

Aha coming to this. This definitely needs some ifdefs regarding wayland so it's not enabled when in wayland mode (also runtime checks too as well).

Now the question really is... do we REALLY want to do this this way? So... my experience with the randr gamma controls is they are limited in resolution. So that means that they use an integer lookup table with ... 8 bits. so if you drop toe.g 1/4 brightness you end up with banding in the image as you now only have 64 levels of r, g, b instead of 256. i looked at this quite a while back and decided for now at least not to do this. The quality is pretty poor. Now this does bring up a bigger topic of general image manipulation. Like not just darkening the image but also color-correcting, doing blue-light filtering and other such things.

Why did you do this? for external monitors? That has been solved via ddcutil now where we actually control the monitor itself.

If we're going to end up doing a filter object that modifies RGB for darkening or any other number of image corrections/transforms, we could improve quality by doing dithering in GLSL shaders (for gpu rendered stuff this will actually then solve the above quality issue as gpu's do their intermediate rendering in floating point so if we add some noise we can actually effectively get more color resolution by noise-like dithering). This then allows brightness, contrast, blue light, color temp and other stuff at the rendering level (but the downside is it's an extra hop for rendering through an FBO so extra overhead).