Similarly to all the other back-ends do the same for the RDP one.
With this change the remote output will be placed, similar to the
VNC/PipeWire on the right side from the native one, when both backends
are loaded.
But ultimately this patch is about having all backends share the same
code path.
Fixes: #820
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
If section is NULL, weston_config_section_get_*() will assign the given
default value and return -1 with ENOENT. Hence, checking for NULL
section is unnecessary.
This cleans up only the simple cases.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Essentially ensures that wet_output_set_eotf_mode() and
wet_output_set_colorimetry_mode() work as intended.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This output section key is used to program the KMS connector property
"Colorspace" when used with the DRM-backend.
This is an essential part in defining the color encoding used in the
video signal, and may allow wide color gamut even on SDR.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It would be painful to mock a struct wet_compositor in the tests, so
pass that one boolean as an explicit argument instead.
This makes it easier to extend the testing of the function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The windowed output API is implemented by the Wayland, the X11 and the
headless backends. It's currently not possible to create a secondary
headless backend when the primary backend is Wayland or X11 because
the windowed output API would be registered twice. This commit
suffixes the windowed output API names with the backend name in order
to avoid clashes: "weston_windowed_output_api_<backend>_v2".
A use case for Wayland or X11 as primary backend and headless as
secondary is for instance to request output captures on the headless
backend to avoid read backs on the primary backend's render buffers.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Add a section about the headless backend to the main Weston manual
page and describe the current CLI options as well the new
`--refresh-rate` one.
Fix the incorrect list of supported transforms in the CLI usage.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Custom headless refresh rates can be useful to instrument clients
matching different screen configurations. This commit adds support for
that to the headless backend and exposes it to the frontend with the
"--refresh-rate" CLI option. The default refresh value is still 60 Hz.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
These warn let to recognize what can be the issue whether
pipewire-output or remote-output has been set but its
mode it is not. Without this log, if mode is not set,
the init just exits
Signed-off-by: Diego Nieto <diego.nieto.m@outlook.com>
Up to now, HAVE_LCMS would be set only when users would build Weston
with the deprecated cms-static enabled. But we'll start using this in
libweston in the next commits, independently of cms-static being enabled
or not. So always set HAVE_LCMS when the LittleCMS dependency is found.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Added an entry with examples into the man page and also
into frontend/main.c for the '--help' interface.
Signed-off-by: Nicholas Niro <blowfist@xroutine.net>
This command is being executed in parallel with the westen instance,
just like the autolaunch config.
I recently came across the kiosk-shell and found out I could start a program exclusive
weston instance using it and that opened my eyes to new possibilities.
With the desktop-shell, it is necessary to set up quite a few options like the panel launchers,
the background image/color and a few other things and that indeed make the configuration file mandatory.
With the kiosk-shell all you really care about is the underlying program,
the vast majority of the configuration file options are not relevant for that shell.
That made me wonder how convenient it would be to forego the configuration file
and implement the autolaunch option directly in the weston program. That indeed worked pretty
well and that is why I decided to propose this merge request.
I think this avenue opens up a different set of uses cases for weston where rather than just have one
"big" desktop-shell instance, we could have multiple smaller and potentially specific usage instances.
Yes, it can be done with configuration files currently. But what it boils down to is convenience.
Maybe this convenience will enable other people to start more than just one weston instance
in the future. For instance, to quickly watch an image or opening up a pdf file.
This patch was made in a matter that is meant to be consistent with the intuitive
way other programs accept a command input, like so :
weston <some options> -- some_command option1 ... optionN
Further work would be necessary to remove the requirement for the '--'
option. To do that, we would need to check if the option is a valid command
and not just a mistyped option.
There may be some conflict with the current autolaunch implementation.
I'm not sure if both 'command' and 'autolaunch' could be used at the
same time using this implementation. I think it would be necessary to
have a distinct watch and pid variable in the 'wet' context variable
for the command to support this.
Signed-off-by: Nicholas Niro <blowfist@xroutine.net>
