| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In the process wl_keyboard's version has been incremented. Given
clients get the wl_keyboard from wl_seat without a version, wl_seat's
version has also been incremented (wl_seat version 4 implies
wl_keyboard version 4).
|
|
Publican now adds a spurious "v" to the version output.
|
|
Because wkhtmltopdf requires a $DISPLAY, and a patched Qt.
https://bugzilla.redhat.com/show_bug.cgi?id=997682
|
|
One html page per chapter.
|
|
|
|
Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
|
|
|
|
|
|
|
|
Commit 99a72777f96f63e4e25dc528bb37115424adac59 introduced a new error
for when the 'since' version decreases. It also reset the version for
messages without a version to 1. Versioning semantics in the spec files
was a little under-specified and we don't want to break projects caught in
this grey zone.
This commits replaces previous configure.ac as the 1.4.93 tag and the
final 1.5 RC.
|
|
This is the last RC before 1.5.
|
|
The wayland-server-protocol.h and wayland-client-protocol.h headers are
currently being shipped in tarballs created using make dist. This causes
out-of-tree builds to fail since make will detect that the headers exist
by looking at the source directory (via VPATH) and not regenerate them.
But as opposed to ${top_builddir}/protocol, ${top_srcdir}/protocol is
not part of the include path and therefore the shipped files can't be
found during compilation.
Two solutions exist to this problem: 1) add ${top_srcdir}/protocol to
the include path to allow shipped files to be used if available or 2)
don't ship these generated files in release tarballs. The latter seems
the most appropriate. wayland-scanner is already a prerequisite in order
to generate wayland-protocol.c, so it is either built as part of the
package or provided externally. Generating all files from the protocol
definition at build time also ensures that they don't get out of sync.
Both of the generated headers are already listed in Makefile.am as
nodist_*_SOURCES, but at the same time they appear in include_HEADERS,
which will cause them to be added to the list of distributable files
after all. To prevent that, split them off into nodist_include_HEADERS.
Note that this problem will be hidden if a previous version of wayland
has been installed, since these files will exist in /usr/include and be
included from there. So this build error will only show for out-of-tree
builds on systems that don't have wayland installed yet.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
|
|
This could be useful for compositors who need to be able to not send
events if the client bound a version lower than the newest provided.
Event version numbers are exposed as
[INTERFACE_NAME]_[EVENT_NAME]_SINCE_VERSION for example wl_output.scale
will have the version macro WL_OUTPUT_SCALE_SINCE_VERSION.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Fail if a message with version implicitly set to 1 (i.e. not specified)
comes after a message with since-version > 1.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
The "release" message of wl_pointer, wl_keyboard and wl_touch introduced
in version 3 was placed first in the respective interface XML element,
causing wayland-scanner to misbehave and set the version number of the
"release" message to all subsequent messages with no explicitly specified
"since" version.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
|
|
If for some reason that errno is neither value (ENOMEM or
EINVAL), then prior to this patch, there would be a NULL
deref in wl_closure_lookup(...) at the "else if" conditional
when closure == NULL. Also, closure might not be NULL but still
fall into the block due to the wl_closure_lookup < 0 condition...
in that case, we need to destroy the closure to avoid a memory
leak.
Currently, wl_connection_demarshal only sets errno to ENOMEM
or EINVAL... we've already checked for ENOMEM so remove check
for EINVAL (just assume it). Also, call wl_closure_destroy(...)
unconditionally in the "else if" block (assume it can handle
NULL closure, too, which it does right now).
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
|
|
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
|
|
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
|
|
|
|
Use wl_log in the last few places where we print to stderr. Remove
logging in a couple of places where we properly return an error code.
https://bugs.freedesktop.org/show_bug.cgi?id=73339
|
|
This implements a simple fix for the blocking problem that occurs when
updating a timer event source after the timer expires, but before its
callback is dispatched. This can happen when another event happens during the
same epoll wakeup as the timer event, and causes the read() call in
wl_event_source_timer_dispatch() to block for the updated duration of the
timer.
We never want this read() call to block, so I believe it makes sense for the
timerfd to be non-blocking, and we simply ignore the case where the read fails
with EAGAIN. We still report all other errors as before, and still ignore the
actual value read from the socket.
With this change, the event_loop_timer_updates unit test case I submitted
previously now passes, and weston appears to work as before.
|
|
I've noticed a blocking problem in Wayland's event-loop code when updating
timer event sources. The problem occurs if you update the timer at a point
after is has expired, but before it has been dispatched, i.e. from an event
callback that happens during the same epoll wakeup.
When the timer is subsequently dispatched, wl_event_source_timer_dispatch
blocks for the duration of the new timeout in its call to read() from the
timer fd (which is the expected behaviour according to the man page for
timerfd_settime).
This isn't too uncommon a scenario - for example, a socket with an associated
timeout timer. You'd typically want to update the timer when reading from the
socket. This is how I noticed the issue, since I was setting a timeout of
1 minute, and saw my server blocking for this duration!
The following patch adds a (currently failing) test case to Wayland's
event-loop-test.c. It demonstrates the problem using two timers, which are
set to expire at the same time. The first timer to receive its expiry
callback updates the other timer with a much larger timeout, which then
causes the test to block for this timeout before calling the second timer's
callback.
As for a fix, I'm not so sure (which is why I thought I'd post the failing
test case first to show what I mean). I notice that it doesn't actually do
anything with the value read from the timerfd socket, which gives the number
of times the timer expired since the last read, or when the timer was last
updated (which blocks if the timer hasn't yet expired). I believe this value
should always read as 1 anyway, since we don't use periodic timers.
A simple fix would be to use the TFD_NONBLOCK option when creating the
timerfd, ensuring that the read call won't block. We'd then have to ignore
the case when the read returns EAGAIN.
|
|
|
|
If a message was too big to fit in the connection buffer, the code
in wl_buffer_put would just write past the end of it.
I haven't seen any real world use case that would trigger this bug, but
it was possible to trigger it by sending a long enough string to the
wl_data_source.offer request.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69267
|
|
|
|
Unused shm space will be automatically reclaimed if unused or can be
explicitly returned by using fallocate FALLOC_FL_PUNCH_HOLE.
https://bugs.freedesktop.org/show_bug.cgi?id=74632
|
|
Just sort the types and only print unique type names. We avoid using
the GCC pragma.
|
|
|
|
This encodes what everyone is doing and avoids other implementers
having to guess.
|
|
This patch adds some error management in wayland cursors
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
|
|
|
|
In order to set a logging function all the time, the output we get
needs to be useful. Logging about trivial things like the socket
we're using and when clients disconnect doesn't realy help anyone.
|
|
Solves this build error:
tests/fixed-benchmark.o: In function `benchmark':
./wayland/tests/fixed-benchmark.c:82: undefined reference to `clock_gettime'
./wayland/tests/fixed-benchmark.c:84: undefined reference to `clock_gettime'
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
|
|
"the callback event will arrive after the next output refresh" is wrong,
if you interpret "output refresh" as framebuffer flip or the moment when
the new pixels turn into light the first time. Weston has probably never
worked this way.
Weston triggers the frame callbacks when it submits repainting commands
to the GPU, which is before the framebuffer flip.
Strike the incorrect claim, and the rest of the paragraph which no
longer offers useful information.
As a replacement, expand on the "throttling and driving animations"
characteristic. The main purpose is to let clients animate at the
display refresh rate, while avoiding drawing frames that will never be
presented.
The new claim is that the server should give some time between
triggering frame callbacks and repainting itself, for clients to draw
and commit. This is somewhat intimate with the repaint scheduling
algorithm a compositor uses, but hopefully the right intention.
Another point of this update is to imply, that frame callbacks should
not be used to count compositor repaint cycles nor monitor refresh
cycles. It has never been guaranteed to work. Removing the mention of
frame callback without an attach hopefully discourages such use.
v2: Don't just remove a paragraph, but add useful information about the
request's intent.
v3: Specify the order of posting frame callbacks.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Axel Davy <axel.davy@ens.fr>
Cc: Jason Ekstrand <jason@jlekstrand.net>
|
|
Makes 'git status' clean again after a successful 'make distcheck'.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
|
|
I suppose the purpose was to print just one GEN line for each doxygen
rule being executed, not print the doxygen command.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
|
|
The doxygen.man make target was not a real file that was generated,
therefore the man page rule was ran on every make invocation. Replace it
with a real file that is produced by the man page rule.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
|
|
Fixes the build failure where the protocol headers were not generated at
all before compiling src/.libs/libwayland_server_la-wayland-server.o.
The failure was reproducable by starting fresh with 'git clean -dxf' and
not having any wayland headers installed system-wide.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
|
|
|
|
Fix up the references in include_HEADERS.
|
|
|
|
|
|
|
|
|
|
A small step towards non-recursive build system for wayland too.
|
