The subscription is directly related to both the log scope and
the subscriber. It makes no sense to destroy one of them and
keep the subscriptions living.
We only had code to destroy subscription with
the destruction of log scopes. Add code to destroy
subscriptions with destruction of subscribers.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Log subscriber API is not type-safe. File and flight recorder
subscribers are created with functions that return
weston_log_subscriber objects. But there's a problem: to destroy
these objects you have to call the right function for each type
of subscriber, and a user calling the wrong destroy function
wouldn't get a warning.
Merge functions that destroy different types of subscribers, making
the log subscriber API type-safe.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
weston_log_subscriber has a member named destroy. There are
other structs (weston_output, for instance) that have this
member, and by convention it is a pointer to a function
that destroys the struct.
In weston_log_subscriber it is being used to destroy
subscriptions of the debug protocol, and not the subscriber,
so this name is misleading. Rename it to destroy_subscription.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
weston_primary_flight_recorder_ring_buffer needs to be cleared on destruction
of the subscriber it was assigned from so that a compositor and be re-executed
in-process (static variables do not get re-initialized automatically).
This will be used by the test harness when it will execute wet_main() multiple
times in the same process. Otherwise it would hit the assert in
weston_log_subscriber_create_flight_rec().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If gl-renderer fails its initialisation, we return to compositor
teardown, which will try to free the renderer if ec->renderer was set.
This is unfortunate when we've already torn it down whilst failing
gl-renderer init, so just clear the renderer member so we don't try to
tear down twice.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Emil Velikov <emil.velikov@collabora.com>
When using weston-launch launcher deactivating the VT is sometimes
racy and leads to Weston still being displayed. The launcher-direct.c
backend makes sure that the session signal is emitted first, then DRM
master is dropped and finally the VT switch is acknowledged via
VT_RELDISP.
However, in the weston-launch case the session signal is emitted via
a socket message to the weston process, which might get handled a bit
later. This leads to dropping DRM master and acknowledging the VT
switch prematurely.
Add a socket message which allows weston to notify weston-launch that
the signal has been emitted and deactivating can be proceeded.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
On weston-launch exit we see errors such as:
failed to restore keyboard mode: Invalid argument
failed to set KD_TEXT mode on tty: Invalid argument
This has been resolved by making sure the tty file descriptor
does not get closed. However, the ioctrl's KDSKBMODE/KDSETMODE
and VT_SETMODE still fail with -EIO:
failed to restore keyboard mode: Input/output error
failed to set KD_TEXT mode on tty: Input/output error
It turns out the reason for this lies in some very particular
behavior of the kernel, the separation of weston-launch/weston
and the fact that we restore the tty only after the weston
process quits: When the controlling process for a TTY exits,
all open file descriptors for that TTY are put in a hung-up
state! For more details see this systemd-logind issue:
https://github.com/systemd/systemd/issues/989
We can work around by reopening the particular TTY. This allows
to properly restore the TTY settings such that a successive VT
switch will show text terminals fine again.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since weston-launch is a setuid-root program we should be extra careful:
Check for a potential string trunction. Move the check in a separate
function and return with error in case trunction has happened.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Currently weston-launch does not activate the VT when opening the
terminal directly (e.g. using --tty=/dev/tty7). Weston takes full
control over the terminal by switching it to graphical mode etc.
However, the old VT stays active as can be seen when looking at
sysfs:
# cat /sys/class/tty/tty0/active
tty1
Always switch to the new VT to make sure the correct VT is active.
This aligns with how TTY setup is implemented in launcher-direct.c.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add newline character at the end of the error message to make sure we
get a new line after this error has been printed.
Fixes: a1450a8a71 ("make error() portable")
Signed-off-by: Stefan Agner <stefan@agner.ch>
In case an user is given but no tty, the code opens tty0 to allocate a
new tty. With that ttynr is known.
In case a tty name is given the user must be given too. In this case
we later recover the ttynr by using stat on the file tty file descriptor
which allows as to find the ttynr by looking at the devices minor number.
However, the third case, when no user and no tty name is given, we do
not get the ttynr.
This hasn't been a problem in practise since ttynr has not been used.
However, it makes sense to get the ttynr always for consistency. Also
upcomming fixes will start to make use of ttynr.
Fixes: 636156d5f6 ("weston-launch: Don't start new session unless -u is given")
Signed-off-by: Stefan Agner <stefan@agner.ch>
The tty file descriptor is used in signal handling (when switching
VT via SIGUSR1/SIGUSR2 for the VT_RELDISP ioctrl) and in quit() when
weston-launch exits for the KDSKBMUTE/KDSKBMODE/KDSETMODE/VT_SETMODE
ioctrls.
This fixes VT switching when using weston-launch from a non-VT shell
(e.g. ssh or from within a container).
Signed-off-by: Stefan Agner <stefan@agner.ch>
The only reason why we have both weston_compositor_tear_down() and
weston_compositor_destroy() is that the only we had to destroy
the log context was keeping weston_compositor alive and calling
weston_log_ctx_compositor_destroy().
After commit "weston-log: replace weston_log_ctx_compositor_destroy()
by weston_log_ctx_destroy()", it's not necessary to keep a zombie
weston_compositor just to be able to call
weston_log_ctx_compositor_destroy().
Fold weston_compositor_tear_down() into weston_compositor_destroy(),
as this split is useless now.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_destroy(), which destroys struct
weston_log_context, takes weston_compositor as argument. We may have a
weston_log_context unlinked from a weston_compositor and currently there
is no way to destroy it.
Add function weston_log_ctx_destroy(), what makes the destruction of
weston_log_context independent of weston_compositor.
With this change, one could destroy a weston_compositor and keep the
related weston_log_context (since now weston_log_context can be destroyed
without the need of a weston_compositor). But if weston_compositor gets
destroyed it's also necessary to destroy weston_log_context::global,
as the debug protocol depends on the compositor. So a listener has been
added to the destroy signal of weston_compositor.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since weston_log_ctx_compositor_create() does not have any relation
with weston_compositor, rename it to weston_log_ctx_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_setup() is being called only inside
weston_compositor_create() and it is so tiny that the code gets easier to
follow if it gets folded in weston_compositor_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
If we use the function weston_log_context_add_log_scope()
in non-core code, it's necessary to access
weston_compositor::weston_log_ctx.
This is not ideal, since the goal is to make core structs
(weston_compositor, weston_surface, weston_output, etc)
opaque.
Add function weston_compositor_add_log_scope(), so non-core
users are able to pass weston_compositor as argument instead
of weston_compositor::weston_log_ctx.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Fixes missing prototypes compilation warnings emitted when a function
is defined before its prototype is declared.
These warnings were introduced over time since the switch to meson
because the -Wmissing-protoypes was not included in the compilation
arguments.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
weston_environment_get_fd was declared in weston-launch and implemented
in compositor.c. Since the function is not used elsewhere in the code,
it is replaced by a static function in launcher-weston-launch.c
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Just a couple of places which shouldn't be possible, so initialized and
added assertions to make sure.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Also, bump libweston_major to 9.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_seat_init_keyboard makes sure that it has its
own reference to keymap, hence we can safely drop our reference.
This is similarly done in the X11 backend. It avoids leaking a
struct xkb_keymap per connection.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Instead of allocating our own copy of struct xkb_context use the
compositor wide instance. This avoids leaking of a struct
xkb_context per connection as well.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Properly disconnect and free all RDP peers on compositor shutdown.
This makes sure that all events are disabled, which should avoid
any race conditions with pending events.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The RDP-backend is reporting a non-zero physical size
value, and there are some clients that get the resolution
in pixels directly from the physical size reported. This
leads to a resolution of 25.4 PPI (or 1px/1mm), which is too
small.
But there's no need for that. The physical size is reported
on enabling the output (in the case of RDP-backend we have
no information about it before this), and the resolution is
already set in this moment.
Report a zero physical size to compositor, what makes frontend
and clients use their default values and applications become
readable.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The aspect ratio definitions for 64:27 and 256:135 have been added with
libdrm 2.4.95. However, Weston currently depends on libdrm 2.4.89 or
higher. Define the definitions in Weston to support libdrm older than
2.4.95.
Fixes: #332
Fixes: 6093772f45 ("backend-drm: Use aspect-ratio bit definitions from libdrm")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Commit adaf8c7410 ("renderer: change frame_signal emission to pass
previous_damage as data argument") missed updating all frame_signal
emissions. Later commit 2619bfe420 ("move frame_signal emission to
weston_output_repaint()") fixed this deficency along with moving the
location of the emission. Due to an issue of the location change, this
commit had to be reverted again.
This makes sure that the pixman as well as the GL renderer now also
emits the damage region instead of the Weston output.
Fixes: adaf8c7410 ("renderer: change frame_signal emission to pass previous_damage as data argument")
Signed-off-by: Stefan Agner <stefan@agner.ch>
The member previous_damage from struct weston_output is no longer necessary.
First, stop calling init, fini and copying output_damage to it. Then remove
it from struct weston_output.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The emission of frame_signal has to happen before a flip, otherwise
glReadPixels() could read an old frame or even worse an uninitialized buffer.
So move frame_signal emission back to renderers.
This reverts commit 2619bfe420.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
When the aspect-ratio-aware mode support was added to Weston, it was
done before the libdrm support was finalised and merged. Between it
being added to Weston and being merged, it changed to no longer provide
the offset for the bitmask.
Instead of using the mask and a compatible enum, if we update our
libdrm dependency, we can use the flag definitions directly from libdrm.
In 94e4068ba1, the libdrm dependency was bumped to 2.4.83, which
enabled us to remove a bunch of error-prone ifdefs by making atomic and
modifier support mandatory.
We determined in the discussion of !311 that it was safe to push the
dependency as high as 2.4.91, as that was what was available in major
distributions.
Bumping to 2.4.86 allows us to safely remove the ifdef and go with
upstream flags, as that was added in mesa/drm@0d889201d106.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of getting previous_damage from the weston_output struct, get it from
the frame_signal data argument. This will make possible to remove
previous_damage from weston_output after we decide what to do with
output->previous_damage usage in DRM backend.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
This will make possible to users that are listening to frame_signal to get
previous_damage from the data parameter instead of using
output->previous_damage.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Instead of getting weston_output from the frame_signal argument 'void *data',
add weston_output in the private data struct of the users that are listening
to frame_signal. With this change we are able to pass previous_damage as the
data argument.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In order to remove duplication and make the code easier to follow, move
frame_signal emission from renderers to weston_output_repaint(). This should
have no observable effect.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Accept XYUV dmabuf buffers that a client application such as
weston-simple-dmabuf-v4l might submit.
v2 (Daniel):
Add XYUV to yuv_formats array to have the compositor color convert
with a shader if GL_TEXTURE_EXTERNAL_OES does not work.
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Instead of using the EGL_*_WL macros imported from EGL headers,
start using enums that would be defined locally. This is needed as
there are limited number of macros defined in EGL headers and
adding new ones is not practically feasible when adding a new
texture type. (suggested by Daniel Stone)
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
contents of the flight recorder
The overlap variable is sufficient to determine from where to start
displaying the contents of the ring buffer. Also redundant to verify
if the position in the buffer went over the maximum size.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
created
Having a (single) global variable which others depend on it implies
having a single flight recorder present. Until we have a reason to
support multiple flight recorders limit the amount to a maximum of one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With it add also a function which can be used in an assert()-like
situation to display the contents of the ring buffer. Within gdb
this call also be called if the program is loaded/still loaded into
memory.
The global variable will be used in a later patch to be accessed from a
python gdb script.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Leandro Ribeiro
Pekka Paalanen
Daniel Stone
Stefan Agner
Guillaume Champagne
Scott Anderson
Emmanuel Gil Peyrot
Vivek Kasireddy
Marius Vlad