Re: multiple wl surfaces commit in one client

[zou lan]

Hi Simon & Jonas

May I ask if
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26#note_554405
only
include the patch of protocol xml file
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26/diffs?commit_id=108ab3ef2c9e028e6159793e6c4cae6ed9c7a546,
there is no weston implementation patch for transactions-unstable-v1.xml,
right?

Thank you!

Best Regards
Nancy


Simon Ser  于2020年11月6日周五 下午5:39写道：

> On Friday, November 6, 2020 10:38 AM, Jonas Ådahl 
> wrote:
>
> > On Fri, Nov 06, 2020 at 07:51:26AM +, Simon Ser wrote:
> >
> > > Hi,
> > > On Friday, November 6, 2020 3:14 AM, zou lan nancy.lan@gmail.com
> wrote:
> > >
> > > > Hi Simon & pekka
> > > > Thank you for your reply!
> > > >
> > > > > > The OS could pre-empt the client after
> > > > > > the first wl_surface_commit is flushed on the wire and before the
> > > > > > second one is.
> > > >
> > > > I want to ask if after first wl_surface_commit, but I don't call
> > > > wl_display_flush/wl_display_dispatch, is the first wl_surface_commit
> > > > flushed to server because  out buffer of the connection is full?
> > >
> > > That is correct.
> > >
> > > >
> https://github.com/wayland-project/wayland/blob/master/src/connection.c,
> > > > can we increase the buffer size in this structure wl_buffer to reduce
> > > > the possibility of this?
> > >
> > > I'd rather not. This would not fix the issue, and it's unclear if it'd
> > > really help.
> > >
> > > > By the way, for the WIP protocol,
> > > >
> https://gitlab.freedesktop.org/jadahl/wayland-protocols/-/blob/wip/transactions/unstable/transactions/transactions-unstable-v1.xml
> ,
> > > > do we have any patchset in weston to implement it? I don't find it in
> > > > weston master branch.
> > >
> > > I'm not aware of any Weston implementation as of yet. As you can see,
> > > the protocol hasn't yet been merged in wayland-protocols. Writing a new
> > > implementation would certainly help getting the protocol merged.
> >
> > weston, mutter and gtk implementations are linked to from this comment:
> >
> >
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26#note_554405
>
> Damn, I completely missed that. Thanks for the heads-up!
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: multiple wl surfaces commit in one client

[zou lan]

Hi Simon & pekka

Thank you for your reply!

>>The OS could pre-empt the client after
>>the first wl_surface_commit is flushed on the wire and before the
>>second one is.

I want to ask if after first wl_surface_commit, but I don't call
wl_display_flush/wl_display_dispatch, is the first wl_surface_commit
flushed to server because  out buffer of the connection is full?
https://github.com/wayland-project/wayland/blob/master/src/connection.c,
can we increase the buffer size in this structure wl_buffer to reduce the
possibility of this?

struct wl_buffer {
char data[4096];
uint32_t head, tail;
};

By the way, for the WIP protocol,
https://gitlab.freedesktop.org/jadahl/wayland-protocols/-/blob/wip/transactions/unstable/transactions/transactions-unstable-v1.xml,
do we have any patchset in weston to implement it? I don't find it in
weston master branch.

Yes, I don't want to use subsurface now because I want each surface have
its own shell role.

Thank you!

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

multiple wl surfaces commit in one client

[zou lan]

Hi pekka

I want to ask if in one client have created many wl surfaces, and commit
all of them to weston in one frame, could weston guarantee to handle these
surface update commands in one repaint?

The sample code may like this:
redraw() {
wl_surface_commit(surface1);
wl_surface_commit(surface2);
wl_display_dispatch();
}

I think weston will handle the commit of surface1 and surface2 before next
repaint because surface1 and surface2 are belong to one client, is that
correct? Thank you!

Best regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

hotplug in weston

[zou lan]

Hi all,

I want to ask if hotplug is fully supported in weston 8.0? I see some
related hotplug changes in drm-backend and compositor, but how to handle
windows if there is application running on that output plugged out? Is
desktop shell or ivi-shell support hotplug?

Thank you!

Best regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: can subsurface and shell surface be used together to manage surfaces

[zou lan]

Hi Daniel

Thank you for reply my question about 'SPURV'.

If 'SPURV' only support one active application on one display, does it
consider to support multiple displays?
can I ask if there is any plan to update 'SPURV' to match hwc2 or the
latest Android version?

Thank you!

Best Regards
Nancy

Daniel Stone  于2020年4月29日周三 下午5:11写道：

> Hi,
>
> On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen  wrote:
> > On Mon, 27 Apr 2020 15:07:20 +0800 zou lan 
> wrote:
> > > I read some documents about chrome OS run Android Apks such as
> > >
> https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-09-10-chromeos-with-android-app/Arcpp_Graphics.pdf
> > >  As far as I known, chrominum could run upon wayland,  I just
> wondering how
> > > it handle Android windows on wayland.
> > > I think the surface of Android apks could be wayland surface in linux,
> the
> > > window could be the shell surface.
> > >  Since all the android apks are still running on android container,
> android
> > > window manager will manage these windows, in wayland, the relationship
> of
> > > these surfaces should be parent-   subsurface that map to android
> > > windows. That's a little of problem, as you are confirmed, one wl
> surface
> > > can't be both subsurface and shell surface.
> > > If each android apks are not subsurfaces, I am confused how Android to
> > > handle the input events from wayland.
> >
> > you'll have to ask or wait for someone who knows ARC++ to answer. I
> > don't dare extrapolate details based on that one simple PDF alone.
> >
> > Android window management is very different from desktop window
> > management, and I don't even know if CrOS window management is close
> > to either. Using custom Wayland extensions is always a possibility, it
> > happens even on the desktops, e.g. GNOME/GTK.
> >
> > Look at the slide titled "Chromium Wayland Interfaces", for instance.
>
> ARC++ is proprietary, and I haven't seen its source code either.
>
> But looking at
> https://github.com/chromium/chromium/blob/master/components/exo/wayland/protocol/aura-shell.xml
> I would very much expect that the ARC++ client implementation uses
> this as an extra to support Android applications running under
> Chromium - for example, the titlebar-colour request is certainly
> fulfilling an Android need.
>
> Integrating Android into a desktop system is non-trivial. You will
> have to make quite a lot of changes along the way: Android assumes
> that you have one, or maybe two, applications open, and a status bar,
> and maybe a button bar, and that's it. If you want to make Android
> behave more like a desktop, then you're going to have to change
> Android to fit your desktop, and you're going to have to change your
> desktop to accommodate Android.
>
> I believe the ARC++ solution of using multiple top-level windows, and
> having the window management be primarily done by the host compositor,
> is a better option than trying to use subsurfaces to invert
> responsibility and effectively control the window management from
> Android.
>
> However, there is no out-of-the-box solution. Whatever you do is going
> to require custom development and experimentation. 'SPURV' is a
> periodically-refreshed effort from Collabora to see what this
> integration would look like, however we never addressed the idea of
> having multiple active applications, as it requires too many changes
> in Android, such as deep changes to the Android activity manager to
> deal with more than one application being current at one time.
>
> Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: can subsurface and shell surface be used together to manage surfaces

[zou lan]

Hi pekka


> >>Another compositor? Do you mean another client?
>
Another compositor means compositor such as HWC or netsed compositor.


>
> >>What are you trying to do?
>
> >>Do you have some sort of middle-man compositor as a third player here?
>
> >>I don't understand at all.
>

I read some documents about chrome OS run Android Apks such as
https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-09-10-chromeos-with-android-app/Arcpp_Graphics.pdf
 As far as I known, chrominum could run upon wayland,  I just wondering how
it handle Android windows on wayland.
I think the surface of Android apks could be wayland surface in linux, the
window could be the shell surface.
 Since all the android apks are still running on android container, android
window manager will manage these windows, in wayland, the relationship of
these surfaces should be parent-   subsurface that map to android
windows. That's a little of problem, as you are confirmed, one wl surface
can't be both subsurface and shell surface.
If each android apks are not subsurfaces, I am confused how Android to
handle the input events from wayland.

Thank you!

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: can subsurface and shell surface be used together to manage surfaces

[zou lan]

Hi Matt

yes, I want to bind a wl_surface to a subsurface first, then create a shell
surface for it.

I want to do that is because if the wl surface is created by another
compositor, it had been declared as a subsurface to map its position of
original compositor. Then weston shell can't
manage the surface as a window directly, I was just wondering how can make
weston shell could manage these kind of surfaces as separate windows too.
It seems create shell surface for each wl surface is not a good idea in
this case.  Thank you for confirmation!


Best Regards
Nancy


Matt Hoosier  于2020年4月11日周六 下午9:38写道：

> If you’re asking whether it’s possible to migrate a given wl_surface from
> being a subsurface (initially) to later being a shell surface, this isn’t
> allowed. This has to do with the immutability of a surface’s so-called
> “role.” (Surfaces are only ever allowed to be registered with one given
> role. )
>
> -Matt
>
> On Fri, Apr 10, 2020 at 5:43 AM zou lan  wrote:
>
>> Hi pekka & all
>>
>> I want to use subsurface to manage the initial position of each surface
>> on screen, then I want to create shell surface for each wl surface to
>> manage them seperately, such as response touch event, ivi-shell can modify
>> the z-order of each surface and move each ivi surface to different displays.
>>
>> Is it ok to use subsurface like this? If the shell surfaces' z-order have
>> been modified by desktop shell or ivi-shell,  will the z-order of
>> subsurfaces be modified too?
>>
>> thank you!
>>
>> Best Regards
>> Nancy
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

