RE: Advertising supported Dmabuf modifiers of DRM device
Hi Daniel, IMO, entire point of having wayland surfaces and buffers to use them for display scanout. If an application does not want to display its rendered content, it can use surfaceless context or render to texture etc. Furthermore, we don’t have information in weston about content producing device. If an application wants to render with gpu, it should be responsibility of the application to query and use gpu friendly modifiers. We can provide them a list of scanout friendly modifiers which application can use. Then, application should choose a format which would work for rendering and scanout. Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: Daniel Stone [mailto:dan...@fooishbar.org] > Sent: Donnerstag, 26. Juli 2018 16:05 > To: Ucan, Emre (ADITG/ESB) > Cc: wayland > Subject: Re: Advertising supported Dmabuf modifiers of DRM device > > Hi Emre, > > On Thu, 26 Jul 2018 at 14:54, Ucan, Emre (ADITG/ESB) > wrote: > > We are currently querying supported modifiers only from gpu drivers via > EGL_EXT_image_dma_buf_modifiers extension. > > But we should also query and advertise modifiers which are supported by > DRM device. We are already getting this information via IN_FORMATS of a > drm plane. > > > > IMO, it is not enough to just query and advertise every supported format > and modifiers combination to applications. > > Applications can easily choose a format, which is only supported by GPU > device and not DRM device. In the end, this would force us to use gpu for > composition. > > We should mark modifiers of DRM device as preferred ones. This would > require modifying linux-dmabuf protocol. > > I agree; I've had the same thought. I think we want to do something > more nuanced than this though. > > Say for example the display controller only supports linear formats. > Doing a clear intersection would mean all clients rendering to linear > at a performance loss, even if they are not candidates for display > scanout. What we would want is a more dynamic hint from the > compositor: to tell clients to prefer scanout-compatible formats where > they are useful, but else to just pick the best GPU format. > > I think the best thing to do would be to make a new dmabuf interface > which takes a surface as a creation parameter, where the compositor > would update the per-surface interface with preferred modifiers. Since > we don't know preference order between modifiers, rather than > enforcing any order, the best thing to do would be to break it into > tranches: send one set of modifiers which are both GPU + scanout > compatible and ask the client to preferentially allocate from that > set, then send a second GPU-only set which the client may fall back to > if it cannot render to the first set. > > I don't have plans to work on that right now - I'd happily review any > patches or have a more detailed discussion though! - but as part of > the debug work I sent out last week, I am planning to expose the > current scanout status of surfaces to the core compositor. For > example, 'is on a plane now', vs. 'can never be on a plane because of > compositor configuration (transform/alpha/etc)' vs. 'could maybe be on > a plane but is not allowed (couldn't find suitable plane, kernel > rejected, etc)' vs. 'could be on a plane but client needs to change > (modifiers, transform, etc)'. That should be quite useful for this > work as well. > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v3 2/4] Add Meson build to Wayland
On Sat, Jul 21, 2018 at 04:31:22PM +0100, Daniel Stone wrote:
> From: Emmanuele Bassi
>
> Meson is a next generation build system, simpler than Autotools and,
> more importantly, faster and more portable. While the latter
> consideration is of lesser importance for Wayland, being easier to
> understand and faster are pretty much key reasons to switch.
>
> This is mostly a mechanical port of Wayland to the Meson build system.
>
> The goal is to maintain feature parity of the Meson build with the
> Autotools build, until such time when we can drop the latter.
>
> [daniels: Changed to bump version, use GitLab issues URL, remove header
> checks not used in any code, remove pre-pkg-config Expat
> support, added missing include paths to wayland-egl and
> cpp-compile-test, added GitLab CI.]
>
> Reviewed-by: Daniel Stone
> ---
> .gitlab-ci.yml | 24 +-
> cursor/meson.build | 30 +++
> doc/meson.build| 5 ++
> egl/meson.build| 45 ++
> meson.build| 94 +
> meson_options.txt | 20 +
> src/meson.build| 203 +
> tests/meson.build | 180
> 8 files changed, 599 insertions(+), 2 deletions(-)
> create mode 100644 cursor/meson.build
> create mode 100644 doc/meson.build
> create mode 100644 egl/meson.build
> create mode 100644 meson.build
> create mode 100644 meson_options.txt
> create mode 100644 src/meson.build
> create mode 100644 tests/meson.build
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 24896659..1d0018b1 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -9,10 +9,11 @@ before_script:
>- echo '#!/bin/sh' > /usr/sbin/policy-rc.d
>- echo 'exit 101' >> /usr/sbin/policy-rc.d
>- chmod +x /usr/sbin/policy-rc.d
> + - echo 'deb http://deb.debian.org/debian stretch-backports main' >>
> /etc/apt/sources.list
>- apt-get update
> - - apt-get -y --no-install-recommends install build-essential automake
> autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev doxygen
> graphviz xmlto xsltproc docbook-xsl
> + - apt-get -y --no-install-recommends install build-essential automake
> autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev doxygen
> graphviz xmlto xsltproc docbook-xsl meson/stretch-backports
>
> -build-native:
> +build-native-autotools:
>stage: build
>script:
>- export BUILD_ID="wayland-$CI_JOB_NAME_$CI_COMMIT_SHA-$CI_JOB_ID"
> @@ -34,3 +35,22 @@ build-native:
> - build-*/wayland*/_build/sub/*.log
> - build-*/*.log
> - prefix-*
> +
> +build-native-meson:
> + stage: build
> + script:
> + - export BUILD_ID="wayland-$CI_JOB_NAME_$CI_COMMIT_SHA-$CI_JOB_ID"
> + - export PREFIX="$(pwd)/prefix-$BUILD_ID"
> + - export BUILDDIR="$(pwd)/build-$BUILD_ID"
> + - export MAKEFLAGS="-j4"
> + - mkdir "$BUILDDIR" "$PREFIX"
> + - cd "$BUILDDIR"
> + - meson --prefix="$PREFIX" -Dicon_directory=/usr/share/X11/icons ..
> + - ninja -k0 test
> + - ninja clean
> + artifacts:
> +name: wayland-meson-$CI_COMMIT_SHA-$CI_JOB_ID
> +when: always
> +paths:
> +- build-meson/meson-logs
> +- prefix-*
> diff --git a/cursor/meson.build b/cursor/meson.build
> new file mode 100644
> index ..c8ed1aab
> --- /dev/null
> +++ b/cursor/meson.build
> @@ -0,0 +1,30 @@
> +icondir = get_option('icon_directory')
> +if icondir == ''
> + icondir = join_paths(get_option('prefix'), get_option('datadir'), 'icons')
> +endif
> +
> +wayland_cursor = library(
> + 'wayland-cursor',
> + sources: [
> +'wayland-cursor.c',
> +'os-compatibility.c',
> +'xcursor.c',
> + ],
> + version: '0.0.0',
> + dependencies: [ wayland_client_dep ],
> + c_args: [
> +'-DICONDIR="@0@"'.format(icondir),
> + ],
> + install: true,
> +)
> +
> +install_headers('wayland-cursor.h')
> +
> +pkgconfig.generate(
> + name: 'Wayland Cursor',
> + description: 'Wayland cursor helper library',
> + version: meson.project_version(),
> + libraries: wayland_cursor,
> + filebase: 'wayland-cursor',
> + install_dir: join_paths(get_option('prefix'), get_option('libdir'),
> 'pkgconfig'),
two things here: this is the default directory anyway so you could skip this
line. But if not, this is going to be annoying at some point, I recommend
defining a dir_pkgconfig variable once and re-using it. Same for the other
places where install_dir is defined.
same for wayland_client_protocol_core_h and friends, probably better to
fetch this once and then use the same variable everywhere.
Acked-by: Peter Hutterer for the series, but I
started glossing over with the doxygen bits :)
Cheers,
Peter
> +)
> diff --git a/doc/meson.build b/doc/meson.build
> new file mode 100644
> index ..8c743fe9
> --- /dev/null
> +++ b/doc/meson.build
> @@ -0,0 +1,5 @@
> +xsltproc = find_program('xsltproc', required: false)
> +doxygen = find_program('doxygen')
> +xmlto = find_program('xmlto')
Re: [PATCH wayland v3 1/4] Support running tests from different build directories
On Sat, Jul 21, 2018 at 04:31:21PM +0100, Daniel Stone wrote:
> From: Emmanuele Bassi
>
> The tests that run exec-fd-leak-checker expect the binary to be located
> in the current directory. This is not always the case; for instance, the
> binaries could be built under `tests`, but be invoked under the
> top-level build directory.
>
> We can use an environment variable to control what's the location of the
> test binaries, and fall back to the current directory if the variable is
> unset.
>
> Reviewed-by: Daniel Stone
> ---
> tests/test-helpers.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tests/test-helpers.c b/tests/test-helpers.c
> index b2189d8e..8ad332b1 100644
> --- a/tests/test-helpers.c
> +++ b/tests/test-helpers.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -67,11 +68,19 @@ count_open_fds(void)
> void
> exec_fd_leak_check(int nr_expected_fds)
> {
> - const char *exe = "./exec-fd-leak-checker";
> + const char *exe = "exec-fd-leak-checker";
> char number[16] = { 0 };
> +const char *test_build_dir = getenv("TEST_BUILD_DIR");
> +char exe_path[256] = { 0 };
> +
> +if (test_build_dir == NULL || test_build_dir[0] == 0) {
> +test_build_dir = ".";
> +}
> +
> +snprintf(exe_path, sizeof exe_path - 1, "%s/%s", test_build_dir,
> exe);
indentation switched to spaces instead of tabs here.
Cheers,
Peter
>
> snprintf(number, sizeof number - 1, "%d", nr_expected_fds);
> - execl(exe, exe, number, (char *)NULL);
> + execl(exe_path, exe, number, (char *)NULL);
> assert(0 && "execing fd leak checker failed");
> }
>
> --
> 2.17.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [writing a compositor] Compositor freezes when popup menu clicked
Any ideas?
The rest of my code can be found at:
https://github.com/adlocode/test-libweston-desktop
Regards
adlo
On Tue, 2018-07-17 at 09:21 +0100, adlo wrote:
> I am writing a compositor using libweston. I am attempting to
> implement raising windows on click. It mostly works, but it has
> introduced a regression where the compositor freezes when I click on
> a popup menu, such as those in gedit.
>
> Here is my code:
>
> static void click_to_activate_binding (struct weston_pointer
> *pointer,
>const struct timespec *time,
>uint32_t button,
>void *data)
> {
> struct TestServer *server = data;
> struct TestServerSurface *shsurf;
> struct weston_seat *s;
> struct weston_surface *main_surface;
>
> main_surface = weston_surface_get_main_surface (pointer->focus-
> >surface);
> shsurf = weston_desktop_surface_get_user_data
> (weston_surface_get_desktop_surface
> (main_surface));
> struct weston_surface *surface = weston_desktop_surface_get_surface
> (shsurf->desktop_surface);
>
> wl_list_for_each (s, &server->compositor->seat_list, link)
> {
> weston_view_activate (pointer->focus, s,
> WESTON_ACTIVATE_FLAG_CLICKED |
> WESTON_ACTIVATE_FLAG_CONFIGURE);
> weston_seat_set_keyboard_focus (s, pointer->focus->surface);
> weston_view_geometry_dirty (shsurf->view);
> weston_layer_entry_remove (&pointer->focus->layer_link);
> weston_layer_entry_insert (&server->surfaces_layer.view_list,
> &pointer->focus->layer_link);
> weston_view_geometry_dirty (shsurf->view);
> weston_surface_damage (main_surface);
> weston_desktop_surface_propagate_layer (shsurf-
> >desktop_surface);
> }
>
> }
>
> How can I resolve this?
>
> Regards
>
> adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: DRM page-flip with damage for weston
> > > The damage region received during output repaint is in Weston's global > > > co-ordinate space. To shift to CRTC co-ordinates, you need to > > > translate the damage region by (-output->x, -output->y). When we are > > > using the renderer, there is no scaling, so CRTC co-ordinates and > > > framebuffer co-ordinates are guaranteed to be equal. This only > > > accounts for the primary plane; damage to views on other planes is > > > considered separately. > > > > > > Also, if you are not already working from git master, I recommend you > > > do so, as the DRM backend has changed hugely since 4.0.0. > > > > Thanks Daniel for help and it the change suggested by you are working with > > my drm code. Another question regarding Weston, does each output in > > Weston create separate scan-out framebuffer always ? > > No problem - it does always create a separate scanout buffer for > renderer (GL/etc) buffers. For user buffers which are directly scanned > out (e.g. fullscreen windows), the user may have specified a viewport > scale/crop which requires translation, but I don't think this should > have an effect if the damage region you are after has to be in CRTC > co-ords. The damage is a plane property and it is in framebuffer coordinate of the framebuffer attached to the plane. For now in Weston I only have covered the first case, will check the case for user buffers which are directly scanned out. Thanks. > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/2] build: Remove execinfo.h check
Hi,
On Thu, 26 Jul 2018 at 16:11, Emil Velikov wrote:
> On 25 July 2018 at 18:36, Derek Foreman
> wrote:
> > On 2018-07-21 06:13 AM, Daniel Stone wrote:
> >> The check for the execinfo.h header is only advisory; the build will not
> >> fail if it is not present, and set HAVE_EXECINFO_H if it is. The check
> >> was added in commit 5cfdbef3d299 ("build: Allow disabling building of
> >> wayland libraries") with no obvious use or reasoning.
> >
> > 5cfdbe3d299 just moved it, it was added in commit bc3e020475
> >
> > It appears to have been accidentally included there, as it doesn't look
> > relevant to the bug ticket referenced in the commit.
> >
> >> Remove the no-op check.
> >>
> >> Signed-off-by: Daniel Stone
> >
> > Reviewed-by: Derek Foreman
> >
> > Though, I wouldn't mind seeing a more accurate commit log. ;)
> >
> It's always better to not get called out for other's copy/paste
> mistakes. If you guys like Fixes tags, here is one
>
> Fixes: bc3e020475e ("build: Add declaration checks to check for
> required syscall flags")
>
> Fwiw, series is
> Reviewed-by: Emil Velikov
Thanks both for the review and accuracy check: I've pushed both patches now.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DRM page-flip with damage for weston
Hi Deepak, On Wed, 25 Jul 2018 at 18:26, Deepak Singh Rawat wrote: > > The damage region received during output repaint is in Weston's global > > co-ordinate space. To shift to CRTC co-ordinates, you need to > > translate the damage region by (-output->x, -output->y). When we are > > using the renderer, there is no scaling, so CRTC co-ordinates and > > framebuffer co-ordinates are guaranteed to be equal. This only > > accounts for the primary plane; damage to views on other planes is > > considered separately. > > > > Also, if you are not already working from git master, I recommend you > > do so, as the DRM backend has changed hugely since 4.0.0. > > Thanks Daniel for help and it the change suggested by you are working with > my drm code. Another question regarding Weston, does each output in > Weston create separate scan-out framebuffer always ? No problem - it does always create a separate scanout buffer for renderer (GL/etc) buffers. For user buffers which are directly scanned out (e.g. fullscreen windows), the user may have specified a viewport scale/crop which requires translation, but I don't think this should have an effect if the damage region you are after has to be in CRTC co-ords. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/2] build: Remove execinfo.h check
On 25 July 2018 at 18:36, Derek Foreman wrote:
> On 2018-07-21 06:13 AM, Daniel Stone wrote:
>> The check for the execinfo.h header is only advisory; the build will not
>> fail if it is not present, and set HAVE_EXECINFO_H if it is. The check
>> was added in commit 5cfdbef3d299 ("build: Allow disabling building of
>> wayland libraries") with no obvious use or reasoning.
>
> 5cfdbe3d299 just moved it, it was added in commit bc3e020475
>
> It appears to have been accidentally included there, as it doesn't look
> relevant to the bug ticket referenced in the commit.
>
>> Remove the no-op check.
>>
>> Signed-off-by: Daniel Stone
>
> Reviewed-by: Derek Foreman
>
> Though, I wouldn't mind seeing a more accurate commit log. ;)
>
It's always better to not get called out for other's copy/paste
mistakes. If you guys like Fixes tags, here is one
Fixes: bc3e020475e ("build: Add declaration checks to check for
required syscall flags")
Fwiw, series is
Reviewed-by: Emil Velikov
-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH weston v5 05/14] clients: add weston-debug
Reviewed-by: Emre Ucan Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of Daniel Stone > Sent: Freitag, 20. Juli 2018 21:07 > To: wayland-devel@lists.freedesktop.org > Cc: pekka.paala...@collabora.co.uk; emre.u...@de.adit-jv.com; > maniraj.devad...@in.bosch.com > Subject: [PATCH weston v5 05/14] clients: add weston-debug > > From: Pekka Paalanen > > A tool for accessing the zcompositor_debug_v1 interface features. > > Installed along weston-info, because it should be potentially useful for > people running libweston-based compositors. > > Signed-off-by: Pekka Paalanen > > Added a man page for weston-debug client > > Signed-off-by: Maniraj Devadoss > [Pekka: fixed 'missing braces aroudn initializer' warning] > > Add --list and --all arguments, using interface advertisement. > > Signed-off-by: Daniel Stone > --- > Makefile.am| 16 +- > clients/weston-debug.c | 453 > + > man/weston-debug.man | 46 + > 3 files changed, 513 insertions(+), 2 deletions(-) > create mode 100644 clients/weston-debug.c > create mode 100644 man/weston-debug.man > > diff --git a/Makefile.am b/Makefile.am > index c2d9048b3..04381e0f7 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -531,7 +531,7 @@ spring_tool_SOURCES = \ > > if BUILD_CLIENTS > > -bin_PROGRAMS += weston-terminal weston-info > +bin_PROGRAMS += weston-terminal weston-info weston-debug > > libexec_PROGRAMS += \ > weston-desktop-shell\ > @@ -862,6 +862,15 @@ nodist_weston_info_SOURCES = > \ > weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la > weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) > > +weston_debug_SOURCES = \ > + clients/weston-debug.c \ > + shared/helpers.h > +nodist_weston_debug_SOURCES =\ > + protocol/weston-debug-protocol.c\ > + protocol/weston-debug-client-protocol.h > +weston_debug_LDADD = $(WESTON_INFO_LIBS) libshared.la > +weston_debug_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) > + > weston_desktop_shell_SOURCES = \ > clients/desktop-shell.c \ > shared/helpers.h > @@ -898,6 +907,8 @@ BUILT_SOURCES += > \ > protocol/weston-screenshooter-client-protocol.h > \ > protocol/weston-touch-calibration-protocol.c\ > protocol/weston-touch-calibration-client-protocol.h \ > + protocol/weston-debug-protocol.c\ > + protocol/weston-debug-client-protocol.h > \ > protocol/text-cursor-position-client-protocol.h \ > protocol/text-cursor-position-protocol.c\ > protocol/text-input-unstable-v1-protocol.c \ > @@ -1595,7 +1606,7 @@ surface_screenshot_la_SOURCES = tests/surface- > screenshot.c > # Documentation > # > > -man_MANS = weston.1 weston.ini.5 > +man_MANS = weston.1 weston.ini.5 weston-debug.1 > > if ENABLE_DRM_COMPOSITOR > man_MANS += weston-drm.7 > @@ -1623,6 +1634,7 @@ SUFFIXES = .1 .5 .7 .man > EXTRA_DIST +=\ > doc/calibration-helper.bash \ > man/weston.man \ > + man/weston-debug.man\ > man/weston-drm.man \ > man/weston-rdp.man \ > man/weston.ini.man > diff --git a/clients/weston-debug.c b/clients/weston-debug.c > new file mode 100644 > index 0..59dacd269 > --- /dev/null > +++ b/clients/weston-debug.c > @@ -0,0 +1,453 @@ > +/* > + * Copyright © 2017 Pekka Paalanen > + * > + * Permission is hereby granted, free of charge, to any person obtaining > + * a copy of this software and associated documentation files (the > + * "Software"), to deal in the Software without restriction, including > + * without limitation the rights to use, copy, modify, merge, publish, > + * distribute, sublicense, and/or sell copies of the Software, and to > + * permit persons to whom the Software is furnished to do so, subject to > + * the following conditions: > + * > + * The above copyright notice and this permission notice (including the > + * next paragraph) shall be included in all copies or substantial > + * portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > OF > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > HOLDERS > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN > AN > + * ACTION OF CONTRACT, TOR
RE: [PATCH weston v5 03/14] libweston: add weston_debug API and implementation
Reviewed-by: Emre Ucan
Best regards
Emre Ucan
Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49 6937
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of Daniel Stone
> Sent: Freitag, 20. Juli 2018 21:06
> To: wayland-devel@lists.freedesktop.org
> Cc: pekka.paala...@collabora.co.uk; emre.u...@de.adit-jv.com;
> maniraj.devad...@in.bosch.com
> Subject: [PATCH weston v5 03/14] libweston: add weston_debug API and
> implementation
>
> From: Pekka Paalanen
>
> weston_debug is both a libweston API for relaying debugging messages,
> and the compositor-debug wayland protocol implementation for accessing
> those
> debug messages from a Wayland client.
>
> weston_debug_compositor_{create,destroy}() are private API, hence not
> exported.
>
> Signed-off-by: Pekka Paalanen
>
> append the debug scope name along with the timestamp in
> weston_debug_scope_timestamp API
>
> Signed-off-by: Maniraj Devadoss
> Reviewed-by: Pekka Paalanen
>
> Add explicit advertisement of debug scope names.
>
> Signed-off-by: Daniel Stone
> ---
> Makefile.am | 2 +
> libweston/compositor.c | 6 +
> libweston/compositor.h | 9 +
> libweston/weston-debug.c | 723
> +++
> libweston/weston-debug.h | 107 ++
> 5 files changed, 847 insertions(+)
> create mode 100644 libweston/weston-debug.c
> create mode 100644 libweston/weston-debug.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 66eb365c5..c2d9048b3 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -98,6 +98,8 @@ libweston_@LIBWESTON_MAJOR@_la_SOURCES =
> \
> libweston/linux-dmabuf.h\
> libweston/pixel-formats.c \
> libweston/pixel-formats.h \
> + libweston/weston-debug.c\
> + libweston/weston-debug.h\
> shared/helpers.h\
> shared/matrix.c \
> shared/matrix.h \
> diff --git a/libweston/compositor.c b/libweston/compositor.c
> index 9deb7817f..8768f67a0 100644
> --- a/libweston/compositor.c
> +++ b/libweston/compositor.c
> @@ -6361,6 +6361,9 @@ weston_compositor_create(struct wl_display
> *display, void *user_data)
> ec, bind_presentation))
> goto fail;
>
> + if (weston_debug_compositor_create(ec) < 0)
> + goto fail;
> +
> if (weston_input_init(ec) != 0)
> goto fail;
>
> @@ -6699,9 +6702,12 @@ weston_compositor_destroy(struct
> weston_compositor *compositor)
>
> weston_plugin_api_destroy_list(compositor);
>
> +
> if (compositor->heads_changed_source)
> wl_event_source_remove(compositor-
> >heads_changed_source);
>
> + weston_debug_compositor_destroy(compositor);
> +
> free(compositor);
> }
>
> diff --git a/libweston/compositor.h b/libweston/compositor.h
> index fd0ff7b5b..83448b70f 100644
> --- a/libweston/compositor.h
> +++ b/libweston/compositor.h
> @@ -1049,6 +1049,7 @@ struct weston_touch_calibrator;
>
> struct weston_desktop_xwayland;
> struct weston_desktop_xwayland_interface;
> +struct weston_debug_compositor;
>
> struct weston_compositor {
> struct wl_signal destroy_signal;
> @@ -1161,6 +1162,8 @@ struct weston_compositor {
> weston_touch_calibration_save_func touch_calibration_save;
> struct weston_layer calibrator_layer;
> struct weston_touch_calibrator *touch_calibrator;
> +
> + struct weston_debug_compositor *weston_debug;
> };
>
> struct weston_buffer {
> @@ -2315,6 +2318,12 @@ int
> weston_compositor_enable_touch_calibrator(struct weston_compositor
> *compositor,
> weston_touch_calibration_save_func save);
>
> +int
> +weston_debug_compositor_create(struct weston_compositor
> *compositor);
> +
> +void
> +weston_debug_compositor_destroy(struct weston_compositor
> *compositor);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/libweston/weston-debug.c b/libweston/weston-debug.c
> new file mode 100644
> index 0..039247f14
> --- /dev/null
> +++ b/libweston/weston-debug.c
> @@ -0,0 +1,723 @@
> +/*
> + * Copyright © 2017 Pekka Paalanen
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining
> + * a copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sublicense, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial
> +
RE: [PATCH weston v5 02/14] protocol: add weston-debug.xml
Reviewed-by: Emre Ucan
Best regards
Emre Ucan
Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49 6937
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of Daniel Stone
> Sent: Freitag, 20. Juli 2018 21:06
> To: wayland-devel@lists.freedesktop.org
> Cc: pekka.paala...@collabora.co.uk; emre.u...@de.adit-jv.com;
> maniraj.devad...@in.bosch.com
> Subject: [PATCH weston v5 02/14] protocol: add weston-debug.xml
>
> From: Pekka Paalanen
>
> This is a new debugging extension for non-production environments. The
> aim is to replace all build-time choosable debug prints in the
> compositor with runtime subscribable debug streams.
>
> Signed-off-by: Pekka Paalanen
>
> Added new libweston-$MAJOR-protocols.pc file and install that
> for external projects to find the XML files installed by libweston.
>
> Signed-off-by: Maniraj Devadoss
>
> Use noarch_pkgconfig_DATA instead, add ${pc_sysrootdir}, drop
> unnecessary EXTRA_DIST of weston-debug.xml.
>
> Signed-off-by: Pekka Paalanen
>
> Add explicit advertisement of available debug interfaces.
>
> Signed-off-by: Daniel Stone
> ---
> Makefile.am | 10 ++
> configure.ac| 1 +
> libweston/libweston-protocols.pc.in | 7 ++
> protocol/weston-debug.xml | 136
> 4 files changed, 154 insertions(+)
> create mode 100644 libweston/libweston-protocols.pc.in
> create mode 100644 protocol/weston-debug.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 3bce47a11..66eb365c5 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -106,6 +106,10 @@ libweston_@LIBWESTON_MAJOR@_la_SOURCES =
> \
> shared/platform.h \
> shared/weston-egl-ext.h
>
> +libweston_@LIBWESTON_MAJOR@_datadir = $(datadir)/weston/protocols
> +dist_libweston_@LIBWESTON_MAJOR@_data_DATA = \
> + protocol/weston-debug.xml
> +
> lib_LTLIBRARIES += libweston-desktop-@LIBWESTON_MAJOR@.la
> libweston_desktop_@LIBWESTON_MAJOR@_la_CPPFLAGS =
> $(AM_CPPFLAGS) -DIN_WESTON
> libweston_desktop_@LIBWESTON_MAJOR@_la_CFLAGS = $(AM_CFLAGS)
> $(COMPOSITOR_CFLAGS)
> @@ -152,6 +156,8 @@ endif
> nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES =
> \
> protocol/weston-screenshooter-protocol.c\
> protocol/weston-screenshooter-server-protocol.h
> \
> + protocol/weston-debug-protocol.c\
> + protocol/weston-debug-server-protocol.h
> \
> protocol/text-cursor-position-protocol.c\
> protocol/text-cursor-position-server-protocol.h \
> protocol/text-input-unstable-v1-protocol.c \
> @@ -276,6 +282,10 @@ pkgconfig_DATA = \
> libweston-desktop/libweston-desktop-${LIBWESTON_MAJOR}.pc \
> compositor/weston.pc
>
> +noarch_pkgconfigdir = $(datadir)/pkgconfig
> +noarch_pkgconfig_DATA = \
> + libweston/libweston-${LIBWESTON_MAJOR}-protocols.pc
> +
> wayland_sessiondir = $(datadir)/wayland-sessions
> dist_wayland_session_DATA = compositor/weston.desktop
>
> diff --git a/configure.ac b/configure.ac
> index 093d6b549..3a138ea91 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -695,6 +695,7 @@ AC_CONFIG_FILES([Makefile libweston/version.h
> compositor/weston.pc])
> # libweston_abi_version here, and outside [] because of m4 quoting rules
> AC_CONFIG_FILES([libweston/libweston-
> ]libweston_major_version[.pc:libweston/libweston.pc.in])
> AC_CONFIG_FILES([libweston/libweston-]libweston_major_version[-
> uninstalled.pc:libweston/libweston-uninstalled.pc.in])
> +AC_CONFIG_FILES([libweston/libweston-]libweston_major_version[-
> protocols.pc:libweston/libweston-protocols.pc.in])
> AC_CONFIG_FILES([libweston-desktop/libweston-desktop-
> ]libweston_major_version[.pc:libweston-desktop/libweston-desktop.pc.in])
> AC_CONFIG_FILES([libweston-desktop/libweston-desktop-
> ]libweston_major_version[-uninstalled.pc:libweston-desktop/libweston-
> desktop-uninstalled.pc.in])
>
> diff --git a/libweston/libweston-protocols.pc.in b/libweston/libweston-
> protocols.pc.in
> new file mode 100644
> index 0..6547a0d5a
> --- /dev/null
> +++ b/libweston/libweston-protocols.pc.in
> @@ -0,0 +1,7 @@
> +prefix=@prefix@
> +datarootdir=@datarootdir@
> +pkgdatadir=${pc_sysrootdir}@datadir@/@PACKAGE@/protocols
> +
> +Name: libWeston Protocols
> +Description: libWeston protocol files
> +Version: @WESTON_VERSION@
> diff --git a/protocol/weston-debug.xml b/protocol/weston-debug.xml
> new file mode 100644
> index 0..1154c3ae2
> --- /dev/null
> +++ b/protocol/weston-debug.xml
> @@ -0,0 +1,136 @@
> +
> +
> +
> +
> +Copyright © 2017 Pekka Paalanen p...@iki.fi
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without
RE: [PATCH wayland v3 0/4] Meson build
Hi, I am looking forward for this feature. Currently, I am not able to test it in our setup. Acked-by: Emre Ucan Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of Daniel Stone > Sent: Samstag, 21. Juli 2018 17:32 > To: wayland-devel@lists.freedesktop.org > Cc: eba...@gnome.org > Subject: [PATCH wayland v3 0/4] Meson build > > Hi, > This is an updated version of Emmanuele's series. Notably it fixes up > the Doxygen man build, so we now correctly build and install all the man > pages. > > I think this should be good to merge at this point. It is past the alpha > freeze, however getting it in a release would be a great way to get > testing from both downstreams and users, who wouldn't necessarily be > testing git. As it's additive, it shouldn't regress anything for anyone, > and the autotools build still exists and works. > > Cheers, > Daniel > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Advertising supported Dmabuf modifiers of DRM device
Hi Emre, On Thu, 26 Jul 2018 at 14:54, Ucan, Emre (ADITG/ESB) wrote: > We are currently querying supported modifiers only from gpu drivers via > EGL_EXT_image_dma_buf_modifiers extension. > But we should also query and advertise modifiers which are supported by DRM > device. We are already getting this information via IN_FORMATS of a drm plane. > > IMO, it is not enough to just query and advertise every supported format and > modifiers combination to applications. > Applications can easily choose a format, which is only supported by GPU > device and not DRM device. In the end, this would force us to use gpu for > composition. > We should mark modifiers of DRM device as preferred ones. This would require > modifying linux-dmabuf protocol. I agree; I've had the same thought. I think we want to do something more nuanced than this though. Say for example the display controller only supports linear formats. Doing a clear intersection would mean all clients rendering to linear at a performance loss, even if they are not candidates for display scanout. What we would want is a more dynamic hint from the compositor: to tell clients to prefer scanout-compatible formats where they are useful, but else to just pick the best GPU format. I think the best thing to do would be to make a new dmabuf interface which takes a surface as a creation parameter, where the compositor would update the per-surface interface with preferred modifiers. Since we don't know preference order between modifiers, rather than enforcing any order, the best thing to do would be to break it into tranches: send one set of modifiers which are both GPU + scanout compatible and ask the client to preferentially allocate from that set, then send a second GPU-only set which the client may fall back to if it cannot render to the first set. I don't have plans to work on that right now - I'd happily review any patches or have a more detailed discussion though! - but as part of the debug work I sent out last week, I am planning to expose the current scanout status of surfaces to the core compositor. For example, 'is on a plane now', vs. 'can never be on a plane because of compositor configuration (transform/alpha/etc)' vs. 'could maybe be on a plane but is not allowed (couldn't find suitable plane, kernel rejected, etc)' vs. 'could be on a plane but client needs to change (modifiers, transform, etc)'. That should be quite useful for this work as well. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Advertising supported Dmabuf modifiers of DRM device
Hi all, We are currently querying supported modifiers only from gpu drivers via EGL_EXT_image_dma_buf_modifiers extension. But we should also query and advertise modifiers which are supported by DRM device. We are already getting this information via IN_FORMATS of a drm plane. IMO, it is not enough to just query and advertise every supported format and modifiers combination to applications. Applications can easily choose a format, which is only supported by GPU device and not DRM device. In the end, this would force us to use gpu for composition. We should mark modifiers of DRM device as preferred ones. This would require modifying linux-dmabuf protocol. What do you think? Best regards Emre Ucan Advanced Driver Information Technology GmbH Engineering Software Base (ADITG/ESB) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6937 Fax +49 5121 49 6999 eu...@de.adit-jv.com ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschaeftsfuehrung: Wilhelm Grabow, Ken Yaguchi ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC libinput] dox: switch to sphinx for the user-visible documentation
Hi, On Thu, 26 Jul 2018 at 02:53, Peter Hutterer wrote: > On Tue, Jul 24, 2018 at 03:42:50PM +1000, Peter Hutterer wrote: > > Sending this out as patch even though what really matters is the > > output. Which is... here, tadaaa! > > > > https://people.freedesktop.org/~whot/libinput-rtd/ > > fwiw, I've played around with it a bit and updated the URL above. It now has > a proper hierarchy, more doxygen tags are being parsed. > > There are still a few parsing issues that need to be fixed manually. And the > doc needs a general do-over to split it better into user docs vs developer > docs. And of course doxygen itself needs to be separated, generated, and > link to the sphinx docs. But otherwise this looks quite nice IMO. Oh, that is really nice. I like that it actually has a navigable hierarchy now. That was always my biggest issue with Doxygen. Given that the kernel also uses Sphinx for the DRM/KMS documentation in particular, it's probably good for us to be using it as well. If it counts for anything at all: Acked-by: Daniel Stone Cheers, Daniel PS: You might want to disable syntax highlighting on the MIT license; also 'generated by from git commit' at the very bottom. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged
Hi Jasper, On Thu, 26 Jul 2018 at 03:53, Jasper St. Pierre wrote: > From IRC conversations with krh a long time ago, this is indeed intentional > and the cursor surface should "lose its role" in modern parlance. > > The original intention was to prevent glitching of the cursor surface. e.g. > If the left side of the surface has a resize left cursor, you leave, and > hover over the right, you don't want to see the resize left cursor for a > split second before the resize right cursor appears. > > The original implementation of Weston respected this and would only change > the cursor on set_cursor calls and would not even remember a per-client > cursor surface. This behavior has probably been lost in numerous reactors by > now. Right, it's not about having the cursor surface stick to the normal surface, but about having the buffer stick to the cursor surface. The former definitely isn't controversial, and EFL is re-associating the cursor surface with the normal surface. What's happening is that they need to attach/damage/commit to that surface to get the content. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
