Opened 6 years ago
Last modified 4 years ago
#14508 new enhancement
Blue light reduction / Night mode enahancement
Reported by: | cb88 | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ttcoder | |
Blocked By: | Blocking: | #14907, #15873 | |
Platform: | All |
Description
As far as I know Haiku doesn't currently have a way to globally adjust the color output of the screen.
This would consist of a UI and probably a deskbar addon to control it. Configurable hours to enable disable the feature. Perhaps have presets for different work shifts? Configurable gradual color shift with sane default.
The feature would work by as the set time approaches blue light output on the screen is gradually reduced globally to the set level.
Windows, Linux, Android, MacOS and iOS all implement this feature in a manner similar to this with varying levels of control over it. This feature is mainly intended to help reduce the effect of computer use at night on circadian rythm so you can get better sleep. I sometimes even use it in the daytime as reducing blue light is a bit easier on the eyes.
f.lux for iOS, redshift on Linux, and as a built in feature on Windows 10 and I think MacOS now.
Change History (11)
comment:1 by , 6 years ago
Component: | - General → Servers/app_server |
---|---|
Owner: | changed from | to
comment:2 by , 6 years ago
comment:3 by , 6 years ago
If the gamma correction tables work, then that's a decent idea. Otherwise it's a sort of post-processing effect as part of window composition - something that is going to be difficult until App Server uses 3D hardware composition I'd imagine.
In the days of binary blob 3D linux drivers I thought 3D hardware support would never come to Haiku, but with Intel's on-board graphics being pretty dominant in modern systems and having an open source driver it does seem to be a more tractable problem now. Definitely not in the R1 timeframe though.
comment:4 by , 6 years ago
@pukomandy I think it would be fine if it just weren't supported on VESA... that's to be expected. On android it is often done as a transparent overlay but this is sort of a hack... and not as optimal as doing it in the driver (which apparently requires a rooted phone).
I wouldn't say impossible or even unlikely before R1 especially if done at the driver level... doing it at any level above that is more likely to be post R1 though sure. If even just the intel and radeon_hd drivers supported it you'd have most new PC's covered.
@tangobravo to be fair AMD has the best open source 3d drivers with Intel just behind (they are finally officially converting over to gallium3d though so they should reach parity soon).
comment:5 by , 6 years ago
Blocking: | 14907 added |
---|
comment:6 by , 6 years ago
I really want this too. ChromeOS finally added some basic built-in support for it recently. I was hoping there would be some fairly easy way to pull it off in Haiku, but it sounds like there isn't.
This is one of those things that you don't know you need until you have it, then you wonder why you went so long without it. Then when it is missing, you really miss it. I tend to use my computer pretty late though, so I may be more affected than most.
comment:7 by , 6 years ago
Cc: | added |
---|
comment:8 by , 5 years ago
Blocking: | 15873 added |
---|
comment:9 by , 5 years ago
My son is almost blind so he needs this feature. I would be very appreciate/happy to see this enhancement.
comment:11 by , 4 years ago
How do other OS handle this? If VESA won't be supported, then it's a no go for the most of the Haiku user base.
This could be implemented at the video driver level (by changing video card gamma correction tables). Failing this, I guess we could attempt doing it at app_server level but I can sense problems coming:
So it could be done when copying the data to the screen frontbuffer, at best. And usin the hardware would be better but needs drivers to collaborate (which probably means no support in VESA driver then)