Some monitors expose a selector for the kind of content that will get
displayed, allowing them to optimise their settings for this particular
content type.
I got access to such a monitor, sadly even setting it to game mode
didn’t lower its atrocious latency, but drm_info[1] reports it to be set
correctly so hopefully it’ll work better with other monitors.
[1] https://github.com/ascent12/drm_info
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
The supplied path for executing the shell client could contain potential
arguments and not only the binary itself. Specifying the platform either
by using an argument (-platform wayland) or using an environmental
variable (QT_QPA_PLATFORM) with clients written in Qt is for instance
an example on why this might be useful to have in.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It's not the most code ever, but it does make desktop-shell somewhat
more complicated for questionable (i.e. no) end-user benefit.
When desktop-shell is back in more healthy shape it could potentially be
reintroduced, but for now it's just making it more difficult to reason
about desktop-shell and fix it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This adds an option to program basic display color characteristics from
weston.ini. In the future there will be a way to set this information
from EDID, but because EDID is unreliable that will probably not be the
default. An ICC profile will likely override most or all of this. The
main reason to add this option is to be able to characterise HDR
monitors.
An 'output' section can have a key 'color_characteristics' (string)
set to a name. The name refers to any 'color_characteristics' section
with 'name' set to the same string.
The 'name' key of a 'color_characteristics' section cannot contain a
colon ':'. Names with colon in 'output' section key
'color_characteristics' value are reserved for future use, e.g. to
indicate that the metadata is to be taken from EDID instead of a
weston.ini section.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With commit 'screen-share: Add option to start screen sharing on weston
star' an section option has been added to start screen-sharing by
default on all outputs. This has the side-effect of attempting to start
screen-share on the same (RDP) output performing the screen-share. That
happens due to re-loading the screen-share module once more.
This patch recommends users to use --no-config option or alternatively,
use a different configuration file to avoid that.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
These added lines are comments (do not affect output) that make it
easier to browse this file and find the section headings.
Removal of the preceding empty lines on two of the section headers
remove a blank line from PDF output. The blank line was kind of nice,
but presumably .SH should add any necessary blanks before a new section
heading. Now all the section headings have the same vertical space to
the preceding content in PDF.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Try to reduce the cargo-culted directives that do not seem to have any
effect on the output.
I verified that are no changes by doing before this patch
$ man -Tpdf man/weston.ini.5 > ref.pdf
and then after this patch
$ ninja && man -Tpdf man/weston.ini.5 > test.pdf
and looking at
$ diffpdf ref.pdf test.pdf
I used PDF as the format for comparisons, because it can express much
more typesetting features than plain text.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This option is used only with the DRM-backend. Options in weston.ini(5)
should be either generic or for backends that do not have their own man
page yet.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This option is used only with the DRM-backend. Options in weston.ini(5)
should be either generic or for backends that do not have their own man
page yet.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Moving forward we're going to be supporting libseat and logind as our
only launchers. We're doing this to reduce our maintenance burden,
and security impact.
Libseat supports all our existing use cases, and seatd can replace
weston-launch so we no longer have to carry a setuid-root program.
This patch removes weston-launch, and launcher-direct, leaving only
libseat and logind.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This isn't about opening new windows but the start-up animation
that desktop-shell does when it is being brought on/started.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This adds "icc_profile" key support in [output] sections for backends
headless, x11, wayland, and drm, and also for remoted and pipewire
outputs FWIW. On the other hand, RDP-backend does not use output
sections from weston.ini, and fbdev-backend does not deserve anything
new (it wouldn't support color management anyway due to no GL-renderer).
This allows one to configure an ICC v2 or v4 file to be used as an
output profile. However, color-lcms does not actually use output
profiles yet, so trying this will fail until support is implemented.
The parent_winsys_profile argument is reserved for using the color
profile from a parent window system where applicable, if nothing else is
set in weston.ini. None of the nested backends provide an output color
profile yet. It is more of a reminder of a missing feature than a
serious implementation.
Note: cms-static Weston plugin uses the exact same weston.ini key for
loading VCGT from ICC profiles. If "color-management" option is set to
false, this new use of "icc_profile" is disabled and the old behavior
with cms-static is kept.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently the screen sharing has to be manually started after weston has
started by pressing Ctrl+Alt+S on a keyboard. Add new bool config option
to the screen-share section which permits starting the screen sharing of
all outputs on weston start up. This is useful e.g. for doing screen
mirroring between two devices over network.
Signed-off-by: Marek Vasut <marex@denx.de>
input-method-v1 protocol provides two surface type for the input
panel, `toplevel` and `overlay`. But there is no example for the later
one. This change enables to set weston-keyboard as overlay panel by the
environment variable `WESTON_KEYBOARD_SURFACE_TYPE=overlay` to
demonstrate this feature. In Addition, add weston.ini option
`overlay-keyboard` to set it.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
The value of the `path` parameter is executed right before
wl_display_run.
The `watch` parameter is meant for things like tests using
the headless backend and the kiosk shell.
Fixes https://gitlab.freedesktop.org/wayland/weston/-/issues/171
Signed-off-by: Alvarito050506 <donfrutosgomez@gmail.com>
This reverts commit 81ef6d0ab3.
This also removes a bit from "tests: ensure color-lcms plugin loads".
Use of the shadow buffer is determined automatically based on
color transformations by the previous commit
"gl-renderer: use shadow framebuffer automatically".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds an output section option use-renderer-shadow in weston.ini.
This option is only recognized with headless and DRM backends, because
it requires GL-renderer and does not support resizing outputs.
The option is called use-renderer-shadow because this is what it does
right now. In the future the same setting will be used to turn on more
complex image processing when operational pieces required for color
management land. Once color management is implemented, this option is
expected to be removed. This option allows developer testing of features
to be used to implement color management.
This is a rewrite of "weston.ini: introduce use-shadow-fbo in output
config" by Harish Krupo. The main.c code is structured differently, the
weston.ini option is renamed, and the man page paragraph is moved to
weston.ini.man with different content.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
kiosk-shell is fullscreen shell for apps that use the xdg-shell
protocol. The goal is to make life easier for people shipping embedded
devices with simple fullscreen shell requirements, and reduce the
proliferation of desktop-shell hacks.
Top level surfaces are made fullscreen, whereas dialogs are placed on
top in the center of the output and retain their natural sizes. Dialogs
can be moved and (un)maximized, but resizing is currently not supported.
An app can be directed to a particular output by populating the
"app-ids" field with the app's XDG app id, in the relevant
"[output]" section in the weston config file.
Fixes: #277
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
It was discovered in issue #99 that the implementations of the 90 and 270
degree rotations were actually the inverse of what the Wayland specification
spelled out. This patch fixes the libweston implementation to follow the
specification.
As a result, the behaviour of the the weston.ini transform key also changes. To
force all users to re-think their configuration, the transform key values are
also changed. Since Weston and libweston change their behaviour, the handling
of clients' buffer transform changes too.
All the functions had their 90/270 cases simply swapped, probably due to
confusion of whether WL_OUTPUT_TRANSFORM_* refers to rotating the monitor or
the content.
Hint: a key to understanding weston_matrix_rotate_xy(m, c, s) is that the
rotation matrix is formed as
c -s
s c
that is, it's column-major. This fooled me at first.
Fixing window.c fixes weston-terminal and weston-transformed.
In simple-damage, window_get_transformed_ball() is fixed to follow the proper
transform definitions, but the fix to the viewport path in redraw() is purely
mechanical. The viewport path looks broken to me in the presence of any
transform, but it is not this patch's job to fix it.
Screen-share fix just repeats the general code fix pattern, I did not even try
to understand that bit.
https://gitlab.freedesktop.org/wayland/weston/issues/99
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Currently, the HDCP support in drm-backend is under review and no
other backend supports HDCP yet. This patch is just to update the
weston.ini with this information.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
This patch enables a user to opt for HDCP per output, by writing into
the output section of weston.ini configuration file. HDCP is always
enabled by default for the outputs.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The desktop-shell-specific bindings were identified from
shell_add_bindings in desktop-shell/shell.c. Various general shortcuts
(like Ctrl+Alt+F) are provided by files in libweston/ and compositor/ .
Also introduce references to the new manual in weston(1) and weston.ini(5).
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
This is so that, for instance, people using weston as their main Wayland
compositor can invert the sense of two finger scrolling or change
pointer acceleration using weston.ini, rather than having to edit C
code.
All of the options that libinput itself exposes through its API are now
exposed in weston.ini. The new options are called `tap-and-drag`,
`tap-and-drag-lock`, `disable-while-typing`, `middle-emulation`,
`left-handed`, `rotation`, `accel-profile`, `accel-speed`,
`scroll-method`, `natural-scroll`, and `scroll-button`. I have
successfully tested everything except for `rotation`, out of a lack of
hardware support.
weston now depends directly on libevdev for turning button name strings into
kernel input codes. This was needed for the `scroll-button` config
option. (weston already depends indirectly on libevdev through
libinput, so I figured people would be OK with this.) As a practical
matter for debian-style packagers, weston now has a build dependency on
libevdev-dev.
Right now, the code applies the same options to all attached devices
that a given option is relevant for. There are plans for multiple
[libinput] sections, each with different device filters, for users who
need more control here.
Signed-off-by: Eric Toombs <3672-ewtoombs@users.noreply.gitlab.freedesktop.org>
This is to increase consistency in config option naming in weston.ini.
(Prefer hyphens over underscores to separate words.)
If enable_tap is present in weston.ini, an obnoxious error message is
logged with weston_log(). In terms of configuration, if enable-tap is
present, enable_tap is ignored.
Signed-off-by: Eric Toombs <3672-ewtoombs@users.noreply.gitlab.freedesktop.org>
Pixman can be used for rendering if the default GLESv2 rendering
is broken or cannot be used.
Pixman-based rendering is already available with the command-line
switch '--use-pixman'. This patch adds support for this option to
the configuration file. Putting
[core]
use-pixman=true
into 'weston.ini' enables pixman-based rendering for all backends
that support it. With this change, pixman has to be enabled only
once.
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/27
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
It's a bit surprising that Weston looks different when launched from the root
of the git repo vs from elsewhere.
But it's also technically a security vulnerability: if I launch it from
a directory like /tmp, it might pick up a weston.ini created by another user,
which could then load modules with arbitrary code. Basically, it's the same
problem as including "." in $PATH.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Remoting plugin support streaming image of virtual output on drm-backend
to remote output. By appending remote-output section in weston.ini,
weston loads remoting plugin module and creates virtual outputs via
remoting plugin. The mode, host, and port properties are configurable in
remote-output section.
This plugin send motion jpeg images to client via RTP using gstreamer.
Client can receive by using following pipeline of gst-launch.
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,
encoding-name=JPEG,payload=26" port=[PORTNUMBER] !
rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtpjpegdepay ! jpegdec ! autovideosink \
udpsrc port=[PORTNUMBER+1] ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 !
udpsink port=[PORTNUMBER+2] sync=false async=false
where, PORTNUMBER is specified in weston.ini.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Add the centered option as background-type. This draws the image
once in the center of the screen. If the image is larger, it will
be cropped like scale-crop.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Change format of substituted variables to follow the pattern used by
configure_file() in Meson.
This helps the migration to Meson, making man/meson.build much cleaner.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The weston.ini.man describes the mode-formats that a user can specify
for selecting a video mode. The DRM specific examples are already
provided in weston-drm.man, so this inofrmation is redundant and can
be removed.
This patch removes the DRM specific mode option details from the
description of mode configuration in weston.ini.man.
A pointer to weston-drm.man is given, which has complete information
about the mode-format options supported by DRM backend.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Replace a few hardcoded paths with the substitutes
https://gitlab.freedesktop.org/wayland/weston/issues/105
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add an option to enable the touchscreen calibrator interface. This is a
global on/off toggle, in lack of more fine-grained access restrictions.
As Weston should not hardcode system specifics, the actual permanent
saving of a new calibration is left for a user supplied script or a
program. Usually this script would write an appropriate udev rule to set
LIBINPUT_CALIBRATION_MATRIX for the touch device.
Co-developed by Louis-Francis and Pekka.
v2:
- use syspath instead of devpath
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When you need to start Weston via weston-launch, systemd unit, or any
other runner, it is annoying to try to get in with a debugger,
especially if the thing you are interested in happens at start-up. To
make it easy, a new option is introduced.
The new option, implemented both as a command line option and a
weston.ini option, raises SIGSTOP early in the start-up, before the
weston_compositor has been created. This allows one to attach a debugger
at a known point in execution, and resume execution with SIGCONT.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Ian Ray <ian.ray@ge.com>
The paragraph about pageflip-timeout was added in between the two
paragraphs of idle-time, causing the paragraphs to be associated wrong.
Move the pageflip-timeout paragraph to the end.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100163
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Weston will not repaint until previous update has been acked by a
pageflip event coming from the drm driver. However, some buggy drivers
won’t return those events or will stop sending them at some point and
Weston output repaints will completely freeze. To ease developers’ task
in testing their drivers, this patch makes compositor-drm use a timer
to detect cases where those pageflip events stop coming.
This timeout implementation is software only and includes basic
features usually found in a watchdog. We simply exit Weston gracefully
with a log message and an exit code when the timout is reached.
The timeout value can be set via weston.ini by adding a
pageflip-timeout=<MILLISECONDS> entry under [core]
section. Setting it to 0 disables the timeout feature.
v2:
- Made sure we would get both the pageflip and the vblank events before
stopping the timer.
- Reordered the error and success cases in
drm_output_pageflip_timer_create() to be more in line with the rest
of the code.
v3:
- Reordered (de)arming of the timer with the code around it to avoid it
being rearmed before the current dearming.
- Return the proper value for the dispatcher in the pageflip_timeout
callback.
- Also display the output name in case the timer fires.
v4:
- Reordered a forgotten timer rearming after its drmModePageFlip().
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=83884
Signed-off-by: Frederic Plourde <frederic.plourde at collabora.co.uk>
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It was renamed from panel-location in
55d5701ddf, and gained a few possible
values.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
As it has been discussed in the past [1], running Weston
without any input device at launch might be beneficial for
some use cases.
Certainly, it's best for the vast majority of users (and
the project) to require an input device to be present, as
to avoid frustration and hassle, but for those brave souls
that so prefer, this patch lets them run without any input
device at all.
This introduces a simple configuration in weston.ini:
[core]
require-input=true
True is the default, so no behavioral change is introduced.
[1] https://lists.freedesktop.org/archives/wayland-devel/2015-November/025193.html
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This patch completely removes the Raspberry Pi backend and the renderer.
The backend and the renderer were written to use the proprietary
DispmanX API available only on the Raspberry Pi, to demonstrate what the
tiny computer is capable of graphics wise. They were also used to
demonstrate how Wayland and Weston in particular could leverage hardware
compositing capabilities that are not OpenGL. The backend was first
added in e8de35c922, in 2012.
Since then, the major point has been proven. Over time, support for the
rpi-backend diminished, it started to deteriorate and hinder Weston
development. On May 11, I tried to ask if anyone actually cared about
the rpi-backend, but did not get any votes for keeping it:
https://lists.freedesktop.org/archives/wayland-devel/2016-May/028764.html
The rpi-backend is a good example of how using an API that is only
available for specific hardware, even more so as it is only available
with a proprietary driver stack, is not maintainable in the long run.
Most developers working on Weston either just cannot, or cannot bother
to test things also on the RPi. Breakage creeps in without anyone
noticing. If someone actually notices it, fixing it will require a very
specific environment to be able to test. Also the quality of the
proprietary implementation fluctuated. There are reports that RPi
firmware updates randomly broke Weston, and that nowadays it is very
hard to find a RPi firmware version that you could expect to work with
Weston if Weston itself was not broken. We are not even sure what is
broken nowadays.
This removal does not leave Raspberry Pi users cold (for long), though.
There is serious work going on in implementing a FOSS driver stack for
Raspberry Pi, including modern kernel DRM drivers and Mesa drivers. It
might not be fully there yet, but the plan is to be able to use the
standard DRM-backend of Weston on the RPis. See:
http://dri.freedesktop.org/wiki/VC4/
The rpi-backend had its moments. Now, it needs to go. Good riddance!
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Add explanations of scaling that are a bit more approachable for users.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94824
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
