09:29pq: MrCooper, ManMower, IMO, "immediate" includes: does not need a commit, and if the spec says it triggers events, those events are sent before the request is retired. IOW, wl_display_sync will guarantee those events being sent. But it's not "real-time clock immediate" ish.
14:56Eighth_Doctor: pq: is it supposed to be possible to launch weston's kiosk mode without an autolaunch section?
14:57pq: Eighth_Doctor, I'm not the best one to comment on kiosk-shell, but I would think it runs; but something needs to start an app, then.
14:57Eighth_Doctor: yeah, it seems to ignore my setting and load desktop-shell
14:58Eighth_Doctor: this is my config for it: https://github.com/rhinstaller/anaconda/blob/1f7ad78bf1e8b06e7beb7524806d3d6f7ae96fe7/pyanaconda/display_wayland.py#L210-L215
15:00pq: could it be loading a wrong weston.ini? The logs say which one it loads.
15:00Eighth_Doctor: let me check
15:00Eighth_Doctor: but this is basically the code generating the config reduced to simple form: https://paste.centos.org/view/8e028b8b
15:02Eighth_Doctor: pq: here's the log from weston: https://paste.centos.org/view/16991bcb
15:03pq: it should at least load the shell you tell it to, there is no magic to fall back to another shell if one refuses to run
15:03Eighth_Doctor: and here's the config: https://paste.centos.org/view/a2b67e2b
15:04Eighth_Doctor: yeah, it's definitely ignoring it for some reason
15:05Eighth_Doctor: because running weston manually with that config triggers the desktop shell
15:05pq: Using config file '/tmp/tmptskpskp0-wl-weston-sysinstall-ini'
15:06pq: does that contain the right stuff at the time it's loaded?
15:06Eighth_Doctor: yup
15:06Eighth_Doctor: and I just manually loaded with it and got the desktop shell instead
15:06pq: huh
15:07Eighth_Doctor: I'm going to try writing a config manually and forcing it to use that and see what happens
15:09pq: I can't see why it wouldn't work.
15:09Eighth_Doctor: oh yeah, it does it even with manual config
15:12Eighth_Doctor: do I need this to be kiosk-shell.so?
15:12Eighth_Doctor: I wonder
15:12pq: no, shell=kiosk works for me
15:13pq: and you're on 13.0.0 which is quite fresh
15:16Eighth_Doctor: well neither kiosk nor kiosk-shell works
15:16pq: I'm trying roughly the same command like as you, and I get kiosk-shell loaded.
15:16Eighth_Doctor: kiosk-shell.so triggers the right behavior at least in a nested weston
15:16Eighth_Doctor: so I'm confused now
15:16pq: *command line, and config
15:16pq: me too
15:16Eighth_Doctor: and now I'm worried weston is doing the wrong thing in anaconda initial-setup too
15:17Eighth_Doctor: we have no patches on Weston either: https://src.fedoraproject.org/rpms/weston/blob/rawhide/f/weston.spec
15:17Eighth_Doctor: so it's just straight upstream
15:20Eighth_Doctor: this behavior is supposed to exist since Weston 12, right?
15:20Eighth_Doctor: I'm also staring at the commit for it and I don't understand why it doesn't work
15:22pq: Eighth_Doctor, yeah, Weston 12 recognizes the short shell names like 13 does.
15:23pq: weston 11 would need the full name: kiosk-shell.so
15:23pq: but even then, if you provide a wrong name, it would complain
15:23pq: the setting it not even noticed at all
15:23Eighth_Doctor: yes
15:23Eighth_Doctor: that's what's bizarre
15:24Eighth_Doctor: it's as if it gets skipped entirely
15:24Eighth_Doctor: if this fixes it, I may need to also make an adjustment to anaconda-initial-setup too
15:24pq: command line --shell option would do that, but you don't have that
15:24Eighth_Doctor: right
15:24Eighth_Doctor: deliberately so
15:25Eighth_Doctor: as an aside, how do I get out of weston-desktop?
15:25Eighth_Doctor: I don't know how to quit it
15:25pq: ctrl+alt+backspace
15:25pq: you can also send SIGINT to weston
15:26pq: I mean, that's how you quit Weston in general... well, I think kiosk-shell does not have ctrl+alt+backspace
15:27Eighth_Doctor: I really do wish we had a weston-control program
15:27Eighth_Doctor: manipulating the compositor is annoyingly difficult
15:28pq: yeah, I'm going to wish the same once we get serious in trying out HDR color mappings
15:29pq: maybe you need to trace weston's startup in gdb to see why it picks desktop-shell, --wait-for-debugger should help with that
15:30Eighth_Doctor: I'm going to have to do it outside of this annoying installer environment
15:30pq: do remote access?
15:30pq: *no?
15:30Eighth_Doctor: no way to install packages
15:30Eighth_Doctor: it's a readonly liveos image
15:30pq: oh, missing gdb and probably debug infos
15:30Eighth_Doctor: yup
15:32Eighth_Doctor: wtf
15:32Eighth_Doctor: it's ignoring it for this too
15:32Eighth_Doctor: okay something is very obviously wrong
15:34Eighth_Doctor: okay this gets more bizarre
15:34Eighth_Doctor: it works for nested weston but not host weston
15:34Eighth_Doctor: hold up
15:34Eighth_Doctor: wait
15:34Eighth_Doctor: I got a brain blast
15:35Eighth_Doctor: pq: what if my selecting backend via commandline means that the core section is ignored in weston.ini?
15:35Eighth_Doctor: I think that's it
15:35pq: That would be a bug.
15:36Eighth_Doctor: NOPE
15:36pq: maybe some scribbling over memory kind of bug? I tried that too, and didn't see anything wrong.
15:36Eighth_Doctor: run weston the first time, it doesn't work
15:36Eighth_Doctor: run it the second time, it works
15:37Eighth_Doctor: this is insane
15:37pq: yes, yes it is
15:38pq: I'll be going now, good luck!
16:39wlb: weston Issue #868 opened by Robert Mader (rmader) Fullscreen video with GL overlay does not hit plane-only renderer on rk3399 - missing Wayland dmabuf scanout tranche https://gitlab.freedesktop.org/wayland/weston/-/issues/868 [DRM/KMS backend]
17:41MrCooper: robertmader[m]: FYI, looks like Firefox is submitting Wayland surface commits while eglSwapBuffers is executing on another thread, which I don't think can be expected to work: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_2243522
17:52ManMower: O.o
17:52ManMower: that seems like a hard EDONTDOTHAT
17:53bl4ckb0ne: EOHNO
17:53ManMower: :)
18:40daniels: yeah, cannot work
18:46emersion: agreed
18:57kennylevinsen: ugh it's the whole Firefox VsyncSource thing again
19:21kchibisov: I guess a protocol where you basically subscribe to vsync but not obligated to draw can work for firefox. Other platforms have something like that as well, e.g. display link stuff on macOS.
19:26ManMower: is there a need for new protocol? why can't it just coordinate between its threads and make sure it sends its wl_surface.frame before calling eglSwapBuffers (which will implicitly commit)
19:27kchibisov: it wants to do that evene without drawing though?
19:27ManMower: then it can frame/commit when it's not drawing?
19:28kchibisov: Probably, but I remember there were complains on why it even should do thing like that, since some compositors are not happy with empty frame requests.
19:29ManMower: just commit a translucent single pixel buffer to a subsurface...
19:29ManMower:runs away
19:30kchibisov: A helper window, I think I've seen it in x... windows.
19:30Company: some compositors get confused with empty frame requests, yeah
19:30Company: I remember the shell had a bug about it
19:31kchibisov: Touching wl_surface state from multiple threads is not that simple.
19:31Company: nobody knew when to trigger the frame request
19:31Company: immediately or wait until after the next frame?
19:32kchibisov: And even with the only one thread it's still requires effort to get right.
19:32kchibisov: because, mesa is a bit special....
19:32ManMower: what's mesa doing wrong in this case?
19:32kchibisov: ManMower: the scaling stuff basically.
19:33kchibisov: There's no guarantee that you'll actually resize the buffer, so if you're not familiar you'll likely crash.
19:35kchibisov: Like you shouldn't create EGLSurface until the window is configured.
19:35kchibisov: but nothing actually stops you from doing so, so you should be _careful_.
19:35ManMower: gotcha
19:36kchibisov: But I believe it's a confirmed mesa bug to allow resizing EGLSurface if you don't actually draw anything.
19:36kchibisov: or haven't drawn.
19:38kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6818
19:39kchibisov: And back buffer locking on creating with wl_compositor@v6 makes it really likely to crash because can't divide, since you get scale along the first configure.
21:37RAOF: Re: empty frame requests: We have a WLCS test _specifically_ for that, since Mir would immediately fire the callback on the grounds that “Sure, we could accept some rendering from you _right now_”, and that does not make Firefox happy.
22:52bwidawsk: iirc immediate callback is required to make Firefox happy
23:05kennylevinsen: no, firefox just expects the callbacks to be sent with the same timing if there are no changes
23:07kennylevinsen: this behavior was discussed back then, and found to be valid: the client is asking for the *next* good time to draw a frame
23:08bwidawsk: I shouldn't have said "required", but yes, this is what I meant
23:09bwidawsk: though it's weird to me if the client previously received a callback event, it knows the next good time
23:10kennylevinsen: that good time was in the past, if it asks again it's the *next* good time
23:11kennylevinsen: but yeah, the issue is that Firefox and browsers in general have a *lot* of mechanisms tied to vsync, so it's... hairy
23:12kennylevinsen: javascript included - requestAnimationFrame() callbacks need to run after their vsync tick, and before render, because web specs :/
23:15bwidawsk: I realize the spec does not preclude the behavior firefox is intending, but it seems this was not the design of frame
23:16bwidawsk: design goal