This API is mostly for use by the DRM-backend. Colorimetry mode is is
the KMS connector property "Colorspace" which defines the video signal
encoding colorimetry. A video sink indicates the supported modes in EDID
or DisplayID.
This patch adds the libweston API that allows backends to indicate the
supported modes for the frontends, and frontends to set the mode to be
used by backends. Colorimetry mode does not directly affect color
management inside Weston, it is only metadata for the video sink. It is
the frontend's responsibility to set up an output color profile that
agrees with the colorimetry mode. (That API has not been implemented
yet.) eotf_mode will be the same.
There is only one reason to make this a libweston core API instead of
a backend-drm API: when wayland-backend gains color-management protocol
support, meaning it can forward WCG and HDR content correctly to a
host compositor, the supported colorimetry modes can be determined from
the host compositor's supported color-management features, allowing the
guest Weston to pick some other output image description than the host
compositor's preferred image description. This likely allows only a few
other choices from standard colorspaces, so it's possible this isn't
sufficient for that use case.
Either way, it is easy to just copy the eotf_mode API design, and since
colorimetry_mode and eotf_mode go together, let both have the same API
design. It is possible to convert this to backend-drm API later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently we flush damage for the "primary plane" every repaint, but this
is folly.
The drm backend may skip rendering entirely if using an all-planes
composition. This could leave the renderer plane in a messy state if a
surface on an overlay plane disappears.
Instead, let the backends flush the primary plane damage when they know
they need to render.
Fixes#864
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that overlapping outputs are a thing, we have a problem with vnc
cursors.
The surface->damage used to update the vnc cursor might actually be
flushed by a previous output's repaint cycle, leading to a missing cursor
update to the vnc client.
Instead we should use the damage accumulated on the cursor plane to choose
when to update the cursor. This damage is in output coordinates, so let's
be lazy and just use the presence of damage as an indicator that the
cursor needs an update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In preparation for multi-backend support, add a list of backends to the
weston_compositor structure. Until backends are converted, this list
just contains the single weston_compositor::backend. Keep that pointer
for now, until the conversion is complete.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Extract the finish frame timestamp code and the call to
weston_output_finish_frame() into a new helper function
weston_output_finish_frame_from_timer() that can be reused
by the other timer driven backends sharing the same logic.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Extract pipewire_output_arm_timer() into libweston so it can be reused
by the other timer driven backends that use the same delay logic.
Call the shared function weston_output_arm_frame_timer().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Let backends declare the presentation clocks they can use with a
new bitfield weston_backend::supported_presentation_clocks and set
presentation clock after loading the backend in the compositor.
Make weston_compositor_set_presentation_clock() internal and replace
weston_compositor_set_presentation_clock_software() with an exported
weston_compositor_backends_loaded(), which is called by the compositor
after the backend is loaded.
In the future, this can be extended to determine the subset of clocks
supported by all backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a weston_backend::shutdown callback to split out the part of
weston_backend::destroy that needs to be done before compositor
shutdown.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Based on a patch from
Peter Hutterer <peter.hutterer@who-t.net>
Lyude Paul <thatslyude@gmail.com>
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Introduces three new structs, weston_tablet and weston_tablet_tool for the
respective devices, with the respective information as it's used on the protocol.
And weston_tablet_tool_id to track the tools of a tablet.
Note that tools are independent of tablets, many tools can be used across
multiple tablets.
The nesting on the protocol level requires a global tablet manager, a tablet
seat nested into weston_seat. The list of tablets and tools are also part of
the weston_seat.
Most functions are stubs except for the actual tablet and tablet tool
creation and removal.
This is based on patches from Peter Hutterer <peter.hutterer@who-t.net> and
Bastian Farkas <bfarkas@de.adit-jv.com>.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Push weston_coord into the notification functions instead of passing
two doubles.
The touch handlers are passed a pointer to a weston_coord, which is
unusual. This is done so we can pass a NULL pointer instead of a
fabricated invalid coordinate when the touch type is TOUCH_UP.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This creates a global coordinate from a device coordinate.
Replace it with weston_coord_global_from_output_point() which
does the same thing and returns a weston_coord_global.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
All through weston we have code that passes int x, y or
float x, y or wl_fixed_t x, y pairs. These pairs are frequently
converted to/from wl_fixed_t and other types.
We also have struct vec2d and struct weston_geometry which also
contain coordinate pairs.
Let's create a family of coordinate vector structures for coordinate
pairs and use it anywhere we sensibly can.
This has a few benefits - it helps remove intermediate conversion
between fixed/float/int types. It lets us roll the homogenous
coordinate normalization bits into helper functions instead of
needing them open coded throughout the source.
Possibly most importantly, it also allows us to do some compile time
validation of what coordinate space we're working in.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Passing the backend as a parameter to the weston_backend function
pointers seems more natural and will be very useful once there can be
more than one backend.
Since all backends already store a pointer to the compositor instance,
replace the compositor parameter with the backend in all functions.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This lets us say what we really mean instead of passing a NULL output
and garbage co-ordinates.
This will help later when manufacturing garbage coordinates becomes much
harder to do.
The clear_pointer_focus() path continues to do nothing, and is just a FIXME
macro, as it has been for a very long time...
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Rename weston_output_region_from_global to weston_region_global_to_output,
and also no longer modify in place.
Trying to make it look a little nicer, as well as making it easier to use
from other places that don't want modify in place semantics.
This becomes a very thin wrapper around weston_matrix_transform_region.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This adds hdr_meta field in weston_output_color_outcome. This field is
intended to be set by color manager modules, and read by backends which
will send the information to the video sink in SMPTE ST 2084 mode a.k.a
Perceptual Quantizer HDR system.
Such metadata is essential in ST 2084 mode for the video sink to produce
a good picture.
The validation of the data and the group split is based on the HDR
Static Metata Type 1 definition in CTA-861-G specification.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the switch to turn HDR mode on.
The values in the enumeration come straight from CTA-861-G standard.
Monitors advertise support for some of the HDR modes in their EDID, and
I am not aware of any other way to detect if a HDR mode actually works
or not. Different monitors may support different and multiple modes.
Different modes may look different. Therefore the high-level choice of
how to drive a HDR video sink is left for the Weston frontend to decide.
All the details like what HDR metadata to use are left for the color
manager.
This commit adds the libweston API for backends to advertise support and
for frontends to choose a mode. Backend and frontend implementations
follow in other commits.
The frontend API does not limit the EOTF mode to the supported ones to
allow experimentation and overriding EDID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Zoom is a neat trick, but in its current form it's very hard to test
and maintain.
It also causes output damage to scale outside of the output's boundaries,
which leads to an extra clipping step that's only necessary when zoom
is enabled.
Remove it to simplify desktop-shell and compositor.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Reported in !179 adding weston_output_repaint_failed resets the output
Co-authored-by: Daniel Stone
Co-authored-by: Julius Krah
Signed-off-by: n3rdopolis <bluescreen_avenger@verizon.net>
Converting a region from global coordinates to output pixel coordinates
will become useful in GL-renderer soon, so move this function to be
shared. It is tricky to reinvent.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Like physical size, subpixel arrangement, etc, transform advises of a
physical transform of a head, if present.
This commit adds the transform member and setter to weston_head, however
it is currently unused.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches.]
Signed-off-by: Daniel Stone <daniels@collabora.com>
Adds a new callback 'can_scanout_dmabuf' in weston_backend, which
can be set by the back-end do determine if the buffer supplied can be
imported directly by KMS.
This patch adds a wrapper over it, 'weston_compositor_dmabuf_can_scanout'
which is called before importing the dmabuf in the GPU if the
direct_display dmabuf is being set. If that's true and the check
failed, we refuse to create a wl_buffer.
This patch avoids importing in the GPU.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
For supporting output layout, compositors need the ability to manually set the
'weston_output' by 'weston_output_move'.
Signed-off-by: sichem <sichem.zh@gmail.com>
Introduce a new private header file that only internal backends are
allowed to use. Starts by migrating functions that operate on the
'struct weston_head'.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