can subsurface and shell surface be used together to manage surfaces

[zou lan]

Hi pekka & all

I want to use subsurface to manage the initial position of each surface on
screen, then I want to create shell surface for each wl surface to manage
them seperately, such as response touch event, ivi-shell can modify the
z-order of each surface and move each ivi surface to different displays.

Is it ok to use subsurface like this? If the shell surfaces' z-order have
been modified by desktop shell or ivi-shell,  will the z-order of
subsurfaces be modified too?

thank you!

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: universal planes in drm backend

[zou lan]

Hi all

Thank you for your feedback.

>From your opinions, the drm backend reserve primary plane for each CRTC to
avoid the failure in hotplug cases. However, as weston already enabled
DRM_CLIENT_CAP_ATOMIC and DRM_CLIENT_CAP_UNIVERSAL_PLANES, the concept of
primary/overlay is no necessary
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#c.drm_plane_type:



For historical reasons not all planes are made the same. This enumeration
is used to tell the different types of planes apart to implement the
different uapi semantics for them. For userspace which is universal plane
aware and which is using that atomic IOCTL there's no difference between
these planes (beyong what the driver and hardware can support of course).



So weston should add the proper way to handle the case when output B is
newly connected while output A is using up all planes, e.g. trigger a
repaint for output A with less plane staged if new output B is hotplugged.
This will optimize the general performance of weston and avoid h/w resource
waste.



It’s popular that the number of CRTCs is more than the number of outputs. A
typical use case is DP-MST, where there could be multiple outputs in the
daisy chain but total link rate is limited, e.g. H/W can either support 2
monitors with 4K output, or 4 monitors with 2K output. 4 CRTCs will be
created at boot to support the 4 monitors with 2K output use case, but for
2 monitors with 4K output use case two planes will be completely wasted.


Thank you!


Best Regards

Nancy

Pekka Paalanen  于2019年9月18日周三 下午3:54写道：

