08:58 kchibisov: Is it correct that 'f2c' in weston's presentation-shm is irrelevant, since the time base of frame events could have different base compared to what clock presentation will use?
09:31 kennylevinsen: kchibisov: the calculation is not guaranteed to be correct, but I would not call it irrelevant
09:32 kennylevinsen: but it might be better to just do a clock_gettime at the top of readraw_mode_feedback instead, making everything operate explicitly in the same clock domain
09:32 kchibisov: I mean that if compositor uses different base values, the time it shouws is like 30000ms or more.
09:34 kchibisov: I've asked simply to ensure that the example is not representative and that compositor is correct to use different time bases.
09:35 pq: kchibisov, yeah, that part is weston-specific.
09:36 pq: because in Weston, the frame callback timestamp has an implementation-specific meaning that was interesting to me at the time
09:37 pq: also the presentation-shm mode where it redraws based on presentation-time feedback events would be ill-advised to be used in real programs.
09:40 pq: If the compositor is not presenting to hardware directly, the compositor itself might take time before feedback is available to it, and that would decimate the throughput framerate.
13:11 heeen: what do you need to support scanout buffers in a qtwayland stack
13:12 heeen: i.e. ommit compositor opengl compositing in favor of hardware scanout compositing
13:12 emersion: maybe ask Qt devs?
13:14 heeen: I mean what are the extensions required
13:15 heeen: e.g. dmabuf with support for this and that
13:15 pq: I've no idea how Qt factors into that. You need to be using dmabuf, and it helps if you follow the dmabuf feedback telling you which device to allocate on and what pixel formats and modifiers to use.
13:15 pq: zwp_linux_dmabuf_v1 is the extension, and preferably you'd support all of it
13:16 pq: The rest is just up to the compositor. Making your window completely opaque might help in some cases.
13:18 pq: Avoiding compositor scaling might help too.
13:18 pq: That's probably it, starting from the most important.
13:21 pq: If the app is using EGL, then a new enough Mesa is probably all that the dmabuf and feedback needs, it's handled under the hood I believe.
13:21 pq: Similar with Vulkan, but the app needs to handle some hints on when to reallocate the swapchain?
13:22 pq: heeen, or were you asking about what a compositor should do?
13:32 heeen: the compositor
13:32 pq: d'oh
13:32 pq: forget all that, and let's start from scratch.
13:33 heeen: surely you will have to talk to some drm? dmabuf? some library that abstracts it like mesa? API for scanout buffers and blitting information?
13:33 pq: The compositor needs to implement zwp_linux_dmabuf_v1 and the more complete the implementation, the better.
13:34 pq: You ask KMS for the pixel format + modifier pairs that it can accept.
13:34 pq: Intersect that list with the format+modifier list you can texture from.
13:35 pq: That gives you the format+modifer list you can advertise in the zwp_linux_dmabuf_v1 trache with the scanout flag.
13:36 pq: Your compositor also needs to analyze its scenegraph: if this wl_surface used a different format+modifier, could it maybe have ended up on KMS scanout?
13:36 pq: If no, do not advertise the scanout tranche to the wl_surface.
13:36 pq: If yes, advertise the scanout tranche to the wl_surface.
13:37 pq: Maybe the client switches to the format+modifier you suggested, and that allows you to use a KMS plane for the surface instead of OpenGL.
13:38 pq: That's the high level story. Of course there are tons of details to get right.
13:39 pq: When clients give you a dmabuf, and your scenegraph says it could be on a KMS plane, you import the dmabuf to KMS, create a DRM FB from it, and do an atomic TEST_ONLY commit to see if it would work.
13:41 pq: Crafting the atomic KMS state even just for TEST_ONLY is a big chore, because you need to test the full state to get a reliable answer. You cannot e.g. test independent KMS planes in isolation.
13:44 pq: There may also be many different possible assignments between surfaces and KMS planes, where only some may work. Combine that with all other KMS state, and you have a combinatorial explosion of a search space to cover in order to find the optimal configuration.
13:44 pq: so some heuristics are in order
13:45 pq: libliftoff might be worth looking into
13:45 emersion: i wouldn't recommend implementing any of this from scratch
13:45 emersion: if possible, use an existing compositor library
13:50 pq: heeen, as for APIs, something definitely needs to use DRM KMS and GBM APIs. OpenGL and EGL are not relevant, and I don't think Vulkan is either.
13:51 heeen: I'm looking for the right keywords to google and grep in weston for
13:55 pq: heeen, in weston, drm_assign_planes() is the entrypoint to the machinery that tries to probe for a good KMS configuration.
13:55 pq: weston implements *all* of the above itself, without using any helping libraries
13:55 pq: for better or worse
13:57 pq: if you grep for dmabuf_feedback you find the code that touches the dmabuf protocol
13:59 pq: mvlad, leandrohrb, do you recall any write-ups or blog posts about how to make direct scanout work in a compositor?
14:09 mvlad: pq, don't recall anything written per se. dmabuf and pixel fmts are the usual suspects. Could try out the drm-backend debug scope, should provide the reason why we can't assign the view to a HW plane.
14:20 pq: mvlad, heeen wants to know how direct scanout works in general, how does one implement it.
15:54 pq: SardemFF7, hmm, I just landed something in Weston and the bot is silent.
15:56 daniels: yeah, I gave up on re-enabling it since it always got disabled later the same day
15:59 SardemFF7: sorry, made a typo in the workaround, of course †_†
16:01 SardemFF7: and made it hourly to be extra safe
21:03 heeen: is weston using libliftoff?