Feature: Add Wayland support

[schmittlauch]

I use a Jolla phone with SailfishOS which already uses Wayland as display server. One thing I'm really missing is color shift in the dark. Is there something similar to the X server extension used for Wayland?

[maandree]

Check if it is possible load xwayland on your phone, it should work transparently then. It does not look like support for colour adjustments have been added to Wayland yet, or at least I have not been able to find the API. Personally I am eagerly waiting for Wayland and Haiku to add colour adjustments support.

[genodeftest]

redshift doesn't work on XWayland (here on Fedora 21 Alpha under wayland/gnome-session) at least without any changes.

According to http://lists.freedesktop.org/archives/wayland-devel/2014-February/ (via: https://en.wikipedia.org/wiki/RandR ) there is a randr extension in wayland since February, but I didn't find any API or cli tool for it.

[maandree]

Running grep -rni randr over the source code for Wayland and Weston reveals that there is no RandR support merged into either Wayland or Weston. However the reference for Wayland's support in the Wikipedia article contains mailing list posts with patches to add RandR support in Weston, nothing about RandR support in Wayland however (probably elsewhere).

In March I did successfully run Redshift in XWayland, so I don't know what has happened. (Have not retried.)

[d9h20f]

As the OP is running Sailfish I thought it would be worth mentioning that it is now possible to run XWayland on it (http://talk.maemo.org/showthread.php?t=93828&page=2), so if you get the chance please do try if you can get Redshift to work (until it's possible to run Redshift on Wayland directly).

[pazooki]

redshift is broken on Fedora 21: Gnome Wayland

~ $ redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m vidmode -v &
Location: 55.700001, 12.600000
Temperatures: 5700K at day, 3600K at night
Brightness: 1.00:1.00
Gamma: 0.800, 0.800, 0.800
Xlib:  extension "XFree86-VidModeExtension" missing on display ":1".
X request failed: XF86VidModeQueryVersion
Failed to start adjustment method vidmode

[maandree]

Have you tried -m randr?

[pazooki]

Ya:

$ redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m randr
Screen 1 could not be found.
Failed to start adjustment method randr.
Job 1, “redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m randr &” has ended

[rubdos]

I'm also running Sailfish and I'd be interested too in this feature. Any updates on Wayland supporting randr?

[maandree]

@pazooki

Try removing your redshift.conf. Most people with
two or more monitors do not have a "Screen 1",
only "Screen 0"; they usually have a "CRTC 1"
in "Screen 0".

[maandree]

@rubdos

It looks like there still is no support in Wayland and that Weston only supports it but utilising colord.
So it looks like XWayland is still required, which does (or atleast did in March) support RandR.

[pazooki]

now it doesn't do anything, it just wait after running the commnad.

[maandree]

Are you running a virtual or physical machine?
Does xgamma or xrandr work for you?

[pazooki]

I'm running it on my laptop, it's not a virtual machine.

~ $ redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m xrandr
Unknown adjustment method `xrandr'.
~ $ redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m xgamma
Unknown adjustment method `xgamma'.

[maandree]

Ok.
I meant to programs xrandr and xgamma. For example xgamma -gamma 0.8.

[pazooki]

this is what I'm getting

~ $ xgamma -gamma 0.8
Xlib:  extension "XFree86-VidModeExtension" missing on display ":1".
Unable to query video extension version
~ $ xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192
XWAYLAND0 connected 1280x800+0+0 260mm x 160mm
   1280x800@0.1Hz   0.00*+

[maandree]

How about xrandr --output XWAYLAND0 --gamma 0.8:0.8:0.8?

[pazooki]

I think that made a difference. no errors

[maandree]

How about redshift -O 4500 -m randr?

[pazooki]

it didn't do anything

[maandree]

That's weird.

[genodeftest]

$ redshift -l 49:11 -t 3500:4000 works fine under Fedora 21 + X.org – at least for me.

[lispykid]

I am also on Jolla. Will see if can test this over the holidays.

[Mikaela]

Jolla/Sailfish here too, did anyone test this? Comments only talk about testing, but I don't see successful result.

[giucam]

It will not work with xrandr and xwayland, since the screen is managed by the wayland compositor, and there is no wayland protocol to se the color temperature (yet).
http://lists.freedesktop.org/archives/wayland-devel/2015-January/019578.html

[genodeftest]

Can this (theoretically) be done by gamma factors?

[genodeftest]

randr and vidmode are not supported on wayland.
Another possibility is using DDC/CI with ddccontrol:
http://ddccontrol.sourceforge.net/
https://github.com/ddccontrol/

[giucam]

I've written the support for some wayland compositors here: giucam/redshift@d3f54ed
The thing to be aware of is that it uses a protocol extension not in core Wayland, and at the moment the only compositor i know that implements it is this (wip): https://github.com/giucam/orbital/tree/gamma

This surely could be implemented in lipstick so that would answer the OP's question, however first i think it is necessary to understand the security implications. In the wayland world clients must not have the ability to screw the user interface, and a protocol like that could surely allow clients to do so.
Either we need some way to mark redshift as trusted or some way for the compositor to cope with malicious/bugged clients.

[jonls]

@giucam That's very cool. It seems that your protocol does gamma adjustments directly. Would it be possible to have the protocol instead only allow adjusting the color temperature or perhaps a color overlay? Perhaps such a scheme could be more easily limited to avoid the security issues?

[giucam]

@jonls It could work with the temperature directly, but i guess that would mean the compositors would need to do what colorramp.c does themselves. I don't really know anything about color management so that was easier for me, but it sure could be possible. I'm not sure that solves the security issue, though.
And not sure what you mean with a color overlay...

[jonls]

@giucam I agree, the color temperature adjustment should probably stay in Redshift. What I would really like to see is a protocol that allows Redshift to set just the scaling of the RGB values. Supposedly the compositors would be able to implement this directly on the pixel output (through a shader or something like that) without having to change the gamma ramps. This would make it a lot easier for Redshift to do what it is supposed to do without having to mess with gamma/brightness/color management because Redshift would simply be asking the compositor to apply a completely separate secondary filter on top of the gamma adjustments.

For example, I know that GNOME Shell is able to apply filters like that and this extension is almost able to replicate the Redshift effect without touching the gamma ramps at all (sadly the ColorizeEffect is not quite what we need but it is close).

[giucam]

@jonls Ah, so you mean a transparent overlay with a slight tint? I can't speak for all compositors out there, but on the ones i touched that wouldn't be a problem at all. That would also mean less data getting passed around, since at least for my laptop every set_gamma() protocol call sends 1.5kb of data. Could i calculate the rgba of the overlay with the data in color_setting_t?

[maandree]

@giucam I suggest implementing something similar to what I am planning for mds where mulitple programs can modify the gamma ramps:
https://github.com/maandree/mds/blob/3ba74289b85199a3079c05788321a9593e16f08f/doc/info/mds.texinfo#L1689
https://github.com/maandree/mds/blob/3ba74289b85199a3079c05788321a9593e16f08f/doc/info/mds.texinfo#L3431

[giucam]

@maandree That's what the current implementation does (minus the priorities) but i don't like the fact that any untrusted client can modify the gamma.

[maandree]

@giucam

It does? I you where to run redshift -O 3000 would the temperature be set permanently to 3000 K until then next time redshift runs? And another program can do its owns modifications without conflicting?

How is that any worse than a program going full screen? Of course that is not that good either; but are there really any alternatives.

Assuming it is possible to identify the PID of the process making the request, you could identify the program by running readlink over /proc/${CLIENT_PID}/exe, check if it is in a whitelist.

[giucam]

It does? I you where to run redshift -O 3000 would the temperature be set permanently to 3000 K until then next time redshift runs? And another program can do its owns modifications without conflicting?

Well, that is up to the implementations the compositor will have, but also kind of orthogonal, i think.

How is that any worse than a program going full screen? Of course that is not that good either; but are there really any alternatives.

And indeed in wayland a client can't force a resolution or video mode. And the compositor has ways to switch out of a fullscreened client, like alt+tab or such. But if a client modifies the gamma so that you cannot see a thing that is a much more serious problem.

Assuming it is possible to identify the PID of the process making the request, you could identify the program by running readlink over /proc/${CLIENT_PID}/exe, check if it is in a whitelist.

Heh, but i'd like to avoid a thing like this :).

[maandree]

@giucam

Orthogonal?

Heh, but i'd like to avoid a thing like this :).

Of course, it is a very bad solution. And it to allow a program that runs under an interpreter, like Python, you would have to allow all programs running under that interpreter.

Perhaps a better solution would be to have options for the compositor that limits what can be done with gamma ramps. For example, the default options could be that gamma ramps consists of only two stops and the difference between the first and the last stop must be atleast 20 pp for one of the ramps and atleast 5 pp on the other ramps; and simply throw an error if the ramps would ever be more flat than that. This would allow for the most popular filters: colour temperatur, contrast, brightness and negative with an insurance that the screen will never become unreadable. Those settings would however not allow "gamma"[1] correction, but that could be handled by the compositor.

[1] Only CRT monitors have proper gamma curves, flat screens have sigmoid curves.

[giucam]

@maandree

Orthogonal?

Yes, it is a different problem than the security one.

For example, the default options could be that gamma ramps consists of only two stops and the difference between the first and the last stop must be atleast 20 pp for one of the ramps and atleast 5 pp on the other ramps

I'm not sure what you mean with this. I don't really know how the gamma ramps work, i just blindly pass them around from redshift to libdrm so not sure what you mean with 'stops' or 'pp'.

[maandree]

@giucam

Yes, it is a different problem than the security one.

OK. I did not understand the metaphore.

I'm not sure what you mean with this. I don't really know how the gamma ramps work, i just blindly pass them around from redshift to libdrm so not sure what you mean with 'stops' or 'pp'.

pp stands for percentage points.
Stops is the number of values there are in the ramps. The size of the ramps.

If a ramp as two stops. You will be able to set the output value of encoding values 0 % and 100 %.
All values between are interpolated. So if the ramps are configured to have two stops. The gamma ramp will be {0, 0xFFFF} by default. If the user than sets all of the temp {0xFFFF, 0}. All colours are inverted.

If the ramps are limited to not be allowed to be flatter than 10 pp. The ramps could be set to {0, 0x199A} but not to {0, 0x0100}. So we can be sure the screen is always readble.

[giucam]

I see... However, i think i like more @jonls' suggestion of not passing the actual gamma values but instead using a color overlay...

[maandree]

If I understand it correctly, a colour overlay will only change the maximum output value of the subpixels. This would not allow a program to invert the colours. Which I do not see as a security issue. If we limit my suggestion to only allow gamma ramps of size 2, this would be the only difference, apart from that it is more flexible too.

However. I don't think that implementing it using a shader is a good idea. Gamma ramps achieve the same effect with lower overhead. And you still need to put a restriction of the darkness level.

[jonls]

@giucam I am no expert in this area but I believe the overlay could be created with the RGB white point color that is calculated in colorramp_fill. The blend mode should be set so that the overlay RGB is multiplied on the destination RGB (output = src * dest). In OpenGL this would be something like

glBlendEquationSeparate(GL_FUNC_ADD, GL_FUNC_ADD);
glBlendFuncSeparate​(GL_DST_COLOR, GL_ZERO, GL_ZERO, GL_ZERO);

As @maandree points out there still needs to be a lower limit on the overlay color to avoid making the screen too dark. This could even be implemented in the compositor using the gamma ramps instead of an overlay if the compositor determines that this is more efficient.

[maandree]

Gamma ramps are always more efficient since they do not have any overhead at all, apart from the very low overhead of setting the CLUT. No matter how it is implemented by the graphics driver, because the graphics driver will use the CLUT anyways, you just modify it.

It should however be noted that gamma ramps are not universally supported, and having fallback methods like shaders should be beneficial.

[giucam]

New chapter: i've implemented this protocol extension in my compositor (https://github.com/giucam/orbital/blob/master/protocol/orbital-authorizer.xml) and made redshift use it: giucam/redshift@1b9c8ac

This allows the compositor to refuse the authorization to change the gamma, or to allow it if it knows redshift is trusted, or to ask the user what it should do, or to simply notify that a program is changing the gamma so that the user is not surprised.

[LeleDev]

+1

[ssokolow]

I can attest to a specific example of "clients must not have the ability to screw the user interface" applying to gamma correction because, under X11, I've had games in Wine adjust the gamma and then crash, leaving it on the adjusted settings.

(Same basic problem and type of symptoms as with how games change resolution under X11)

...and, of course, when they're running windowed the in-game Gamma adjustment isn't limited to "Make this window bright enough to actually see more than just hazy shadows in the darkness".

Orthogonal

It's a math term that's come into more general use. It means they're independent. (In math, two axes are orthogonal if movement on one does not cause movement on the other. X and Y on the cartesian plane are examples of orthogonal axes.)

[genodeftest]

On wayland this feature has to be implemented in the compositor, since only the compositor is allowed to do such operations.
In gnome-shell this is possible to implement this via JavaScript. There is a gnome-shell extension called shade inactive windows which just shades all inactive windows, working on both Wayland and X11. This solution is limited to Gnome-Shell of course.

[alexduf]

That's interesting, so potentially we could implement something similar with https://developer.gnome.org/clutter/stable/ClutterColorizeEffect.html instead of the BrightnessContrastEffect that is used in that plugin?
That's worth experimenting.

[LeleDev]

@genodeftest, @alexduf nice points

[Espionage724]

Not too sure if this is helpful, but I have gamma control indirectly working with Wayland.

I'm on Fedora 23 with a Radeon HD 7850. In xorg.conf, I have my 3 monitors with gamma set at 0.8. I have GDM not using Wayland. The login screen has the gamma i set in xorg.conf. After logging into GNOME on Wayland, the gamma carries over to that session.

This doesn't work with auto-login though (I guess since you don't see the login screen, the gamma isn't set there, and thus, the default gamma is what's used in the GNOME session).

