I want to consolidate 'struct drm_device' destruction into a single
function in the next patch, and that function needs to be usable for
both the primary device drm_backend::drm, and the secondary KMS devices
drm_backend::kms_list.
Sprites, a.k.a drm_planes, are objects fundamentally owned by their
drm_device. To encapsulate drm_device destruction into a single function
(that assumes that all outputs on that device are already destroyed),
one cannot call destroy_sprites() from drm_shutdown() anymore - it
logically belongs in drm_device_destroy().
The problem is that that will reverse the order of destroying drm_planes
vs. output (GBM) surfaces. drm_plane_state holds a reference to drm_fb
which points to a GBM BO that was received from a GBM surface. When the
GBM surface is destroyed, all its GBM BOs are destroyed as well, which
will cause all drm_fb pointing to them to be destroyed as well
regardless of drm_fb reference count. Therefore, if any object was
thought to hold a reference to a drm_fb, it now holds a dangling
pointer.
Why is drm_output_deinit() not clearing the drm_plane state it used,
releasing all the drm_fb references? And do that before destroying the
GBM surface?
Because drm_output_deinit_planes() explicitly skips clearing the
drm_plane state during compositor shutdown, because during shutdown the
drm_planes have already been destroyed.
If we change both, we get a much simpler tear-down logic:
- drm_output_deinit_planes() will always clear drm_plane states, no
special handling for shutdown (which is an elaborate way of saying
"before outputs are destroyed").
- drm_output_deinit() calls drm_output_deinit_planes() before it
destroys the GBM surface, which ensures no dangling drm_fb pointers
are left.
- destroy_sprites() call is moved *after* destruction of outputs where
it logically belongs.
This also means that the per-renderer fini functions do not need to
clean up manually when the compositor is not shutting down. They can
just assert the scanout_plane has already been cleaned up.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes it possible to use drm_device_create() from
drm_backend_create() in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
find_primary_gpu() and open_specific_drm_device() are modified to return
drm_kms_device instead of modifying fields inside the given drm_device.
Likewise, there is no need to pass the whole drm_backend in (which is
not fully initialized, maybe), but just the needed things.
This should make the code a little easier to follow.
Accidentally, this seems to fix a reference leak of udev_device in
drm_device_create(), because the udev_device is now tracked inside
drm_kms_device and properly unref'd. drm_backend_create() had the unref
that drm_device_create() missed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
find_primary_gpu() and open_specific_drm_device() are currently
returning the udev_device while modifying the passed in drm_device. To
stop the modification, these functions should return drm_kms_device
directly, but the udev_device is also needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
drm_device_is_kms() used to populate a few fields of the passed in
struct drm_device, releasing old values. This was inconvenient, because
one must allocate struct drm_device first, then call drm_device_kms() in
a loop, and finally end up with only some fields of drm_device
populated, then continue to populate it more.
The new function drm_kms_device_create() will malloc a new struct
drm_kms_device every time. RAII. No need to populate and re-populate the
same fields in drm_device until the right KMS device is found.
One can no longer check the fd >= 0 for device validity, now one checks
if kms_device is not NULL.
The fd_owner field is added because it would be inconvenient to pass in
the launcher to the destroy function. It's cleaner to save it, make sure
the right one used for releasing an fd (as if we had multiple launcher
instances, haa haa). Can't release it properly without the launcher.
This is just a minor step to facilitate more refactoring.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This gives the anonymous struct at struct drm_device::drm a name.
drm_device::drm is renamed to kms_device, which I think is a better
name, lacking an even better one.
The type of kms_device field is changed into a pointer, so that struct
drm_kms_device could be created and destroyed separately from struct
drm_device. Actually implementing this is left for the next patch, and
here the pointer is temporarily initialized with
device->kms_device = &device->kms_device_allocd;
Changing the name and type causes tons of trivial changes all over the
DRM-backend. This patch does only that, and the next patch will be more
interesting.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
There are failure paths here that may return without resetting the
variables, leaving dangling pointers behind.
Make sure there cannot be dangling pointers.
Found by manual code review.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
drm_gbm_dmabuf was the type allocated, so that is the type that should
be freed, too.
This was only a semantical bug. It did work before because 'base' was
the first member of struct drm_gbm_dmabuf and therefore the two pointers
were identical.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Having the options printed in addition to the layout and variant is
essential to trace how keyboard assignments ended up as they did.
Signed-off-by: Roland Kaufmann <rlndkfmn+freerdp@gmail.com>
The structure that convert_rdp_keyboard_to_xkb_rule_names fills is
next sent as argument to xkb_keymap_new_from_names, which constructs
the complete keymap.
Signed-off-by: Roland Kaufmann <rlndkfmn+freerdp@gmail.com>
Initially just allocate an extra data field and initialize this to
zero (meaning no particular options) for all keybords in the mapping
table.
Signed-off-by: Roland Kaufmann <rlndkfmn+freerdp@gmail.com>
The X Keyboard Extension (XKB) allows layout to be specified
modularly, combining several layers to compose a complete map of
keycodes to keysyms. Typically the main section of the keyboard is
specified with a 'layout' family further refined with a 'variant',
whereas aspects that are orthogonal to the letter bindings, such as
for instance AltGr behaviour, are specified through 'options'.
On Windows, the layout is identified with a double-word where the
lower word is the language, roughly equivalent to the 'layout' in XKB,
and the upper word corresponds to the 'variant'. The identifier
completely describes the layout to be loaded, as each identifier has
an entry in the Registry that points to a system library containing
all the mappings.
RDP, originating from Windows, thus describes the keyboard layout of
the display server with such an ID, although more than just a base
layout and a variant may be needed in XKB to describe a true
equivalent layout.
This changeset contains a set of patches that adds the possibility of
an option string to be attached to each supported RDP keyboard
identifier, which will also be applied when setting up keyboard
through the RDP backend. Using such options, true layout fidelity can
be achieved between the client and server without having the user to
do additional configuration.
(This changeset only provide the means for such fidelity, it does not
aim to setup appropriate options for all the keyboard layouts).
Impact on current users is considered to be small: Any users that rely
on the a different layout than specified through the RDP identifier,
most likely through FreeRDP from another *nix system, are probably
specifying those explicitly already, or could not unreasonably be
required to do so.
Signed-off-by: Roland Kaufmann <rlndkfmn+freerdp@gmail.com>
And rename for consistency with other Markdown files.
This re-order the sections to include a mention about using the glab
client and the fact that you need to be authenticated prior to
doing a release.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
weston-test-client-helper.h includes all these generated header files. I
could not figure out what might guarantee that these headers are
generated before compiling anything that includes
weston-test-client-helper.h, maybe we are simply lucky. I could not make
the build fail by building a single test program from a clean builddir.
Yet, this seems like the right thing to do.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
There is no need to special-case this generated header in foreach-tests
if we list it as an order-only dependency implied by dep_test_client.
The viewporter header is already there.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
xdg-client-helper is already built into the dep_test_client library,
there is no need to add the sources again.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A minor simplification to tests/meson.build. The disabler object
prevents the test from being built or run.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It was getting difficult to see which files were part of the test
harness and which were actual tests. Moving the harness sources into a
subdirectory helps to see at a glance what is what, and will allow using
shorter file names in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
weston_output_init() should be setting all members to a default value,
it can't assume anything is already 0.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Since commit "xdg-shell: handle xdg_wm_base being destroyed before its
children", we raise a protocol error DEFUNCT_SURFACES for misbehaved
clients.
This adds a test to ensure that DEFUNCT_SURFACES is being posted for
such clients.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There's no need to use the desktop-shell if the purpose of these tests
is to test our xdg-shell implementation.
In the next commits it will be important to have a simpler shell to
work with, as we'll introduce additional tests for xdg-shell that
trigger leaks that are hard to fix with the desktop-shell.
So let's change this test file to use SHELL_TEST_DESKTOP.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Functions that implement the xdg_surface, toplevel and popup
interfaces may depend on struct weston_desktop_client::resource.
In normal circumstances, this resource can't be NULL. The xdg protocol
extension forbids destroying xdg_wm_base before destroying all its child
surfaces. If that happens, we disconnect the client with protocol error
DEFUNCT_SURFACES (see commit "xdg-shell: handle xdg_wm_base being
destroyed before its children").
But during client teardown resources are destroyed in arbitrary order,
so it is possible that client resource becomes NULL before its surfaces
are destroyed.
This commit adds checks to avoid using NULL client resource, in order to
avoid crashes. It is safe to silently do nothing in these cases, as the
client is being destroyed anyway.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently if weston_desktop_surface_add_resource() fails to create a
wl_resource, it disconnects the client and destroys the desktop surface
that we pass.
It is odd to do that, callers should be responsible for destroying the
desktop surface when it is reasonable to do so. This is dangerous and
can leave dangling pointers.
Besides that, in many cases callers should not even destroy the desktop
surface, as they are not the owners of it. When we are giving the role
of toplevel/popup to a xdg_surface and we fail to do so, client gets
disconnected and the base desktop surface will get destroyed by the
destructor of the xdg_surface resource.
This commit fixes these issues, bringing a more consistent behavior.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
According to the xdg-shell protocol specification, if the xdg_wm_base
object is destroyed while there are still xdg_surface objects associated
with it, the compositor must post a protocol error (DEFUNCT_SURFACES) to
the client. In this patch we do that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This signal is never emitted when touch focus changes. In this patch we
start emitting it, allowing listeners to react to touch focus changes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We can get this right from the plane state/paint node now, so let's do
that and get rid of a bunch of crufty stuff.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Right now, any non-renderer plane only has a single paint node on it. It
can be useful to know what paint node that was after the damage flush.
This will be used shortly to simplify cursor handling in the drm backend.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I found it confusing to read:
[view] view 3-2-1 will be placed on the renderer: no color transform
The view definitely has a color transform. What this means is:
[view] view 3-2-1 will be placed on the renderer: cannot off-load color transform
I hope that's more clear.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The scene-graph debug already uses these names, and they are much more
human-friendly to read than memory addresses.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Makes the print-out a little bit tidier. Passing NULL for "%s" is
handled by glibc gracefully, but I'm not sure what standard requires it
if any.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have a consistent and more human-friendly name for views. Use it
instead of pointer values, view_idx, and protocol object ID. This makes
the scene-graph print more readable.
I presume the view_idx was just an ad hoc human-readable addressing for
views. It was stable only as long as the scene-graph didn't change. The
view internal_name is always stable and unique.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Views did not have any identification of their own, except the memory
address "%p" (not human-readable) and very likely assumption that a
surface would have only one view (but we support multiple views).
For trace and debug print purposes, give views nice names like we just
added for surfaces. The owning surface is apparent from the view name.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
So far we have had two ways of identifying a weston_surface: by its
memory address "%p", and by its get_label function. The memory address
is not human-friendly and can get recycled. get_label() is not unique,
and in some cases it is client-controllable.
Oh, we also have the protocol object ID, but that does not exist for
internally created weston_surfaces.
We also have weston_surface::s_id, damage_track_id and flow_id. These
are used by some Perfetto instrumentation. s_id comes from a
compositor-wide counter rather than per-client counter, the others are
probably not what I'm looking for.
None of these are really nice for trace and debug prints for identifying
surfaces for human reading. Therefore, let's add one more ID, and with
it, a nice name for each surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds the framework to track clients with custom data. The first use
is to associate an ID with each client. The ID is much better suited for
debug printing than a pointer value.
The string representation is stored so that it can be overridden if
desired for compositor forked clients like Xwayland or shell helpers.
Change to a struct in the public header forces a major version bump for
this development cycle.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is a basic implementation. First the input parametric profile's
transfer function is decoded, and a HDR-aware luminance mapping into a
[0, 1] relative SDR luminance expected by the ICC workflow is done.
Then, a shaper+matrix ICC profile is crafted with the primaries, white
point and black point of the input profile. That is connected with the
output ICC profile similar to init_icc_to_icc_chain(). LittleCMS handles
the rendering intents.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
