The pointer seat->keyboard was set before some possible error returns.
That pointer was left unchanged in case of failure, pointing to an
uninitialized keyboard struct (that was also leaked). If a client sent
a wl_seat::get_keyboard request, that would cause Weston to crash.
Fix this by setting the seat->keyboard pointer only after the keymap
initialization is done and there is no more possibilities for failure.
Also plug the memory leaks on the error path.
https://bugs.freedesktop.org/show_bug.cgi?id=74035
The input region of the cursor surface is set to empty in
pointer_cursor_surface_configure(). Since during the commit process
this function is called before the pending input region is made
current, it empties surface->pending.input instead of surface->input.
But pointer_cursor_surface_configure() is also called from
pointer_set_cursor() in order to map the cursor even if there isn't a
subsequent attach and commit to the cursor surface. In that case,
surface->input is never emptied, since the configure function emptied
only the pending input region and there wasn't a commit that made it
effective.
Fix this by emptying both pending and current input regions. The latter
shouldn't cause problems since the surface can't have a role prior to
being assigned the cursor role, so it shouldn't be mapped in the first
place.
Also change toytoolkit so that it triggers the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73711
We rely on .git/logs/HEAD to be a file that changes when we commit to HEAD.
The first idea is to make the makefile rule depend on .git/HEAD, but that's
a symbolic ref that points to the current ref in refs/heads. However,
.git/logs/HEAD changes whenever we commit to HEAD, so we can use that in the
makefile rule.
This makes automake place the object files in the same subdir as the
source file. For a recursive build system as we have now, there's
no difference, but with a non-recursive build system it means that
the object files don't all end up in the toplevel directory.
Not doing this would leave a invalid list item in the view's destroy
signal listener list if destroying a seat that had previously lost
keyboard focus.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Fixes the following compiler warning:
simple-egl.c:434:36: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Adding this comment to explain the behavior:
This macro may not do what you expect. Weston doesn't guarantee any
stable API between 1.X and 1.Y, and thus this macro will return
FALSE on any WESTON_VERSION_AT_LEAST(1,X,0) if the actualy version
is 1.Y.0 and X !=Y). In particular, it fail if X < Y, that is,
1.3.0 is considered to not be "at least" 1.4.0.
If you want to test for the version number being 1.3.0 or above or
maybe in a range (eg 1.2.0 to 1.4.0), just use the WESTON_VERSION_*
defines above directly.
Version number testing is the one thing we can't break in the weston API,
so we'll have to settle for documenting the behavior and recommending
using the version number macros directly.
https://bugs.freedesktop.org/show_bug.cgi?id=74023
If we VT switch away between picking a cursor surface and actually doing
the pageflip in drm_output_repaint(), we never set output->cursor_view to
NULL. Then we unplug all the input devices and as the last pointer device
goes away we destroy the cursor surface. Then when we switch back, we
call drm_output_set_cursor() with an invalid surface and crashes.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73566
We have to move the surface destroy listener around as we track the
currently focused surface. Introduce a helper function,
focus_state_set_focus() for this and use throughout.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73768
Use the STAMP_SPACE to make the output mode logging
a little nicer looking.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
The API to use remoteFx encoding has changed between master and stable 1.1
branch. This patch should fix compilation for both.
This new version adds checks for the freerdp/version.h file
Assigning a string constant (i.e. memory that we didn't allocate)
to a char* pointer and then freeing that pointer is bad news.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
In frame_create, we need to destroy any frame buttons created
in preceding calls to frame_button_create during the function
execution if any of the successive calls to frame_button_create
fail.
This has minimal severity since most, if not all, cases in
frame_button_create that result in a fail (i.e. NULL result) means
a program is OOM and the program will have to exit/abort anyway.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Various functions that operate on a weston_surface assume the
surface has a shell_surface. That is, they unconditionally
deref the get_shell_surface() result. Hence, if for some reason
the call to get_shell_surface() returned NULL to those functions then
a segmentation fault would occur and the program would crash. So,
adding an assert(...) on the get_shell_surface() return value adds an
extra sanity check and does not change this behavior. The assert also
adds an extra benefit to the programmer by documenting that the function
expects and requires the weston_surface to have a shell_surface and
would be a program logic error, otherwise.
The assert() also silences some static analyzers about the possible
NULL deref.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
exposay_highlight_surface() is called from exposay_pick(),
exposay_layout(), and exposay_maybe_move() where the esurface
parameter is already validated prior to the call. This makes
the 'esurface' NULL check redundant. This assumes any future
calls to exposay_highlight_surface() will also validate the
'esurface' parameter prior to the call.
This fixes the logic in exposay_highlight_surface so static
analyzers don't complain about the possibility that 'view'
might be NULL deref'd when a 'esurface' == NULL condition is
true.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>