1. 16 Apr, 2020 1 commit
  2. 04 Feb, 2020 1 commit
  3. 15 Jan, 2020 1 commit
  4. 10 Jan, 2020 1 commit
  5. 06 Nov, 2019 1 commit
    • Joshua Watt's avatar
      Move wl_priv_signal to wayland-server-private.h · e7d88f35
      Joshua Watt authored
      
      
      Including wayland-server-core.h in wayland-private.h is problematic
      because wayland-private.h is included by wayland-scanner which should be
      able to build against non-POSIX platforms (e.g. MinGW). The only reason
      that wayland-server-core.h was included in wayland-private.h was for the
      wl_private_signal definitions, so move those to a
      wayland-server-private.h file that can be included by both
      wayland-server.c and the tests.
      Signed-off-by: Joshua Watt's avatarJoshua Watt <JPEWhacker@gmail.com>
      e7d88f35
  6. 17 Sep, 2019 1 commit
  7. 29 Jul, 2019 1 commit
    • Jonas Ådahl's avatar
      proxy: Add API to tag proxy objects · 493ab79b
      Jonas Ådahl authored
      
      
      When an application and a toolkit share the same Wayland connection,
      it will receive events with each others objects. For example if the
      toolkit manages a set of surfaces, and the application another set, if
      both the toolkit and application listen to pointer focus events,
      they'll receive focus events for each others surfaces.
      
      In order for the toolkit and application layers to identify whether a
      surface is managed by itself or not, it cannot only rely on retrieving
      the proxy user data, without going through all it's own proxy objects
      finding whether it's one of them.
      
      By adding the ability to "tag" a proxy object, the toolkit and
      application can use the tag to identify what the user data pointer
      points to something known.
      
      To create a tag, the recommended way is to define a statically allocated
      constant char array containing some descriptive string. The tag will be
      the pointer to the non-const pointer to the beginning of the array.
      
      For example, to identify whether a focus event is for a surface managed
      by the code in question:
      
      	static const char *my_tag = "my tag";
      
      	static void
      	pointer_enter(void *data,
      		      struct wl_pointer *wl_pointer,
      		      uint32_t serial,
      		      struct wl_surface *surface,
      		      wl_fixed_t surface_x,
      		      wl_fixed_t surface_y)
      	{
      		struct window *window;
      		const char * const *tag;
      
      		tag = wl_proxy_get_tag((struct wl_proxy *) surface);
      
      		if (tag != &my_tag)
      			return;
      
      		window = wl_surface_get_user_data(surface);
      
      		...
      	}
      
      	...
      
      	static void
      	init_window_surface(struct window *window)
      	{
      		struct wl_surface *surface;
      
      		surface = wl_compositor_create_surface(compositor);
      		wl_surface_set_user_data(surface, window);
      		wl_proxy_set_tag((struct wl_proxy *) surface,
      				 &my_tag);
      	}
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      493ab79b
  8. 31 May, 2019 1 commit
    • orbea's avatar
      Add a missing -pthread to fix compile with slibtool. · 2485a5c2
      orbea authored
      When compiling wayland with slibtool instead of GNU libtool
      it will fail building libtest_runner with an undefined
      reference to pthread_join@@GLIBC_2.2.5. This is because
      -pthread (Or -lpthread) is missing from display_test. If its
      added the build succeeds as expected with slibtool and
      continues to work with libtool. Its likely that libtool is
      hiding this failure by silently adding the missing flag which
      is not uncommon...
      
      Exposed in commit aa51a833.
      
      Fixes #91
      
      Signed-off-by: orbea's avatarorbea <orbea@riseup.net>
      2485a5c2
  9. 02 May, 2019 1 commit
  10. 06 Apr, 2019 1 commit
  11. 25 Feb, 2019 1 commit
    • Leonid Bobrov via wayland-devel's avatar
      tests: fix main symbol duplication · c70fd8a8
      Leonid Bobrov via wayland-devel authored
      
      
      So far I got these errors before patching:
      
      libtool: link: cc -o .libs/headers-test -pthread -Wall -Wextra -Wno-unused-parameter -g -Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden -O2 -pipe tests/headers-test.o tests/headers-protocol-test.o tests/headers-protocol-core-test.o /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a -L.libs -lwayland-client -lffi -lm -lwayland-server -lkvm -Wl,-rpath-link,/usr/local/lib
      ld: error: duplicate symbol: main
      >>> defined at headers-test.c:53 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/headers-test.c:53)
      >>>            tests/headers-test.o:(main)
      >>> defined at test-runner.c:377 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/test-runner.c:377)
      >>>            test-runner.o:(.text+0x250) in archive /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a
      
      libtool: link: cc -o .libs/exec-fd-leak-checker -pthread -Wall -Wextra -Wno-unused-parameter -g -Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden -O2 -pipe tests/exec-fd-leak-checker.o /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a -L.libs -lwayland-client -lffi -lm -lwayland-server -lkvm -Wl,-rpath-link,/usr/local/lib
      ld: error: duplicate symbol: main
      >>> defined at exec-fd-leak-checker.c:57 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/exec-fd-leak-checker.c:57)
      >>>            tests/exec-fd-leak-checker.o:(main)
      >>> defined at test-runner.c:377 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/test-runner.c:377)
      >>>            test-runner.o:(.text+0x250) in archive /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a
      
      Makefile.am: error: object 'tests/test-helpers.$(OBJEXT)' created both with libtool and without
      
      libtool: link: cc -o .libs/fixed-benchmark -pthread -Wall -Wextra -Wno-unused-parameter -g -Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden -O2 -pipe tests/fixed-benchmark.o /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a -L.libs -lwayland-client -lffi -lm -lwayland-server -lkvm -Wl,-rpath-link,/usr/local/lib
      ld: error: duplicate symbol: main
      >>> defined at fixed-benchmark.c:100 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/fixed-benchmark.c:100)
      >>>            tests/fixed-benchmark.o:(main)
      >>> defined at test-runner.c:377 (/tmp/obj/wayland-1.16.0/wayland-1.16.0/tests/test-runner.c:377)
      >>>            test-runner.o:(.text+0x250) in archive /tmp/obj/wayland-1.16.0/build-amd64/.libs/libtest-runner.a
      
      This commit fixes all of that.
      Signed-off-by: Leonid Bobrov's avatarLeonid Bobrov <mazocomp@disroot.org>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      c70fd8a8
  12. 14 Jun, 2018 1 commit
  13. 19 Mar, 2018 2 commits
  14. 22 Feb, 2018 2 commits
  15. 09 Feb, 2018 3 commits
  16. 19 Jan, 2018 1 commit
  17. 09 Jan, 2018 1 commit
  18. 18 Sep, 2017 1 commit
  19. 18 Aug, 2017 1 commit
  20. 25 Jan, 2017 1 commit
  21. 23 Nov, 2016 1 commit
    • Pekka Paalanen's avatar
      tests: add scanner tests · c9f64544
      Pekka Paalanen authored
      Add tests that ensure that wayland-scanner output for a given input does
      not change unexpectedly. This makes it very easy to review
      wayland-scanner patches.
      
      Before, when patches were proposed for wayland-scanner, I had to
      build wayland without the patches, save the generated files into a
      temporary directory, apply the patches, build again, and diff the old
      vs. new generated file.
      
      No more. Now whenever someone makes intentional changes to
      wayland-scanner's output, he will also have to patch the example output
      files to match. That means that reviewers see the diff of the generated
      files straight from the patch itself. Verifying the diff is true is as
      easy as 'make check'.
      
      The tests use separate example XML files instead of wayland.xml
      directly, so that wayland.xml can be updated without fixing scanner
      tests, avoiding the churn.
      
      example.xml starts as a copy of wayland.xml. If wayland.xml starts using
      new wayland-scanner features, they should be copied into example.xml
      again to be covered by the tests.
      
      This patch relies on the previous patch to actually add all the data
      files for input and reference output.
      
      The scanner output is fed through sed to remove parts that are allowed
      to vary: the scanner version string.
      
      v2: no need for scanner-test.sh to depend on the test data
      
      Task: https://phabricator.freedesktop.org/T3313
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk> (v1)
      Reviewed-by: default avatarYong Bakos <ybakos@humanoriented.com>
      Tested-by: default avatarYong Bakos <ybakos@humanoriented.com>
      c9f64544
  22. 18 Nov, 2016 1 commit
  23. 17 Nov, 2016 1 commit
  24. 16 Nov, 2016 1 commit
  25. 12 Aug, 2016 1 commit
  26. 11 Aug, 2016 1 commit
  27. 29 Feb, 2016 1 commit
  28. 17 Feb, 2016 2 commits
  29. 19 Nov, 2015 1 commit
  30. 17 Nov, 2015 2 commits
  31. 09 Oct, 2015 1 commit
  32. 23 Jul, 2015 1 commit
  33. 17 Jul, 2015 1 commit
    • Ross Burton's avatar
      build: always build wayland-scanner · 21f80b89
      Ross Burton authored
      
      
      The previous idiom for building a cross-compiled Wayland is to build once for
      the build host (with --enable-scanner --disable-libraries) to get a
      wayland-scanner binary that can then be used in a cross-compile (with
      --disable-scanner).  The problem with this is that the cross wayland is missing
      a wayland-scanner binary, which means you then can't do any Wayland development
      on the target.
      
      Instead, always build wayland-scanner for the target and change
      --enable/disable-scanner to --with/without-host-scanner.  Normal builds use the
      default of --without-host-scanner and run the wayland-scanner it just built, and
      cross-compiled builds pass --with-host-scanner to use a previously built host
      scanner but still get a wayland-scanner to install.
      
      (a theoretically neater solution would be to build two scanners if required (one
      to run and one to install), but automake makes this overly complicated)
      
      [daniels: Bikeshedded naming with Ross's OK.]
      Signed-off-by: default avatarRoss Burton <ross.burton@intel.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      21f80b89
  34. 23 Jun, 2015 1 commit