> On Tue, 17 Sep 2019 10:02:44 +
> Simon Ser  wrote:
>
> > On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen <
> ppaala...@gmail.com> wrote:
> >
> > > On Tue, 17 Sep 2019 19:50:01 +1200
> > > Scott Anderson scott.ander...@collabora.com wrote:
> > >
> > > > On 17/09/19 7:38 pm, zou lan wrote:
> > > >
> > > > > Hi Daniel & all
> > > > > I find the function drm_output_prepare_overlay_view() only use the
> plane
> > > > > type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some
> planes of
> > > > > type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.
> > > > > For example, the kernel define 6 crtcs, and each crtc will have one
> > > > > primary type plane, but not all of the crtcs are used by
> weston_output.
> > > > > Some crtcs may never used, if we reserve  all the primary type
> planes as
> > > > > scanout plane, that could waste some of them.
> > > > > Could the open source drm backend modify the logic of judge the
> overlay
> > > > > plane? let the primary plane equal to overlay plane or judge in
> > > > > drm_output_prepare_overlay_view(), if the plane is not used by
> outputs,
> > > > > it could be used by overlay?
> > > > > Thank you!
> > > > > Best regards
> > > > > Nancy
> > > > > Hi,
> > > >
> > > > As far as I'm aware, the kernel never advertises more than one
> primary
> > > > plane per CRTC and they're never possible to be used with multiple
> > > > CRTCs:
> > > >
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction
> > > >
> > > > > All drivers should provide one primary plane per CRTC to avoid
> > > > > surprising userspace too much
> > > >
> > > > Perhaps that restriction is not as strict as I interpret it to be,
> but
> > > > I'm not aware of anything which does not have a one-to-one
> relationship
> > > > between primary planes and CRTCs.
> > >
> > > If the kernel actually did expose multiple primary planes on the same
> > > CRTC, they would also need zpos property to tell their stacking order,
> > > and Weston needs to use it (which it does not yet).
> > >
> > > However, given the special expectations that all userspace likely has
> > > for primary planes, the kernel driver might be better exposing more
> > > planes of type OVERLAY while internally mapping them to the "other
> > > primary planes".
> > >
> > > However, that would still pose a problem, that userspace would need to
> > > know to disable some/all overlay planes when activating a new output
> > > fails and try again with the hope that a primary plane was made
> > > available under the hood. That would be pretty special. So it is
> > > possible that exposing the additional planes would break existing
> > > userspace for hotplug output activation under special circumstances
> > > (overlay pl

Re: universal planes in drm backend

[zou lan]

Hi scott

yes, one CRTC bind to one primary plane. But if not all the crtcs are
connected and universal planes is enable, the spare primary plane could be
an overlay plane.

for example, plane 0 ~ 5 for 6 CRTCs, they are all primary planes. But
weston only enable 3 output, then plane 3 ~ 5 could treat as overlay plane.

Thank you!

Best regards
Nancy

Scott Anderson  于2019年9月17日周二 下午3:50写道：

> On 17/09/19 7:38 pm, zou lan wrote:
> > Hi Daniel & all
> >
> > I find the function drm_output_prepare_overlay_view() only use the plane
> > type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some planes of
> > type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.
> >
> > For example, the kernel define 6 crtcs, and each crtc will have one
> > primary type plane, but not all of the crtcs are used by weston_output.
> > Some crtcs may never used, if we reserve  all the primary type planes as
> > scanout plane, that could waste some of them.
> >
> > Could the open source drm backend modify the logic of judge the overlay
> > plane? let the primary plane equal to overlay plane or judge in
> > drm_output_prepare_overlay_view(), if the plane is not used by outputs,
> > it could be used by overlay?
> >
> > Thank you!
> >
> > Best regards
> > Nancy
> Hi,
>
> As far as I'm aware, the kernel never advertises more than one primary
> plane per CRTC and they're never possible to be used with multiple
> CRTCs:
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction
>
>  >All drivers should provide one primary plane per CRTC to avoid
> surprising userspace too much
>
> Perhaps that restriction is not as strict as I interpret it to be, but
> I'm not aware of anything which does not have a one-to-one relationship
> between primary planes and CRTCs.
>
> Scott
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

universal planes in drm backend

[zou lan]

Hi Daniel & all

I find the function drm_output_prepare_overlay_view() only use the plane
type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some planes of
type  WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.

For example, the kernel define 6 crtcs, and each crtc will have one primary
type plane, but not all of the crtcs are used by weston_output. Some crtcs
may never used, if we reserve  all the primary type planes as scanout
plane, that could waste some of them.

Could the open source drm backend modify the logic of judge the overlay
plane? let the primary plane equal to overlay plane or judge in
drm_output_prepare_overlay_view(), if the plane is not used by outputs, it
could be used by overlay?

Thank you!

Best regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Independent clone mode

[zou lan]

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?

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
> > 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(_damage);
> -   pixman_region32_intersect(_damage,
> - >primary_plane.damage,
> >region);
> -   pixman_region32_subtract(_damage,
> - 

Independent clone mode

[zou lan]

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?

Thank you!

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: question about drm backend

[zou lan]

Hi pekka

I check the atomic commit part of the drm backend in weston 5.0. But I am
not sure if some vendors support one atomic commit to update many CRTCs, so
I was wondering
if one output repaint to do one atomic commit would match the weston 5.0's
architecture if they don't support it. I think the answer it's yes, is it
right?

I also have another question about the function
output_repaint_timer_arm() in compositor.c, about the following comment:
/* Even if we should repaint immediately, add the minimum 1 ms delay.
* This is a workaround to allow coalescing multiple output repaints
* particularly from weston_output_finish_frame()
* into the same call, which would not happen if we called
* output_repaint_timer_handler() directly.
*/
If the vendor doesn't support commit multi outputs together, does this
increase the latency for next repaint? The latency could be larger than 1ms
if the timer event can't be
triggered immediately.

If the outputs' refresh rate is not the same, is there any problem to
repaint multi outputs together?

Thank you!

Best Regards
Nancy

Pekka Paalanen  于2018年11月23日周五 下午6:00写道：

> On Fri, 23 Nov 2018 16:22:56 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > >>do you mean users as humans or as apps?
> > yes. I mean the apps. I think it's no big impact for apps. The major
> > changes for weston new version is focus on libweston/drm backend.
>
> Hi Nancy,
>
> Weston and any compositor is always bound by the Wayland protocol
> stability promises. The only thing where a compositor implementation
> can use its own judgement is which globals it will advertise and will
> it implement new versions of existing interfaces. (New versions of
> interfaces as denoted by the "version" attribute in the XML are
> required to be backwards-compatible.)
>
> So the only things you need to watch out for are:
> - did the compositor stop advertising some global interface
> - do you have a client that requires a global interface the compositor
>   has never supported yet
> - do you have a client that requires a certain minimum version of an
>   interface that the compositor does not support yet
>
> > I still want to ask something about drm backend. About on_drm_input()
> > function in compositor-drm.c, do this function plan to listen all CRTCs'
> > pageflip/vblank event or only listen
> > one primary CRTC's pageflip/vblank event? I think the repaint_flush()
> want
> > to do AtomicCommit for all crtcs one time, does it support commit for
> each
> > output just like the old
> > drm backend design in weston 5.0 or latest weston architecture?
>
> A repaint_flush() call will do an atomic commit involving any number of
> outputs (CRTCs). Which outputs happen to be included depends on the
> timings of each individual output. It can and will vary on each atomic
> commit.
>
> on_drm_input() handles all DRM events. Depending on libdrm and kernel
> support, it can dispatch to page_flip_handler() or
> atomic_flip_handler().
>
> page_flip_handler() is only used on legacy KMS, which means it will
> process an event for each drmModePageFlip() call. That is naturally per
> CRTC.
>
> atomic_flip_handler() is only for atomic commits and will also get
> called per CRTC by the kernel, not per atomic commit as a whole, and it
> carries the CRTC id as an argument. It does not get called for a
> TEST_ONLY atomic commit.
>
> Since someone probably will be hacking around in downstream, I'd would
> like to offer a warning. Whatever you do, do not ever add new calls to
> drmModeAtomicCommit or call anything that synchronously calls atomic
> commit or the legacy KMS functions. The architecture is designed around
> first collecting all the state an atomic commit needs, building the
> commit, testing it first, and if the test succeeds, only then firing
> the real commit. So if you want to control some new property or you
> want to turn off a monitor or anything, you have to make that new thing
> part of the state machinery and let the state machinery commit it for
> you. Anything else will quickly spiral into an unfixable mess.
>
> It was a huge effort to get rid of the "immediate" libdrm KMS calls and
> replace them with the atomic state machine. I recall that temporary
> video mode switching and maybe even DPMS might still be not quite there
> yet, because their original internal API fit really badly into the
> atomic design.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: question about drm backend

[zou lan]

Hi pekka

>>do you mean users as humans or as apps?
yes. I mean the apps. I think it's no big impact for apps. The major
changes for weston new version is focus on libweston/drm backend.

I still want to ask something about drm backend. About on_drm_input()
function in compositor-drm.c, do this function plan to listen all CRTCs'
pageflip/vblank event or only listen
one primary CRTC's pageflip/vblank event? I think the repaint_flush() want
to do AtomicCommit for all crtcs one time, does it support commit for each
output just like the old
drm backend design in weston 5.0 or latest weston architecture?

Thank you!
Best Regards
Nancy

Pekka Paalanen  于2018年11月20日周二 下午10:43写道：

> On Tue, 20 Nov 2018 20:32:53 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > Thank you so much to explain the drm backend details. I ask these because
> > some company may implement their own drm backend, changes on interfaces
> > between libweston
> > and drm backend may increase the merge effort.
> >
> > Could I also ask is weston backward compatible from weston 2.0 to weston
> > 5.0 from users. According to my study, I think there is no big impacts
> for
> > users, is it right?
>
> Hi Nancy,
>
> do you mean users as humans or as apps? There may have been some
> changes in the command line options and weston.ini, but I think they
> have generally been fairly stable. The biggest impact on app support
> was probably the xdg-shell v5 era and the eventual removal of it.
>
> I can't really remember even 5.0 release, but I would hope the notable
> changes would have been mentioned in the release announcements.
>
> Oh, removal of the Raspberry Pi backend, and removal of EGL support
> from the fbdev-backend come to mind. I'm not actually sure if those
> were before or after 2.0, it was so long ago.
>
> > Will AGL adopt the weston 5.0 or other weston version in their new AGL
> > version sunch as AGL 7.0?
>
> I haven't followed AGL, so I don't know, nor do I participate there
> currently.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: question about drm backend

[zou lan]

Hi pekka

Thank you so much to explain the drm backend details. I ask these because
some company may implement their own drm backend, changes on interfaces
between libweston
and drm backend may increase the merge effort.

Could I also ask is weston backward compatible from weston 2.0 to weston
5.0 from users. According to my study, I think there is no big impacts for
users, is it right?
Will AGL adopt the weston 5.0 or other weston version in their new AGL
version sunch as AGL 7.0?

Thank you!

Best Regards
Nancy

Pekka Paalanen  于2018年11月20日周二 下午7:28写道：

> On Tue, 20 Nov 2018 17:37:34 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > Thank you for your reply. I have other questions about drm backend.
> >  I find weston 5.0 modify so much about drm backend and the interfaces of
> > compositor communicate with drm backend.
> > Is there any documents about the drm backend design?
>
> Hi Nancy
>
> Mostly no. The compositor/backend interface is a purely internal
> libweston detail, with the exception of compositor-drm.h which is
> libweston public API.
>
> We do try to add API docs in the form of doxygen comments to at least
> all new functions.
>
> > Why compositor need to add a structure weston_head? Is weston_output not
> > enough? why not let drm backend to judge whether to do
> > repaint/repaint_flush/repaint_cancel to keep libweston separate from drm
> > backend?
>
> There actually is a design doc for the head API (which is public
> libweston API, not just a backend detail), but it is unfortunately
> unreadable atm. while Phabricator is broken. I've been meant to migrate
> that content but haven't had a chance yet:
> https://gitlab.freedesktop.org/wayland/weston/issues/25
>
> In a crude summary, weston_head represents a connector while
> weston_output represents a CRTC. Heads were added to support hardware
> clone mode, where the same CRTC is feeding two or more connectors. That
> is, weston_output provides the content for more than one weston_head.
>
> Heads are exposed in the libweston public API, because the display
> configuration must be controlled by the compositor, not guessed by
> libweston. E.g. there are use cases where hardware clone mode must be
> used explicitly, and falling back to something else is not acceptable.
>
> While the Phabricator document is unavailable, you can read more
> rationale and details in the git history: git log -Sweston_head
> and 01f60211b2ff3d12bd8bc6a008ba07c30a666760 in particular.
>
> repaint_begin/repaint_flush/repaint_cancel is a general concept
> required by atomic KMS. Weston core manages the output timings and the
> surface state and protocol implications from repaints, and
> special-casing the repaint coalescing to the DRM backend would have
> been more complicated than this. We want to get as many repaints into a
> single atomic commit as possible, and modesets during CRTC
> reconfiguration may even require it for succeeding at all.
>
> Granted, the DRM-backend is the primary backend of libweston, so we
> tend to adapt the core infrastructure to cater for the DRM-backend
> foremost while letting everything else work with some changes as well.
> E.g. the weston_output::assign_planes hook is only really used by the
> DRM-backend.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: question about drm backend

[zou lan]

Hi pekka

Thank you for your reply. I have other questions about drm backend.
 I find weston 5.0 modify so much about drm backend and the interfaces of
compositor communicate with drm backend.
Is there any documents about the drm backend design?
Why compositor need to add a structure weston_head? Is weston_output not
enough? why not let drm backend to judge whether to do
repaint/repaint_flush/repaint_cancel to keep libweston separate from drm
backend?

Thank you!
Best Regards
Nancy



Pekka Paalanen  于2018年11月14日周三 下午11:34写道：

> On Wed, 14 Nov 2018 23:00:21 +0800
> zou lan  wrote:
>
> > Hi pekka & all
> >
> > I find weston support many xdg shell versions in different weston
> versions,
> > as far as I know,
> > applications only use the genernal xdg shell interfaces to create a
> window,
> > for example, waylandsink. If the weston upgrade, should the applications
> > modify its xdg shell interface or are they  just backward compatible.
> Does
> > weston only support stable/xdg-shell.xml in the future?  How could make
> > weston upgrade not impact applications?
>
> Hi Nancy,
>
> Weston still supports even wl_shell, I don't think there is much
> pressure to drop the deprecated versions. I would imagine Weston will
> carry the support for a good number of years if not indefinitely.
> Weston still doesn't have an implementation for the stable xdg-shell
> though.
>
> Applications are recommended to move on to the stable xdg-shell version.
>
> xdg-shell v5 support was dropped quite some time ago as maintaining it
> with the other revisions became inconvenient. The revisions other than
> v5 should not suffer from similar issues.
>
> A compositor can support several major revisions at the same time, and
> Weston does. Clients can also choose which one they use and they can
> see what the compositor supports.
>
> The stable xdg-shell will be developed in a backwards-compatible way.
> Actually all Wayland extensions are developed that way, both stable and
> unstable ones. The difference is that unstable ones may get a new
> incompatible revision through renaming most of the interfaces, which
> technically allows both compositors and clients to support multiple
> incompatible versions at the same time.
>
> If you are worried about loosing something, you can always follow the
> Weston merge requests in Gitlab and chime in if something you care
> about is about to disappear.
>
> I don't think bringing xdg-shell v5 support back would be impossible if
> someone really wanted to, but I suspect it would be much more work than
> just reverting the removal. xdg-shell v5 is actually multiple
> incompatible versions IIRC, it was using an ad hoc versioning mechanism
> which didn't turn out to be that good in the long run.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

question about xdg shell version

[zou lan]

Hi pekka & all

I find weston support many xdg shell versions in different weston versions,
as far as I know,
applications only use the genernal xdg shell interfaces to create a window,
for example, waylandsink. If the weston upgrade, should the applications
modify its xdg shell interface or are they  just backward compatible. Does
weston only support stable/xdg-shell.xml in the future?  How could make
weston upgrade not impact applications?

Thank you!

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

calculate subsurface's bounding box

[zou lan]

Hi pekka & all

I find function weston_view_update_transform_enable() function will
calculate view's bounding box, but after that function,
weston_view_update_transform will update subsurface's scissor region by
parent surface's region, the code is in weston_view_transfer_scissor(). But
the sub view's bounding box is not going to recalculated.  Is it a problem?

weston_view_update_transform(struct weston_view *view)
{
.
weston_view_update_transform_enable();
..
if (parent) {
if (parent->geometry.scissor_enabled) {
view->geometry.scissor_enabled = true;
weston_view_transfer_scissor(parent, view);
} else {
view->geometry.scissor_enabled = false;
}
}
}


Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: how to handle the last_error of wl_display

[zou lan]

Hi pekka

I find the last_error is caused by
wl_display_flush()-->wl_connection_flush(). The sendmsg() return fail.

Many applications write code like this:

redraw()
{
wl_surface_commit();
wl_display_sync();
wl_display_flush();
}

while (1) {
redraw();
}


The code will block to wait buffer release event  if there is no free
buffer. But if display->last_error happen, the wl_display_dispatch_queue()
fail too. Does the application use the wl_display_flush() right?

Thank you!

Best Regards
Nancy

2018-06-14 18:33 GMT+08:00 Pekka Paalanen :

> On Thu, 14 Jun 2018 16:59:35 +0800
> zou lan  wrote:
>
> > Dear pekka & All:
> >
> > I find a wayland application report error about allocate memory fail.
> > I check the code, after request to weston to allocate dma buffer, it call
> > wl_display_roundtrip().
> > But this function return very fast, it doesn't block until the create
> > events back.
> >
> > I suspect the display->last_error is not 0. Then the
> wl_display_roundtrip()
> > return fast because of the last_error. Does it right?
>
> Hi,
>
> sounds plausible.
>
> > I find the following log:
> >
> > wl_display@1: error 0: invalid object 10
>
> Your application has a bug.
>
> > Does the application need to handle the display errors? How could I make
> > the last_error not impact wl_display_roundtrip?
>
> All protocol errors are always fatal: they cause the client to be
> disconnected and render the client wl_display unusable. The application
> can only report the error somewhere and quit.
>
> Protocol errors always imply a bug. Usually the bug is in the client
> code, but it could be in compositor code as well.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

how to handle the last_error of wl_display

[zou lan]

Dear pekka & All:

I find a wayland application report error about allocate memory fail.
I check the code, after request to weston to allocate dma buffer, it call
wl_display_roundtrip().
But this function return very fast, it doesn't block until the create
events back.

I suspect the display->last_error is not 0. Then the wl_display_roundtrip()
return fast because of the last_error. Does it right?

I find the following log:

wl_display@1: error 0: invalid object 10

Does the application need to handle the display errors? How could I make
the last_error not impact wl_display_roundtrip?

Thank you.

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi Michel & pekka

>>Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
>>otherwise it's not surprising that the timestamp in the event is wrong. :)
Yes. our code call drm_crtc_send_vblank event first. The orignal fps is 60,
but if I swap the order of drm_crtc_send_vblank_event and
drm_handle_vblank, the fps drop to 30fps.

@pekka
>>Weston schedules a repaint based on the pageflip timestamp. If the
>>timestamp is in the past by a whole refresh period, the computed new
>>deadline will be in the past as well, so Weston will attempt to repaint
>>as soon as possible.
I agree with this.

>>The intended behaviour is that Weston repaints at most once for each
>>display refresh cycle, the deadline being 7 ms (if using the default
>>value of repaint-window) before the next vblank. In other words, there
>>should be a significant delay (say, 50-90% of a refresh period) between
>>receiving the pageflip event and repaint.
I can't understand this. I use weston 1.9 now, the repaint_msc is 7ms.
our code always execute output_repaint_timer_handler() as soon as possible
because msec always lower than 1ms. Why there is delay?

Best Regards
Nancy

2018-05-31 0:12 GMT+08:00 Michel Dänzer :

> On 2018-05-30 02:48 PM, Pekka Paalanen wrote:
> > On Wed, 30 May 2018 18:33:40 +0800
> > zou lan  wrote:
> >
> >> Hi pekka
> >>
> >> I'm not familiar with kernel. I know part of drm driver is implement by
> >> ourself. I check the vblank callback function, it sends pageflip event
> >> first if there is a frame complete, update vblank timestamp later.
> >>
> >> I don't know why the owner write code like this. but if I swap the code
> >> order, the fps  decrease a lot.
> >
> > Hi Nancy,
> >
> > I do not know your hardware, so I cannot say why fps decreases, but the
> > order of sending event first and updating the timestamp later does
> > sound wrong to me.
>
> Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
> otherwise it's not surprising that the timestamp in the event is wrong. :)
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

I'm not familiar with kernel. I know part of drm driver is implement by
ourself. I check the vblank callback function, it sends pageflip event
first if there is a frame complete, update vblank timestamp later.

I don't know why the owner write code like this. but if I swap the code
order, the fps  decrease a lot.
I can sure this impact the weston's page flip timestamp. Does this have
some impacts to weston except timeline?

I study a little about timeline, I think the picture could still show the
c2p(interval between damage commit and hit screen). Is it right? Thank you.

Best Regards
Nancy

2018-05-24 15:42 GMT+08:00 Pekka Paalanen :

> On Thu, 24 May 2018 15:26:23 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > >>are the c2p numbers from weston-presentation-shm demo?
> > yes. I use this demo. My clock is  CLOCK_MONOTONIC.
> >
> > I check the drm kernel code, I find each vblank event send the last
> > vblank's timestamp.
> >
> > system time sec  msec
> > [  263.000526] vblank_event  262  983
> > [  263.017236] vblank_event 2630
> > [  263.033864] vblank_event  263   17
> > [  263.050533] vblank_event  26333
> > [  263.067215] vblank_event  26350
> >
> > I think that's should be the main reason cause the c2p time weird. I
> don't
> > know why kernel return last frame's timestamp. I am still debuging it.
>
> Indeed, that does not sound right. Maybe contact the driver developers
> about this?
>
> Which kernel display driver are you using?
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

>>are the c2p numbers from weston-presentation-shm demo?
yes. I use this demo. My clock is  CLOCK_MONOTONIC.

I check the drm kernel code, I find each vblank event send the last
vblank's timestamp.

system time sec  msec
[  263.000526] vblank_event  262  983
[  263.017236] vblank_event 2630
[  263.033864] vblank_event  263   17
[  263.050533] vblank_event  26333
[  263.067215] vblank_event  26350

I think that's should be the main reason cause the c2p time weird. I don't
know why kernel return last frame's timestamp. I am still debuging it.

Best Regards
Nancy


2018-05-22 15:51 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:

> On Mon, 21 May 2018 23:06:12 +0800
> zou lan <nancy.lan@gmail.com> wrote:
>
> > Hi pekka
> >
> > I debug the presentation time recently. I have checked each user call
> > drmAtomicCommit get the corresponding pageflip event.
> > But some presentation results (c2p) are a little weird. They are 1~5ms or
> > -1 ~ -5 ms. some results are normal(8 ~ 20 ms).
> > I used to explain the weird result is because  pageflip return last
> frame's
> > timestamp, but I can't explain the normal results.
> >
> > I suspect whether the kernel and user have the same time start point.
> It's
> > just a guess, I have no evidence.
> >
> > Do you have some tips about the c2p results? Thank you.
>
> Hi Nancy,
>
> are the c2p numbers from weston-presentation-shm demo?
>
> The presentation-time extension has an event to tell the client which
> clock domain is being used for the timestamps. This comes from DRM,
> Weston attempts to enable CLOCK_MONOTONIC, but if your kernel is
> ancient or otherwise weird, the default in DRM is CLOCK_REALTIME.
>
> Check your weston log for these lines:
>presentation clock: CLOCK_MONOTONIC, id 1
>presentation clock resolution: 0.1 s
>
> If the resolution is much coarser than this, you have a kernel build
> configuration issue.
>
> If all that checks out and you see the problem even with unmodified
> weston, then I would suspect a driver bug, but it's hard to tell.
>
> You may want to grab a timeline recording and post that compressed. We
> can then use wesgr to visualize it:
> https://github.com/ppaalanen/wesgr
> You can start and stop the recording by typing Mod+Shift+Space, 't'. It
> writes a file to weston's current working directory and you see it
> mentioned in the log as well.
>
>
> The c2p times should really not vary much. On an intel GPU, with 60 Hz
> display, the default mode of weston-presentation-shm gives me a steady
> 23-24 ms c2p. This is the default repaint window setting. If I use the
> low latency mode (-p), I get c2p 17-18 ms. (The intel driver can
> actually send the pageflip event a little earlier than the timestamp it
> carries, because it predicts the vblank when it's sure the presentation
> will happen.)
>
> I also found a crash bug in Weston just now when playing with
> weston-presentation-shm, probably related to a patch I recently landed.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

I debug the presentation time recently. I have checked each user call
drmAtomicCommit get the corresponding pageflip event.
But some presentation results (c2p) are a little weird. They are 1~5ms or
-1 ~ -5 ms. some results are normal(8 ~ 20 ms).
I used to explain the weird result is because  pageflip return last frame's
timestamp, but I can't explain the normal results.

I suspect whether the kernel and user have the same time start point. It's
just a guess, I have no evidence.

Do you have some tips about the c2p results? Thank you.

Best Regards
Nancy


2018-05-12 23:17 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:

> On Thu, 10 May 2018 12:53:49 +0800
> zou lan <nancy.lan@gmail.com> wrote:
>
> > Hi pekka
> >
> > I test presentation on my side. The presentation results is not accurate
> > because our pageflip event send last frame's timestamp every time. So
> > weston_output_finish_frame send last frame's present tine
> > to current frame's feedback. For this situation, I just delay one frame
> to
> > send present event. Does this get the right c2p time? Thank you.
>
> Hi Nancy,
>
> I think your driver needs to get fixed, so that it provides the
> correct timestamp instead of an outdated one. If this is a kernel
> DRM driver, then the behaviour you describe is clearly a bug. The
> timestamp of the pageflip event signifies the time the new frame
> starts transmitting out of the connector. I believe there should be
> DRM driver API documentation stating that.
>
> This is also what weston_output_finish_frame() expects. Anything
> else will cause the frame scheduling to misbehave.
>
> It may be possible to work around the bug as you suggest, but that
> will make the compositor incorrect on any other driver, and it may
> cause other subtle breakage (the timestamp may be correct, but the
> time the event gets sent is now wrong and might even be delayed
> indefinitely if nothing causes a repaint).
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

I test presentation on my side. The presentation results is not accurate
because our pageflip event send last frame's timestamp every time. So
weston_output_finish_frame send last frame's present tine
to current frame's feedback. For this situation, I just delay one frame to
send present event. Does this get the right c2p time? Thank you.

Best Regards
Nancy

2018-05-02 18:17 GMT+08:00 zou lan <nancy.lan@gmail.com>:

> Hi pekka
>
> Thank you for your clearly analysis. I understand the presentation
> protocol is enough for the requirement now.
>
> I used to not study the protocol deeply because the code is a little more
> than just record the flip timestamp. The
> test want to do this as simple as possible.
>
> I will try the presentation first. Thank you!
>
> Best Regards
> Nancy
>
> 2018-05-02 16:59 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:
>
>> On Wed, 2 May 2018 16:33:43 +0800
>> zou lan <nancy.lan@gmail.com> wrote:
>>
>> > Add to wayland mail list.
>> >
>> > Hi pekka
>> >
>> > I used to consider the time line and presentation protocol. But they are
>> > all focus on surface, not buffer. The test want to know the buffer
>> latency,
>> > although they are the same as surface's on
>> > most cases. Applications think maybe some buffers doesn't display and
>> used
>> > again.
>> >
>> > By the way, could add a event to wl_buffer's protocol achieve the
>> > requirement? Thank you.
>>
>> Hi Nancy,
>>
>> when a client creates a wp_presentation_feedback object, that object
>> tracks the particular wl_surface.commit carrying an attached wl_buffer.
>> So it is specific to the particular commit, not just to the surface
>> or even to the buffer (buffers get re-used or could theoretically be
>> used on multiple surfaces).
>>
>> Can you not have the client record both the current time at sending
>> wl_surface.commit and the corresponding timestamp it gets from
>> wp_presentation_feedback? Why would this not be enough?
>>
>> Please, see clients/presentation-shm.c in the Weston repository for an
>> example that tracks this kind of presentation latencies.
>>
>>
>> Thanks,
>> pq
>>
>> > -- Forwarded message --
>> > From: Pekka Paalanen <ppaala...@gmail.com>
>> > Date: 2018-05-02 15:48 GMT+08:00
>> > Subject: Re: unique id for wayland objects
>> > To: zou lan <nancy.lan@gmail.com>
>> >
>> >
>> > On Wed, 2 May 2018 10:57:17 +0800
>> > zou lan <nancy.lan@gmail.com> wrote:
>> >
>> > > Hi pekka
>> > >
>> > > I want to get the accurate buffer latency from a buffer commit by
>> client
>> > to
>> > > display on the screen. The client can get the timestamp when buffer
>> commit
>> > > and release. So weston only need to give a
>> > > timestamp when call on_pageflip.
>> > >
>> > > When do the real time analysis, there are many clients,  I want to
>> use one
>> > > unique id to distinguish from each other quickly.
>> >
>> > Hi,
>> >
>> > is there any reason you don't use presentation_feedback interface? To
>> > me it sounds like that would provide exactly what you need.
>> >
>> > https://cgit.freedesktop.org/wayland/wayland-protocols/
>> > tree/stable/presentation-time
>> >
>> > Also, could we have this coversation on the mailing list, please?
>> >
>> >
>> > Thanks,
>> > pq
>>
>>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

Thank you for your clearly analysis. I understand the presentation protocol
is enough for the requirement now.

I used to not study the protocol deeply because the code is a little more
than just record the flip timestamp. The
test want to do this as simple as possible.

I will try the presentation first. Thank you!

Best Regards
Nancy

2018-05-02 16:59 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:

> On Wed, 2 May 2018 16:33:43 +0800
> zou lan <nancy.lan@gmail.com> wrote:
>
> > Add to wayland mail list.
> >
> > Hi pekka
> >
> > I used to consider the time line and presentation protocol. But they are
> > all focus on surface, not buffer. The test want to know the buffer
> latency,
> > although they are the same as surface's on
> > most cases. Applications think maybe some buffers doesn't display and
> used
> > again.
> >
> > By the way, could add a event to wl_buffer's protocol achieve the
> > requirement? Thank you.
>
> Hi Nancy,
>
> when a client creates a wp_presentation_feedback object, that object
> tracks the particular wl_surface.commit carrying an attached wl_buffer.
> So it is specific to the particular commit, not just to the surface
> or even to the buffer (buffers get re-used or could theoretically be
> used on multiple surfaces).
>
> Can you not have the client record both the current time at sending
> wl_surface.commit and the corresponding timestamp it gets from
> wp_presentation_feedback? Why would this not be enough?
>
> Please, see clients/presentation-shm.c in the Weston repository for an
> example that tracks this kind of presentation latencies.
>
>
> Thanks,
> pq
>
> > -- Forwarded message --
> > From: Pekka Paalanen <ppaala...@gmail.com>
> > Date: 2018-05-02 15:48 GMT+08:00
> > Subject: Re: unique id for wayland objects
> > To: zou lan <nancy.lan@gmail.com>
> >
> >
> > On Wed, 2 May 2018 10:57:17 +0800
> > zou lan <nancy.lan@gmail.com> wrote:
> >
> > > Hi pekka
> > >
> > > I want to get the accurate buffer latency from a buffer commit by
> client
> > to
> > > display on the screen. The client can get the timestamp when buffer
> commit
> > > and release. So weston only need to give a
> > > timestamp when call on_pageflip.
> > >
> > > When do the real time analysis, there are many clients,  I want to use
> one
> > > unique id to distinguish from each other quickly.
> >
> > Hi,
> >
> > is there any reason you don't use presentation_feedback interface? To
> > me it sounds like that would provide exactly what you need.
> >
> > https://cgit.freedesktop.org/wayland/wayland-protocols/
> > tree/stable/presentation-time
> >
> > Also, could we have this coversation on the mailing list, please?
> >
> >
> > Thanks,
> > pq
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fwd: unique id for wayland objects

[zou lan]

Add to wayland mail list.

Hi pekka

I used to consider the time line and presentation protocol. But they are
all focus on surface, not buffer. The test want to know the buffer latency,
although they are the same as surface's on
most cases. Applications think maybe some buffers doesn't display and used
again.

By the way, could add a event to wl_buffer's protocol achieve the
requirement? Thank you.

Best Regards
Nancy


-- Forwarded message --
From: Pekka Paalanen <ppaala...@gmail.com>
Date: 2018-05-02 15:48 GMT+08:00
Subject: Re: unique id for wayland objects
To: zou lan <nancy.lan@gmail.com>


On Wed, 2 May 2018 10:57:17 +0800
zou lan <nancy.lan@gmail.com> wrote:

> Hi pekka
>
> I want to get the accurate buffer latency from a buffer commit by client
to
> display on the screen. The client can get the timestamp when buffer commit
> and release. So weston only need to give a
> timestamp when call on_pageflip.
>
> When do the real time analysis, there are many clients,  I want to use one
> unique id to distinguish from each other quickly.

Hi,

is there any reason you don't use presentation_feedback interface? To
me it sounds like that would provide exactly what you need.

https://cgit.freedesktop.org/wayland/wayland-protocols/
tree/stable/presentation-time

Also, could we have this coversation on the mailing list, please?


Thanks,
pq


pgpRHOLRCj147.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

unique id for wayland objects

[zou lan]

Hi Pekka & all

I want to ask is there a method to mark the wl_buffer between client and
server. .

I try to use the id of wl_object, but it's not unique between different
clients. Do you have some
suggestions?

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] ivi-shell: Damage view below after unmapping

[zou lan]

Hi Emre

I ask why calling it?  which scenario could reproduce the issue you said
"keep visible after set layer/surface invisible "?

Thank you.

Best Regards
Nancy

2018-04-10 22:19 GMT+08:00 Ucan, Emre (ADITG/ESB) <eu...@de.adit-jv.com>:

> Hi,
>
>
>
> Are you asking if it is possible to move weston_view_damage_below() to
> commit_screen_list ? or are you asking why we are calling it ?
>
>
>
> Best regards
>
> *Emre Ucan*
> Engineering Software Base (ADITG/ESB)
>
> Tel. +49 5121 49 6937
>
> *From:* zou lan [mailto:nancy.lan@gmail.com]
> *Sent:* Dienstag, 10. April 2018 08:55
> *To:* Pekka Paalanen
> *Cc:* Ucan, Emre (ADITG/ESB); wayland-devel@lists.freedesktop.org
> *Subject:* Re: [PATCH weston v2] ivi-shell: Damage view below after
> unmapping
>
>
>
> Hi  Emre
>
>
>
> I have a question about this change:
>
>
>
> Is the commit_screen_list function not enough to handle the
> layer/surface's visibility? Why need to handle visibility in
> commit_changes? They are  called ivi_layout_commit_changes together.
>
>
>
> Best Regards
>
> Nancy
>
>
>
> 2017-02-07 21:04 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:
>
> On Tue, 7 Feb 2017 12:55:59 +
> "Ucan, Emre (ADITG/SW1)" <eu...@de.adit-jv.com> wrote:
>
> > If ivilayer or ivisurf of ivi_view is made invisible in the
> > commit_changes call, we have to damage the weston_view below this
> > ivi_view. Otherwise content of this ivi_view will stay visible.
> >
> > Signed-off-by: Emre Ucan <eu...@de.adit-jv.com>
> > ---
> >  ivi-shell/ivi-layout.c |   13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > index 712cc30..64e4ead 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c
> > @@ -681,8 +681,19 @@ commit_changes(struct ivi_layout *layout)
> >* If the view's layer or surface is invisible, we do not
> need
> >* to update its properties.
> >*/
> > - if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility)
> > + if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility) {
> > + /*
> > + * If ivilayer or ivisurf of ivi_view is made
> invisible
> > + * in this commit_changes call, we have to damage
> > + * the weston_view below this ivi_view. Otherwise
> content
> > + * of this ivi_view will stay visible.
> > + */
> > + if ((ivilayer->prop.event_mask |
> ivisurf->prop.event_mask) &&
> > + IVI_NOTIFICATION_VISIBILITY)
> > + weston_view_damage_below(ivi_view->view);
> > +
> >   continue;
> > + }
> >
> >   update_prop(ivi_view);
> >   }
>
> Hi,
>
> looks fine to me, pushed:
>19222b4..7fe0bb2  master -> master
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] ivi-shell: Damage view below after unmapping

[zou lan]

Hi  Emre

I have a question about this change:

Is the commit_screen_list function not enough to handle the layer/surface's
visibility? Why need to handle visibility in commit_changes? They are
called ivi_layout_commit_changes together.

Best Regards
Nancy

2017-02-07 21:04 GMT+08:00 Pekka Paalanen :

> On Tue, 7 Feb 2017 12:55:59 +
> "Ucan, Emre (ADITG/SW1)"  wrote:
>
> > If ivilayer or ivisurf of ivi_view is made invisible in the
> > commit_changes call, we have to damage the weston_view below this
> > ivi_view. Otherwise content of this ivi_view will stay visible.
> >
> > Signed-off-by: Emre Ucan 
> > ---
> >  ivi-shell/ivi-layout.c |   13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > index 712cc30..64e4ead 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c
> > @@ -681,8 +681,19 @@ commit_changes(struct ivi_layout *layout)
> >* If the view's layer or surface is invisible, we do not
> need
> >* to update its properties.
> >*/
> > - if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility)
> > + if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility) {
> > + /*
> > + * If ivilayer or ivisurf of ivi_view is made
> invisible
> > + * in this commit_changes call, we have to damage
> > + * the weston_view below this ivi_view. Otherwise
> content
> > + * of this ivi_view will stay visible.
> > + */
> > + if ((ivilayer->prop.event_mask |
> ivisurf->prop.event_mask) &&
> > + IVI_NOTIFICATION_VISIBILITY)
> > + weston_view_damage_below(ivi_view->view);
> > +
> >   continue;
> > + }
> >
> >   update_prop(ivi_view);
> >   }
>
> Hi,
>
> looks fine to me, pushed:
>19222b4..7fe0bb2  master -> master
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_list_remove(>link) point to invalid address

