01:22 daniels: JoshuaAshton: a compositor that signals a frame callback for frame n+1 before frame n has retired is terminally broken
05:30 luna_: https://www.youtube.com/watch?v=AoCTOHRjjbU this just dropped episode 2 of the Fedora Video Podcast
07:00 MrCooper: emersion: my interpretation of frame event semantics results from the compositor sending them when picking the surface buffer for its output frame, which seems quite natural and simple
09:12 pq: emersion, TFs in Weston: depends on the API. On the protocol facing side, probably const struct weston_tf *. In the weston_color_transform API, there are already enums with unioned parameters for what a renderer needs to implement. So yes, there will be enums at some point, but not exactly what the protocol has.
09:34 emersion: dcz: do you have time to move forward the virtual-keyboard proto? if not, i can try
09:34 dcz: emersion: not really. I have no objection against you taking it
09:35 emersion: also let me know if at some point you have time for the IME/OSK stuff :)
09:35 emersion: ack!
09:35 dcz: emersion: not from the Purism or personal side, but I am ready to pick it up if someone wants to hire me
09:36 dcz: (to anyone interested in hiring me, I'm at https://dorotac.eu/ )
09:51 DodoGTA: Is there a Wayland equivalent of XFillRectangle()?
09:52 kennylevinsen: single-pixel-buffer + viewport
09:53 kennylevinsen: but it takes a full (sub)surface, and is not meant as a general drawing API
09:53 kennylevinsen: it is intended for things like background fill
10:05 DodoGTA: So it wouldn't be possible to do something like this?: https://github.com/Suricrasia-Online/Tiny-X11-Trans-Flag
10:05 wlb: wayland-protocols Merge request !211 opened by Simon Ser (emersion) ext-virtual-keyboard: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/211 [In 30 day discussion period], [Needs acks], [Needs implementations], [Needs review], [New Protocol]
10:07 pq: emersion, the semantics of wl_surface.frame callback done is that a new commit is guaranteed to not override the commit of the callback. Unfortunately we were not that good at writing spec language all those years ago. Whether it should be used to implement a FIFO is a whole another question, since it does not ask the done event to be sent ASAP.
10:08 emersion: pq, if a client renders in a loop, and i want to make it render at full speed, i need to send frame callbacks as soon as the client commits
10:10 vbt: emersion: would the ext-virtual-keyboard protocol that you proposed would work for game controllers(/gamepads/xinput devices) ?
10:10 emersion: no
10:10 pq: emersion, re: TFs in Weston; there is also the LittleCMS layer in between, and LCMS already has some curve types defined which we use, and then add those that it misses. Vitaly may even propose to upstream them once they are solid.
10:10 emersion: wayland doesn't do gamepad input
10:11 heftig: > <@ahmadranirilidg:matrix.org> Hello, I'm trying some examples of qt wayland compositior (from qtwayland5-examples package). It's launchable both from TTY or nested. I notice that if I launch the compositor from TTY, my keyboard input become double, like if I type "l", the output become "ll". It doesn't happen when I launch it as nested... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/vLyVoScLguzATLAuwfXBeGqs>)
10:11 vbt: emersion: so, games directly read gamepad events from device fd?
10:11 emersion: yes
10:13 vbt: so, consider this hypothetical situation. remote desktop client wants to support gamepads. so, instead of using any protocols, should it needs to directly read from /dev/js* ?
10:13 emersion: i have no idea how this would work
10:13 kennylevinsen: DodoGTA: sure, just takes a subsurface per bar. Just don't try to do advanced drawing that way with hundreds or thousands of elements :P
10:16 pq: emersion, re: client render at full speed; Well, technically yes, but if you break the no-override guarantee, you violate protocol intention. But, you can say that your presentation is a no-op on a headless compositor, so you don't break the guarantee. Whatever. *shrug*
10:16 emersion: it not headless
10:16 emersion: i just want the freshest frame
10:17 pq: there is no protocol to ask for the freshest frame
10:17 emersion: i just want the client to render at full speed and pick the freshest frame when i do scanout*
10:17 heftig: vbt: a raw hid protocol would be nice
10:18 pq: emersion, sure, but there is no protocol to tell the client to do the equivalent of eglSwapinterval=0.
10:19 emersion: i am not following
10:19 emersion: i'm talking about core wayland only
10:19 pq: there is no way to tell a client to do what you want - there is only a mechanism that you might abuse by violating the intent of the protocol to practically achieve what you want.
10:19 pq: yes, core
10:19 emersion: i disagree
10:20 pq: too bad
10:20 pq: that's the problem with the low-level mechanics, they can always be abused for something they were not meant for
10:21 zubzub: is there a way to deduce if a fourcc code has an alpha channel or do I have to manually map all of them?
10:21 emersion: i don't believe it's an abuse
10:21 pq: zubzub, make an exhaustive map.
10:22 emersion: there's nothing wrong with saying "please render your next frame" right when the client submits a frame
10:22 zubzub: pq: ok :')
10:22 pq: Fine. We disagree. I'm also not going to file a bug against your compositor if you do that, but I will keep my opinion on this for now.
10:22 emersion: we do this in gamescope right now
10:23 zubzub:wonders of some ai chatbot can do it for him
10:23 emersion: zubzub: my long-term plan was to do codegen with https://pixfmtdb.emersion.fr/
10:23 pq: isn't that mainly because EGL is using frame callbacks for something it probably shouldn't?
10:23 emersion: well, not the website, but then underlying library
10:23 emersion: the*
10:24 zubzub: emersion: ooh that looks nice
10:24 pq: zubzub, there's also https://afrantzis.com/pixel-format-guide/ with its tool
10:25 wlb: wayland Issue #378 opened by IgnI VerTiKalCaD (IgnIVertiKalCaD) input lag mouse cursor | Cursor delay https://gitlab.freedesktop.org/wayland/wayland/-/issues/378
10:39 vbt: heftig: but, is the protocol really necessary for that? as per emersion , wayland doesn't handle that.
10:40 kennylevinsen: heftig: maybe something abstracted slightly further away, but yeah would be nice if it could be routed through
10:41 heftig: it could, but resolving fights between applications reading or configuring gamepads, or securing gamepad access doesn't seem like a pressing problem
10:42 vbt: heftig: one of the solution would be "wayland must handle those devices"
10:42 kennylevinsen: especially with the gaming usecase largely served through Xwayland for now anyway
10:43 kennylevinsen: Would be more useful when wine Wayland is completed so gamescope and proton could utilize it
10:44 vbt: kennylevinsen: Xwayland is running on Wayland only, right? it would use the devices in the same way other Wayland clients would.
10:45 kennylevinsen: Yeah but then you need an equivalent X extension to forward it to
10:46 kennylevinsen: IIRC, games like that access the device directly right now...
10:52 kennylevinsen: hmm what would it take to get "close trivial misguided issues" rights
10:58 emersion: want the Reporter role?
10:59 wlb: weston Merge request !1234 opened by Marius Vlad (mvlad) build: bump to version 11.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1234
11:00 kennylevinsen: *looks at gitlab role pages* yeah that should do the trick
11:01 emersion: daniels, pq: ACK to give kenny the Reporter role?
11:01 pq: emersion, sure!
11:01 wlb: weston Merge request !1234 merged \o/ (build: bump to version 11.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1234)
11:01 wlb: weston/main: Marius Vlad * build: bump to version 11.0.93 for the RC1 release https://gitlab.freedesktop.org/wayland/weston/commit/1cad8ea5fd8b meson.build
11:01 wlb: wayland Issue #378 closed \o/ (input lag mouse cursor | Cursor delay https://gitlab.freedesktop.org/wayland/wayland/-/issues/378)
11:05 wlb: weston New tag: 11.0.93 https://gitlab.freedesktop.org/wayland/weston/tags/11.0.93
11:22 wlb: wayland.freedesktop.org Merge request !54 opened by Marius Vlad (mvlad) releases: add weston 11.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/54
11:23 daniels: emersion: absolutely yeah - I just assumed he was already tbh
11:23 emersion: thx!
11:23 wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 11.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/6b4b4c860229 releases/weston-11.0.93.tar.xz releases/weston-11.0.93.tar.xz.sig releases.html
11:23 wlb: wayland.freedesktop.org Merge request !54 merged \o/ (releases: add weston 11.0.93 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/54)
11:24 emersion: i wonder if we should decrease the role of inactive devs/maintainers
11:25 kennylevinsen: daniels: a version of the "walking in with a clipboard and a ladder" effect? :P
11:26 emersion: i do appreciate their past contributions, but decreasing the role to e.g. Reporter would increase security
11:26 kennylevinsen: I don't think there's any harm to having a policy to have permissions expire, they can always ask to have them back
11:31 pq: I thought we already had a policy to reduce privs, but maybe that required the person itself to do it.
11:32 emersion: do you know if the policy was documented somewhere?
11:33 pq: it should be in CONTRIBUTING doc if anywhere
11:34 pq: in Weston it is under "Commit rights" heading
11:42 zzag: Do you think it makes sense to grant "developer" permissions to people/members covered by wayland governance model?
11:43 emersion: we already do that for the w-p repo
11:43 emersion: i was looking at the wayland org mainly
11:44 pq: something something CI permissions by org group...
11:45 pq: otherwise I'd be happy to have very few people with dev or higher role in the wayland org group and use project roles instead
11:45 emersion: use detached pipelines and you don't have this issue
11:46 pq: wasn't detached pipelines a requirement to get CI privs through org groups?
11:46 emersion: and i think Reporter still gives CI access
11:46 emersion: i don't believe it is
11:46 emersion: i may be wrong, haven't checked
11:46 pq: okay, I don't remember how it was supposed to work
11:46 emersion: i think it's either detached pipelines _or_ being a member
11:47 emersion: to be able to run the pipeline
11:48 pq: I can run CI, and I can "retry" other people's CI when they don't have privs. That's all I know and rely on.
11:48 daniels: yeah, reporter lets you run CI afaik
11:49 swick[m]: vbt, heftig, kennylevinsen the inputfd protocol exists and raw HID access is coming with HID-BPF
11:49 daniels: and I'm totally fine with downgrading stuff; maybe we could just come up with a list of people and ping them as a courtesy
11:49 swick[m]: I also have a hacky SDL2 branch which implements the inputfd protocol but for evdev only right now
11:49 zzag: emersion: re w-p: I don't have that https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/205#note_1872856 I was upgraded to "Reporter" though, but it's not enough to merge things
11:49 emersion: zzag, reporter in an org
11:49 emersion: not in a project
11:50 emersion: also, merge ≠ run CI?
11:50 emersion: did you mean the latter?
11:51 zzag: merge
11:51 emersion: zzag: i believe https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/fbf7fc351715aa1f05763bec73f7fc1aa97bc5bd would help
11:51 emersion: but it was later on
11:51 emersion: it was merged later on*
11:51 emersion: zzag, blocked by CI, or blocked by something else?
11:52 emersion: zzag, you are only Reporter in w-p
11:52 emersion: maybe we forgot to upgrade you?
11:53 emersion: zzag, invited you
11:55 emersion: here's a list of people who've made contributions in the past in wayland and wayland-protocols, but are no longer active: @bryce, @rdp.effort, @gfxstrand, @krh, @sardemff7
11:55 zzag: emersion: thanks!
11:55 emersion: (maybe rdp.effort and sardemff7 are still active in weston? they could be added to that project if needed)
11:56 pq: How to contact them... maybe open an issue somewhere and cc them there?
11:57 emersion: okay, ask them to reply if they want to keep their role, and give them 1 month to speak up?
11:58 pq: sure
11:58 SardemFF7: not sure I’d consider myself “active” but definitely available for pings, whatever role that may be :-D
11:58 pq: that makes you at least a Reporter :-)
12:06 wlb: wayland Issue #379 opened by Simon Ser (emersion) Lowering inactive developers/maintainers to reporters https://gitlab.freedesktop.org/wayland/wayland/-/issues/379
12:41 Company: emersion: I see you've never had the pleasure of using imlib ;)
12:41 emersion: aha, no, didn't know about this one
12:42 swick[m]: so, can I also get the reporter role?
12:43 emersion: sure, where?
12:43 emersion: org?
12:43 emersion: hm, i remember this discussion
12:43 emersion: it was about CI, and i'm not a fan hanbding off roles just for the sake of CI
12:44 pq: if you want the color-management factory re-design back to traditional, I'd like to do that before the name abbreviating I think.
12:44 emersion: better just patch projects to use detached pipelines so that anyone can have a working CI
12:44 pq: and the enums after both of those, if wanted
12:46 swick[m]: emersion: the projects inherit from the org, right? so sure, org would work for me
12:46 swick[m]: I mean, it's not just CI
12:49 pq: swick[m], seems we should rebase your color branch to main, that would bring in detached CI pipelines.
12:50 swick[m]: pq: I honestly just don't care about the factory design. if you don't want it anymore, go ahead and remove it, otherwise, keep it.
12:50 swick[m]: but sure, the order makes sense
12:51 pq: I'm torn. It works only half-way.
12:54 pq: To make it work in full, wp_image_description_v1 should have an event delivering the name string of the interface that can be used to inspect it, and clients need to create an extension object from it using that (global) interface in order to get the describing events.
12:55 pq: perhaps version in addition to name
12:56 pq: then we should have no need to ever extend wp_image_description_v1, so we can leave it like wl_buffer is and not bother with the versioning factory requests.
12:56 pq: or, just drop the idea of multiple factory globals, and have a fully traditional monolithic design.
12:56 emersion: can't factories create an interface with a wp_image_description_v1 event?
12:57 pq: what do you mean exactly?
12:58 pq: an event with new_id and without an XML-defined interface?
12:58 emersion: icc_profile_manager provides a request to create an icc_img_desc, which has ICC-specific events and requests
12:58 emersion: icc_img_desc has an event with a new_id, sent once when created, carrying the img_desc
12:59 pq: the problem case is asking a wl_surface for its preferred image description, which could then be from any factory
13:00 emersion: querying img_desc data only makes sense for this case right?
13:01 pq: it should somehow emit factory-specific data in events
13:01 pq: yes
13:01 emersion: so you could have surface_img_desc which carries the img_desc
13:01 emersion: in a new_id event
13:01 emersion: and also provides ways to query the image description data
13:02 pq: can you separate the factory-specific requests in separate interfaces like that? or do you end up with the current wp_image_description_v1 with events covering all factories?
13:03 pq: I mean, one interface for ICC stuff, another interface for parametric stuff, since they are mutually exclusive
13:03 emersion: the goal is indeed to split the requests/events based on the actual type
13:03 emersion: each kind of img_desc gets its own interface
13:04 pq: how do you achieve that?
13:04 emersion: i'm not sure i understand your question
13:05 pq: If I ask a wl_surface for preferred image description, I get a generic object. How do I get a type-specific object instead, when I don't know before-hand which type it is going to be?
13:06 emersion: if you ask a wl_surface for preferred image description, you get a surface_img_desc, not the generic object
13:06 emersion: then the surface_img_desc gives you the generic object as an event carrying a new_id with an img_desc object
13:07 pq: but surface_img_desc is not specific to ICC factory and not specific to parametric factory. How do I get either ICC or parametric object?
13:09 pq: A compositor internally chooses whether it uses ICC or parametric description for the preferred, how can a client get that object with a specific ICC or parametric interface?
13:09 emersion: eh
13:10 emersion: flag and two requests?
13:10 pq: That won't work if someone wants to add a third type with a new global factory. (This is the independent extendability.)
13:12 pq: the flag could be replaced with an interface name string, and the request be in the global factory interface instead...
13:13 pq: I'm getting the feeling that this is over-engineering extendability.
13:14 emersion: this would work, they'd just add their own request to get an img desc from a wl_surface
13:14 emersion: yeah, i think this is a bit tad complicated too
13:15 pq: right
13:15 emersion: do we need the img_desc to be both feedback and input?
13:15 emersion: hm i guess so
13:16 pq: yeah, I want to be able to attach the same object I get as "wl_surface preferred" as the surface's image description.
13:16 emersion: yea
13:16 pq: it's not strictly necessary, but...
13:17 pq: the alternative is to trust that the compositor is efficient in de-duplicating internal image descriptions
13:17 emersion: an ICC ping-pong would be weird
13:17 pq: oh yeah, totally
13:17 pq: that's the point
13:19 pq: I suppose the conclusion is that I'll blow up the whole factory design once more, and go back to the simplest, traditional, monolithic design.
13:20 pq: and add equivalent advertisements as currently is done via globals ads
13:20 pq: or maybe even fold it into the "features" enum
13:21 pq: yeaaah... that's a plan
13:23 pq: I'll sleep over it anyway
13:48 wlb: wayland Issue #380 opened by Med Medin (med.medin.2014) Wayland is slow and laggy on iGPU https://gitlab.freedesktop.org/wayland/wayland/-/issues/380
13:50 wlb: wayland Issue #380 closed \o/ (Wayland is slow and laggy on iGPU https://gitlab.freedesktop.org/wayland/wayland/-/issues/380)
14:11 pq: PQ EOTF is funny. If you deal in YCbCr, the Y goes through the TF, so your max encoded luminance is 10k cd/m². But if you deal in RGB, the TF applies per-channel, so your max is 3 x 10k = 30k cd/m²???
14:13 pq: there must be some subtlety here...
14:13 vsyrjala: it's specified also for YCbCr? that seems unusual
14:13 pq: the YCbCr is the part that makes sense
14:13 pq: I'm looking at BT.2100-2
14:15 pq: Note 4b might explain it, if I can understand it.
14:19 swick[m]: eh, I think the luminance is still defined as weighted sum of RGB
14:19 swick[m]: attaching luminance to the TF was a mistake
14:19 pq: so... if only one of encoded R, G or B is non-zero and that encoded value is v, then PQ EOTF will give the luminance of the code RGB=(v, v, v)
14:21 swick[m]: ah...
14:22 swick[m]: well, that makes sense, doesn't it? always the luminance of the achromatic color
14:26 pq: the only thing I can get from that is red cd/m² is different from green cd/m² is different from blue cd/m²
14:26 pq: so there are three different units, all called cd/m²
14:27 pq: then again, cd/m² is only defined for a green laser, so
14:27 pq: I mean cd is
14:31 pq: suddenly computing the overall luminance of a pixel as EOTF(max(R, G, B)) makes some perverse sense
14:31 pq: but it's all a fallacy, because the nits aren't "real"
14:34 pq: the answer has different units depend on which channel is highest
14:34 emersion: (i think i've already said this before but: you client is sending non-UTF-8, pq, i see � instead of ²)
14:35 pq: oh, right
14:35 pq: and I see your ^2 just fine, and the question mark in a blob
14:36 emersion: (it's possible your bouncer is configured to use a non-UTF-8 encoding as well)
14:37 pq: I'm not using a bouncer, but I very likely have some odd irssi config from a couple decades ago.
14:39 emersion: maybe check your term_charset, recode_fallback, recode_out_default_charset
14:42 pq: recode_out_default_charset was definitely stuck in the 90s
14:42 jadahl: hmm, I see pqs ^2, but maybe irssi is very forgiving
14:42 pq: how's cd/m² ?
14:42 jadahl: works here
14:42 emersion: works, thanks!
14:43 pq: cool, thanks. Now to save the config too...
14:44 emersion: yeah, older clients will try to detect the charset -- but my clients are strict and only understand UTF-8
14:44 pq: ö is o with two dots?
14:44 emersion: yup
14:44 pq: yay
14:44 emersion: \o/
14:44 jadahl: yäy
14:45 pq: ha
15:46 MrCooper: pq: yay, welcome to the 21st century! :P