sway/output: new "edid" and "gamma22" modes for color_profile

[poisotf]

This adds the two modes mentioned in #8922 (comment)

• output <criteria> color_profile gamma22 takes the place of the current default srgb (no color processing)
• output <criteria> color_profile srgb assumes the display uses the piece-wise srgb transfer function
• edid argument can be added to either, to build a color profile using it and the display's self-reported color characteristics

[kennylevinsen]

Blocked on two unmerged wlroots MR's, so converted to draft for good measure.

[llyyr]

output <criteria> color_profile edid builds a color profile using gamma22 and the display's self-reported color characteristics

I'm not sure it makes sense for this to be gamma22 only, it's perfectly valid to use the display's self reported primaries along with either srgb/gamma22 transfer depending on what the display actually does

[poisotf]

I agree 'edid' is more useful as a modifier for the first two. I've switched to doing that

Also adding a check to not build identity color matrix, which it turns out would happen on more displays that I thought

[quietvoid]

Would it be possible to use an ICC file as sole source for primaries, without having the whole ICC used as it currently exists?
For example if calibrated primaries differ from EDID.

Alternatively, being able to specify custom primaries may be useful. But that might be out of scope for this PR.

Most likely I should just use the existing icc setting but IIRC it's not particularly efficient in its current state?

[poisotf]

In principle yes, but I think your use case would be best served by some sort of "fast" option for the icc setting

The modes from this PR are not optimal either : all except the default will disallow direct scanout

wlroots still has margin for improvement around hardware offload, that would help both

[poisotf]

The required wlroots work is merged : this now looks as intended

Gaining direct scanout for the new modes is still some changes away, though

[llyyr]

I wonder if it would make sense to support this for the for_window directive too, if the user knows for sure whatever application is outputting srgb/gamma2.2 for sure but it might not be picking the right swapchain. This isn't a blocker for this PR though

[kennylevinsen]

I wonder if it would make sense to support this for the for_window directive too

That wouldn't really work - for_window runs the first time a window matches the criteria. If you had rules setting gamma2.2 and srgb, the display configuration would end up solely determined by the order windows are opened in.

I imagine you were thinking of was instead rules that apply whenever a particular window is on screen or fullscreen, which for_window cannot do. That would require an IPC client to monitor changes to the tree.

[poisotf]

Do you mean a for_window rule to direct how the window is linearized before composition ?

That would be a way to complete the signal chain and give the user full control over the srgb gamma question, but it touches different bits than this PR

[llyyr]

Do you mean a for_window rule to direct how the window is linearized before composition ?

Yes, and I agree that it wouldn't need to be a part of this PR

[kennylevinsen]

Do you mean a for_window rule to direct how the window is linearized before composition ?

No I was describing shortcomings of a for_window rule to apply the output commands implemented here to change TF - given that those commands are the scope of the PR I thought that was your suggestion.

Properties like color management are surface traits, while a window can be comprised of many surfaces with intentionally different traits. Trying to override things there would be tricky and likely to cause issues, especially if the goal would be to override already set image descriptions rather than, say, a default image description for surfaces without color management.

[emersion]

Thanks for the patch! Here are a few comments.

[emersion]

This updates sway_output, however this is called from queue_output_config() so may be rolled back in case the output commit fails.

queue_output_config() should only update wlr_output.pending and shouldn't update other fields.

[poisotf]

moved the call to apply_resolved_output_configs.
Still a bit confused over how this could be moved back to finalize_output_config without showing a wrong frame

[emersion]

Hm, I'm still a bit antsy about applying after test() but before commit(): commit() (or operations before that call) may fail still, and we'd end up applying the change even though we shouldn't…

Maybe we could extract the color transform from the output config instead of using cfg->output->color_transform in apply_resolved_output_configs()?

[emersion]

Maybe we could extract the color transform from the output config instead of using cfg->output->color_transform in apply_resolved_output_configs()?

Ah, I suppose this approach will not scale with the rest of the output properties, such as output position?

We probably need to apply after test() and rollback on error? This would have the downside of potentially flip-flopping some state (which might be visible externally via e.g. IPC), on the other hand commit() and ENOMEM errors should be quite rare (test() passed, so most errors should've been caught already).

[poisotf]

Trying with a new 'state' struct, to use the new color transform for the first commit, but move it into sway_output in finalize_output_config

[poisotf]

updated for previous remarks + changed error handling in color_profile_from_device