I assume the main point of redshift is dynamic gamma control, so I'm not certain if this would really be too helpful or work with it (this looks to be a one-shot thing).

[antistress]

Hi, in case it could be useful, I've found that GNOME wiki page https://wiki.gnome.org/Initiatives/Wayland/Gaps#Color_management

[HeikoAdams]

I recently talked to Matthias Clasen and he said you should take a look at how gnome-color-manager modifies gama.values because gcm should almost work on wayland too.

[maandree]

I don't think we shall try to support Wayland before it supports Redshift properly. I think the best way for Wayland to do this too implement something similar to the protocols described in https://github.com/maandree/mds/blob/3ba74289b85199a3079c05788321a9593e16f08f/doc/info/mds.texinfo#L3431 and https://github.com/maandree/mds/blob/3ba74289b85199a3079c05788321a9593e16f08f/doc/info/mds.texinfo#L1689. Anything short of it is just a hack.

[crepererum]

@HeikoAdams I quickly checked the gnome-color-manager source code and it doesn't do anything on it's own. It's "only" an interface for colord (it uses this API). Now redshift could do the same but I'm wondering if

• colord is only a load+store+lookup service for color profiles and all apps have to do the conversion on their own
• or if by default colord activates the right profile for displays (when combined with KDE and GNOME) and then apps optionally can convert their images (e.g. darktable seems to do so) to match this profile

