09:50koty0f: Greetings. I would like to ask for help. I'm using A64 (Mali-400MP2) with lima. I just bumped my Yocto build to kirkstone which has Weston 10.0.2 and Mesa 22.0.3 (previously on honister with Weston 9.0.0 and Mesa 21.2.4 worked OK) and started to get error messages for all of the outputs `format 0x34325258 not supported by output` when I start Weston.
10:13pq: pitust, the authoritative spec of the Wayland wire format is libwayland. Everything else is just reflecting or documenting that. Likewise, the authoritative spec of handling the XML language is wayland-scanner, unless it's something it doesn't care about but others do (like annotating something as a bitfield).
10:14pq: I agree things could be better, but that's how it is today.
10:15mvlad: koty0f, 0x34325258 matches that of XR24, which should be supported by the KMS driver (ubiquitous format). modetest or drm_info should tell you what driver says about it. Last time when this come up, it looks like IN_FORMATS property was found but it couldn't be decoded, which pretty much says that the format couldn't found. It suggest an issue with the driver.
10:16mvlad: koty0f, if possible suggest trying a newer version of the driver, yocto/OE.
10:17pq: the DRM KMS driver, which lima is not, is it?
10:40koty0f: mvlad it seems supported by drm_info https://pastebin.com/GPpmMBwN I noticed I don't have libdrm up to date 2.4.110 while compiling the drm_info.
10:42emersion: the IN_FORMATS is borked
10:45pq: koty0f, you are looking at the legacy info. The IN_FORMATS plane property OTOH is totally broken. This is a bug in the sun4i-drm kernel driver.
10:55pq: swick[m], thanks a lot for the SMPTE follow-up!
10:59koty0f: emerson,pq huh. Sry never used drm_info before. Thanks for pointing it out. Lets bump the kernel then.
11:44swick[m]: pq: I'm still failing to follow your interpretation of the HDR static metadata
11:45swick[m]: I'd like to add something to color-and-hdr about the metadata but if you disagree with the interpretation I'm not sure if it's worth it
11:45pq: swick[m], hmm? Where did I disagree?
11:46swick[m]: > I could perhaps argue that chromatic adaptation could be still be fitted there
11:46pq: ...but I won't.
11:46swick[m]: got it :)
11:47pq: that would be a play with the meaning of the word "color" used in some of the texts we're looking at
11:47pq: like, is it a perceptual color or colorimetric color
11:50swick[m]: especially "any color present in the image signal that is within the mastering color volume is assumed to have been presented as-is on the mastering display during creative approval." would have been much clearer if it said colorimetry
11:51swick[m]: at a few places they are not clear about this, indeed
11:51pq: yeah, that
11:52pq: it could be a "slightly incorrect simplification to help an uneducated reader" like I have a habit of doing, or not
11:53pq: (e.g. my use of the wording "color of light")
11:54pq: ehm, s/uneducated/non-expert/ perhaps
14:27wlb: wayland-protocols Merge request !253 opened by Sebastian Wick (swick) Draft: security-context-v1: Make sandbox engine names use reverse-DNS https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/253
14:33pq: There is no way to make sure that a shared fd stays O_NONBLOCK, is there?
14:34emersion: if you can open it twice, there is
14:35pq: I've no idea where it was opened from.
14:35pq: nor if I would have access to that path
14:36emersion: there is the Linux-specific trick of /dev/fd/<n>
14:37pq: yeah... eh
14:37emersion: but no portable way
14:38pq: read()'ing a shared fd has this problem, and mmap()'ing it has the SIGBUS catastrophe. *sigh*
14:39manmower: heh, can you dup the fd and trust your private copy?
14:39pq: dup does not make a copy
14:39manmower: unix was a mistake
14:40pq: adding more threads could unblock this...
14:41pq: nnnno-
14:41pq: oh hey, EINTR is a thing, just schedule continuous SIGALRM
14:42pq: manmower, see, I'm learning from the best. You.
14:42manmower: that does have a certain manmower charm to it
14:44emersion: in wlroots we just have our own SIGBUS logic
14:45pq: could do that, doesn't make it any prettier
14:45emersion:remembers about that kernel patch
14:50pq: wait a minute... if I try to read from a middle of a file with pread(), and I get EAGAIN, how does the kernel know when the fd should poll as readable again?
14:53pq: maybe the kernel is smart, or maybe I'd just busyloop until the pread proceeds
14:55manmower: I'm a little curious as to pread() behaviour in the non-EAGAIN case too.
14:56pq: I'll leave this question to dan, it'll make a nice present when he comes back from holidays.
14:57pq: which poison to pick
14:57kennylevinsen: pq: does pread on a seekable file affect readability state in the first place? :S
14:58manmower: ^ that's my wonder
14:58pq: kennylevinsen, the thing I want to protect against is flaky network file systems or rotating disk gone to sleep kinda things. I *hope* getting EAGAIN there and then later poll signalling readable.
14:59pq: but no, I don't know
14:59pq: but if I mmap, it's guaranteed to block me, right?
15:00pq: there's no SIGTRYMEMORYACCESSLATERKTHXBYE
15:00pq: though that too has a "solution"
15:00pq: moar thread
15:00pq: s
15:00pq: ^ example result
15:01kennylevinsen: Hah
15:02pq: hmm, or was there some mincore kind of magic to lock stuff into memory...
15:04pq: madvise, MADV_POPULATE_READ...
15:04pq: aaargh, SIGBUS on error >_<
15:05pq: what is it with throwing everything under a SIGBUS
15:08kennylevinsen: Ah yeah, there we go: > Regular files shall always poll TRUE for reading and writing.
15:09pq: pfff
15:09kennylevinsen: so to answer your question: yes, it will poll as readable again :D
15:10pq: Are we going to need library to hide all the horribleness of accessing shared fds in? Oh, but that won't work because SIGBUS.
15:10kennylevinsen: we'll make our own kernel! in webassembly! with hoo...
15:11manmower: sounds like a solid GSoC project
15:11pq: kennylevinsen, where did you find that note?
15:11kennylevinsen: I imagine reviving emersion's old thread about new mmap flags might be a good way forward, at least for Linux...
15:11kennylevinsen: pq: man 3 poll
15:12pq: oh 3, not 2
15:12bl4ckb0ne: linux 2 memory boogaloo
15:12pq: ....maybe Linux is more useful than posix requires?
15:13kennylevinsen: the manpage reads more like their good intentions than their implementation...
15:14kennylevinsen: I doubt it - how would nfs know in advance that a future read RPC operation won't stall?
15:14pq: is someone from the matrix trying to speak again?
15:15pq: ah, no, I guess
15:15kennylevinsen: (it was a response to you pq)
15:15pq: nfs could cache the part of the file that was attempted
15:16pq: sure, it could be out of date again, but then again
15:19pq: so the only way things could be async is... threads
15:22kennylevinsen: io_uring!
15:23kennylevinsen: but yeah, from a portable perspective... everything blocks I/O for regular files, so a thread is an option
15:23pq: good note
16:21emersion:opens social thread about GNOME removing X11 session
16:21emersion:closes thread
17:03kennylevinsen: are you saying the thread wasn't... social?
17:06manmower: he merely said he closed the thread, no other inference should be made. ;)
17:34wlb: weston Issue #822 opened by Doğukan Korkmaztürk (dkorkmazturk) Closing a Steam client window crashes Weston https://gitlab.freedesktop.org/wayland/weston/-/issues/822
17:58Riolku: curious, whats blocking ext-session-lock-v1 from becoming stable?
18:09bl4ckb0ne: isnt it already?
18:17zzag: bl4ckb0ne: no, it's not in stable/ directory
18:17bl4ckb0ne: isnt staging the new stable
18:18kennylevinsen: No, staging is the new "unstable" beacuse the name was confusing people a lot
18:18zzag: bl4ckb0ne: no, it's considered as a testing ground
18:18bl4ckb0ne: > gAfter a staging protocol has been sufficiently tested in the wild and proven adequate, its maintainers and the community at large may declare it "stable", meaning it is unexpected to become superseded by a new major version.
18:19bl4ckb0ne: Riolku: probably time
18:20kennylevinsen: it does not matter that much to implementers, protocols in staging are safe to implement and we avoid breaking them all the same
18:21JoshuaAshton: I think the entire split system is just... :/
18:21zzag:would prefer not to split protocols in stable and staging but it's bring old discussions up.....
18:21zzag: bringing*
18:21JoshuaAshton: srry i already did :D
18:22kennylevinsen: idea: rename stable to something equally vague
18:22bl4ckb0ne: horsey
18:22vyivel: not_staging
18:22kennylevinsen: "staged"
18:23bl4ckb0ne: stalwart
18:24zzag: JoshuaAshton: either way, it was discussed, but I don't remember the arguments in favor of still having "stable" protocols
18:24JoshuaAshton: ancient
18:24JoshuaAshton: crusty?
18:24JoshuaAshton: crusty protocols
18:26bl4ckb0ne: durable
18:27bl4ckb0ne: or sturdy
18:27zzag: JoshuaAshton: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/55#note_861701
18:29JoshuaAshton: I've been making your point about not needing to get everything right from the start for a while
18:30JoshuaAshton: Really we are in the best situation we have ever been for iterating on this side of the stack and discarding baggage, yet things move significantly slower than they did back on X11 :s
18:33zzag: I think it's connected to the requirements that have to be met in order for a protocol to get in. A protocol must be agreed upon by some number of communities, but it's **also** has to be implemented by some number of compositors and clients
18:33zzag: Depending on member priorities that can be challenging
18:33zzag: On X11, you've got effectively only one server
18:34zzag: So you don't need to worry about various members prioritizing implementing particular protocol
18:35JoshuaAshton: I mean you also do not need to worry about that for Wayland. Wayland Protocols is just a repo of some protocol xmls, anyone can implement something in their compositor and have clients use it.
18:36zzag: Sure, but depending on the protocol namespace, N parties have to implement the protocol so it can land in wayland-protocols
18:36JoshuaAshton: Nothing technically has to land in wayland-protocols :p
18:37manmower: oh come on, let's not give up entirely. we could just make everything ext- protocols. ;)
18:39Riolku: looks like gnome, kde, and weston all dont support ext-session-lock-v1 yet
18:39wlb: weston Issue #823 opened by Link Mauve (linkmauve) Weston crashes when starting Warcraft III in wine-wayland https://gitlab.freedesktop.org/wayland/weston/-/issues/823 [Input]
18:39JoshuaAshton: I iterate pretty quickly on SteamOS/Gamescope using private protocols implemented in Gamescope + a Vulkan Layer. It's a pretty nice environment to play with. Stuff there could probably also be ext protocols, but not having to worry about API/ABI between Gamescope<->Layer is nice so I can just chop and change at wll.
18:41kennylevinsen: Riolku: stable != supported
18:42Riolku: Do those compositors have their own screen locking protocol? and... why?
18:42kennylevinsen: The "ext_" namespace is for protocols that aren't necessarily meant to be supported across the entire ecosystem, just ones that are useful to a number of compositors/clients and would be good to not be private.
18:43kennylevinsen: which is also why it's easier to get an ext_ protocol in than, say, wp_ or xdg_
18:43Riolku: ah. Compatability would be nice
18:44kennylevinsen: Riolku: GNOME handles screen locking internally in their shell with some integration with GDM IIRC
18:44kennylevinsen: no wayland protocols in sight
18:44Riolku: oh
18:47vyivel: is there an easier way to run locally built weston than `WESTON_MODULE_MAP=<comically large mapping of at least 4 components> build/compositor/weston"?
19:18pitust: okay so i'm trying to draw like actual content into my buffer now
19:18pitust: and my seemingly correct rendering code (and its 2 for loops, you cant really fuck it up that hard) draws completly wrong
19:19manmower: I guess stride, format, and modifiers are the easy traps to fall into...
19:20manmower: you're using shm? probably a stride error?
19:20pitust: wl_shm, yes
19:20pitust: er, i'm setting my stride to buffer width * 4
19:21pitust: setting it to one less makes sway really upset and it doesn't draw it anymore
19:22manmower: width * 4 is pretty normal
19:22pitust: not a hard error because who would want hard errors in this kind of scenario!
19:22kennylevinsen: for ARGB8888 that would be correct. You're probably just mathing wrong. Position starts upper left, each line is *stride* long, remember alpha...
19:23pitust: i'm drawing without alpha, format = wl_shm::format::xrgb8888
19:23pitust: xrgb8888 is one of the two default ones, so i figured it's a safe bet
19:23manmower: you're still throwing in a byte for alpha though, right?
19:23manmower: it's just ignored, but still present
19:24pitust: yes of course
19:24pitust: i'm doing ((uint32_t*)buf2.mem)[x + y * maxW] = 0xffffff; to draw pixels
19:24pitust: buf2.mem is memory_mapped_region + buffer_ofset, maxW is the width of the buffer
20:04pitust: hmm okay
20:04pitust: sway seems to have decided to scale my buffer for some reason?
20:05pitust: okay so i needed to tell the viewporter that it should take [0x0, WxH] as the sourcce
20:06kennylevinsen: only if your buffer isn't WxH
20:09pitust: oh well yeah that makes sense
20:10pitust: i preallocate a bunch of buffers that are really large, and then just use the viewporter to clip off all the stuff i don't need
20:10kennylevinsen: why? wl_shm_pool lets you make multiple wl_shm from the same array if you for some reason want it to be one big allocation
20:11kennylevinsen: s/array/anonymous file/
20:11pitust: i know, but allocating contignous regions from a file is super pain
20:12pitust: and my ID allocator is also incredibly crap and i'm sorta worried about running out of IDs
20:12kennylevinsen: maybe fix that first then, pretty core to dealing with the wire protocol
20:13pitust: well no i mean i can allocate them, i just don't handle freeing them yet
20:13pitust: i should probably handle that too
20:14kennylevinsen: sounds like a good idea
20:15pitust: i can reuse an ID the moment i get a delete_id event from the compositor, right?
20:15kennylevinsen: yeah, delete_id means the compositor acknowledged the ID as dead
20:16pitust: cool. so that's implemented now
20:16kennylevinsen: until then the ID is zombie-fied - not referring to anything, not valid to allocate
20:17pitust: i guess if the compositor is slow enough at deallocating callbacks i'll just commit lots of ids
20:17pitust: but thats fine
20:18kennylevinsen: just remember to service your display connection to pick up the delete_ids, but yeah - allocate away
20:19pitust: my absolutely incredible design choices have led me to construct a system where the event loop is handled by the wayland mini-library exclusively
20:19pitust: i mean i read that this was definitely a bad idea for libwayland
20:19pitust: but nahh
20:19kennylevinsen: yes that is definitely a bad idea for any client that wishes to do anything *other* than talk to wayland
20:20kennylevinsen: if you want an event loop in there, make sure it can be sanely driven by a parent event loop from the client
20:20pitust: yeah i'll probably have to rework that part
20:21vaxry: there is a typo in the governance.md of w-p in point 2.2 :(
20:22vaxry: 2.3*. It says "if if" :(
20:24i509vcb: vaxry: file an MR lol
20:25vaxry: I find typo mrs low quality, can't someone who's a member just make a commit? lol
20:25i509vcb: Or make an issue and let a bunch accumulate before someone makes a batch mr?
20:26vaxry: fair point, I could do that. I'll scrub the MRs and see if any other are hiding
20:26vaxry: MDs*
20:40daniels: pq: I assume that question is for sima rather than me … ?
21:06wlb: wayland-protocols Merge request !254 opened by vaxerski (vaxerski) Fix typos/grammar in README.md and GOVERNANCE.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/254
21:26ojhsdfmne: Hello wayland friends! I am currently trying to implement the wayland protocol, but I am confused about returning errors. The documentation says "Events can be error conditions" "Each interface provides requests, events, and errors (which are really just special events)". But what does that actually mean? what kind of special events? what error conditions? the wl_shm enum says "These errors can be emitted in response to wl_
21:26ojhsdfmne: [23:24] <ojhsdfmne> shm requests." but how do i emit them? with wl_display::error? That appearently is only for fatal errors though so are all errors considered fatal?
21:28ifreund: yes, all protocol errors are fatal
21:28ifreund: (to the client, the server of course keeps running)
21:28ojhsdfmne: alright. so i have to use wl_display::error?
21:29ifreund: that is the event to send error codes yes
21:30i509vcb: I think wl_display::error is where the internal machinery for protocol errors is sent?
21:30i509vcb: Non-fatal errors you'd just send via a plain ol event on the protocol object that raises the error
21:30i509vcb: i.e. zwp_linux_dmabuf_params_v1::failed
21:32ojhsdfmne: but not all interfaces with errors have such an error event. how would i decide what is fatal and what not then? or is the dmabuf extension just an exception?
21:34i509vcb: for fatal errors use the *_post_error functions
21:34i509vcb: for falliable errors send an event
21:34i509vcb: Although if the protocol does not define an event to handle fallible errors then that's a whole other issue
21:35ojhsdfmne: thats libwayland specific though right? i am writing my implemntation from scratch
21:35i509vcb: Ah from scratch
21:35i509vcb: The error in dmabuf is just a regular event
21:35i509vcb: I'm less sure about the wl_display::error, if you can understand rust maybe look at the wayland-rs implementation?
21:36ojhsdfmne: hm never used rust. i will try peeking at the scanner for guidance
21:36ifreund: the description of wl_display.error in the protocol xml explains how it should be used
21:37ifreund: also, just look at what wayland-scanner generates, it's like 1 line of code
21:38ifreund: see the wl_shm.error enum for an example of how interfaces define error codes
21:38ojhsdfmne: i cant find anything generating the *_post_error functions in the scanner
21:39ojhsdfmne: yeah yeah i get how the errors are defined, just not how they are sent
21:39ifreund: oh whoops, I forgot wayland-scanner doesn't generate interface-specific types on the server side
21:40ifreund: it's just wl_resource_post_error()
21:43ojhsdfmne: alright i think i figured it out. wl_resource_post_error just calls wl_resource_post_event(client->display_resource, WL_DISPLAY_ERROR, resource, code, buffer);
21:43ojhsdfmne: so yeah it is using wl_display::error
21:45ojhsdfmne: thank you so much for your help everyone. gn o/
22:09Riolku: Curious, are some shm formats more efficient than others? Or does it depend solely on what my GPU supports, or something?
22:13kennylevinsen: Riolku: the compositor isn't passing shm formats to your GPU, it's uploading it to a GPU texture first
22:15kennylevinsen: Well I guess that copy counts as "passing to the GPU", but not in the efficient zero-copy sense
22:16kennylevinsen: If you need performance or efficiency on the GPU side, you want dmabufs from a GPU resource (gl, vulkan, vaapi, etc.)
22:36Riolku: oh, so i pay a copy regardless, interesting
22:37Riolku: is linux-dmabuf an implementation of dmabufs that avoids a copy?
22:38Riolku: as in, my buffer would not need any transformation before being sent to the gpu?