configure
event which will never arrive: the initial configure event gets queued,
but calling set_maximised(false) causes the 'same event' check to get
tripped which promptly deletes the timer, and no event is ever sent.
Signed-off-by: Daniel Stone
Cc: Quentin Glidic
---
libweston-d
Hi,
On 21 July 2017 at 15:18, Pekka Paalanen wrote:
> On Tue, 18 Jul 2017 14:14:33 +0100
> Daniel Stone wrote:
>> @@ -1517,10 +1518,20 @@ drm_output_render(struct drm_output_state *state,
>> pixman_region32_t *damage)
>> if (scanout_state->fb)
>>
Hi Philipp,
Thanks for the review!
On 21 July 2017 at 13:30, Philipp Zabel wrote:
> On Tue, 2017-07-18 at 14:14 +0100, Daniel Stone wrote:
>> @@ -3804,7 +3840,8 @@ drm_output_enable(struct weston_output *base)
>> else
>> b-&g
Hi Pekka,
On 21 July 2017 at 14:59, Pekka Paalanen wrote:
> On Tue, 18 Jul 2017 14:14:32 +0100
> Daniel Stone wrote:
>> @@ -1424,15 +1419,29 @@ drm_output_prepare_scanout_view(struct
>> drm_output_state *output_state,
>> return NULL;
>> }
Hi Pekka,
On 20 July 2017 at 18:01, Pekka Paalanen wrote:
> On Tue, 18 Jul 2017 14:14:30 +0100
> Daniel Stone wrote:
>> @@ -986,6 +1130,20 @@ drm_output_state_duplicate(struct drm_output_state
>> *src,
>> else
>> wl_list_init(&dst->
Hi Quentin,
On 28 August 2017 at 19:12, Quentin Glidic
wrote:
> The old code for scheduling configure events on idle looked like:
> if (configure_scheduled) {
> if (this_event_is_the_same) {
> remove_timer();
> return;
> }
> }
>
> If we queued one new event (either changed, or the
Hi Tomek,
On 14 August 2017 at 11:02, Tomek Bury wrote:
> Daniel, can we have this one merged, please?
We sure can. Sorry for the delay.
To ssh://git.freedesktop.org/git/wayland/wayland-protocols
9ee1d59..875130e push -> master
Cheers,
Daniel
___
Hi Matt,
On 24 August 2017 at 15:24, Matt Hoosier wrote:
> @@ -1545,10 +1548,22 @@ drm_assign_planes(struct weston_output *output_base,
> void *repaint_data)
> next_plane = primary;
> if (next_plane == NULL)
> next_plane = drm_outpu
Hi Joseph,
On 6 September 2017 at 11:56, Joseph Burt wrote:
> I'm thinking this might be a job for a bit of translation shim within
> Xwayland. Everything an X client needs either has a Wayland equivalent
> (through an X server and a little translating XWM shim) or, where
> forbidden by Wayland,
On 15 September 2017 at 12:39, Pekka Paalanen wrote:
> I am not familiar yet with the fence/sync APIs so I cannot review their
> usage at this time. I do review all the Weston parts.
I walked through it the other night, and the fence bits at least are:
Reviewed-by: Daniel
c
Apart from the below, this series, when squashed into a single patch
for import, is:
Reviewed-by: Daniel Stone
I realise this is a straight copy/import, so sorry to pick on these, but:
> +#include // offsetof
> +#include // printf
> +
> +#include "wayland-egl-priv.h" /
Hi Emil,
On 15 September 2017 at 15:54, Emil Velikov wrote:
> On 15 September 2017 at 14:50, Daniel Stone wrote:
>> Currently the client-facing libwayland-egl API is defined by a header
>> file shipped by Wayland, but the implementation is left to each
>> vendor. This can
Hi Drew,
On 15 September 2017 at 16:21, Drew DeVault wrote:
> On 2017-09-15 6:17 PM, Pekka Paalanen wrote:
>> DRM is for driving any kind of display, GPU or not, acceleratable or
>> not. What it gives us is a standard userspace ABI to poke all display
>> devices with.
>>
>> There could be other
Signed-off-by: Daniel Stone
---
Makefile.am| 1 +
unstable/linux-explicit-synchronization/README | 5 +
.../linux-explicit-synchronization-unstable-v1.xml | 208 +
3 files changed, 214 insertions(+)
create mode 100644 unstable
Hi Matt,
On 20 September 2017 at 05:48, Matt Hoosier wrote:
> On a related subject, there was discussion back at
> https://lists.freedesktop.org/archives/wayland-devel/2013-September/011091.html
> that acknowledged a longstanding bug where wl_buffer::release events
> are starved indefinitely in t
Hi Emre,
On 20 September 2017 at 06:38, Ucan, Emre (ADITG/ESB)
wrote:
> Will this protocol be used by libEGL, or applications has to use it directly ?
The idea was for whoever calls wl_surface_attach() to also attach the
fence: an EGL/Vulkan driver, or a client framework directly if using
buffer
On 22 September 2017 at 07:31, Pekka Paalanen wrote:
> Fix the assumption that MAP_FAILED would be equal to NULL. It is not.
> Set 'fb' explicitly to NULL on mmap failure so that comparisons to NULL
> would produce the expected result.
>
> Signed-off-by: Pekka Paalanen
Hi,
On 21 July 2017 at 04:56, Pekka Paalanen wrote:
> On Tue, 18 Jul 2017 14:14:31 +0100
> Daniel Stone wrote:
>> @@ -3634,10 +3844,11 @@ drm_output_deinit(struct weston_output *base)
>> drm_output_fini_egl(output);
>>
>> weston_plane_
to guarantee that they get correctly notified of buffer
> lifecycle events.
File under, 'good ideas that didn't quite work out'.
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
Hello Esaki-san,
On 1 November 2016 at 19:09, Daniel Stone wrote:
>> @@ -1101,15 +1096,9 @@ drm_output_prepare_overlay_view(struct drm_output
>> *output,
>> if (!found)
>> return NULL;
>>
>> - if ((dmabuf = linux_dmabuf_buffer_ge
plane-but-but-atomic-plane
content.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 354 ++---
1 file changed, 300 insertions(+), 54 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 5e87cb41..51aacd48 1
e.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 423 ++---
1 file changed, 322 insertions(+), 101 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 0827e953..33555d00 100644
--- a/libweston/compositor-d
If we don't have any damage for the primary plane, then don't force a
repaint; simply reuse the old buffer we already have.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
Add a test environment variable to allow disabling universal planes.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index b28e602f..0827e953 100644
--- a
If we have an unused CRTC or connector, explicitly disable it during the
end of the repaint cycle, or when we get VT-switched back in.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 60 --
1 file changed, 48
part of
output->state_last, and is not directly visible from the plane itself.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 342 -
1 file changed, 277 insertions(+), 65 deletions(-)
diff --git a/libweston/compositor-drm.c b/libwes
Rather than a more piecemeal approach at backend creation, explicitly
track connectors and CRTCs we do not intend to use, so we can ensure
they are disabled where appropriate.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
---
libweston/compositor-drm.c | 53
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 157 +
1 file changed, 88 insertions(+), 69 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
When leaving Weston, don't attempt to restore the previous CRTC
settings. The framebuffer may well have disappeared, and in every
likelihood, whoever gets the KMS device afterwards will be repainting
anyway.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c
For atomic modesetting support, the mode is identified by a blob
property ID, rather than being passed inline. Add a blob_id member to
drm_mode to handle this, including refactoring mode destruction into a
helper function.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 21
From: Pekka Paalanen
Set the atomic client cap, where it exists, and use this to discover the
plane/CRTC/connector properties we require for atomic modesetting.
Signed-off-by: Daniel Stone
Co-authored-by: Pekka Paalanen
---
configure.ac | 3 +++
libweston/compositor-drm.c | 57
Use a real drm_plane to back the scanout plane, displacing
output->fb_{last,cur,pending} to their plane-tracked equivalents.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 167 +++--
1 file changed, 101 insertions(+), 66 deletions(-)
d
When trying to assign planes, keep track of the areas which are
already occluded, and ignore views which are completely occluded. This
allows us to build a state using planes only, when there are occluded
views which cannot go into a plane behind views which can.
Signed-off-by: Daniel Stone
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone
---
configure.ac | 3 +++
libweston/compositor-drm.c | 28 ++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/configure.ac b
Since we now incrementally test atomic state as we build it, we can
loosen restrictions on what we can do with planes, and let the kernel
tell us whether or not it's OK.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 22 ++
1 file changed, 14 insertions(
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Add support for this, which we will later use in
assign_planes to ensure our plane configuration is valid.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 180
Make it a bit more clear what the purpose of the variable is.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 3b22faf1..093e75b1 100644
--- a
Rather than a hardcoded ARGB -> XRGB translation inside a
GBM-specific helper, just determine whether or not the view is opaque,
and use the generic helpers to implement the format translation.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c |
ioctl
for users on old kernels without AddFB2; unfortunately, we cannot detect
the complete absence of the ioctl, as the return here is -EINVAL rather
than -ENOTTY.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 46 --
1 file change
In our new and improved helper to determine the src/dest values for a
buffer on a given plane, make sure we account for all buffer
transformations, including viewport clipping.
Rather than badly open-coding it ourselves, just use the helper which
does exactly this.
Signed-off-by: Daniel Stone
Use the extended GBM allocator interface to support modifiers and
multi-planar BOs.
Depends on bwidawsk's 'modifiers' tree.
Signed-off-by: Daniel Stone
---
configure.ac | 3 +++
libweston/compositor-drm.c | 57 ++
2 fi
Add support for the GBM_BO_IMPORT_FD_MODIFIER path, which allows us to
import multi-plane dmabufs, as well as format modifiers.
Signed-off-by: Daniel Stone
---
configure.ac | 3 -
libweston/compositor-drm.c | 181 +
2 files changed
When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 24
Add support for multiple modes: toggling whether or not the renderer
and/or planes are acceptable. This will be used to implement a smarter
plane-placement heuristic when we have support for testing output
states.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 39
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston
Return a pointer to the plane state, rather than indirecting via a
weston_plane.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 73 ++
1 file changed, 42 insertions(+), 31 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston
Use the new helper to populate the cursor state as well, with some
special-case handling to account for how we always upload a full-size
BO.
Signed-off-by: Daniel Stone
Reported-by: Derek Foreman
---
libweston/compositor-drm.c | 48 +++---
1 file changed
Add a test environment variable to allow disabling atomic modesetting.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index d04ba12f..8cd69f1f
Use the shiny new helper we have for working through scanout as well.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 66 --
1 file changed, 23 insertions(+), 43 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor
_dpms generating a
synchronous state update.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 313 ++---
1 file changed, 240 insertions(+), 73 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 530b0fd5..6c1c6881 1
Add support for using the atomic-modesetting API to apply output state.
Unlike previous series, this commit does not unflip sprites_are_broken,
until further work has been done with assign_planes to make it reliable.
Signed-off-by: Daniel Stone
Co-authored-by: Pekka Paalanen
Co-authored-by
Use the same codepath, which has the added advantage of being able to
import dmabufs.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 62 +-
1 file changed, 12 insertions(+), 50 deletions(-)
diff --git a/libweston/compositor-drm.c b
Move drm_assign_planes into two functions: one which proposes a plane
configuration, and another which applies that state to the Weston
internal structures. This will be used to try multiple configurations
and see which is supported.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c
Nothing in this loop reorders views within the compositor's view_list.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 72c9e5a2..3b22faf1 100644
Much like we already have to_drm_output and to_drm_backend.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 2a72456d..3c75ec56 100644
--- a
... in order to be able to use it from scanout as well.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 221 -
1 file changed, 119 insertions(+), 102 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index
Rather than open-coding it ourselves, use the new apply_state helper in
drm_output_start_repaint.
Signed-off-by: Daniel Stone
Reported-by: Fabien DESSENNE
---
libweston/compositor-drm.c | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a
We currently do the same thing in two places, and will soon have a
third.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 93 --
1 file changed, 48 insertions(+), 45 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston
x, and then analyse that.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index e835d3b7..07f0b105 100644
--- a/libweston/compositor-
Hi,
Here's a cleaned-up and fully-tested version of the atomic series. I'm
fairly happy with it now. There are a few things I'd want to change, but
figured I'd send it all out now rather than waiting another however
long:
* I'd rather track unused_{crtcs,connectors} by putting them all in
ori
ff-by: Sergi Granell
Reviewed-by: Daniel Stone
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 126 ++---
1 file changed, 118 insertions(+), 8 deletions(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 111cb9e3..811
Hi Chris,
Thanks for taking a look!
On 27 September 2017 at 13:18, Chris Wilson wrote:
> Quoting Alexandros Frantzis (2017-09-27 13:09:16)
>> Use EGL fence sync objects to emit timepoints for the beginning and the
>> end of rendering on the GPU.
>
> But why not use a qbo with GL_TIMESTAMP?
As Al
Hi Matt,
On 27 September 2017 at 14:46, Matt Hoosier wrote:
> On Tue, Sep 26, 2017 at 12:15 PM, Daniel Stone wrote:
>> Here's a cleaned-up and fully-tested version of the atomic series.
>
> Just wondering: do you maintain these in a publicly fetchable repo
> somewhere? I
Hi,
On 28 September 2017 at 03:49, Ian Romanick wrote:
> On 09/27/2017 04:55 PM, Rob Clark wrote:
>> Sadly by the time we were aware of the dates for the khronos f2f it
>> was not possible to change the dates for XDC :-(
>>
>> The XDC dates were set in Feb, and afaict the khronos dates were
>> an
ting too many wl_registry objects.
>
> Signed-off-by: Derek Foreman
Reviewed-by: Daniel Stone
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi Pekka,
On 22 September 2017 at 15:31, Pekka Paalanen wrote:
> *
> * \param output The weston_output object to initialize
> * \param compositor The compositor instance.
> + * \param name Name for the output.
Please document that @name is duplicated internally, i.e. reference
bo
-v1
A small nit on 'weston_output_init(..., +name)' notwithstanding, the
series to date on head-prep-v1 (different to what was sent; maybe just
rebased?) is:
Acked-by Daniel Stone
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel
hand, if a modifier _is_ explicitly specified and we don't
have the modifiers extension, then refuse to import the buffer.
Signed-off-by: Daniel Stone
---
libweston/gl-renderer.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libweston/gl-renderer.c b/libwesto
On 5 October 2017 at 08:15, Pekka Paalanen wrote:
> On Wed, 4 Oct 2017 18:35:45 +0100
> Daniel Stone wrote:
>> If the user has passed an INVALID modifier, it's because there is no
>> applicable modifier, and the buffer layout should be determined by a
>>
Hi Emil,
On 2 October 2017 at 10:29, Pekka Paalanen wrote:
> On Fri, 29 Sep 2017 14:21:02 +0100
> Emil Velikov wrote:
>> Just a general idea, please don't bother with it for now:
>>
>> Normally it's great if one can have clear description of the format
>> env. variables expect.
>> Quick grep sho
Hi,
On 5 October 2017 at 13:39, Emil Velikov wrote:
> On 29 September 2017 at 14:00, Emil Velikov wrote:
>> With the above data in mind, we can reuse the current Wayland version
>> AKA WAYLAND_VERSION.
>> It should just work for all the known cases, plus it provides
>> consistency as a nice bon
h for each plane, according to subsampling.
Tested with:
$ gst-launch-1.0 videotestsrc ! waylandsink
Signed-off-by: Daniel Stone
Fixes: fdeefe42418 ("gl-renderer: add support of WL_SHM_FORMAT_YUV420")
Reported-by: Fabien Lahoudere
Bugzilla: https://bugs.freedesktop.org/show_bug.c
search, as well as a GitHub code search, the
only user of WL_SHM_FORMAT_YUV420 is ... GStreamer waylandsink. And
that doesn't seem to have changed in quite some time, though Nicolas
could probably confirm that. So this is probably just fixing it up
full stop?
>> Tested with:
>> $
Hi Matt,
On 10 October 2017 at 17:12, Matt Hoosier wrote:
> My organization maintains a small patch against the DRM compositor
> that causes it to register another output. This output accepts the
> usual compositor scenegraph, does the rendering down to a primary
> plane, and then funnels the res
Hi Pekka,
On 12 October 2017 at 07:56, Pekka Paalanen wrote:
> On Wed, 11 Oct 2017 09:01:30 -0500
> Matt Hoosier wrote:
>> I'll have a look there. One thing that for simplicity I left out of
>> the original description above is that this custom Weston output has a
>> fast-path very similar to th
Hi Emre,
On 12 October 2017 at 10:20, Ucan, Emre (ADITG/ESB)
wrote:
> I tested your branch " wip/2017-09/atomic-v12" on Intel Apollo Lake with:
> - Linux Kernel v4.9
> - Libdrm 2.4.83
> - Mesa 13.0.6
Thanks for testing!
> In the end, I could not test the atomic modesetting with this setup. I go
Hi Deepak,
On 20 October 2017 at 18:50, Deepak Jois wrote:
> I have Gnome running under Wayland on tty2. The Gnome session is
> running some app like gnome-terminal.
>
> I do the following:
>
> * Press Ctrl-Alt-F3 (switching to tty3, the lowest free tty)
> * Login as the same user running the Gno
Hi Emre, Maniraj,
On 12 October 2017 at 13:13, Emre Ucan wrote:
> 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-
Hi all,
On 12 October 2017 at 13:13, Emre Ucan wrote:
> +
> +
> + This is a generic debugging interface for Weston internals, the global
> + object advertized through wl_registry.
> +
> + WARNING: This interface by design allows a denial-of-service attack. It
> + should
Hi,
On 12 October 2017 at 13:13, Emre Ucan wrote:
> +WL_EXPORT char *
> +weston_debug_scope_timestamp(struct weston_debug_scope *scope,
> +char *buf, size_t len)
> +{
> + struct timeval tv;
> + struct tm *bdt;
> + char string[128];
> + size_t re
Hi,
On 12 October 2017 at 13:13, Emre Ucan wrote:
> +static void
> +list_scope_begin(struct weston_debug_stream *stream, void *user_data)
> +{
> + struct weston_debug_compositor *wdc = user_data;
> + struct weston_debug_scope *scope;
> +
> + weston_debug_stream_printf(stream, "S
Hey,
On 23 October 2017 at 12:54, Pekka Paalanen wrote:
> On Mon, 23 Oct 2017 12:34:47 +0200
> Daniel Stone wrote:
>> On 12 October 2017 at 13:13, Emre Ucan wrote:
>> > + gettimeofday(&tv, NULL);
>> > +
>> > + bdt =
Hey,
One last comment from IRC discussion.
On 23 October 2017 at 13:10, Daniel Stone wrote:
> On 23 October 2017 at 12:54, Pekka Paalanen wrote:
>> On Mon, 23 Oct 2017 12:34:47 +0200
>> Daniel Stone wrote:
>>> I would very much not like to see formatted time in the
testing hard by being
>> already
>> broken in many ways. Here is a series to fix the issues I found. The
>> series can
>> also be found at:
>
> Great work!
>
> The whole series is:
> Reviewed-by: Quentin Glidic
And with a read-through but no more:
Acked-
tect the SEGV handler from dereferencing
>> NULL when we don't yet have a compositor or a backend.
>>
>> The SEGV handler uses weston_log(), so cannot move catch_signals() any
>> earlier.
>>
>> Signed-off-by: Pekka Paalanen
>
> So
Hi Emre.
On 1 November 2017 at 11:56, Ucan, Emre (ADITG/ESB)
wrote:
> Is this the latest WIP branch to test "
> https://gitlab.collabora.com/daniels/weston/commits/wip/2017-10/atomic-v13"; ?
Right you are.
> In my opinion, it would easier to review/test your patches if you can
> separate them
Hi,
On 3 November 2017 at 07:33, Pekka Paalanen wrote:
> People, give your acks/nacks for the two ideas, please:
>
> - modify WAYLAND_DISPLAY to support absolute paths which overrides
> any search paths
ACK. It's a simple and straightforward extension to current behaviour.
> - when the curren
Hi Emil,
On 8 November 2017 at 14:06, Emil Velikov wrote:
> On 10 October 2017 at 14:43, Emil Velikov wrote:
>> In summary - we want the user facing library to live in Wayland with
>> vendors providing a backend/plugin. Otherwise we'll get file conflicts
>> as library can come from different ve
Hi Emil,
On 2 November 2017 at 17:09, Emil Velikov wrote:
> Import latest version (v2) of the protocol from Mesa.
>
> From the README:
>
> Warning!
> The goal is to share the protocol file across Mesa and other low-level
> components graphics stack such as libva and Xwayland. File is moved to
> w
On Mon, 8 Aug 2022 at 17:24, samuel ammonius wrote:
> I've just looked at the xdg-shell protocol as you said. I was really
> surprised at the
> amount of features it had, but one part in particular caught my eye:
Window geometry is relative to surface co-ordinates. As the first
paragraph describ
On Fri, 9 Sept 2022 at 12:50, Simon Ser wrote:
> On Friday, September 9th, 2022 at 12:23, Hans de Goede <
> hdego...@redhat.com> wrote:
> > "people using
> > non fully integrated desktop environments like e.g. sway often use custom
> > scripts binded to hotkeys to get functionality like the brigh
Hi Martin,
On Fri, 17 Feb 2023 at 11:27, Martin Petzold wrote:
> Feb 17 12:16:24 tavla DISPLAY Wayland[957]: [12:16:24.624] Loading module
> '/usr/lib/aarch64-linux-gnu/libweston-9/g2d-renderer.so'
> Feb 17 12:16:25 tavla DISPLAY Wayland[957]: [ 1] Failed to open device:
> No such file or d
Hi Daniel,
On Fri, 10 Mar 2023 at 14:28, Levin, Daniel wrote:
> We are currently attempting to update from Weston 9.0.0 to Weston 10+ and
> facing issues with GLES2 compatibility at both build time and run time.
>
> For instance, gl_renderer_setup() exits with error if GL_EXT_unpack_subimage
>
Hi,
On Thu, 8 Jun 2023 at 14:28, Pekka Paalanen wrote:
> On Thu, 8 Jun 2023 14:49:37 +0200
> Martin Petzold wrote:
> > btw. we are using a Weston 9 package from NXP and there may be important
> > fixes for our i.MX8 platform in there.
>
> Oh. We cannot support modified Weston, sorry. Significan
On Thu, 8 Jun 2023 at 16:54, Martin Petzold wrote:
> Am 08.06.23 um 16:58 schrieb Daniel Stone:
>
> On Thu, 8 Jun 2023 at 14:28, Pekka Paalanen wrote:
>
>> On Thu, 8 Jun 2023 14:49:37 +0200
>> Martin Petzold wrote:
>> > btw. we are using a Weston 9
Hi,
On Tue, 13 Jun 2023 at 10:20, Pekka Paalanen wrote:
> On Tue, 13 Jun 2023 01:11:44 + (UTC)
> Joe M wrote:
> > As I understand, there is one global wl_display. Is there always one
> > wl_compositor too?
>
> That is inconsequential.
>
Yeah, I think the really consequential thing is that
Hi Joe,
On Wed, 14 Jun 2023 at 21:33, Joe M wrote:
> Thanks Daniel. Do you know if wl_output instances are decoupled from each
> other, when it comes to display refresh?
>
Yep, absolutely.
> The wl_output geometry info hints that each output can be thought of as a
> region in a larger composi
Hi Namit,
On Thu, 15 Jun 2023 at 16:37, Namit Solanki (QUIC) <
quic_nsola...@quicinc.com> wrote:
>
> As we all know Weston 10 has bitbakes files available for Yocto kirkstone
> version. Can Weston 12 work with Kirkstone as well?
>
>
>
> Is Weston 12 compatible with Kirkstone?
>
>
>
> Do we need t
Hi Dawn,
On Thu, 22 Jun 2023 at 18:09, Dawn HOWE wrote:
> I am developing an (embedded) medical device which is required to have a
> touchscreen display and also mirror the output to a monitor connected via
> HDMI. The device is using Wayland/Weston on TorizonCore (based on a yocto
> kirkstone).
Hi Huy,
On Sat, 8 Jul 2023 at 08:39, huy nguyen wrote:
> I have a Linux system based on weston wayland and I need to get the
> current setting of the display resolution.
> Unfortunately, xrandr command does not work on Wayland.
> After much searching, I came to this information which is about ad
901 - 1000 of 2140 matches
Mail list logo
