Re: where is weston-content-protection-client-protocol.h?
Scott Anderson 于2019年10月1日周二 下午3:45写道：
>
> On 1/10/19 3:35 pm, Barry Song wrote:
> > Hi Ankit and all,
> > clients/content_protection.c includes
> > weston-content-protection-client-protocol.h, and i found commit
> > 8b40def845c1b965c2888b1f036ef1f19d76 added
> > weston_content_protection_protocol_c and
> > weston_content_protection_client_protocol_h
> >
> > diff --git a/clients/meson.build b/clients/meson.build
> > index 3d36efe4..ff6246db 100644
> > --- a/clients/meson.build
> > +++ b/clients/meson.build
> > @@ -229,6 +229,14 @@ demo_clients = [
> > 'dep_objs': dep_vertex_clipping
> > },
> > { 'basename': 'confine' },
> > + {
> > + 'basename': 'content_protection',
> > + 'add_sources': [
> > + weston_content_protection_client_protocol_h,
> > + weston_content_protection_protocol_c,
> > + ]
> > + },
> > +
> > { 'basename': 'dnd' },
> > {
> > 'basename': 'editor',
> >
> > But anyway, where is the weston-content-protection-client-protocol.h?
> > I can't find it in weston:
> > weston$ find ./ -name "weston-content-protection-client-protocol.h"
> >
> > And i failed to find it in google.
> >
> > Thanks
> > Barry
>
> Hi Barry,
>
> With all Wayland extension protocols (and even the core protocol
> itself), they are all defined in an .xml file, and then the
> wayland-scanner tool generates the .c and .h code for it. So if you want
> to look at the header file directly, it'll be inside of your build
> directory (e.g.
> build/protocols/weston-content-protection-client-protocol.h).
>
> If you want to use this in your own projects, you should use
> wayland-scanner yourself rather than copying the .c and .h files.
Thank you very much, Scott.
>
> Cheers,
> Scott
-barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
where is weston-content-protection-client-protocol.h?
Hi Ankit and all,
clients/content_protection.c includes
weston-content-protection-client-protocol.h, and i found commit
8b40def845c1b965c2888b1f036ef1f19d76 added
weston_content_protection_protocol_c and
weston_content_protection_client_protocol_h
diff --git a/clients/meson.build b/clients/meson.build
index 3d36efe4..ff6246db 100644
--- a/clients/meson.build
+++ b/clients/meson.build
@@ -229,6 +229,14 @@ demo_clients = [
'dep_objs': dep_vertex_clipping
},
{ 'basename': 'confine' },
+ {
+ 'basename': 'content_protection',
+ 'add_sources': [
+ weston_content_protection_client_protocol_h,
+ weston_content_protection_protocol_c,
+ ]
+ },
+
{ 'basename': 'dnd' },
{
'basename': 'editor',
But anyway, where is the weston-content-protection-client-protocol.h?
I can't find it in weston:
weston$ find ./ -name "weston-content-protection-client-protocol.h"
And i failed to find it in google.
Thanks
Barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年8月8日周四 下午11:18写道： > > On Thu, 8 Aug 2019 16:11:23 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Hi Pekka, > > > > it seems the memcpy(spa_buffer->datas[0].data, ptr, size) is a big > > problem to limit the usage of pipewire. > > i am wondering if there is a zero-copy solution to share the drm_fb to > > pipewiresrc then to encoder? > > Hi, > > I know nothing about pipewire, sorry. I seem to recall that very > question was asked and answered in the MR that introduced the > pipewire plugin. I recommend checking there. i have commented here: https://gitlab.freedesktop.org/wayland/weston/merge_requests/177 it believe pipewire plugin should move to dmabuf. > > > Thanks, > pq -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年8月3日周六 上午12:06写道：
>
> On Wed, 31 Jul 2019 10:20:22 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > as said in the other email, independent clone mode has been resolved
> > by hacking weston damage tracking system.
> > i am looking for a solution to support remote screen mirroring. the
> > current idea is making the pipewire display work as a duplicated
> > display which shows the same content with the physical display.
> > this will probably resolve the screen mirror issue. would you like to
> > think it is the right direction?
>
> Hi,
>
> yes, that can work, and it is nicely orthogonal in implementation to
> the real outputs.
>
> It will have the same problem as the remoting plugin already worked
> around with the concept of DRM virtual outputs. Libweston currently
> supports only one backend at a time, but we would really need to able to
> have multiple input and output backends in use at the same time to
> improve the internal architecture and make remoting independent of the
> actual backends.
Hi Pekka,
it seems the memcpy(spa_buffer->datas[0].data, ptr, size) is a big
problem to limit the usage of pipewire.
i am wondering if there is a zero-copy solution to share the drm_fb to
pipewiresrc then to encoder?
static void
pipewire_output_handle_frame(struct pipewire_output *output, int fd,
int stride, struct drm_fb *drm_buffer)
{
...
if (pw_stream_get_state(output->stream, NULL) !=
PW_STREAM_STATE_STREAMING)
goto out;
buffer = pw_stream_dequeue_buffer(output->stream);
if (!buffer) {
weston_log("Failed to dequeue a pipewire buffer\n");
goto out;
}
spa_buffer = buffer->buffer;
...
ptr = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
memcpy(spa_buffer->datas[0].data, ptr, size);
munmap(ptr, size);
...
pw_stream_queue_buffer(output->stream, buffer);
}
>
> An alternative approach would be to hook up to a real existing output
> and copy frames from it when the remote video pipeline is ready to
> consume them. That could also side-step the issue of the video encoder
> wanting to keep a hold of too many old frames for reference, that would
> otherwise cause gbm_surface to run out of buffers.
>
> The screen-share plugin does the copying already through glReadPixels
> from an existing output. That would be fine for a software video
> encoder, but sub-optimal for a hardware video encoder.
>
> FWIW, I wrote down some ramblings here:
> https://gitlab.freedesktop.org/wayland/weston/issues/268
>
>
> Thanks,
> pq
-barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Independent clone mode
Pekka Paalanen 于2019年8月3日周六 上午12:24写道： > > On Wed, 31 Jul 2019 09:48:07 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Pekka Paalanen 于2019年7月27日周六 下午8:20写道： > > > > > > On Fri, 26 Jul 2019 08:58:42 +1200 > > > Barry Song <21cn...@gmail.com> wrote: > > > > > > > Pekka Paalanen 于2019年7月26日周五 上午3:30写道： > > > > > > > > > > On Thu, 25 Jul 2019 13:00:55 +1200 > > > > > Barry Song <21cn...@gmail.com> wrote: > > > > > > > > > > > Pekka Paalanen 于2019年7月24日周三 下午8:10写道： > > > > > > > > > > > > > > On Wed, 24 Jul 2019 13:22:43 +0800 > > > > > > > zou lan wrote: > > > > > > > > > > > > > > > Hi pekka > > > > > > > > > > > > > > > > I see the clone mode is supported from this commit message. > > > > > > > > https://patchwork.freedesktop.org/patch/227970/ > > > > > > > > > > > > > > > > I also see the message "Independent CRTC clone mode cannot be > > > > > > > > supported > > > > > > > > until output layout logic is moved from libweston into the > > > > > > > > frontend and > > > > > > > > libweston's damage tracking issues stemming from overlapping > > > > > > > > outputs are > > > > > > > > solved". > > > > > > > > > > > > > > > > I want to ask is independent CRTC clone mode already supported > > > > > > > > in Weston 6 > > > > > > > > or 7? If not, > > > > > > > > is there a plan to support it? > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > no, that commit message is still accurate. I don't know of any > > > > > > > plans to work on independent CRTC clone mode. > > > > > > > > > > > > Pekka, > > > > > > any possible workaround do you know to support independent crtc > > > > > > clone > > > > > > within weston? right now it is very important product feature. > > > > > > for example, force weston to identify only one screen, and sync copy > > > > > > the screen to 2nd screen and call the drm api of 2nd screen? > > > > > > > > > > Hi, > > > > > > > > > > you could hack it up to do that, but it would be in no way an > > > > > upstreamable solution. It would also hurt display timings because > > > > > every repaint would have to wait for both monitors to refresh. Or, > > > > > all but one monitor would tear. > > > > > > > > > > A simpler hack would be to create overlapping outputs and > > > > > force them repaint fully on every refresh instead of repainting > > > > > only the damage. That's not upstreamable either, but the damage > > > > > could be hacked with probably a one-liner. > > > > > > > > Hi Pekka, > > > > Thanks. even though i have seen many times that damage tracking of > > > > overlapping outputs is the main cause stopping weston from supporting > > > > full clone mode, i haven't fully understood what is overlapping > > > > outputs in weston and found the code related with overlapping output, > > > > would you like to point out some code path so that i can begin to do > > > > some work on it? pls forgive me if you think the question is just > > > > stupid. > > > > > > Hi, > > > > > > > > > i made a very great progress to hack weston to support clone mode in > > the direction you pointed out. > > > > it works very well without any tearing. > > Hi, > > sorry, I did not mean tearing. I meant areas with outdated content. > > I guess the best way to make that clearly visible is to have the > outputs overlap by 50%, not 100%, and then continuously move a window > such that it will cross all four areas: > - output A: exclusive area > - output A: shared with output B area > - output B: shared with output A area > - output B: exclusive area > > Then observe inconsistency in the image between the exclusive and the > shared area on each output separately. If you see the window decimate > on ei
Re: Independent clone mode
zou lan 于2019年8月1日周四 上午3:40写道： > > Hi Barry > > May I ask if the overlay path is considered for the views between cloned > outputs? For example, one view in this output could go through overlay, but > in other > cloned output, it can't. Or only using gpu composition for all cloned outputs? for this case, i suggest you don't use overlay. > > Thank you! > > Best Regards > Nancy > > Barry Song <21cn...@gmail.com> 于2019年7月31日周三 上午5:48写道： >> >> Pekka Paalanen 于2019年7月27日周六 下午8:20写道： >> > >> > On Fri, 26 Jul 2019 08:58:42 +1200 >> > Barry Song <21cn...@gmail.com> wrote: >> > >> > > Pekka Paalanen 于2019年7月26日周五 上午3:30写道： >> > > > >> > > > On Thu, 25 Jul 2019 13:00:55 +1200 >> > > > Barry Song <21cn...@gmail.com> wrote: >> > > > >> > > > > Pekka Paalanen 于2019年7月24日周三 下午8:10写道： >> > > > > > >> > > > > > On Wed, 24 Jul 2019 13:22:43 +0800 >> > > > > > zou lan wrote: >> > > > > > >> > > > > > > Hi pekka >> > > > > > > >> > > > > > > I see the clone mode is supported from this commit message. >> > > > > > > https://patchwork.freedesktop.org/patch/227970/ >> > > > > > > >> > > > > > > I also see the message "Independent CRTC clone mode cannot be >> > > > > > > supported >> > > > > > > until output layout logic is moved from libweston into the >> > > > > > > frontend and >> > > > > > > libweston's damage tracking issues stemming from overlapping >> > > > > > > outputs are >> > > > > > > solved". >> > > > > > > >> > > > > > > I want to ask is independent CRTC clone mode already supported >> > > > > > > in Weston 6 >> > > > > > > or 7? If not, >> > > > > > > is there a plan to support it? >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > no, that commit message is still accurate. I don't know of any >> > > > > > plans to work on independent CRTC clone mode. >> > > > > >> > > > > Pekka, >> > > > > any possible workaround do you know to support independent crtc clone >> > > > > within weston? right now it is very important product feature. >> > > > > for example, force weston to identify only one screen, and sync copy >> > > > > the screen to 2nd screen and call the drm api of 2nd screen? >> > > > >> > > > Hi, >> > > > >> > > > you could hack it up to do that, but it would be in no way an >> > > > upstreamable solution. It would also hurt display timings because >> > > > every repaint would have to wait for both monitors to refresh. Or, >> > > > all but one monitor would tear. >> > > > >> > > > A simpler hack would be to create overlapping outputs and >> > > > force them repaint fully on every refresh instead of repainting >> > > > only the damage. That's not upstreamable either, but the damage >> > > > could be hacked with probably a one-liner. >> > > >> > > Hi Pekka, >> > > Thanks. even though i have seen many times that damage tracking of >> > > overlapping outputs is the main cause stopping weston from supporting >> > > full clone mode, i haven't fully understood what is overlapping >> > > outputs in weston and found the code related with overlapping output, >> > > would you like to point out some code path so that i can begin to do >> > > some work on it? pls forgive me if you think the question is just >> > > stupid. >> > >> > Hi, >> > >> >> >> i made a very great progress to hack weston to support clone mode in >> the direction you pointed out. >> >> it works very well without any tearing. >> >> > what I suggested is not about code for overlapping outputs at all. >> > I'm simply suggesting to hack e.g. weston_output_repaint() or >> > something to ignore the accumulated damage and use full damage >> > instead. I can't tell you exactly what and where without doing it
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年7月27日周六 下午8:10写道：
>
> On Fri, 26 Jul 2019 13:31:47 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > Pekka Paalanen 于2019年7月26日周五 上午3:30写道：
>
> > > Hi,
> > >
> > > I don't think that would work too well, because eglSwapBuffers has
> > > not been called yet at that time, and using glReadPixels would hurt
> > > performance a lot.
> > >
> > > You don't need to use vaapi-recorder per se. You just hook up your
> > > sink exactly like vaapi-recorder does, and pay attention to
> > > synchronization.
> >
> > well. i'd like to continue in this way.
> > another possible solution is using a way like ffpmeg kmsgrab:
> > https://www.ffmpeg.org/ffmpeg-devices.html#Options-10
> >
> > it is using get the DRM framebuffer outside the weston:
> > https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/kmsgrab.c
> > by code like:
> > static int kmsgrab_read_packet(AVFormatContext *avctx, AVPacket *pkt)
> > {
> > ...
> > plane = drmModeGetPlane(ctx->hwctx->fd, ctx->plane_id);
> > ...
> > fb = drmModeGetFB(ctx->hwctx->fd, plane->fb_id);
> > ...
> > err = drmPrimeHandleToFD(ctx->hwctx->fd, fb->handle, O_RDONLY, &fd);
> > ...
> > desc = av_mallocz(sizeof(*desc));
> > ...
> > }
> >
> > do you think if kmsgrab will have some serial synchronization or
> > performance issues?
>
> Hi,
>
> first, I am surprised to hear kmsgrab exists or can even work
> at all. I guess the superuser is allowed to do all kinds of nasty
> things.
>
> I think synchronization issues are unavoidable with kmsgrab.
>
> There is no way to know when Weston flips the FB, right? That means
> you will be polling and randomly sampling the KMS state, so you
> don't know what frames you'll be getting. I imagine that causes
> jerky animation. Or you have to be polling very frequently to
> observe FB changes.
>
> Weston will be using hardware planes. This means that it is not
> enough to sample the primary plane, you have to sample all planes
> and the full KMS state including the active areas of each FB. Then
> you get to composite those various FBs together before you have a
> single picture.
>
> You will probably also have problems with buffer content
> synchronization: you may be reading the content while Weston is
> already flipped to another FB and is half-way repainting the buffer
> you are reading. This will cause artifacts in the image.
>
> So I cannot really recommend that approach at all, based on a
> theoretical analysis.
as said in the other email, independent clone mode has been resolved
by hacking weston damage tracking system.
i am looking for a solution to support remote screen mirroring. the
current idea is making the pipewire display work as a duplicated
display which shows the same content with the physical display.
this will probably resolve the screen mirror issue. would you like to
think it is the right direction?
>
>
> Thanks,
> pq
-barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Independent clone mode
Pekka Paalanen 于2019年7月27日周六 下午8:20写道：
>
> On Fri, 26 Jul 2019 08:58:42 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > Pekka Paalanen 于2019年7月26日周五 上午3:30写道：
> > >
> > > On Thu, 25 Jul 2019 13:00:55 +1200
> > > Barry Song <21cn...@gmail.com> wrote:
> > >
> > > > Pekka Paalanen 于2019年7月24日周三 下午8:10写道：
> > > > >
> > > > > On Wed, 24 Jul 2019 13:22:43 +0800
> > > > > zou lan wrote:
> > > > >
> > > > > > Hi pekka
> > > > > >
> > > > > > I see the clone mode is supported from this commit message.
> > > > > > https://patchwork.freedesktop.org/patch/227970/
> > > > > >
> > > > > > I also see the message "Independent CRTC clone mode cannot be
> > > > > > supported
> > > > > > until output layout logic is moved from libweston into the frontend
> > > > > > and
> > > > > > libweston's damage tracking issues stemming from overlapping
> > > > > > outputs are
> > > > > > solved".
> > > > > >
> > > > > > I want to ask is independent CRTC clone mode already supported in
> > > > > > Weston 6
> > > > > > or 7? If not,
> > > > > > is there a plan to support it?
> > > > >
> > > > > Hi,
> > > > >
> > > > > no, that commit message is still accurate. I don't know of any
> > > > > plans to work on independent CRTC clone mode.
> > > >
> > > > Pekka,
> > > > any possible workaround do you know to support independent crtc clone
> > > > within weston? right now it is very important product feature.
> > > > for example, force weston to identify only one screen, and sync copy
> > > > the screen to 2nd screen and call the drm api of 2nd screen?
> > >
> > > Hi,
> > >
> > > you could hack it up to do that, but it would be in no way an
> > > upstreamable solution. It would also hurt display timings because
> > > every repaint would have to wait for both monitors to refresh. Or,
> > > all but one monitor would tear.
> > >
> > > A simpler hack would be to create overlapping outputs and
> > > force them repaint fully on every refresh instead of repainting
> > > only the damage. That's not upstreamable either, but the damage
> > > could be hacked with probably a one-liner.
> >
> > Hi Pekka,
> > Thanks. even though i have seen many times that damage tracking of
> > overlapping outputs is the main cause stopping weston from supporting
> > full clone mode, i haven't fully understood what is overlapping
> > outputs in weston and found the code related with overlapping output,
> > would you like to point out some code path so that i can begin to do
> > some work on it? pls forgive me if you think the question is just
> > stupid.
>
> Hi,
>
i made a very great progress to hack weston to support clone mode in
the direction you pointed out.
it works very well without any tearing.
> what I suggested is not about code for overlapping outputs at all.
> I'm simply suggesting to hack e.g. weston_output_repaint() or
> something to ignore the accumulated damage and use full damage
> instead. I can't tell you exactly what and where without doing it
> myself first, which I cannot do at the moment.
hacked by:
@@ -2406,13 +2406,20 @@ weston_output_repaint(struct weston_output
*output, void *repaint_data)
}
}
- compositor_accumulate_damage(ec);
+ if (!output->external) {
+ compositor_accumulate_damage(ec);
- pixman_region32_init(&output_damage);
- pixman_region32_intersect(&output_damage,
- &ec->primary_plane.damage, &output->region);
- pixman_region32_subtract(&output_damage,
-&output_damage, &ec->primary_plane.clip);
+ pixman_region32_init(&output_damage);
+ pixman_region32_intersect(&output_damage,
+ &ec->primary_plane.damage, &output->region);
+ pixman_region32_subtract(&output_damage,
+ &output_damage, &ec->primary_plane.clip);
+ } else {
+ /** From Pekka Paalanen: the damage could be hacked
with probably
+* a one-liner, ignore the accumulated damage and use
full damage
+
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年7月26日周五 上午3:30写道：
>
> On Thu, 25 Jul 2019 13:06:02 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > Pekka Paalanen 于2019年7月24日周三 下午8:07写道：
> > >
> > > On Wed, 24 Jul 2019 14:02:43 +1200
> > > Barry Song <21cn...@gmail.com> wrote:
> > >
> > > > Hi Esaki,
> > > >
> > > > Esaki Tomohito 于2019年7月24日周三 下午1:44写道：
> > > > >
> > > > > Hello Barry,
> > > > >
> > > > > The remoting plugin doesn't support mirroring.
> > > > > If the recently merged pipewire plugin doesn't support mirroring,
> > > > > I think that weston doesn't support remote mirroring.
> > > > >
> > > >
> > > > thanks for your reply. it seems pipewire is a good plugin which can
> > > > move gstreamer pipeline out of weston. so it makes remote-plugin more
> > > > flexible.
> > > > but it is probably another extended screen rather than mirroring.
> > > >
> > > > I am wondering if it is possible to make the "same-as" clone-mode
> > > > support remote screen as well:
> > > > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html
> > > >
> > > > since remote screen has no real crtc, it should be able to simulate a
> > > > sharing-crtc scenerios which "same-as" clone-mode depends on?
> > >
> > > Hi,
> > >
> > > not the "same-as" directive specifically, because it is reserved
> > > for shared-CRTC cloning where the main feature is that the cloned
> > > outputs' timings are guaranteed to be synchronized in hardware.
> > >
> > > We need a new directive, "clone-of", or whatever, to denote
> > > independent outputs (meaning independent timings, pixel format,
> > > etc.) scanning out the same area of the desktop.
> > >
> > > The reason why that still has not been implemented is libweston's
> > > damage tracking framework. It needs to be re-designed, because
> > > currently it simply cannot have overlapping outputs - damage would
> > > be cleared too early when just the random first output repaints,
> > > leaving other overlapping outputs showing randomly old content.
> > >
> > > Another way could be to use the vaapi-recorder code paths and feed
> > > that video stream to a transmitter - or to pipewire, if the buffer
> > > reservation/release convetions allow (a real DRM output probably
> > > has only few buffers available, so the transmitter cannot keep a
> > > hold of very many at the same time). Another disadvantage is that
> > > the buffer domain, pixel format and modifier must be scanout-able,
> > > which may not be optimal or suitable for e.g. hardware video
> > > encoders. However, vaapi-recorder works, so it can obviously work
> > > at least on Intel.
> >
> > if vaapi-recorder is not available for an embedded system, do you
> > think if hacking libweston/screenshooter.c is an option?
> > i mean writing the frame to pipewire in screenshooter_frame_notify()?
>
> Hi,
>
> I don't think that would work too well, because eglSwapBuffers has
> not been called yet at that time, and using glReadPixels would hurt
> performance a lot.
>
> You don't need to use vaapi-recorder per se. You just hook up your
> sink exactly like vaapi-recorder does, and pay attention to
> synchronization.
well. i'd like to continue in this way.
another possible solution is using a way like ffpmeg kmsgrab:
https://www.ffmpeg.org/ffmpeg-devices.html#Options-10
it is using get the DRM framebuffer outside the weston:
https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/kmsgrab.c
by code like:
static int kmsgrab_read_packet(AVFormatContext *avctx, AVPacket *pkt)
{
...
plane = drmModeGetPlane(ctx->hwctx->fd, ctx->plane_id);
...
fb = drmModeGetFB(ctx->hwctx->fd, plane->fb_id);
...
err = drmPrimeHandleToFD(ctx->hwctx->fd, fb->handle, O_RDONLY, &fd);
...
desc = av_mallocz(sizeof(*desc));
...
}
do you think if kmsgrab will have some serial synchronization or
performance issues?
>
>
> Thanks,
> pq
-barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Independent clone mode
Pekka Paalanen 于2019年7月26日周五 上午3:30写道： > > On Thu, 25 Jul 2019 13:00:55 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Pekka Paalanen 于2019年7月24日周三 下午8:10写道： > > > > > > On Wed, 24 Jul 2019 13:22:43 +0800 > > > zou lan wrote: > > > > > > > Hi pekka > > > > > > > > I see the clone mode is supported from this commit message. > > > > https://patchwork.freedesktop.org/patch/227970/ > > > > > > > > I also see the message "Independent CRTC clone mode cannot be supported > > > > until output layout logic is moved from libweston into the frontend and > > > > libweston's damage tracking issues stemming from overlapping outputs are > > > > solved". > > > > > > > > I want to ask is independent CRTC clone mode already supported in > > > > Weston 6 > > > > or 7? If not, > > > > is there a plan to support it? > > > > > > Hi, > > > > > > no, that commit message is still accurate. I don't know of any > > > plans to work on independent CRTC clone mode. > > > > Pekka, > > any possible workaround do you know to support independent crtc clone > > within weston? right now it is very important product feature. > > for example, force weston to identify only one screen, and sync copy > > the screen to 2nd screen and call the drm api of 2nd screen? > > Hi, > > you could hack it up to do that, but it would be in no way an > upstreamable solution. It would also hurt display timings because > every repaint would have to wait for both monitors to refresh. Or, > all but one monitor would tear. > > A simpler hack would be to create overlapping outputs and > force them repaint fully on every refresh instead of repainting > only the damage. That's not upstreamable either, but the damage > could be hacked with probably a one-liner. Hi Pekka, Thanks. even though i have seen many times that damage tracking of overlapping outputs is the main cause stopping weston from supporting full clone mode, i haven't fully understood what is overlapping outputs in weston and found the code related with overlapping output, would you like to point out some code path so that i can begin to do some work on it? pls forgive me if you think the question is just stupid. > > > Thanks, > pq -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年7月24日周三 下午8:07写道： > > On Wed, 24 Jul 2019 14:02:43 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Hi Esaki, > > > > Esaki Tomohito 于2019年7月24日周三 下午1:44写道： > > > > > > Hello Barry, > > > > > > The remoting plugin doesn't support mirroring. > > > If the recently merged pipewire plugin doesn't support mirroring, > > > I think that weston doesn't support remote mirroring. > > > > > > > thanks for your reply. it seems pipewire is a good plugin which can > > move gstreamer pipeline out of weston. so it makes remote-plugin more > > flexible. > > but it is probably another extended screen rather than mirroring. > > > > I am wondering if it is possible to make the "same-as" clone-mode > > support remote screen as well: > > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html > > > > since remote screen has no real crtc, it should be able to simulate a > > sharing-crtc scenerios which "same-as" clone-mode depends on? > > Hi, > > not the "same-as" directive specifically, because it is reserved > for shared-CRTC cloning where the main feature is that the cloned > outputs' timings are guaranteed to be synchronized in hardware. > > We need a new directive, "clone-of", or whatever, to denote > independent outputs (meaning independent timings, pixel format, > etc.) scanning out the same area of the desktop. > > The reason why that still has not been implemented is libweston's > damage tracking framework. It needs to be re-designed, because > currently it simply cannot have overlapping outputs - damage would > be cleared too early when just the random first output repaints, > leaving other overlapping outputs showing randomly old content. > > Another way could be to use the vaapi-recorder code paths and feed > that video stream to a transmitter - or to pipewire, if the buffer > reservation/release convetions allow (a real DRM output probably > has only few buffers available, so the transmitter cannot keep a > hold of very many at the same time). Another disadvantage is that > the buffer domain, pixel format and modifier must be scanout-able, > which may not be optimal or suitable for e.g. hardware video > encoders. However, vaapi-recorder works, so it can obviously work > at least on Intel. if vaapi-recorder is not available for an embedded system, do you think if hacking libweston/screenshooter.c is an option? i mean writing the frame to pipewire in screenshooter_frame_notify()? > > > Thanks, > pq -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Independent clone mode
Pekka Paalanen 于2019年7月24日周三 下午8:10写道： > > On Wed, 24 Jul 2019 13:22:43 +0800 > zou lan wrote: > > > Hi pekka > > > > I see the clone mode is supported from this commit message. > > https://patchwork.freedesktop.org/patch/227970/ > > > > I also see the message "Independent CRTC clone mode cannot be supported > > until output layout logic is moved from libweston into the frontend and > > libweston's damage tracking issues stemming from overlapping outputs are > > solved". > > > > I want to ask is independent CRTC clone mode already supported in Weston 6 > > or 7? If not, > > is there a plan to support it? > > Hi, > > no, that commit message is still accurate. I don't know of any > plans to work on independent CRTC clone mode. Pekka, any possible workaround do you know to support independent crtc clone within weston? right now it is very important product feature. for example, force weston to identify only one screen, and sync copy the screen to 2nd screen and call the drm api of 2nd screen? i don't think the so-called "clone" supported by ivi-shell is what i want. > > > Thanks, > pq -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
Hi Esaki, Esaki Tomohito 于2019年7月24日周三 下午1:44写道： > > Hello Barry, > > The remoting plugin doesn't support mirroring. > If the recently merged pipewire plugin doesn't support mirroring, > I think that weston doesn't support remote mirroring. > thanks for your reply. it seems pipewire is a good plugin which can move gstreamer pipeline out of weston. so it makes remote-plugin more flexible. but it is probably another extended screen rather than mirroring. I am wondering if it is possible to make the "same-as" clone-mode support remote screen as well: https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html since remote screen has no real crtc, it should be able to simulate a sharing-crtc scenerios which "same-as" clone-mode depends on? > pipewire plugin: > https://gitlab.freedesktop.org/wayland/weston/merge_requests/177 > > Thanks, > Esaki > > On 2019/07/24 6:24, Barry Song wrote: > > + Tomohito Esaki > > > > using remote-output i found i could broadcast a virtual screen through > > UDP. but this screen is working as an extension of existing physical > > screens. is it possible for it to mirror the existing screen, > > displaying same content? > > there is a "same-as" option for physical screen, but it seems it > > doesn't work for remote-output: > > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html > > > > Barry Song <21cn...@gmail.com> 于2019年7月22日周一 上午8:57写道： > >> > >> Daniel Stone 于2019年7月21日周日 上午6:48写道： > >>> > >>> Hi Barry, > >>> > >>> On Sun, 21 Jul 2019 at 00:33, Barry Song <21cn...@gmail.com> wrote: > >>>> if i want to send the framebuffers using DRM backend as the video src > >>>> in gstreamer to networks through rtsp, does weston have an existing > >>>> solution. > >>>> > >>>> i mean something similar with the below for /dev/fb0 backend: > >>>> sudo ./test-launch "( multifilesrc location=/dev/fb0 ! videoparse > >>>> format=29 framerate=30/1 ! decodebin ! videoconvert ! x264enc ! > >>>> rtph264pay name=pay0 pt=96 )" > >>>> > >>>> but if the backend is DRM, it seems it is much different, only weston > >>>> is the master of DRM. > >>>> > >>>> after some investigation, i found weston supports rdp and virtual > >>>> remote display. but it seems both of them is not what i want. > >>> > >>> The DRM backend has remote-display support, which lets you specify an > >>> arbitrary GStreamer pipeline as of the 7.0 alpha release. Details on > >>> configuring it are available in the weston-drm manpage. > >> > >> Hi Daniel, > >> Thanks for your information. > >> Do you mean the below remote-output? is it a mirror of existing screen > >> or is it a new separate screen? > >> i mean whether i can display the same content on the remote output as > >> the existing physical LCD like a clone mode? > >> or the remote output is working as an extension of the existing screens? > >> > >> Section remote-output > >> name=name > >> Specify unique name for the output. > >> mode=mode > >> Specify the video mode for the output. The argument mode is a > >> resolution setting, such as: > >> mode=widthxheight mode=widthxheight@refresh_rate > >> If refresh_rate is not specified it will default to a 60Hz. > >> host=host > >> Specify the host name or IP Address that the remote output will be > >> transmitted to. > >> port=port > >> Specify the port number to transmit the remote output to. Usable port > >> range is 1-65533. > >> > >>> > >>> > >>> CHeers, > >>> Daniel > >> > >> -barry -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
+ Tomohito Esaki using remote-output i found i could broadcast a virtual screen through UDP. but this screen is working as an extension of existing physical screens. is it possible for it to mirror the existing screen, displaying same content? there is a "same-as" option for physical screen, but it seems it doesn't work for remote-output: https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html Barry Song <21cn...@gmail.com> 于2019年7月22日周一 上午8:57写道： > > Daniel Stone 于2019年7月21日周日 上午6:48写道： > > > > Hi Barry, > > > > On Sun, 21 Jul 2019 at 00:33, Barry Song <21cn...@gmail.com> wrote: > > > if i want to send the framebuffers using DRM backend as the video src > > > in gstreamer to networks through rtsp, does weston have an existing > > > solution. > > > > > > i mean something similar with the below for /dev/fb0 backend: > > > sudo ./test-launch "( multifilesrc location=/dev/fb0 ! videoparse > > > format=29 framerate=30/1 ! decodebin ! videoconvert ! x264enc ! > > > rtph264pay name=pay0 pt=96 )" > > > > > > but if the backend is DRM, it seems it is much different, only weston > > > is the master of DRM. > > > > > > after some investigation, i found weston supports rdp and virtual > > > remote display. but it seems both of them is not what i want. > > > > The DRM backend has remote-display support, which lets you specify an > > arbitrary GStreamer pipeline as of the 7.0 alpha release. Details on > > configuring it are available in the weston-drm manpage. > > Hi Daniel, > Thanks for your information. > Do you mean the below remote-output? is it a mirror of existing screen > or is it a new separate screen? > i mean whether i can display the same content on the remote output as > the existing physical LCD like a clone mode? > or the remote output is working as an extension of the existing screens? > > Section remote-output > name=name > Specify unique name for the output. > mode=mode > Specify the video mode for the output. The argument mode is a > resolution setting, such as: > mode=widthxheight mode=widthxheight@refresh_rate > If refresh_rate is not specified it will default to a 60Hz. > host=host > Specify the host name or IP Address that the remote output will be > transmitted to. > port=port > Specify the port number to transmit the remote output to. Usable port > range is 1-65533. > > > > > > > CHeers, > > Daniel > > -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: has weston a rtsp video src support?
Daniel Stone 于2019年7月21日周日 上午6:48写道： > > Hi Barry, > > On Sun, 21 Jul 2019 at 00:33, Barry Song <21cn...@gmail.com> wrote: > > if i want to send the framebuffers using DRM backend as the video src > > in gstreamer to networks through rtsp, does weston have an existing > > solution. > > > > i mean something similar with the below for /dev/fb0 backend: > > sudo ./test-launch "( multifilesrc location=/dev/fb0 ! videoparse > > format=29 framerate=30/1 ! decodebin ! videoconvert ! x264enc ! > > rtph264pay name=pay0 pt=96 )" > > > > but if the backend is DRM, it seems it is much different, only weston > > is the master of DRM. > > > > after some investigation, i found weston supports rdp and virtual > > remote display. but it seems both of them is not what i want. > > The DRM backend has remote-display support, which lets you specify an > arbitrary GStreamer pipeline as of the 7.0 alpha release. Details on > configuring it are available in the weston-drm manpage. Hi Daniel, Thanks for your information. Do you mean the below remote-output? is it a mirror of existing screen or is it a new separate screen? i mean whether i can display the same content on the remote output as the existing physical LCD like a clone mode? or the remote output is working as an extension of the existing screens? Section remote-output name=name Specify unique name for the output. mode=mode Specify the video mode for the output. The argument mode is a resolution setting, such as: mode=widthxheight mode=widthxheight@refresh_rate If refresh_rate is not specified it will default to a 60Hz. host=host Specify the host name or IP Address that the remote output will be transmitted to. port=port Specify the port number to transmit the remote output to. Usable port range is 1-65533. > > > CHeers, > Daniel -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
has weston a rtsp video src support?
Hi guys, if i want to send the framebuffers using DRM backend as the video src in gstreamer to networks through rtsp, does weston have an existing solution. i mean something similar with the below for /dev/fb0 backend: sudo ./test-launch "( multifilesrc location=/dev/fb0 ! videoparse format=29 framerate=30/1 ! decodebin ! videoconvert ! x264enc ! rtph264pay name=pay0 pt=96 )" but if the backend is DRM, it seems it is much different, only weston is the master of DRM. after some investigation, i found weston supports rdp and virtual remote display. but it seems both of them is not what i want. Thanks barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
Scott Anderson 于2019年5月6日周一 下午1:45写道： > > On 6/05/19 1:37 pm, Barry Song wrote: > > sorry for the ascii text picture can't show well in gmail. the > > animation is pretty much like > > drop-down terminal - Yakuake > > https://kde.org/applications/system/yakuake/ > > > > when you push a key, the Yakuake will move out from the top. > > > > > > Barry Song <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > >> > >> Hi Simon, > >> > >> Simon Ser 于2019年5月6日周一 上午9:54写道： > >>> > >>> Hi, > >>> > >>> On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@gmail.com> wrote: > >>>> Hi, > >>>> It seems wayland doesn't support the move() and setGeometry() from > >>>> clients. No any message is sent from Qt to weston for qWidget.move() > >>>> or qDialog.move(). So weston has no any idea that clients are > >>>> requesting to move a window. > >>>> Under this condition, how could people implement animation of a window? > >>>> > >>>> Right now, a software uses a timer to move window, in the callback of > >>>> the timer, the window is moved a little and the timer is fired again. > >>>> So the window can move and move, which is generating an animation. > >>>> This works well in non-wayland platforms. But the move() codes seems > >>>> to have no any impact under wayland. > >>>> > >>>> So do we have some alternative way to implement the animation of a > >>>> window? > >>> > >>> This has been intentionally left out. > >>> > >>> Could you explain exactly what is your use-case? What kind of > >>> application are you working on, what does this dialog contain, what you > >>> want to do? > >> > >> click a button, a window will move out from the top to its position. > >> > >> click a button, a window will move out from the right to its position. > >> > >> the windows are not shown on screen directly, it is moving out. > >> > >>> > >>> Thanks, > >>> > >>> -- > >>> Simon Ser > >>> https://emersion.fr > >> > >> -barry > > Hi, > > This is the kind of feature that would be implemented in the compositor, > not in the client. As Simon already mentioned, normal clients have know > knowledge or control of where they are placed. > > However, there is an extension protocol called wlr-layer-shell which > allows clients to anchor itself to the side of the screen (among other > things) which would work for something like Yakuake, but that is not > implemented in all compositors. it seems set_anchor() can set window to a corner, but it doesn't have the animation according to the below? Requests that the compositor anchor the surface to the specified edges and corners. If two orthogonal edges are specified (e.g. 'top' and 'left'), then the anchor point will be the intersection of the edges (e.g. the top left corner of the output); otherwise the anchor point will be centered on that edge, or in the center if none is specified. Anchor is double-buffered, see wl_surface.commit. > > Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
Scott Anderson 于2019年5月6日周一 下午1:45写道： > > On 6/05/19 1:37 pm, Barry Song wrote: > > sorry for the ascii text picture can't show well in gmail. the > > animation is pretty much like > > drop-down terminal - Yakuake > > https://kde.org/applications/system/yakuake/ > > > > when you push a key, the Yakuake will move out from the top. > > > > > > Barry Song <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > >> > >> Hi Simon, > >> > >> Simon Ser 于2019年5月6日周一 上午9:54写道： > >>> > >>> Hi, > >>> > >>> On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@gmail.com> wrote: > >>>> Hi, > >>>> It seems wayland doesn't support the move() and setGeometry() from > >>>> clients. No any message is sent from Qt to weston for qWidget.move() > >>>> or qDialog.move(). So weston has no any idea that clients are > >>>> requesting to move a window. > >>>> Under this condition, how could people implement animation of a window? > >>>> > >>>> Right now, a software uses a timer to move window, in the callback of > >>>> the timer, the window is moved a little and the timer is fired again. > >>>> So the window can move and move, which is generating an animation. > >>>> This works well in non-wayland platforms. But the move() codes seems > >>>> to have no any impact under wayland. > >>>> > >>>> So do we have some alternative way to implement the animation of a > >>>> window? > >>> > >>> This has been intentionally left out. > >>> > >>> Could you explain exactly what is your use-case? What kind of > >>> application are you working on, what does this dialog contain, what you > >>> want to do? > >> > >> click a button, a window will move out from the top to its position. > >> > >> click a button, a window will move out from the right to its position. > >> > >> the windows are not shown on screen directly, it is moving out. > >> > >>> > >>> Thanks, > >>> > >>> -- > >>> Simon Ser > >>> https://emersion.fr > >> > >> -barry > > Hi, > > This is the kind of feature that would be implemented in the compositor, > not in the client. As Simon already mentioned, normal clients have know > knowledge or control of where they are placed. while I agree this feature should be implemented in compositor, client still needs to tell compositor which window needs this animation as not everyone needs it. how can compositor knows which window needs moving out and which needs to present directly if there are no any code difference between these two kinds of windows? right now, using non-wayland, clients can differentiate by QDialog D1, D2; T1 time: D1.move(x1, y1); T2 time: D1.move(x2, y2); D2.show(); Then D1 has animation, but D2 has no. > > However, there is an extension protocol called wlr-layer-shell which > allows clients to anchor itself to the side of the screen (among other > things) which would work for something like Yakuake, but that is not > implemented in all compositors. > > Scott -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
sorry for the ascii text picture can't show well in gmail. the animation is pretty much like drop-down terminal - Yakuake https://kde.org/applications/system/yakuake/ when you push a key, the Yakuake will move out from the top. Barry Song <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > > Hi Simon, > > Simon Ser 于2019年5月6日周一 上午9:54写道： > > > > Hi, > > > > On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@gmail.com> wrote: > > > Hi, > > > It seems wayland doesn't support the move() and setGeometry() from > > > clients. No any message is sent from Qt to weston for qWidget.move() > > > or qDialog.move(). So weston has no any idea that clients are > > > requesting to move a window. > > > Under this condition, how could people implement animation of a window? > > > > > > Right now, a software uses a timer to move window, in the callback of > > > the timer, the window is moved a little and the timer is fired again. > > > So the window can move and move, which is generating an animation. > > > This works well in non-wayland platforms. But the move() codes seems > > > to have no any impact under wayland. > > > > > > So do we have some alternative way to implement the animation of a window? > > > > This has been intentionally left out. > > > > Could you explain exactly what is your use-case? What kind of > > application are you working on, what does this dialog contain, what you > > want to do? > > click a button, a window will move out from the top to its position. > > > `-`-.```- > `. - > `.. - > `. - > `.- - > `. - > `.- - > `. - > `.- - > `. - > `. ` -` - > `. > -. ``:` - > `. > `- > `. > - > `. > - > `. > - > `. > - > `. > - > `. > - > `. > - > `. > - > `. > - > `. > - > > .``` > > click a button, a window will move out from the right to its position. > > the windows are not shown on screen directly, it is moving out. > > > > > Thanks, > > > > -- > > Simon Ser > > https://emersion.fr > > -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
Hi Simon, Simon Ser 于2019年5月6日周一 上午9:54写道： > > Hi, > > On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@gmail.com> wrote: > > Hi, > > It seems wayland doesn't support the move() and setGeometry() from > > clients. No any message is sent from Qt to weston for qWidget.move() > > or qDialog.move(). So weston has no any idea that clients are > > requesting to move a window. > > Under this condition, how could people implement animation of a window? > > > > Right now, a software uses a timer to move window, in the callback of > > the timer, the window is moved a little and the timer is fired again. > > So the window can move and move, which is generating an animation. > > This works well in non-wayland platforms. But the move() codes seems > > to have no any impact under wayland. > > > > So do we have some alternative way to implement the animation of a window? > > This has been intentionally left out. > > Could you explain exactly what is your use-case? What kind of > application are you working on, what does this dialog contain, what you > want to do? click a button, a window will move out from the top to its position. `-`-.```- `. - `.. - `. - `.- - `. - `.- - `. - `.- - `. - `. ` -` - `. -. ``:` - `. `- `. - `. - `. - `. - `. - `. - `. - `. - `. - `. - .``` click a button, a window will move out from the right to its position. the windows are not shown on screen directly, it is moving out. > > Thanks, > > -- > Simon Ser > https://emersion.fr -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
how to implement animation in wayland since window move request is not supported?
Hi, It seems wayland doesn't support the move() and setGeometry() from clients. No any message is sent from Qt to weston for qWidget.move() or qDialog.move(). So weston has no any idea that clients are requesting to move a window. Under this condition, how could people implement animation of a window? Right now, a software uses a timer to move window, in the callback of the timer, the window is moved a little and the timer is fired again. So the window can move and move, which is generating an animation. This works well in non-wayland platforms. But the move() codes seems to have no any impact under wayland. So do we have some alternative way to implement the animation of a window? Thanks barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
Simon Ser 于2019年4月26日周五 下午4:57写道： > > On Friday, April 26, 2019 12:58 AM, Barry Song <21cn...@gmail.com> wrote: > > Simon Ser cont...@emersion.fr 于2019年4月17日周三 下午10:26写道： > > > > > On Wednesday, April 17, 2019 1:23 PM, Barry Song 21cn...@gmail.com wrote: > > > > > > > Simon Ser cont...@emersion.fr 于2019年4月15日周一 下午5:18写道： > > > > > > > > > Hi, > > > > > Weston now uses GitLab 1 merge requests for contributions. Can you > > > > > resend your patch on GitLab? > > > > > > > > sure. do i just need to send it for master, or do we also do a fix for > > > > 6.0 and 5.0 release? > > > > > > A merge request for master would be enough. Once the fix is merged we > > > can discuss about backporting (though we generally don't do it). > > > > Ongoing on gitlab and Daniel Stone is handling the pull request. > > > > BTW, I am looking forward for some comment from you about: > > "weird behavior of transient windows in desktop shell in weston" > > https://lists.freedesktop.org/archives/wayland-devel/2019-April/040501.html > > For bug reports, you can open issues on GitLab. But I think there's > already an issue opened for the bug you describe: > > https://gitlab.freedesktop.org/wayland/weston/issues/231 > > Can you confirm? it is basically one same bug as i am reporting. not only modal dialogs, all transient dialogs have unexpected behaviour in weston. Other window managers will keep child windows on top, but weston takes child dialogs as top-level. > -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
Simon Ser 于2019年4月17日周三 下午10:26写道： > > On Wednesday, April 17, 2019 1:23 PM, Barry Song <21cn...@gmail.com> wrote: > > Simon Ser cont...@emersion.fr 于2019年4月15日周一 下午5:18写道： > > > > > Hi, > > > Weston now uses GitLab 1 merge requests for contributions. Can you > > > resend your patch on GitLab? > > > > sure. do i just need to send it for master, or do we also do a fix for > > 6.0 and 5.0 release? > > A merge request for master would be enough. Once the fix is merged we > can discuss about backporting (though we generally don't do it). Ongoing on gitlab and Daniel Stone is handling the pull request. BTW, I am looking forward for some comment from you about: "weird behavior of transient windows in desktop shell in weston" https://lists.freedesktop.org/archives/wayland-devel/2019-April/040501.html > > Thanks, > > Simon -barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weird behavior of transient windows in desktop shell in weston
ping
Barry Song <21cn...@gmail.com> 于2019年4月17日周三 下午10:19写道：
>
> Hi guys,
>
> I got some very weird result while using transient window in weston.
> Let's start from a simplest qt program:
>
> int main(int argc, char *argv[])
> {
> QApplication a(argc, argv);
> MainWindow w;
> w.show();
>
> QDialog d1(&w)
> d1.setWindowTitle("transient& non toplevel dialog d1");
> d1.show();
>
> return a.exec();
> }
> Under x11 or mutter wayland compositor, D1 transient window will
> always be on the top of Mainwindow W. But under weston desktop shell,
> if we click mainwindow, d1 will be covered by mainwindow W.
>
> I tried to read source code to figure out why and found weston will
> only think WL_SHELL_SURFACE_TRANSIENT_INACTIVE transient windows as
> "TRANSIENT", otherwise it will think it as "TOPLEVEL" window.
> code path: libweston-desktop/wl-shell.c
>
> static void
> weston_desktop_wl_shell_surface_protocol_set_transient(struct
> wl_client *wl_client,
>struct
> wl_resource *resource,
>struct
> wl_resource *parent_resource,
>int32_t x, int32_t y,
>enum
> wl_shell_surface_transient flags)
> {
> struct weston_desktop_surface *dsurface =
> wl_resource_get_user_data(resource);
> struct weston_surface *wparent =
> wl_resource_get_user_data(parent_resource);
> struct weston_desktop_surface *parent;
> struct weston_desktop_wl_shell_surface *surface =
> weston_desktop_surface_get_implementation_data(dsurface);
>
> if (!weston_surface_is_desktop_surface(wparent))
> return;
>
> parent = weston_surface_get_desktop_surface(wparent);
> if (flags & WL_SHELL_SURFACE_TRANSIENT_INACTIVE) {
> weston_desktop_wl_shell_change_state(surface, TRANSIENT,
> parent,
> x, y);
> } else {
> weston_desktop_wl_shell_change_state(surface, TOPLEVEL, NULL,
> 0, 0);
> surface->parent = parent;
> weston_desktop_api_set_parent(surface->desktop,
> surface->surface, parent);
> }
> }
>
> Actually WL_SHELL_SURFACE_TRANSIENT_INACTIVE is pretty difficult to be
> true unless we put Qt::WindowTransparentForInput or Qt::ToolTip for a
> qt window.
>
> On the other hand, mutter doesn't check this flag at all:
>
> code path: mutter/src/wayland/meta-wayland-wl-shell.c
> static void
> wl_shell_surface_set_transient (struct wl_client *client,
> struct wl_resource *resource,
> struct wl_resource *parent_resource,
> int32_t x,
> int32_t y,
> uint32_tflags)
> {
> MetaWaylandWlShellSurface *wl_shell_surface =
> META_WAYLAND_WL_SHELL_SURFACE (wl_resource_get_user_data (resource));
> MetaWaylandSurface *surface =
> surface_from_wl_shell_surface_resource (resource);
> MetaWaylandSurface *parent_surf = wl_resource_get_user_data
> (parent_resource);
>
> wl_shell_surface_set_state (surface,
> META_WL_SHELL_SURFACE_STATE_TRANSIENT);
>
> set_wl_shell_surface_parent (surface, parent_surf);
> wl_shell_surface->x = x;
> wl_shell_surface->y = y;
>
> if (surface->window && parent_surf->window)
> sync_wl_shell_parent_relationship (surface, parent_surf);
> }
>
> I seem mutter is doing right things just like a typical x11 window manager.
>
> On the other hand, the code path of
> WL_SHELL_SURFACE_TRANSIENT_INACTIVE can easily crash as I have sent
> the patch yesterday:
> commit e87c23ffcf3dc209cb8e7f24c3087636b8db3f53 (HEAD -> 6.0)
> Author: Barry Song
> Date: Mon Apr 15 11:28:07 2019 +1200
>
> desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
>
> It is pretty easy to replicate this bug by involving a Qt Window with
> Qt::WindowTransparentForInput flag.
>
> int main(int argc, char *argv[])
> {
> QApplication a(argc, argv);
> MainWindow w;
> w.show();
>
> QDialog d1(&w, Qt::WindowTransparentForInput);
> d1.show();
>
&
Re: [PATCH] desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
Simon Ser 于2019年4月15日周一 下午5:18写道： > > Hi, > > Weston now uses GitLab [1] merge requests for contributions. Can you > resend your patch on GitLab? sure. do i just need to send it for master, or do we also do a fix for 6.0 and 5.0 release? > > Thanks, > > [1]: https://gitlab.freedesktop.org/wayland/weston > > -- > Simon Ser > https://emersion.fr Barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
weird behavior of transient windows in desktop shell in weston
Hi guys,
I got some very weird result while using transient window in weston.
Let's start from a simplest qt program:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
QDialog d1(&w)
d1.setWindowTitle("transient& non toplevel dialog d1");
d1.show();
return a.exec();
}
Under x11 or mutter wayland compositor, D1 transient window will
always be on the top of Mainwindow W. But under weston desktop shell,
if we click mainwindow, d1 will be covered by mainwindow W.
I tried to read source code to figure out why and found weston will
only think WL_SHELL_SURFACE_TRANSIENT_INACTIVE transient windows as
"TRANSIENT", otherwise it will think it as "TOPLEVEL" window.
code path: libweston-desktop/wl-shell.c
static void
weston_desktop_wl_shell_surface_protocol_set_transient(struct
wl_client *wl_client,
struct
wl_resource *resource,
struct
wl_resource *parent_resource,
int32_t x, int32_t y,
enum
wl_shell_surface_transient flags)
{
struct weston_desktop_surface *dsurface =
wl_resource_get_user_data(resource);
struct weston_surface *wparent =
wl_resource_get_user_data(parent_resource);
struct weston_desktop_surface *parent;
struct weston_desktop_wl_shell_surface *surface =
weston_desktop_surface_get_implementation_data(dsurface);
if (!weston_surface_is_desktop_surface(wparent))
return;
parent = weston_surface_get_desktop_surface(wparent);
if (flags & WL_SHELL_SURFACE_TRANSIENT_INACTIVE) {
weston_desktop_wl_shell_change_state(surface, TRANSIENT, parent,
x, y);
} else {
weston_desktop_wl_shell_change_state(surface, TOPLEVEL, NULL,
0, 0);
surface->parent = parent;
weston_desktop_api_set_parent(surface->desktop,
surface->surface, parent);
}
}
Actually WL_SHELL_SURFACE_TRANSIENT_INACTIVE is pretty difficult to be
true unless we put Qt::WindowTransparentForInput or Qt::ToolTip for a
qt window.
On the other hand, mutter doesn't check this flag at all:
code path: mutter/src/wayland/meta-wayland-wl-shell.c
static void
wl_shell_surface_set_transient (struct wl_client *client,
struct wl_resource *resource,
struct wl_resource *parent_resource,
int32_t x,
int32_t y,
uint32_tflags)
{
MetaWaylandWlShellSurface *wl_shell_surface =
META_WAYLAND_WL_SHELL_SURFACE (wl_resource_get_user_data (resource));
MetaWaylandSurface *surface =
surface_from_wl_shell_surface_resource (resource);
MetaWaylandSurface *parent_surf = wl_resource_get_user_data (parent_resource);
wl_shell_surface_set_state (surface,
META_WL_SHELL_SURFACE_STATE_TRANSIENT);
set_wl_shell_surface_parent (surface, parent_surf);
wl_shell_surface->x = x;
wl_shell_surface->y = y;
if (surface->window && parent_surf->window)
sync_wl_shell_parent_relationship (surface, parent_surf);
}
I seem mutter is doing right things just like a typical x11 window manager.
On the other hand, the code path of
WL_SHELL_SURFACE_TRANSIENT_INACTIVE can easily crash as I have sent
the patch yesterday:
commit e87c23ffcf3dc209cb8e7f24c3087636b8db3f53 (HEAD -> 6.0)
Author: Barry Song
Date: Mon Apr 15 11:28:07 2019 +1200
desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
It is pretty easy to replicate this bug by involving a Qt Window with
Qt::WindowTransparentForInput flag.
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
QDialog d1(&w, Qt::WindowTransparentForInput);
d1.show();
return a.exec();
}
Click d1 dialog, weston will crash.
Signed-off-by: Barry Song
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 93b1c70b..9473bac1 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2697,11 +2697,16 @@ desktop_surface_move(struct
weston_desktop_surface *desktop_surface,
struct weston_touch *touch = weston_seat_get_touch(seat);
struct shell_surface *shsurf =
weston_desktop_surface_get_user_data(desktop_surface);
- struct weston_surface *surface =
- weston_desktop_surface_get_surface(shsurf->desktop_surfac
weird behavior of transient windows in desktop shell in weston
Hi guys,
I got some very weird result while using transient window in weston.
Let's start from a simplest qt program:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
QDialog d1(&w)
d1.setWindowTitle("transient& non toplevel dialog d1");
d1.show();
return a.exec();
}
Under x11 or mutter wayland compositor, D1 transient window will
always be on the top of Mainwindow W. But under weston desktop shell,
if we click mainwindow, d1 will be covered by mainwindow W.
I tried to read source code to figure out why and found weston will
only think WL_SHELL_SURFACE_TRANSIENT_INACTIVE transient windows as
"TRANSIENT", otherwise it will think it as "TOPLEVEL" window.
code path: libweston-desktop/wl-shell.c
static void
weston_desktop_wl_shell_surface_protocol_set_transient(struct
wl_client *wl_client,
struct
wl_resource *resource,
struct
wl_resource *parent_resource,
int32_t x, int32_t y,
enum
wl_shell_surface_transient flags)
{
struct weston_desktop_surface *dsurface =
wl_resource_get_user_data(resource);
struct weston_surface *wparent =
wl_resource_get_user_data(parent_resource);
struct weston_desktop_surface *parent;
struct weston_desktop_wl_shell_surface *surface =
weston_desktop_surface_get_implementation_data(dsurface);
if (!weston_surface_is_desktop_surface(wparent))
return;
parent = weston_surface_get_desktop_surface(wparent);
if (flags & WL_SHELL_SURFACE_TRANSIENT_INACTIVE) {
weston_desktop_wl_shell_change_state(surface, TRANSIENT, parent,
x, y);
} else {
weston_desktop_wl_shell_change_state(surface, TOPLEVEL, NULL,
0, 0);
surface->parent = parent;
weston_desktop_api_set_parent(surface->desktop,
surface->surface, parent);
}
}
Actually WL_SHELL_SURFACE_TRANSIENT_INACTIVE is pretty difficult to be
true unless we put Qt::WindowTransparentForInput or Qt::ToolTip for a
qt window.
On the other hand, mutter doesn't check this flag at all:
code path: mutter/src/wayland/meta-wayland-wl-shell.c
static void
wl_shell_surface_set_transient (struct wl_client *client,
struct wl_resource *resource,
struct wl_resource *parent_resource,
int32_t x,
int32_t y,
uint32_tflags)
{
MetaWaylandWlShellSurface *wl_shell_surface =
META_WAYLAND_WL_SHELL_SURFACE (wl_resource_get_user_data (resource));
MetaWaylandSurface *surface =
surface_from_wl_shell_surface_resource (resource);
MetaWaylandSurface *parent_surf = wl_resource_get_user_data (parent_resource);
wl_shell_surface_set_state (surface,
META_WL_SHELL_SURFACE_STATE_TRANSIENT);
set_wl_shell_surface_parent (surface, parent_surf);
wl_shell_surface->x = x;
wl_shell_surface->y = y;
if (surface->window && parent_surf->window)
sync_wl_shell_parent_relationship (surface, parent_surf);
}
I seem mutter is doing right things just like a typical x11 window manager.
On the other hand, the code path of
WL_SHELL_SURFACE_TRANSIENT_INACTIVE can easily crash as I have sent
the patch yesterday:
commit e87c23ffcf3dc209cb8e7f24c3087636b8db3f53 (HEAD -> 6.0)
Author: Barry Song
Date: Mon Apr 15 11:28:07 2019 +1200
desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
It is pretty easy to replicate this bug by involving a Qt Window with
Qt::WindowTransparentForInput flag.
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
QDialog d1(&w, Qt::WindowTransparentForInput);
d1.show();
return a.exec();
}
Click d1 dialog, weston will crash.
Signed-off-by: Barry Song
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 93b1c70b..9473bac1 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2697,11 +2697,16 @@ desktop_surface_move(struct
weston_desktop_surface *desktop_surface,
struct weston_touch *touch = weston_seat_get_touch(seat);
struct shell_surface *shsurf =
weston_desktop_surface_get_user_data(desktop_surface);
- struct weston_surface *surface =
- weston_desktop_surface_get_surface(shsurf->desktop_surfac
[PATCH] desktop-shell: fix the crash while clicking TRANSIENT_INACTIVE window
From: Barry Song
It is pretty easy to replicate this bug by involving a Qt Window with
Qt::WindowTransparentForInput flag.
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
QDialog d1(&w, Qt::WindowTransparentForInput);
d1.show();
return a.exec();
}
Click d1 dialog, weston will crash due to NULL==shruf.
Signed-off-by: Barry Song
---
desktop-shell/shell.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 93b1c70b..9473bac1 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2697,11 +2697,16 @@ desktop_surface_move(struct weston_desktop_surface
*desktop_surface,
struct weston_touch *touch = weston_seat_get_touch(seat);
struct shell_surface *shsurf =
weston_desktop_surface_get_user_data(desktop_surface);
- struct weston_surface *surface =
- weston_desktop_surface_get_surface(shsurf->desktop_surface);
- struct wl_resource *resource = surface->resource;
+ struct weston_surface *surface;
+ struct wl_resource *resource;
struct weston_surface *focus;
+ if (!shsurf)
+ return;
+
+ surface = weston_desktop_surface_get_surface(shsurf->desktop_surface);
+ resource = surface->resource;
+
if (pointer &&
pointer->focus &&
pointer->button_count > 0 &&
--
2.17.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