? If the second case would be true, than this would be really awesome because this would mean that we could change the profile to emulate a redshift while image editing software would recognize that change and even do the right conversion for it. This would be a way more standard approach than bypassing all apps and hijacking the display using xrandr.

[simdol]

Hello, I am also on Jolla, powered by Sailfish OS. I would like to see the update to this as Redshift is my favorite app and it is a must for me. Should anyone need testers for this device, I am up for testing although I have no experience compiling in arm. Though, I will give it a try since I was able to successfully compile it with amd64 on Gentoo Linux.

[OhDaeto]

@simdol Assembly for arm no difference compared to amd. You have root in Jolla?

[Mikaela]

Workaround until this is implemented on Jolla/SfOS with aliendalvik

F.lux from Google Play Store and possibly other Android stores (I was unable to find it from Aptoide or F-Droid) works with aliendalvik as long as you have installed Aliendalvik Superuser from OpenRepos.

Root on Jolla

You get root on SailfishOS by enabling developer mode in settings and giving password which you will then use in terminal with devel-su to become root.

Terminal app will be installed at the same time as you enable developer mode and sshd enabled.

[simdol]

@OhDaeto Indeed, I do. However, I think that the problem here isn't the architecture but rather Wayland issue. @Mikaela I have been using Twilight for Android apps. However, the problem arouses when I am using Sailfish native apps -- it does not work with Sailfish native apps even though I am rooted with SuperUser from OpenRepos.

