Feature: Add Wayland support #55

Open
schmittlauch opened this Issue Mar 27, 2014 · 91 comments

Projects

None yet
@schmittlauch
schmittlauch commented Mar 27, 2014 edited

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
Contributor

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.

@jonls jonls added the enhancement label Mar 31, 2014
@genodeftest
Contributor

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
Contributor

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.)

@d9h02f
d9h02f commented Oct 19, 2014

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
pazooki commented Dec 22, 2014

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
Contributor

Have you tried -m randr?

@pazooki
pazooki commented Dec 22, 2014

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
rubdos commented Dec 22, 2014

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

@maandree
Contributor

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

@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
pazooki commented Dec 22, 2014

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

@maandree
Contributor

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

@pazooki
pazooki commented Dec 22, 2014

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
Contributor

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

@pazooki
pazooki commented Dec 22, 2014

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
Contributor

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

@pazooki
pazooki commented Dec 22, 2014

I think that made a difference. no errors

@maandree
Contributor

How about redshift -O 4500 -m randr?

@pazooki
pazooki commented Dec 22, 2014

it didn't do anything

@maandree
Contributor

That's weird.

@genodeftest
Contributor

$ 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
Mikaela commented Feb 7, 2015

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

@giucam
giucam commented Feb 7, 2015

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
Contributor

Can this (theoretically) be done by gamma factors?

@genodeftest
Contributor

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
giucam commented May 2, 2015

I've written the support for some wayland compositors here: giucam@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
Owner
jonls commented May 2, 2015

@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
giucam commented May 2, 2015

@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
Owner
jonls commented May 2, 2015

@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
giucam commented May 2, 2015

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

@giucam
giucam commented May 2, 2015

@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
Contributor
maandree commented May 2, 2015

@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
giucam commented May 2, 2015

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
Contributor
maandree commented May 2, 2015

@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
giucam commented May 3, 2015

@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
Contributor
maandree commented May 3, 2015

@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
giucam commented May 3, 2015

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

@maandree
Contributor
maandree commented May 3, 2015

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
Owner
jonls commented May 3, 2015

@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
Contributor
maandree commented May 3, 2015

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
giucam commented Nov 24, 2015

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@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
LeleDev commented Nov 26, 2015

+1

@ssokolow
ssokolow commented Dec 6, 2015

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
Contributor

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
alexduf commented Dec 8, 2015

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
LeleDev commented Dec 8, 2015

@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
Contributor
maandree commented Mar 21, 2016 edited

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
simdol commented May 10, 2016

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
OhDaeto commented May 10, 2016

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

@Mikaela
Mikaela commented May 10, 2016 edited
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
simdol commented May 10, 2016 edited

@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
Mikaela commented May 10, 2016

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

@psgarsenal psgarsenal referenced this issue in Cloudef/wlc Jun 23, 2016
Closed

Support for color temperature #174

@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
auscompgeek commented Aug 28, 2016 edited

@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
Contributor
genodeftest commented Aug 29, 2016 edited

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

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.

@DoctorJellyface

Linking the relevant GNOME bug if someones interested.

@jonls
Owner
jonls commented Oct 12, 2016 edited

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

@azmeuk
azmeuk commented Nov 30, 2016 edited

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

@MrSorcus

Any progress with wayland support?

@genodeftest
Contributor

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

@popenke
popenke commented Dec 13, 2016

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
Contributor

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
Contributor
maandree commented Dec 18, 2016 edited

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
popenke commented Dec 18, 2016

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
SirCmpwn commented Dec 29, 2016 edited

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
Contributor
maandree commented Dec 29, 2016 edited

@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
danielng01 commented Dec 29, 2016 edited

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

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 jonls locked and limited conversation to collaborators Jan 2, 2017
@jonls
Owner
jonls commented Jan 8, 2017

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!

@jonls jonls unlocked this conversation Jan 14, 2017
@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment