question about drm backend

[Pekka Paalanen]

On Fri, 23 Nov 2018 16:22:56 +0800
zou lan <nancy.lan.zou at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181123/1a8ec799/attachment.sig>