In regards to your last comment, do you mean that F.lux will work with cross Sailfish & Android apps unlike Twilight? I wanted to confirm this before I look for F.lux app as I don't have and don't want to have Playstore installed on my Jolla. Thanks for the guide, by the way! 👍

[Mikaela]

Yes, F.lux works also on SaiflishOS apps and homescreen and is not visible in screenshots just like with Android. It does root magic instead of applying random filter like Twilight which I had tried before and encountered the same issue as you.

[craftyguy]

Any workarounds or alternatives for Wayland on Linux (not Sailfish OS)?

[HeikoAdams]

Any progress on this? Fedora is planing to switch to Wayland with Fedora 25 and AFAIK Ubuntu Gnome 16.10 will use Wayland too

[auscompgeek]

@HeikoAdams AFAIK, GNOME 3.22 some time in the future will have similar functionality in their colour manager thing. Whilst it'd be great to have this on Wayland, it probably won't impact GNOME users if they're using 3.22 when it's released once it's done.

[ssokolow]

I suspect that we'll see that pattern recur. (Compositors adding a Redshift-alike at the same time they add the interfaces necessary to implement such a thing.)

[genodeftest]

@auscompgeek: Any source or more information on

AFAIK, GNOME 3.22 will have similar functionality in their colour manager thing.

