Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for using any number of CRTC:s in any number of screens #44

Closed
wants to merge 8 commits into from

Conversation

@maandree
Copy link
Contributor

@maandree maandree commented Mar 17, 2014

This pull request continues #42 (Support for running Redshift outside X) by
adding support for using any number of CRTC:s in any number of screens with
individual gamma correction for each monitor.

The configurations are backwards compatible but are extended so that you
can select any monitor and apply gamma corrections individually by specifying
one section in the configuration file per monitor with the same name as the
adjustment method. For example:

[redshift]
adjustment-method=randr
gamma=1:1:1
; this gamma setting will be used if not specified otherwise

[randr]
screen=0
crtc=0
gamma=1.1:1.1:1.1

[randr]
screen=0
crtc=1
gamma=1.2:1.2:1.2
; screen=1 with crtc=0 will also work, although I cannot say
; for sure because I only have one screen, with two outputs.

The reason the sections are named as the adjustment method is
so that it is simple to have adjustment method dependent settings.
For example, if I use DRM the CRTC:s will be swapped so a can
extend the example above with:

[drm]
card=0
crtc=1
gamma=1.1:1.1:1.1

[drm]
card=0
crtc=0
gamma=1.2:1.2:1.2
@maandree
Copy link
Contributor Author

@maandree maandree commented Mar 20, 2014

I have rebased and squashed this branch.

@jonls
Copy link
Owner

@jonls jonls commented Mar 23, 2014

Can you please rebase this on the master (instead of merging master into your branch)? Maybe it would be a good idea to split the changes for each gamma method into separate commits so they can be reviewed separately. Also, maybe all the (void)variable; edits can go into a separate commit (I assume these are just to suppress some overeager warning setting) and maybe drop them entirely since they are not needed.

maandree added 7 commits Mar 23, 2014
…CRTC:s in any number of screens

Signed-off-by: Mattias Andrée <maandree@operamail.com>
Signed-off-by: Mattias Andrée <maandree@operamail.com>
Signed-off-by: Mattias Andrée <maandree@operamail.com>
Signed-off-by: Mattias Andrée <maandree@operamail.com>
Signed-off-by: Mattias Andrée <maandree@operamail.com>
Signed-off-by: Mattias Andrée <maandree@operamail.com>
…rence in a comparision

Signed-off-by: Mattias Andrée <maandree@operamail.com>
@maandree
Copy link
Contributor Author

@maandree maandree commented Mar 23, 2014

I have rebased and splitted into logical steps. I also added an update to .gitignore.

(void) variable and cast to unsigned as added to suppress the overwhelming
amount of worknings when a was compiling, to make it easier to read the output.
I compile with -Wall -Wextra -pedantic to reduce errors and make sure that I do
not use any feature that is not portable.

@jonls
Copy link
Owner

@jonls jonls commented Mar 23, 2014

Thanks, I've merged the two minor commits.

@maandree maandree mentioned this pull request Mar 27, 2014
1 of 3 tasks complete
@maandree
Copy link
Contributor Author

@maandree maandree commented Apr 7, 2014

@jonls how is it looking on merging this and its child branches?

@jonls
Copy link
Owner

@jonls jonls commented Apr 10, 2014

@mandree I'm a bit busy these days so I decided it was more important to push out the 1.9 release since I think we had some good features ready to go. I will start merging this as soon as I find some time. I see that you made some other pull requests but they seem to be based on this, no? I will focus only on merging this branch if it is the basis of the following pulls.

Also, please don't merge master back into pull requests. If you need new features from master (i.e. they are essential to your patch) you can do a rebase on master.

@maandree
Copy link
Contributor Author

@maandree maandree commented Apr 10, 2014

Okey.
I was wondering because I was not sure whether to wait or make pull request #61,
which obsoletes this pull request and all pull requests based on this pull request.

@jonls
Copy link
Owner

@jonls jonls commented Apr 10, 2014

Alright, if you make something obsolete please close it so I won't spend time reviewing it ;) It's generally way easier for me if you break the pull requests up into small self-contained units.

@maandree
Copy link
Contributor Author

@maandree maandree commented Apr 10, 2014

Sorry about that on 61, I did not want to have to rewrite a bunch of stuff if I missed something.

@maandree maandree closed this Apr 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.