ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
ybogdano has joined #wayland
gfxstrand has joined #wayland
genpaku has quit [Remote host closed the connection]
genpaku has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
molinari has joined #wayland
gfxstrand is now known as Guest2948
Guest2948 has quit []
gfxstrand has joined #wayland
co1umbarius has joined #wayland
eroc1990 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
ngortheone has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Guest2934 has quit []
ybogdano has joined #wayland
ybogdano has quit []
floof58 has quit [Remote host closed the connection]
ybogdano has joined #wayland
mkoncek has quit []
floof58 has joined #wayland
julio7359 has joined #wayland
ukiran has joined #wayland
dcz has joined #wayland
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
that_guy_ has joined #wayland
that_guy has quit [Read error: Connection reset by peer]
ukiran has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
kts has joined #wayland
mvlad has joined #wayland
ukiran has joined #wayland
molinari has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
hardening has joined #wayland
pochu has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
ukiran has joined #wayland
ukiran85 has joined #wayland
ukiran85_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
ukiran has quit [Ping timeout: 480 seconds]
ukiran85 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
manuel1985 has joined #wayland
ukiran has joined #wayland
ukiran85_ has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
kts has quit [Quit: Leaving]
rasterman has joined #wayland
<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?
sstiller has joined #wayland
<kennylevinsen>
kchibisov: the calculation is not guaranteed to be correct, but I would not call it irrelevant
<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
<kchibisov>
I mean that if compositor uses different base values, the time it shouws is like 30000ms or more.
<kchibisov>
I've asked simply to ensure that the example is not representative and that compositor is correct to use different time bases.
<pq>
kchibisov, yeah, that part is weston-specific.
<pq>
because in Weston, the frame callback timestamp has an implementation-specific meaning that was interesting to me at the time
<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.
<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.
lmaoman has joined #wayland
jmdaemon has joined #wayland
fmuellner has joined #wayland
sstiller has quit [Quit: Leaving]
sstiller has joined #wayland
Lightsword has quit [Read error: Connection reset by peer]
Lightsword has joined #wayland
devilhorns has joined #wayland
Sachiel has quit [Ping timeout: 480 seconds]
Lightsword has quit [Quit: ZNC]
Brainium has joined #wayland
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
manuel_ has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Ping timeout: 480 seconds]
Lightsword has joined #wayland
Lightsword has quit []
jmdaemon has quit [Ping timeout: 480 seconds]
Lightsword has joined #wayland
mvlad has quit [Remote host closed the connection]
mvlad has joined #wayland
devilhorns has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
ukiran85 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
<heeen>
what do you need to support scanout buffers in a qtwayland stack
<heeen>
i.e. ommit compositor opengl compositing in favor of hardware scanout compositing
<emersion>
maybe ask Qt devs?
<heeen>
I mean what are the extensions required
<heeen>
e.g. dmabuf with support for this and that
<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.
<pq>
zwp_linux_dmabuf_v1 is the extension, and preferably you'd support all of it
<pq>
The rest is just up to the compositor. Making your window completely opaque might help in some cases.
<pq>
Avoiding compositor scaling might help too.
<pq>
That's probably it, starting from the most important.
kts has quit [Quit: Leaving]
<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.
<pq>
Similar with Vulkan, but the app needs to handle some hints on when to reallocate the swapchain?
<pq>
heeen, or were you asking about what a compositor should do?
<heeen>
the compositor
<pq>
d'oh
<pq>
forget all that, and let's start from scratch.
<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?
<pq>
The compositor needs to implement zwp_linux_dmabuf_v1 and the more complete the implementation, the better.
<pq>
You ask KMS for the pixel format + modifier pairs that it can accept.
<pq>
Intersect that list with the format+modifier list you can texture from.
<pq>
That gives you the format+modifer list you can advertise in the zwp_linux_dmabuf_v1 trache with the scanout flag.
<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?
<pq>
If no, do not advertise the scanout tranche to the wl_surface.
<pq>
If yes, advertise the scanout tranche to the wl_surface.
<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.
<pq>
That's the high level story. Of course there are tons of details to get right.
<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.
fmuellner has quit []
fmuellner has joined #wayland
<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.
<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.
<pq>
so some heuristics are in order
<pq>
libliftoff might be worth looking into
<emersion>
i wouldn't recommend implementing any of this from scratch
<emersion>
if possible, use an existing compositor library
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #wayland
<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.
<heeen>
I'm looking for the right keywords to google and grep in weston for
<pq>
heeen, in weston, drm_assign_planes() is the entrypoint to the machinery that tries to probe for a good KMS configuration.
<pq>
weston implements *all* of the above itself, without using any helping libraries
<pq>
for better or worse
<pq>
if you grep for dmabuf_feedback you find the code that touches the dmabuf protocol
<pq>
mvlad, leandrohrb, do you recall any write-ups or blog posts about how to make direct scanout work in a compositor?
DodoGTA has quit [Quit: DodoGTA]
fmuellner has quit []
fmuellner has joined #wayland
DodoGTA has joined #wayland
<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.
<pq>
mvlad, heeen wants to know how direct scanout works in general, how does one implement it.
fmuellner has quit []
fmuellner has joined #wayland
ukiran85 has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
ukiran85 has joined #wayland
rv1sr has joined #wayland
Company has joined #wayland
ukiran85 has quit [Ping timeout: 480 seconds]
gfxstrand has quit [Quit: leaving]
gfxstrand has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
ukiran85 has joined #wayland
<pq>
SardemFF7, hmm, I just landed something in Weston and the bot is silent.
cool110 has quit [Ping timeout: 480 seconds]
<daniels>
yeah, I gave up on re-enabling it since it always got disabled later the same day
sstiller has quit [Remote host closed the connection]
<SardemFF7>
sorry, made a typo in the workaround, of course †_†
<SardemFF7>
and made it hourly to be extra safe
cool110 has joined #wayland
agd5f_ has quit []
agd5f has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
mokee has joined #wayland
jmdaemon has joined #wayland
floof58 is now known as Guest3026
floof58 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Guest3026 has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
jmdaemon has joined #wayland
junaid has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
Sachiel has joined #wayland
ukiran85 has quit [Ping timeout: 480 seconds]
manuel_ has quit [Remote host closed the connection]
manuel_ has joined #wayland
fgdfgdfgd has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
maxzor__ has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
maxzor__ has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Brainium has joined #wayland
d42 has joined #wayland
maxzor__ has joined #wayland
daz has quit [Read error: Connection reset by peer]