Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

Add gamma control #24

Merged
merged 3 commits into from
Aug 6, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 126 additions & 0 deletions unstable/wlr-gamma-control-unstable-v1.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_gamma_control_unstable_v1">
<copyright>
Copyright © 2015 Giulio camuffo
Copyright © 2018 Simon Ser

Permission to use, copy, modify, distribute, and sell this
software and its documentation for any purpose is hereby granted
without fee, provided that the above copyright notice appear in
all copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of
the copyright holders not be used in advertising or publicity
pertaining to distribution of the software without specific,
written prior permission. The copyright holders make no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied
warranty.

THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
</copyright>

<description summary="manage gamma tables of outputs">
This protocol allows a privileged client to set the gamma tables for
outputs.

Warning! The protocol described in this file is experimental and
backward incompatible changes may be made. Backward compatible changes
may be added together with the corresponding interface version bump.
Backward incompatible changes are done by bumping the version number in
the protocol and interface names and resetting the interface version.
Once the protocol is to be declared stable, the 'z' prefix and the
version number in the protocol and interface names are removed and the
interface version number is reset.
</description>

<interface name="zwlr_gamma_control_manager_v1" version="1">
<description summary="manager to create per-output gamma controls">
This interface is a manager that allows creating per-output gamma
controls.
</description>

<request name="get_gamma_control">
<description summary="get a gamma control for an output">
Create a gamma control that can be used to adjust gamma tables for the
provided output.
</description>
<arg name="id" type="new_id" interface="zwlr_gamma_control_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>

<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>

<interface name="zwlr_gamma_control_v1" version="1">
<description summary="adjust gamma tables for an output">
This interface allows a client to adjust gamma tables for a particular
output.

The client will receive the gamma size, and will then be able to set gamma
tables. At any time the compositor can send a failed event indicating that

This comment was marked as resolved.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see, it's the failed event, but what about the error enum? That doesn't seem to be used anywhere

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Protocol errors are reserved for situations in which the client does something wrong. Protocol errors are suitable for a client passing a gamma with an invalid size, but are unsuitable for signaling that an output doesn't support gamma control.

this object is no longer valid.

There can only be at most one gamma control object per output, which
has exclusive access to this particular output. When the gamma control
object is destroyed, the gamma table is restored to its original value.
</description>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be good to reset the gamma table not when gamma_control is destroyed but when the gamma_control_manager is destroyed? This would

  • avoid having the app to hold the gamma_control all the time (can release it when after updating the table)
  • would still give a sane output when the client disconnects

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I'm not sure what the upside is, since you'll need to hold the gamma_control_manager instead of the gamma_control?
  • Clients are supposed to keep the gamma_control around to keep a "lock" on the output and prevent other clients from controlling the same output. How would this mechanism work with your proposal?
  • A common Wayland idiom is to create the manager, create the control, and immediately destroy the manager. This is done with wl_region for instance (clients create a region, assign it to a surface, and then immediately destroy it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The upside is since the manager is the singleton global the client is unlikely to dismiss it since it will need it anyway to handle monitor hotplug. (in your region example the wl_compositor is the singleton global not the region). I also wonder how much sense it makes to have different clients to be able to keep a lock for different outputs.


<event name="gamma_size">
<description summary="size of gamma ramps">
Advertise the size of each gamma ramp.

This event is sent immediately when the gamma control object is created.
</description>
<arg name="size" type="uint" summary="number of elements in a ramp"/>
</event>

<enum name="error">
<entry name="invalid_gamma" value="1" summary="invalid gamma tables"/>
</enum>

<request name="set_gamma">
<description summary="set the gamma table">
Set the gamma table. The file descriptor can be memory-mapped to provide
the raw gamma table, which contains successive gamma ramps for the red,
green and blue channels. Each gamma ramp is an array of 16-byte unsigned
integers which has the same length as the gamma size.

The file descriptor data must have the same length as three times the
gamma size.
</description>
<arg name="fd" type="fd" summary="gamma table file descriptor"/>
</request>

<event name="failed">
<description summary="object no longer valid">
This event indicates that the gamma control is no longer valid. This
can happen for a number of reasons, including:
- The output doesn't support gamma tables
- Setting the gamma tables failed
- Another client already has exclusive gamma control for this output
- The compositor has transfered gamma control to another client

Upon receiving this event, the client should destroy this object.
</description>
</event>

<request name="destroy" type="destructor">
<description summary="destroy this control">
Destroys the gamma control object. If the object is still valid, this
restores the original gamma tables.
</description>
</request>
</interface>
</protocol>