Calls into cairo-gles may change the current context, so it was only by
chance that sometimes we had the proper one as current and updated the
correct texture in surface_attach().
In order to fix this, calling display_acquire_window_surface() before
binding the texture for setup is necessary. However this call has the
side effect of allocating a cairo surface for the window. At flush time,
the existence of this surface will cause an eglSwapBuffers(), even
if no rendering was done to it, leading to undefined contents on the
screen. This happens when the idle redraw task runs while there is a
pending frame callback.
Workaround this by moving the texture setup from surface_attach() to the
redraw handler, so that the cairo surface is only allocated when
redering is done.
config.h includes were missing in a few files, including input.c, the
lack of which caused the X11 backend to segfault instantly due to not
having an xkbcommon context.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We go one utf8 char back and then one forward. Just remember the original
position instead, which also avoids a warning about potentially
dereferencing a NULL return value from next_utf8_char().
This allows a surface to live on after its resource has been
destroyed. The ref-count can be increased in a resource destroy signal
listener, to keep the surface around for a destroy animation, for example.
We don't handle them in any way now and having your steering wheel move
the cursor isn't useful. Applications can still open evdev devices and
access them directly like they already do.
This patch adds 3 new options to weston.ini to allow
the user to change default constant_accel_factor,
min_accel_factor and max_accel_factor. If no options
are set, it falls back using defaults as it did before.
v2: create weston_config_section_get_double and use it
instead of manualy converting string to double.
v3: add default values in weston_config_get_double
instead of using conditionals.
v4: don't pass diagonal as pointer.
Other clients of an evdev device need to have the events they receive
be separated, in moment in time, from other events by an EV_SYN/
SYN_REPORT. This is the responsibility of the client who writes events
into the stream.
Previously the configure script would silently disable the use of
accelerated cairo in the clients if cairo-gl could not be found (or
cairo-glesv2 if that was requested.) Conversely the use of cairo-gl
would be automatically enabled if it was found with no way to disable
that feature
This change adds --with-cairo which takes one of "image", "gl" or
"glesv2" (defaulting to "image"). If "gl" or "glesv2" is specified
cairo-egl is checked for as well as the specified renderer. If the check
fails then the configure process errors out.
cairo_egl_device_create(), which is called next,
already checks if EGL_KHR_surfaceless_context is
available. If not, it fallbacks to pbuffer.
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
This removes the use of wl_client_get_display() where the client is
derived from the focussed resource. This starts the removal of the
assumption of a single resource on a client that would be notified about
events on the focussed surface.
device->mt.slot is uninitialized when we're not receiving the
evdev slot events. Always use ID 0 as we do when we generate the
touch down and motion events.
The current code works if pw->pw_shell is bash because:
"If the shell is started with the effective user (group) id not equal to
the real user (group) id, and the -p option is not supplied, these actions
are taken and the effective user id is set to the real user id."
Thus, for bash, weston's EUID == UID.
For zsh, the -p option "is enabled automatically on startup if the effective
user (group) ID is not equal to the real user (group) ID."
Thus, weston's EUID = 0, and if pw_shell is zsh, /run/user/$UID/wayland-0 is
created with euid root and not writeable by the user, causing all clients to
fail.
Fix this by always dropping privileges to the user.
Regression introduced in 636156d.
For touchpads, device->dispatch is set up when exiting
evdev_handle_device() and a potential source for a memleak.
This can't actually happen at the moment, as evdev_handle_device() won't
fail for touchpads after setting up the dispatch but prevent this from
happening in the future.
If touches are already present on the device, absinfo has the currently
active touch slot. There's a race condition where the slot may change before
we enable the fd and we thus miss out on the ABS_MT_SLOT event. It's still
slightly more correct than assuming whatever comes next is slot 0.
For Protocol B devices, mtdev merely routes the events and is not needed.
For Protocol A devices, mtdev is needed, so fail for those devices now if we
mtdev fails.
Rusty Lynch