?

[craftyguy]

Excuse my ignorance in this area, but if compositors are able to (theoretically) implement this functionality (redshifting) on Wayland, why can't Redshift? That's neat Gnome users are supposedly covered and would no longer need Redshift, but not everyone uses gnome :)

[soren121]

@craftyguy Because Wayland lacks a standard API to shift color temperature. I don’t know how Mutter (GNOME’s compositor) implemented this, but for Redshift to function, your chosen compositor would need to add a non-standard Wayland extension to allow color temp. shifting.

[maandree]

Anyone, working on a Wayland compositor, feel free to extend libgamma or port and integrate coopgammad. It doesn't stop untrusted clients, but if you add a hotkey to disable it or add restricts on the resulting gamma ramps, it shouldn't be much of a problem.

[jurf]

Linking the relevant GNOME bug if someones interested.

[jonls]

@doctorjellyface Thanks! Great to see that GNOME is actually trying to integrate this.

[azmeuk]

There is also a fedora bug opened, and a COPR repository with wayland support enabled.

[M5oul]

Redshift functionality on Fedora 25 (GNOME + Wayland). Yes, it's possible!.

[MrSorcus]

Any progress with wayland support?

[genodeftest]

@debugreport : Yes, somebody needs to make a real patch for mutter with some functionality similar to the prototype linked in the GNOME bug.

[popenke]

I've switched to Wayland since GNOME 3.22 landed in Arch Linux. I'm using the @M5oul suggestion now.
There's any progress in Redshift implementation of this feature?

[maandree]

It's up to every Wayland compositor to embed Redshift into the compositor. However (@jonls), I guess Redshift could add -m print-binary which just prints the values for the CLUT in a binary format, and the compositors could use that, so they do not have to maintain a fork of Redshift.

A hack that could be done is to create a fork of colord which uses Redshift.

I have posted a lengthy recommendation on freedesktop.org for solve this problem once and for all, but I guess I'll have to post it on a Wayland-specific mailing list.

[maandree]

There has not been much response on freedesktop.org, but it we were encouraged to suggest colour management issues on https://lists.freedesktop.org/mailman/listinfo/openicc.

[popenke]

The @M5oul solution doesn't work on a two monitors setup. 😢

[ssokolow]

@popenke *chuckle* I wonder if it would be worse in any interesting ways on my triple-head system.

