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

[Pekka Paalanen]

On Wed, 14 Nov 2018 23:00:21 +0800

Post by 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?

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

[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

Post by Pekka Paalanen
On Wed, 14 Nov 2018 23:00:21 +0800

Post by zou lan
Hi pekka & all
I find weston support many xdg shell versions in different weston

versions,

Post by zou lan
as far as I know,
applications only use the genernal xdg shell interfaces to create a

window,

Post by zou lan
for example, waylandsink. If the weston upgrade, should the applications
modify its xdg shell interface or are they just backward compatible.

Does

Post by zou lan
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

[Pekka Paalanen]

On Tue, 20 Nov 2018 17:37:34 +0800

Post by 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?

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.

Post by zou lan
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

[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

Post by Pekka Paalanen
On Tue, 20 Nov 2018 17:37:34 +0800

Post by 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?

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.

Post by zou lan
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
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

[Pekka Paalanen]

On Tue, 20 Nov 2018 20:32:53 +0800

Post by 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?

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.

Post by zou lan
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

[zou lan]

Hi pekka

Post by Pekka Paalanen

Post by Pekka Paalanen
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

Post by Pekka Paalanen
On Tue, 20 Nov 2018 20:32:53 +0800

Post by Pekka Paalanen
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

Post by Pekka Paalanen
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.

Post by Pekka Paalanen
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

[Pekka Paalanen]

This post might be inappropriate. Click to display it.

[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

Post by Pekka Paalanen
On Fri, 23 Nov 2018 16:22:56 +0800

Post by zou lan
Hi pekka

Post by Pekka Paalanen
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.)
- 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

Post by zou lan
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

Post by zou lan
to do AtomicCommit for all crtcs one time, does it support commit for

each

Post by zou lan
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

[Pekka Paalanen]

On Fri, 23 Nov 2018 20:12:53 +0800

Post by 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

Hi Nancy,

in my opinion vendors really should support it. If they don't, it
leaves one of the big benefits of atomic modesetting unimplemented: the
ability to change multiple CRTC-connector-routings reliably. Therefore
I would not want Weston to encourage the use of half-made atomic
drivers.

Post by zou lan
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?

Currently Weston does not enable atomic modesetting at all without
DRM_CAP_CRTC_IN_VBLANK_EVENT. Could that be used as a flag to see if
the driver can accept multi-CRTC atomic commits, or do we need to
TEST_ONLY? The Linux commit 5db06a8a98f515f67446a69c57577c4c363ec65d
only talks about a field being set correctly, it does not imply that
the flag could be used to detect multi-CRTC commit support.

Is an atomic driver that doesn't support multi-CRTC atomic commits even
a thing, Daniel?

Post by zou lan
I also have another question about the function
/* 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.

It shouldn't. If one was to implement strict per-output atomic commits,
it shouldn't involve re-arming the timer for each output to be
repainted on the same cycle.

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

No.

If the vblanks of the outputs do not coincide, then they are not put
into the same repaint_begin/flush cycle. This is decided separately
every time in output_repaint_timer_handler().

Each output will always repaint according to its own timings
independently, but if multiple outputs happen to be ready at roughly
the same time, they get into the same atomic commit.
weston_output_maybe_repaint() decides if the output gets into the
atomic commit right now or not.

Only in rare occasions, like compositor start-up, will all outputs be
forced into the same atomic commit regardless of their timings. This is
used to e.g. make the CRTC-connector-routing changes reliable.


Thanks,
pq