By default the server will dump protocol for both the server and its
clients when run with WAYLAND_DEBUG=1. That's still the case, but it now
also understands WAYLAND_DEBUG=client or WAYLAND_DEBUG=server, which
will only enable debug dumping on either client or server side.
Touch grabs allow the compositor to be placed into a mode where touch events
temporarily bypass their default behavior and perform other operations.
Wayland already supports keyboard and pointer grabs, but was lacking
corresponding touch support. The default touch grab handlers here contain the
client event delivery code that was previously called directly in weston.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
On the client side where we queue up multiple events before dispatching, we
need to look up the receiving proxy and argument proxies immediately before
calling the handler. Between queueing up multiple events and eventually
invoking the handler, previous handlers may have destroyed some of the
proxies.
The only way to make the global object listener interface thread safe is to
make it its own interface and make different listeners different wl_proxies.
The core of the problem is the callback we do when a global show up or
disappears, which we can't do with a lock held. On the other hand we can't
iterate the global list or the listener list without a lock held as new
globals or listeners may come and go during the iteration.
Making a copy of the list under the lock and then iterating after dropping
the lock wont work either. In case of the listener list, once we drop the
lock another thread may unregister a listener and destroy the callbackk
data, which means that when we eventually call that listener we'll pass it
free memory and break everything.
We did already solve the thread-safe callback problem, however. It's what
we do for all protocol events. So we can just make the global registry
functionality its own new interface and give each thread its own proxy.
That way, the thread will do its own callbacks (with no locks held) and
destroy the proxy when it's no longer interested in wl_registry events.
The update callback for the file descriptors was always a bit awkward and
un-intuitive. The idea was that whenever the protocol code needed to
write data to the fd it would call the 'update' function. This function
would adjust the mainloop so that it polls for POLLOUT on the fd so we
can eventually flush the data to the socket.
The problem is that in multi-threaded applications, any thread can issue
a request, which writes data to the output buffer and thus triggers the
update callback. Thus, we'll be calling out with the display mutex
held and may call from any thread.
The solution is to eliminate the udpate callback and just require that
the application or server flushes all connection buffers before blocking.
This turns out to be a simpler API, although we now require clients to
deal with EAGAIN and non-blocking writes. It also saves a few syscalls,
since the socket will be writable most of the time and most writes will
complete, so we avoid changing epoll to poll for POLLOUT, then write and
then change it back for each write.
wl_client_add_resource() used to return no error even though the new
resource wasn't added to the client. This currently makes it very easy to
DOS weston by simply posting thousands of "create_surface" requests with
an invalid ID. Weston simply assumes the wl_client_add_resource() request
succeeds but will never destroy the surface again as the "destroy" signal
is never called (because the surface isn't linked into the wl_map).
This change makes wl_client_add_resource() return the new ID of the added
object and 0 on failure. Servers (like weston) can now correctly
immediately destroy the surface when this call fails instead of leaving
the surface around and producing memory-leaks.
Instead of returning -1 on failure and 0 on success, I made it return the
new ID as this seems more appropriate. We can directly use it when calling
it with new_id==0.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Creation of new client resources was silently ignored when
wl_client_add_resource() was used on server side and new object id was out
of range.
An error is now send out to the client in such case.
Also changed error message in wl_client_add_object, since
wl_map_insert_at() returns -1 only at invalid new id.
This makes wl_seat_set_keyboard similar to wl_seat_set_pointer in that
it's a no-op, if you try to set keyboard to NULL when it already is
NULL, instead of refusing to set it to NULL ever.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Attempting to write anything longer into the embedded char
array would create a non-null-terminated string, and all
later reads would run off the end into invalid memory.
This is a hard limitation of AF_LOCAL/AF_UNIX sockets.
Always unlink() the lock file before closing the file
descriptor for it. Otherwise, there is a race like this:
Process A closes fd, releasing the lock
Process B opens the same file, taking the lock
Process A unlinks the lock file
Process C opens the same file, which now no longer exists,
and takes the lock on the newly created lock file
Process B and C both 'own' the same display socket.
unlink()ing while holding the lock is effectively a better
way to release the lock atomically.
When the server send a new object ID, the client used to have to allocate
the proxy manually and without type-safety. We now allocate the proxy
in a client-side post-processing step on the incoming closure.
Provide a slot for keyboard modifier state inside wl_keyboard for
implementations to update, and use this to send wl_keyboard:;modifier
events whenever the keyboard or pointer focus changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This event sends the current keyboard modifier/group state from the
compositor to the client, allowing all clients to have a consistent view
of the keyboard state (e.g. current layout, Caps Lock, et al). It
should be sent after a keyboard enter event, and also immediately after
any key event which changes the modifier state.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If wl_pointer_set_focus or wl_keyboard_set_focus have been called before
a listener has been established for that seat and client combination,
the focus window will be set but the focus resource will be NULL. This
changes these functions to always attempt to search for the relevant
focus resource, allowing the resource to be set by calling
wl_keyboard_set_focus and wl_pointer_set_focus again when a listener has
been established.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The core libwayland libraries should not handle logging, only passing
the error messages to subscribed functions.
An application linked to libwayland-server or libwayland-client
will be able to set own functions (one per library) to handle error
messages.
Change in this series: make the wl_log return int, because
of compatibility with printf. It will return the number of bytes logged.
This ends up propagating through and creating a valgrind error like:
==22573== Conditional jump or move depends on uninitialised value(s)
==22573== at 0x409E57: pointer_attach (compositor.c:1999)
==22573== by 0x34ECE05D63: ffi_call_unix64 (unix64.S:75)
==22573== by 0x34ECE05784: ffi_call (ffi64.c:486)
==22573== by 0x5674C45: wl_closure_invoke (connection.c:770)
==22573== by 0x566ECCB: wl_client_connection_data (wayland-server.c:255)
==22573== by 0x56722F1: wl_event_source_fd_dispatch (event-loop.c:79)
==22573== by 0x5672C91: wl_event_loop_dispatch (event-loop.c:410)
==22573== by 0x56705F4: wl_display_run (wayland-server.c:1003)
==22573== by 0x40C775: main (compositor.c:2937)
wl_input_device has been both renamed and split. wl_seat is now a
virtual object representing a group of logically related input devices
with related focus.
It now only generates one event: to let clients know that it has new
capabilities. It takes requests which hand back objects for the
wl_pointer, wl_keyboard and wl_touch interfaces it exposes which all
provide the old input interface, just under different names.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some system C libraries do not have SOCK_CLOEXEC, and completely miss
accept4(), too. Provide a fallback for this case.
This changes the behaviour: no error messages are printed now for
failing to set CLOEXEC but the file descriptor is closed.
The unit test for this wrapper is NOT included.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Some system C libraries do not offer SOCK_CLOEXEC flag.
Add a new header for OS compatibility wrappers. Wrap socket() calls into
wl_os_socket_cloexec() which makes sure the O_CLOEXEC flag gets set on
the file descriptor.
On systems having SOCK_CLOEXEC this uses the old socket() call, and
falls back if it fails due to the flag (kernel not supporting it).
wayland-os.h is private and not exported.
Add close-on-exec tests for both normal and forced fallback paths.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
wl_input_device::grab_button is unsigned but the button parameter to
wl_grab_interface::button is signed. This lead to a warning in
data-device.c.
The button number is unsigned in the protocol, so make it unsigned in
the wl_grab_interface API, too. Fixes the compiler warning "comparison
between signed and unsigned integer expressions".
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The variables opcode and size were unsigned, which lead to warnings
about comparisons of signed vs. unsigned.
Change these variable to signed. Their usage never relies on being
unsigned.
This also fixes (an assumed) printf format string problem, where these
were printed with %d, not %u.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
These were not bugs in practice, because the first (and only) field of
struct wl_surface is struct wl_resource.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