(1xDVI-D, 1xHDMI with an HDMI->DVI-D cable, and 1x DisplayPort with a $7 passive DVI-D converter. Works for anyone whose video card manufacturer didn't forget to connect all the traces.)

[SirCmpwn]

I've implemented @giucam's orbital protocol extension in sway (another compositor), or at least started proposing the necessary changes to do so. I suggest upstreaming his changes.

SirCmpwn/sway#1019

Cloudef/wlc#216

[danielng01]

Nice job @giucam and @SirCmpwn.

Can you please somebody tell me if I'm correct.

So with Wayland there is no more Xrandr which was the way to change the gamma?

Wayland has DRM, but we can't use DRM, because it's working under Wayland and there will be no change to the screen?

Wayland compositors will be different user interfaces like today are GNOME and KDE?

The way to make Gamma changes right now is to add them to each compositor?

The people who work on Wayland don't want to add Gamma API, because some applications can screw the UI which is basically the thing we want.

The only cross-platform way at the moment seems DDC/CI, but this doesn't work on all monitors and is not good solution.

Distros with GNOME can make a hack with GNOME shell and this will work in the future with randr?

We can use colord instead of the Wayland compositor and directly change the gamma system wide?

For Android some application are using custom driver, can we just write custom driver which will work on all distros.

I work mostly on Windows so I'm not so good with Linux terminology, but want to help to make this

[SirCmpwn]

The correct way to implement this feature is via a protocol like @giucam has done. The GNOME folks are correct that not every application should be able to fiddle with the screen, but seemingly don't understand that access to the protocol can be limited (security features of this sort just shipped in sway 0.11).

Edit by moderator: Please stay on topic and refrain from insulting other developers here. I have removed some off-topic paragraphs.

[maandree]

@danielng01, mostly correct, however colord cannot change the gamma, only the compositor can do this, but the compositor communicates with colord to figure out how to set the gamma. The reason Wayland does not have a gamma API is more complicated, but if you are really interested, you can follow these threads https://lists.freedesktop.org/archives/xdg/2016-December/013795.html and https://lists.freedesktop.org/archives/wayland-devel/2016-December/032426.html.

[danielng01]

@maandree Thanks for the 2 links, I was also checking your code yesterday since I research the issue from several days. Good job :)

So basically every compositor will just write the Redshift code.
And what about the Mir, many people use Ubuntu. Something is really broken, there should be a way for color profiles. I guess we just need to wait for the official code in Wayland about color management.

Will everyone really switch to Wayland after a year or 2?

One solution I was thinking about is just to make GUI transparent overlay the way like most Android apps work. There will be ugly colors and no real gamma, but at least it will be cross-platform

[danielng01]

With the Overlay the real question will be does Wayland have support for transparent for mouse input top level windows

[maandree]

Thanks!

Last time I checked (a long time ago) Mir did not have a gamma API, but I don't know way, my guess is that they just haven't got to it, or they could have the same rationale as Wayland.

I think a lot of people will be using Wayland in 2 years, but I think it will a very divided world. Wayland and Mir and not the only camp, their is a third large camp that thinks X is the better alternative. My stats from 2 years ago tells me that 69.5 % want Wayland, 15.5 % want X, 2.5 % want Mir, and 4.1 % want some other display server protocol.

I don't think the overlay solution will work on all window managers, but it should work for stacking window managers. However, I don't see how it could be implemented without causing problems with windows that are marked as always-on-top.

[SirCmpwn]

I don't think the overlay solution is a solution at all. It's just a hack.

[danielng01]

So then I want to implement something like Redshift for your compositor Sway and for Orbital since they are the only one who have gamma changes. What to install and how can I do that in plain C

[SirCmpwn]

You could look at the resources I linked when I first commented in this thread earlier.

[danielng01]

This was so hard to make, I wasn't even able to get different compositors running, so instead I made it cross-platform by using DDC/CI

Here is the example code
https://github.com/danielng01/iris-floss-wayland

And it looks like this
https://youtu.be/Qa3nYfOKB0M

I know that this solution is not so good, but this is the only way at the moment which I can think of.

I guess we just need to wait for the official API for Color management or someone to include this DDC/CI code into Redshift

[jonls]

Hey all, just a reminder that this issue is for constructive discussion about Wayland support in Redshift and possible workarounds to use at the moment. This is not a general forum for your opinions on which display server is superior or other opinions that you may have that are unrelated to Wayland support in Redshift. I have edited and deleted comments that are off-topic. Please also keep in mind that insulting other people or projects is not tolerated here and will get you banned. I will unlock this issue in a few days. Thanks!

[auscompgeek]

Looks like things are happening on the gnome-settings-daemon side of things: https://bugzilla.gnome.org/show_bug.cgi?id=742149

[auscompgeek]

and the UI for it too in gnome-control-center: https://bugzilla.gnome.org/show_bug.cgi?id=778326

[SirCmpwn]

sway 0.12-rc1 has been released and includes gamma adjustment support via @giucam's proposed protocol. It would be nice if we could coordinate releases so that we don't have to ask sway users to patch redshift :)

