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>
This is a basic implementation. The input ICC profile is connected to a
shaper+matrix profile that uses the output primaries, white point, and
black point. This way LittleCMS applies the rendering intent. Then, we
manually add HDR-aware luminance mapping and the output electrical
encoding when necessary.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To see what is outside of the ICC-to-ICC pipeline, when falling back to
3D LUT for example. This will be particularly useful with
parametric<->icc color transformations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Set up the color transformer even when steps_valid.
There will be cases where the color transformation needs to be applied
on the CPU: solid color surfaces, renderer debug drawings, and
DRM-backend 3D LUT when it cannot realize the steps for some reason.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When parametric<->ICC color transformations are created in the future,
they need more than the icc_chain. Add the needed elements.
This path is used for the 3D LUT fallback when the steps in struct
weston_color_transform cannot be used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When parametric<->ICC color transformations are implemented, a single
cmsHTRANSFORM will not be enough for evaluating a color transformation.
At least one more curve and a matrix will be needed. This introduces the
structure to encapsulate them all. For now, we just wrap the existing
cmsHTRANSFORM.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
