Usually there should be at least one input device, when Weston starts
up, or is reactivated by a VT switch. Add a nice warning, in case there
are no input devices.
This is to give a clue to users who happen to try Weston on DRM, and
do not get any response.
Add also a message to another failure case, that may lead to missing
input devices.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Weston initialises to faded-out state, which means all outputs are just
black, even if they render fine.
Previously the fade-in was triggered probably by some random input
event, since Weston was not guaranteed to wake up. Especially with the
drm backend, and the usual problem of not having permissions to input
devices, Weston would not fade in at all and appear broken.
Force Weston to fade in right after initialisation. This show that at
least rendering works, if it does not respond to any input.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We have to deal with the data source going away. Even if we have a
reference to the server side data source, we can't do anything if the
client that provided the source went away. So just NULL the offers
source pointer in the destroy callback for the source.
This collided with the big weston rename, but git did a good job of fixing
most cases.
Conflicts:
compositor/compositor.h
src/compositor-x11.c
src/compositor.c
src/screenshooter.c
src/util.c
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
Free many things we were leaking before:
- input device
- EGL resources
- xcb event source
- X Display
Fixes lots of Valgrind leaks.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Nothing was freeing the allocation from screenshooter_create().
Add enough boilerplate, that we can free it. Fixes a Valgrind leak.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The two pixman regions of struct wlsc_surface were not being freed
properly.
Fixes some Valgrind errors.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a function for destroying all objects allocated in
wlsc_input_device_init().
This patch depends on "server: add wl_input_device_fini()" commit in the
Wayland core.
Compositor backends could now call wlsc_input_device_fini() to fix some
memory leaks.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Free idle_source, shm, and vertices and indices arrays on compositor
shutdown.
Fixes some Valgrind errors.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
After the compositor exits the main loop in wl_display_run(), set the
compositor state to SLEEPING. This prevents scheduling repaints, that
will never be executed.
A repaint is scheduled by calling wl_event_loop_add_idle(), which
creates an idle event source. Normally the idle event source object is
destroyed after it has been executed. However, in the shutdown case we
never dispatch events again, and the object is leaked.
This leak is triggered by shell.c destructor, which destroys the
desktop-shell client. Destroying a client ends up calling
wlsc_compositor_schedule_repaint() while destroying the client
resources, especially surfaces.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
If the compositor is shutting down while the desktop_shell still exists,
we leaked some resources by not destroying the client record.
Call wl_client_destroy() on the desktop_shell client, if it exists
during shutdown. Fixes some Valgrind errors.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
wlsc_binding_destroy() was not being called at all. Fix the leaks by
introducing a function that destroys a whole list of bindings, instead
of individually saving an extra pointer to the binding object and
calling wlsc_binding_destroy() separately on each.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Some of the local pixman region objects were not being properly
destroyed before returning from the function. Destroy them, fixes
some Valgrind errors.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new wlsc_shell API function for destroying the shell plugin
object. Helps to reduce Valgrind reports.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This is the other direction. The selection bridge will grab the X11
CLIPBOARD selection on behalf of the Wayland client when it sets the
Wayland selection. Right now only UTF-8 text is supported, but the
data types offered will be taken from the Wayland data source.
We need to store all touchpoint positions so that if we just get an
ABS_MT_POSITION_X or Y event, we can pull the other coordinate from the
cache. And we need this across invocations of evdev_input_device_data(),
so the accumulator approach doesn't work.
Instead, we go back to the approach of storing all this state in the
evdev device struct and we might as well just move the rel and abs state
there too.
Kristian Høgsberg