[cyplo]

Hello ! Any news/blockers on this one ? thanks a lot !

[maandree]

You can write a script that every hour quickly switches VT to a TTY runs redshift -o -m drm and switches back to the display. However, you not give you full functionality. I think it's also possible to run Wayland inside X, but I'm not sure your Wayland experience will be that good.

[prahal]

Likely obsolete as of now ( well as soon as gnome 3.24 lands) but I mangled a bash script:shift2red-mutter.sh to test if redshift could work on gnome wayland.
It is based on org.gnome.Mutter.DisplayConfig.SetCrtcGamma and redshift.

I did not manage to devote enough time to make it a redshift's method, so I cleaned it up and shared here

[CubeTheThird]

I wouldn't say that the gnome 2.24 night settings are entirely a replacement for redshift. As far as I can tell, it doesn't have brightness control (which I personally love). It also seems to adjust the colour temperature based solely on time of day, whereas redshift adjusts according to your geographic location. This means that, regardless of factors such as time of year and daylight-savings (for those who have it), it still adjusts accurately relative to current daylight levels.

[prahal]

Here is an implementation for gnome (wayland and likely Xorg too) https://github.com/prahal/redshift/tree/add-gnomerr-method

Internally gnome-desktop-3.0 gnome-rr nowadays calls the mutter dbus api that is semi-private per
https://wiki.gnome.org/Initiatives/Wayland/Gaps/DisplayConfig. This page suggest to use this GnomeRR API from gnome-desktop (even though it is itself tagged unstable).

Tell me if this is of interest to the project even though it is gnome only and not a stable API, and I send the PR. It also adds a dependency on gnome-desktop-3.0 thus gtk-3.0.

Note the "gnomerr" method I implement is lower priority.than default "randr" one.
Thus one need to hardcode it in

; $HOME/.config/redshift.conf 
[redshift]
adjustment-method=gnomerr

or call redshift with the "gnomerr" method explcitely:
redshift -lgeoclue2 -t 6500:4500 -r -m gnomerr

[Thor77]

@prahal Wow, that's great! Works perfectly on ArchLinux + Gnome (Wayland) 3.22.2

[aiguofer]

@prahal's branch is working great on Fedora 26 alpha with Gnome 3.24.1 on Wayland... this should be pulled in! Although I do understand the concerns of not using a completely open api, I think many people would benefit from having a working option without having to re-compile from his source.

[matysek]

@aiguofer Gnome 3.24 introduces new feature "Night Light" https://help.gnome.org/misc/release-notes/3.24/.
Is it similar to redshift or is it anything completely different?

[alexduf]

I think it is very similar, but wayland may be used for other DE than gnome, so I suppose this is still relevant (or I missed something)

[aiguofer]

@matysek interesting, yeah just tried it out and it seems about the same. It allows you to use sunrise/sunset based on location as well as manual. However, to change temperature it looks like you need to go into dconf and change it.

It also seems like their 4000 is like 2000 on redshift... not sure why the difference

[auscompgeek]

GNOME 3.24's Night Light feature doesn't support changing the colour temperature during the day though, only during the night.

[konfou]

I ain't sure if it has been mentioned but Lourens-Rich/redshift (found as source to redshift-wayland-git package on Arch AUR) seems to add Wayland support on redshift.

[CubeTheThird]

While I haven't had success with the version by Lourens-Rich (getting SEGFAULTS), the method using gnomerr that prahal appears to work. I uploaded it to the AUR under redshift-gnomerr-git in case anyone is interested in trying it.

[konfou]

Checking a bit, what I posted is a Sway adaption of Orbital's patch seen at the first comments. The problem is that core Wayland protocol doesn't specify something for color temperature management so everything is based on whether the used compositor implements extensions for that. I don't know if anything has changed.

[breznak]

Is anyone solving the problem for KDE/Neon on Wayland side?

Also, how is the development of this package going? I'm considering giving it some time on new feature, but I see a lot of unmerged PRs and opened issues..is the development stalled?

[breznak]

This is a new addition to KDE (DE support for Gnome already in place)
https://bugs.kde.org/show_bug.cgi?id=371494
Does this make redshift obsolete for Wayland?

[SirCmpwn]

No.