[zou lan]

Hi Pekka

Thank you for your comment. They are very helpful.

>that's a good find. If I understand correctly, we do not handle the
>case where a weston_view is effectively unmapped by removing it from a
>weston_layer. As weston_compositor::view_list is never torn down
>properly but simply rebuilt, the unmapped view is left with dangling
>pointers, and those will be hit when finally destroying the view.

Your explanation is exactly correct.

I have verified the optional 1 can't work.

optional 2
>> weston_view_damage_below(shsurf->fullscreen.black_view);
>> +
>>  wl_list_remove(>fullscreen.black_view->link);

> Removing without init might cause issues with a potential double-remove
>on e.g. view destruction.

yes.  I add the initialization for the list.

+ wl_list_init (>fullscreen.black_view->link);

I agree with you weston_view_unmap maybe better for optional 2.  Since I
find crashes  caused by invalid pointer, I only concern how to make the
view.link to point  the right address.

No matter what functions use here, this only handle the black views.
Are there other views have the same problems?  Especially in ivi shell, I
find the crash exist in many  scenarios.

How would weston to resolve the potential risks? Thank you.

Best Regards
Nancy

2018-04-03 20:28 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:

> On Thu, 29 Mar 2018 11:01:47 +0800
> zou lan <nancy.lan@gmail.com> wrote:
>
> > Hi Pekka & all
> >
> > When I run some full screen applications under desktop shell,  then kill
> > some applications randomly, I find
> > crashes maybe happened sometimes.
> >
> > Crash call stack:
> > weston_view_destroy-->weston_view_unmap-->wl_list_reomve(>link).
> > The view is black view.
>
> Hi,
>
> that's a good find. If I understand correctly, we do not handle the
> case where a weston_view is effectively unmapped by removing it from a
> weston_layer. As weston_compositor::view_list is never torn down
> properly but simply rebuilt, the unmapped view is left with dangling
> pointers, and those will be hit when finally destroying the view.
>
> Would that be an accurate explanation?
>
> > Then I debug code, find that shell.c  lower_fullscreen_layer function
> only
> > delete the layer of black view from layer_list, but not handle the
> > 
> > lower_fullscreen_layer()
> > {
> > .
> > /* Hide the black view */
> >
> > weston_layer_entry_remove(>fullscreen.black_view->layer_link);
> >
> > wl_list_init(>fullscreen.black_view->layer_link.link);
>
> This wl_list_init() seems to be redundant, btw.
>
> >
> > weston_view_damage_below(shsurf->fullscreen.black_view);
>
> Could this path simply call weston_view_unmap() to unmap the black_view?
>
> It effectively is unmapping the view, but forgetting to clear the
> 'is_mapped' boolean, which later leads to accessing weston_view::link
> dangling pointers. weston_view_unmap() does a lot more which might be
> necessary as well.
>
> >
> > }
> >
> > The code will be called when start second full screen application.
> >
> > when weston build view list again, the first surface's black view is not
> in
> > the view list, the list  maybe point some invalid address.
> >
> > I think ivi shell will have the same problems too.  I have a temporary
> > patch to resolve this problem. I want to discuss it in the community.
> >
> > option 1
> > --- a/libweston/compositor.c
> > +++ b/libweston/compositor.c
> > @@ -2195,7 +2195,7 @@ view_list_add(struct weston_compositor *compositor,
> > struct weston_subsurface *sub;
> >
> > weston_view_update_transform(view);
> > -
> > +   wl_list_remove();
>
> For better or worse, the weston_view::link is deliberately left with
> garbage pointers when the weston_compositor::view_list is discarded for
> a rebuild.
>
> Wouldn't this addition cause weston_compositor::view_list to become
> corrupted if the link removed here happened to be the first or the last
> in the old list order? Or maybe be get lucky most times, and it would
> need quite special circumstances to trigger the corruption.
>
> I still think this approach is not good.
>
> >
> > option 2:
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -3651,6 +3651,7 @@ lower_fullscreen_layer(struct desktop_shell *shell,
> >
> > weston_layer_entry_remove(>fullscreen.black_view->layer_link);
> >
> > wl_list_init(>fullscreen.black_view->layer_link.link);
> >
> > weston_view_damage_below(shsurf->fullscreen.black_view);
> >

wl_list_remove(>link) point to invalid address

[zou lan]

Hi Pekka & all

When I run some full screen applications under desktop shell,  then kill
some applications randomly, I find
crashes maybe happened sometimes.

Crash call stack:
weston_view_destroy-->weston_view_unmap-->wl_list_reomve(>link).
The view is black view.


Then I debug code, find that shell.c  lower_fullscreen_layer function only
delete the layer of black view from layer_list, but not handle the

lower_fullscreen_layer()
{
.
/* Hide the black view */

weston_layer_entry_remove(>fullscreen.black_view->layer_link);

wl_list_init(>fullscreen.black_view->layer_link.link);

weston_view_damage_below(shsurf->fullscreen.black_view);

}

The code will be called when start second full screen application.

when weston build view list again, the first surface's black view is not in
the view list, the list  maybe point some invalid address.

I think ivi shell will have the same problems too.  I have a temporary
patch to resolve this problem. I want to discuss it in the community.

option 1
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -2195,7 +2195,7 @@ view_list_add(struct weston_compositor *compositor,
struct weston_subsurface *sub;

weston_view_update_transform(view);
-
+   wl_list_remove();

option 2:
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3651,6 +3651,7 @@ lower_fullscreen_layer(struct desktop_shell *shell,

weston_layer_entry_remove(>fullscreen.black_view->layer_link);

wl_list_init(>fullscreen.black_view->layer_link.link);

weston_view_damage_below(shsurf->fullscreen.black_view);
+
 wl_list_remove(>fullscreen.black_view->link);

}

Do you think these options reasonable? Thank you.

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

touch drag and drop

[zou lan]

Hi all

I find a issue in touch drag and drop caused by function
data_device_end_drag_grab.

when data_device_end_drag_grab call weston_view_unmap
and weston_view_destroy,
if the view->surface is commited but not repaint, the callback in
view->surface's callbacklist will not sent done. The drag window on client
side will hang in waiting callback.

I use weston 1.8.0. Test case is the the Qt filedialog demo.  Is there any
method to reslove this issue? Thank you.

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

weston flip a null frame first before start launcher

[zou lan]

Hi pekka & others

I find weston flip a null frame before start the launcher
weston-desktop-shell. So there is always a black surface flash before the
launcher. That doesn't have the relationship with the animation mode.
I think it's caused by the code weston_output_init which call
the weston_output_damage.

weston_output_damage will paint nothing if the animation mode is noe and
flip one frame.

Does this frame is normal or my implementions have problems?  Thank you.
I try it on weston version 1.8 and 1.9.

weston.ini
[shell]
animation=none
startup-animation=none
client=/usr/lib/weston/weston-desktop-shell


Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: black surface in desktop shell fullscreen mode

[zou lan]

Hi Pekka

I have another question about the fullscreen NULL buffer display black
surface. Why the fullscreen App call hide(commit Null buffer), then start
another App, only the fullscreen App can show normally? Is  the normal
screen App's layer below on the black surface?

Best Regards
Nancy

2015-11-20 17:31 GMT+08:00 zou lan <nancy.lan@gmail.com>:

> Hi pekka
>
> >Or are you asking for instructions on how to fix the alleged Weston
> >desktop-shell bug where the black surface is not removed when attaching
> >a NULL wl_buffer to the wl_surface?
>
> Actually I ask for instructions on this. Because I use "hide" to switch
> the apps. But I met some problems of the black screen if I just hide the
> surface.
>
> I want to implement the function like "background" or "home", just hide
> the UI.
>
> Thank you.
>
> Best Regards
> Nancy
>
> 2015-11-20 16:03 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:
>
>> On Fri, 20 Nov 2015 10:52:54 +0800
>> zou lan <nancy.lan@gmail.com> wrote:
>>
>> > Hi Pekka
>> >
>> > How to not use the black surface behind the fullscreen surface? I want
>> to
>>
>> Hi Nancy,
>>
>> are you looking for disabling the black surface in a way that would
>> work on upstream Weston or be upstreamable, or something you hack just
>> for yourself?
>>
>> Or are you asking for instructions on how to fix the alleged Weston
>> desktop-shell bug where the black surface is not removed when attaching
>> a NULL wl_buffer to the wl_surface?
>>
>> > have a try for the special needs to switch the apps. I can't use the
>> > minimize because it can't restore to its original shape.
>>
>> Oh that's the real problem here. Obviously restoring to original size
>> and position after minimization should work, so I think that is the
>> primary issue to be solved. However, I'm not sure if it is possible
>> with wl_shell, but it should be possible with xdg_shell.
>>
>> You have to note, that both desktop shell protocols are still far from
>> being finished. Switching the active window from clients is still on
>> the drawing board, AFAIK.
>>
>> Hmm, or is the fundamental problem really that you want to reassign
>> which window is active and on top from the client?
>>
>> There is a continuum of possible solutions, ranging from
>> non-upstreamable quick hacks on one end to joining the work on
>> designing the family of desktop related protocol extensions on the
>> other end which can take at least months.
>>
>> I think we should go back to the original use case you are trying to
>> make work:
>>
>> App1 launches App2. App2 appears on top and active (by the current
>> policy implemented in Weston's desktop shell, which is subject to
>> change). Then App2 wants to put App1 on top and active again. Is this
>> right?
>>
>> Should App2 stay up but behind App1? Or should App2 be hidden or
>> minimized?
>>
>> Note that hiding and minimizing are two different things: minimizing
>> leaves a window handle in something like a task bar, while hiding does
>> not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston
>> where it forgets the window position, IIRC.)
>>
>> And you want App2 to be able to come back later in the original
>> position and size, active and on top of App1?
>>
>> I'm afraid on short term, all workable solutions will be more or less
>> hacks, because the desktop shell protocol extensions just do not exist
>> yet for this sort of things.
>>
>>
>> Thanks,
>> pq
>>
>> > > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen <ppaala...@gmail.com>:
>> > > > > On Fri, 9 Oct 2015 10:04:49 +0300
>> > > > > Giulio Camuffo <giuliocamu...@gmail.com> wrote:
>> > > > >
>> > > > >> You get a black surface because weston puts a black surface
>> behind the
>> > > > >> fullscreen one even if it has the right size, and it seems like
>> it
>> > > > >> doesn't remove the black surface when the client surface attachs
>> a
>> > > > >> NULL buffer. That's a weston bug, i'd say.
>> > > > >
>> > > > > Giulio's analysis sounds good to me. I think no-one has tried - or
>> > > > > reported - to hide a window using wl_shell that was also
>> fullscreen, so
>> > > > > probably we have never considered that case in the code.
>> > > > >
>> > > > > Very likely a Weston bug indeed, specifically in the case of
>> committing
>> > > > > a NULL wl_buffer when using wl_shell. Transparency was a red
>> herring
>> > > > > all along.
>> > >
>>
>>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

check layer orders

[zou lan]

Dear all:

Is there any command to print the desktop shell layer orders?  Thank you.

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: black surface in desktop shell fullscreen mode

[zou lan]

Hi pekka

>Or are you asking for instructions on how to fix the alleged Weston
>desktop-shell bug where the black surface is not removed when attaching
>a NULL wl_buffer to the wl_surface?

Actually I ask for instructions on this. Because I use "hide" to switch the
apps. But I met some problems of the black screen if I just hide the
surface.

I want to implement the function like "background" or "home", just hide the
UI.

Thank you.

Best Regards
Nancy

2015-11-20 16:03 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>:

> On Fri, 20 Nov 2015 10:52:54 +0800
> zou lan <nancy.lan@gmail.com> wrote:
>
> > Hi Pekka
> >
> > How to not use the black surface behind the fullscreen surface? I want to
>
> Hi Nancy,
>
> are you looking for disabling the black surface in a way that would
> work on upstream Weston or be upstreamable, or something you hack just
> for yourself?
>
> Or are you asking for instructions on how to fix the alleged Weston
> desktop-shell bug where the black surface is not removed when attaching
> a NULL wl_buffer to the wl_surface?
>
> > have a try for the special needs to switch the apps. I can't use the
> > minimize because it can't restore to its original shape.
>
> Oh that's the real problem here. Obviously restoring to original size
> and position after minimization should work, so I think that is the
> primary issue to be solved. However, I'm not sure if it is possible
> with wl_shell, but it should be possible with xdg_shell.
>
> You have to note, that both desktop shell protocols are still far from
> being finished. Switching the active window from clients is still on
> the drawing board, AFAIK.
>
> Hmm, or is the fundamental problem really that you want to reassign
> which window is active and on top from the client?
>
> There is a continuum of possible solutions, ranging from
> non-upstreamable quick hacks on one end to joining the work on
> designing the family of desktop related protocol extensions on the
> other end which can take at least months.
>
> I think we should go back to the original use case you are trying to
> make work:
>
> App1 launches App2. App2 appears on top and active (by the current
> policy implemented in Weston's desktop shell, which is subject to
> change). Then App2 wants to put App1 on top and active again. Is this
> right?
>
> Should App2 stay up but behind App1? Or should App2 be hidden or
> minimized?
>
> Note that hiding and minimizing are two different things: minimizing
> leaves a window handle in something like a task bar, while hiding does
> not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston
> where it forgets the window position, IIRC.)
>
> And you want App2 to be able to come back later in the original
> position and size, active and on top of App1?
>
> I'm afraid on short term, all workable solutions will be more or less
> hacks, because the desktop shell protocol extensions just do not exist
> yet for this sort of things.
>
>
> Thanks,
> pq
>
> > > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen <ppaala...@gmail.com>:
> > > > > On Fri, 9 Oct 2015 10:04:49 +0300
> > > > > Giulio Camuffo <giuliocamu...@gmail.com> wrote:
> > > > >
> > > > >> You get a black surface because weston puts a black surface
> behind the
> > > > >> fullscreen one even if it has the right size, and it seems like it
> > > > >> doesn't remove the black surface when the client surface attachs a
> > > > >> NULL buffer. That's a weston bug, i'd say.
> > > > >
> > > > > Giulio's analysis sounds good to me. I think no-one has tried - or
> > > > > reported - to hide a window using wl_shell that was also
> fullscreen, so
> > > > > probably we have never considered that case in the code.
> > > > >
> > > > > Very likely a Weston bug indeed, specifically in the case of
> committing
> > > > > a NULL wl_buffer when using wl_shell. Transparency was a red
> herring
> > > > > all along.
> > >
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: black surface in desktop shell fullscreen mode

[zou lan]

Hi Pekka

How to not use the black surface behind the fullscreen surface? I want to
have a try for the special needs to switch the apps. I can't use the
minimize because it can't restore to its original shape.

Thank you.

Best Regards
Nancy

2015-10-13 18:31 GMT+08:00 Pekka Paalanen :

> On Tue, 13 Oct 2015 12:19:47 +0200
> Joaquim Duran  wrote:
>
> > Hello,
> >
> > Last Friday, we executed Weston for first time. We also view the black
> > screen in full screen shell. Weston breaks when desktop shell is used.
>
> Hi Joaquim,
>
> this email thread is about fullscreen windows on desktop shell, not
> about the fullscreen shell. Fullscreen shell is not for desktop apps.
>
> If you want us to look into a problem, you need to be more specific
> about what happens and what you want to achieve, and at the minimum
> include stdout and stderr of Weston. In your case, the ./configure
> options you used for weston would also be useful, since previously you
> were disabling far too many things.
>
> With fullscreen shell, it is normal to get a black or maybe garbled
> screen if you do not manually run a client written for the fullscreen
> shell.
>
> Desktop shell is likely to not work well without the
> weston-desktop-shell client, which Weston starts automatically if you
> allowed it to be built.
>
>
> Thanks,
> pq
>
> > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen :
> > > On Fri, 9 Oct 2015 10:04:49 +0300
> > > Giulio Camuffo  wrote:
> > >
> > >> You get a black surface because weston puts a black surface behind the
> > >> fullscreen one even if it has the right size, and it seems like it
> > >> doesn't remove the black surface when the client surface attachs a
> > >> NULL buffer. That's a weston bug, i'd say.
> > >
> > > Giulio's analysis sounds good to me. I think no-one has tried - or
> > > reported - to hide a window using wl_shell that was also fullscreen, so
> > > probably we have never considered that case in the code.
> > >
> > > Very likely a Weston bug indeed, specifically in the case of committing
> > > a NULL wl_buffer when using wl_shell. Transparency was a red herring
> > > all along.
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: black surface in desktop shell fullscreen mode

[zou lan]

Hi Giulio

>>qtwayland uses wl_shell unless the user explicitly enables xdg_shell,
>>and right now hide() attachs a NULL buffer. Even in the xdg_shell
>>case, so that's broken.

Can qtwayland "hide"  implement the transparent window in desktop shell
fullscreen mode? I know it can work in normal mode.  Or Does it expects a
black screen in fullscreen mode?
The app developpers like use this function to swich multi apps.

Thank you.

Best Regards
Nancy



2015-10-08 16:33 GMT+08:00 Giulio Camuffo <giuliocamu...@gmail.com>:

> 2015-10-08 9:59 GMT+03:00 Pekka Paalanen <ppaala...@gmail.com>:
> > On Thu, 8 Oct 2015 11:12:42 +0800
> > zou lan <nancy.lan@gmail.com> wrote:
> >
> >> >>If a client really wants to use the transparency, and does not want
> >> opaque black bars, it can be the client's responsibility to produce a
> >> buffer that can fill the screen.
> >>
> >> This is what the client wants to. The Qt app call "hide" function just
> >> wants to implement a function like minimize the window. But there is no
> >> minimize in fullscreen mode. I think maybe the qtwayland
> >> can implement the "hide" to make the window really transparent , not a
> >> black screen now.
> >
> > Hi,
> >
> > "hide" should be implemented by destroying the wl_surface and/or the
> > xdg_surface, in case committing a NULL wl_buffer is not allowed by the
> > xdg_shell spec.
> >
> > "Minimizing" is a very different operation, you would use
> > xdg_surface.set_minimized for that, and I don't think being fullscreen
> > prevents that in any way.
> >
> > Both of those do what you want: make the window disappear.
> >
> > Making a window completely transparent though is not something you
> > should try to do, and it won't make a fullscreen window disappear
> > guaranteed.
> >
> > So, my question stands: what does Qt do in Wayland terms for "hide"?
> > Is it using wl_shell or xdg_shell protocol?
>
> qtwayland uses wl_shell unless the user explicitly enables xdg_shell,
> and right now hide() attachs a NULL buffer. Even in the xdg_shell
> case, so that's broken.
>
>
> --
> Giulio
>
> >
> >
> > Thanks,
> > pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: black surface in desktop shell fullscreen mode

[zou lan]

>>If a client really wants to use the transparency, and does not want
opaque black bars, it can be the client's responsibility to produce a
buffer that can fill the screen.

This is what the client wants to. The Qt app call "hide" function just
wants to implement a function like minimize the window. But there is no
minimize in fullscreen mode. I think maybe the qtwayland
can implement the "hide" to make the window really transparent , not a
black screen now.

Thank you.

Best Regards
Nancy

2015-10-02 14:36 GMT+08:00 Pekka Paalanen :

> On Thu, 1 Oct 2015 12:27:21 -0700
> Bill Spitzak  wrote:
>
> > On Thu, Oct 1, 2015 at 12:50 AM, Pekka Paalanen 
> wrote:
> >
>
> > > The black blanket surface behind the window OTOH allows for direct
> > > scanout. If black bars are not visible and the client buffer is
> > > completely opaque, it is possible to scan it out without composition by
> > > rendering.
> > >
> >
> > There should be some way to detect if the buffer is opaque, in which case
> > these optimizations could be done.
>
> There is, the hint is given by the client:
> wl_surface.set_opaque_region. This one we already do in Weston.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: random window positon with desktop shell

[zou lan]

Hi all

I ask this because I run a qt media player on platform wayland, I find it
shows video contents in anothor hardware layer through V4L2 interface, but
the UI is in fb layer by wayland path. So V4L2 interfaces need to know the
UI window start position. But wayland don't have protocol to get this
position. So some functions of this player can't work well on wayland.

Best Regards
Nancy

2015-09-25 14:48 GMT+08:00 Nancy Zou :

> Dear All:
>
>
>
> Can I ask why desktop shell create a new window with random initial
> position? Can I modify it to fixed position in
> weston_view_set_initial_position?  How can the Weston client get the window
> initial position?
>
>
>
> Thank you.
>
> Best Regards
>
> Nancy
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: random window positon with desktop shell

[zou lan]

Hi Giulio

I use the player in qtmultimedia examples. But our video team modify the
code xvimagesink to v4L2sink. They say we can't support xvimagesink.
My Qt version is 5.4.1 now.

Best Regards
Nancy

2015-09-30 15:36 GMT+08:00 Giulio Camuffo <giuliocamu...@gmail.com>:

> 2015-09-30 10:33 GMT+03:00 zou lan <nancy.lan@gmail.com>:
> > Hi all
> >
> > I ask this because I run a qt media player on platform wayland, I find it
> > shows video contents in anothor hardware layer through V4L2 interface,
> but
> > the UI is in fb layer by wayland path. So V4L2 interfaces need to know
> the
> > UI window start position. But wayland don't have protocol to get this
> > position. So some functions of this player can't work well on wayland.
>
> I don't know what that player is and does, but qtwayland 5.6 uses
> subsurfaces for child QWindows, so i believe that fixes your issue.
>
>
> --
> Giulio
>
> >
> > Best Regards
> > Nancy
> >
> > 2015-09-25 14:48 GMT+08:00 Nancy Zou <l...@qti.qualcomm.com>:
> >>
> >> Dear All:
> >>
> >>
> >>
> >> Can I ask why desktop shell create a new window with random initial
> >> position? Can I modify it to fixed position in
> >> weston_view_set_initial_position?  How can the Weston client get the
> window
> >> initial position?
> >>
> >>
> >>
> >> Thank you.
> >>
> >> Best Regards
> >>
> >> Nancy
> >>
> >>
> >>
> >>
> >> ___
> >> wayland-devel mailing list
> >> wayland-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >>
> >
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: random window positon with desktop shell

[zou lan]

Hi Daniel

I agree with you.  Maybe waylandsink can resolve this problem. But we need
update Qt too.
Thank you.

2015-09-30 16:01 GMT+08:00 Daniel Stone <dan...@fooishbar.org>:

> Hi Nancy,
>
> On 30 September 2015 at 08:56, zou lan <nancy.lan@gmail.com> wrote:
> > I use the player in qtmultimedia examples. But our video team modify the
> > code xvimagesink to v4L2sink. They say we can't support xvimagesink.
> > My Qt version is 5.4.1 now.
>
> Newer versions support waylandsink, which performs the same function
> as xvimagesink did under X11. If your KMS driver under Weston and your
> V4L2 media decoder driver both support dmabuf, this approach will be
> zero-copy.
>
> Cheers,
> Daniel
>
> > 2015-09-30 15:36 GMT+08:00 Giulio Camuffo <giuliocamu...@gmail.com>:
> >>
> >> 2015-09-30 10:33 GMT+03:00 zou lan <nancy.lan@gmail.com>:
> >> > Hi all
> >> >
> >> > I ask this because I run a qt media player on platform wayland, I find
> >> > it
> >> > shows video contents in anothor hardware layer through V4L2 interface,
> >> > but
> >> > the UI is in fb layer by wayland path. So V4L2 interfaces need to know
> >> > the
> >> > UI window start position. But wayland don't have protocol to get this
> >> > position. So some functions of this player can't work well on wayland.
> >>
> >> I don't know what that player is and does, but qtwayland 5.6 uses
> >> subsurfaces for child QWindows, so i believe that fixes your issue.
> >>
> >>
> >> --
> >> Giulio
> >>
> >> >
> >> > Best Regards
> >> > Nancy
> >> >
> >> > 2015-09-25 14:48 GMT+08:00 Nancy Zou <l...@qti.qualcomm.com>:
> >> >>
> >> >> Dear All:
> >> >>
> >> >>
> >> >>
> >> >> Can I ask why desktop shell create a new window with random initial
> >> >> position? Can I modify it to fixed position in
> >> >> weston_view_set_initial_position?  How can the Weston client get the
> >> >> window
> >> >> initial position?
> >> >>
> >> >>
> >> >>
> >> >> Thank you.
> >> >>
> >> >> Best Regards
> >> >>
> >> >> Nancy
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ___
> >> >> wayland-devel mailing list
> >> >> wayland-devel@lists.freedesktop.org
> >> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >> >>
> >> >
> >> >
> >> > ___
> >> > wayland-devel mailing list
> >> > wayland-devel@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >> >
> >
> >
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

black surface in desktop shell fullscreen mode

[zou lan]

Hi all

As I known, when a window is fullscreen, desktop shell will create a black
surface after it. If the window is transparent later, it shows a black
screen. But the app developers maybe except it to be hide.

Just take QWindow function hide for example, app1 start app2, then app2
call hide, it excepts to show app1, but it shows the black surface of app2.



   - Does the desktop shell doesn't support set fullscreen surface to be
   transparent?
   - Thank you.

Best Regards
Nancy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel