05:49Dami_Lu: Hi Is there a way to set the position of a child window relative to the main window in wayland?
05:49Dami_Lu: Already read the upstream discussion on "Can't set a position for the top-level window":
05:49Dami_Lu: https://gitlab.freedesktop.org/wayland/wayland/-/issues/183
06:13Dami_Lu: Reproduce using Qt program : https://bugreports.qt.io/browse/QTBUG-124369
07:44wlb: wayland Issue #454 opened by BTD Master (btdmaster) [wayland-cursor] kernel: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set https://gitlab.freedesktop.org/wayland/wayland/-/issues/454
07:44MrCooper: Dami_Lu: it's possible if the child window uses e.g. xdg_popup
07:48Dami_Lu: MrCooper: Thank you, if it is just a widget child window; is there any way to set the position relative to the parent window?
07:49Dami_Lu: Or whether it is necessary to supplement the protocol for such scenarios
07:51MrCooper: only child windows with special roles such as xdg_popup or wl_subsurface can be positioned relative to their parent
07:56Dami_Lu: Yes, got it ; Is it necessary to add corresponding protocols for other child Windows, so that the child window can set the position relative to the parent window
08:47pq: Dami_Lu, the default answer is "no". There would need to be a good justification why, and a good plan for how, given that the client cannot know what the area around the parent window contains or maybe the parent is at the edge of the screen.
08:48pq: this is why xdg_popup uses the positioner interface - you cannot simply set a position, it needs to be negotiated, because your idea of a position might go off-screen etc.
08:49pq: wl_subsurface does not use positioner, because a sub-surface is not a child window; it's an integral part of the same window as the parent surface.
08:56Dami_Lu: pq: Thank you for your reply. Currently, it is a necessary requirement to set the position of the child window in the user scenario. Can we create another issue to track this issue or reopen https://gitlab.freedesktop.org/wayland/wayland/- /issues/183
08:57emersion: Dami_Lu: can you elaborate what the "user scenario" is?
08:57pq: Dami_Lu, please do not re-open that one.
08:57Dami_Lu: pq: I personally think a good plan is necessary :-)
08:58emersion: unless the "user scenario" is a new thing that hasn't been brought up before, the answer is unlikely to change, fwiw
08:58emersion: not to discourage you -- but we really need more context here
08:59emersion: Dami_Lu: btw, there is a proposal for a compromise here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
09:04Dami_Lu: emersion: Thank you for your reply; I am not sure if there is a problem with my description. In terms of user scenarios, my user feedback is that under x11, his program can set the position of the sub-window, and can also adjust or move the sub-window arbitrarily; but in This is not possible under wayland
09:04emersion: the problem is that it's too vague
09:04emersion: we would like to know exactly _why_ you think it's necessary to set the position
09:05emersion: what is the exact app? what is it used for?
09:05emersion: what does the window that needs positioning?
09:06emersion: or, are you working on a toolkit kind of thing, and your "user" is a developer?
09:06Dami_Lu: Thank you. I will also check out the link you sent first https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
09:07Dami_Lu: https://bugreports.qt.io/browse/QTBUG-124369 . Here is a record of a problem I submitted, with comparison effects between x11 and wayland.
09:10emersion: right, but this is not about a concrete use-case
09:10pq: Dami_Lu, we generally do not accept additions to Wayland simply because something was possible on X11, or that the behavior is defined in a toolkit's API.
09:12pq: There needs to be a specific use case: what is the original goal of the application's end user, when the application is deciding to place a certain window in a certain position.
09:15pq: Migrating an application from X11 to Wayland can include redesigning some parts of the application. It's not just a replacement of an API with another.
09:17pq: https://bugreports.qt.io/browse/QTBUG-124369 does not explain anything of the needs of the application end user.
09:17pq: you think you need to position that window, but what for?
09:19pq: Dami_Lu, that is what you would need to explain.
09:28Dami_Lu: The actual scenario is this: there are two screens, the second screen is used as an extension screen. When the child window is opened it needs to be moved to the second screen for display
09:29pq: but not as fullscreen?
09:29pq: what is an "extension screen"?
09:30pq: is this not a desktop?
09:30pq: Who defines which screen is the "extension screen"?
09:34emersion: is this an embedded use-case?
09:38Dami_Lu: The sub-window is not full screen, or the Plasma6 desktop system uses two screens. want to set the sub-window on the second screen.
09:40Dami_Lu: It's not an embedded system, it's just a desktop system.
09:44davidre: If you as a user want a window to always open on a specific screen you can create a window rule for it
09:44davidre: (in the context that this is a plasma system)
09:52Dami_Lu: Thanks. Not a special screen, just a second screen.
09:52Dami_Lu: Regarding creating window rules, can you give me an overview.
09:52davidre: right click on titlebar, more actions, configure special window settings
09:53davidre: there you can select properties on which to match a window and apply actions
10:02Dami_Lu: Is there an API that can be set? If I don’t use kwin, other compositor probably won’t support it either;
10:02Dami_Lu: Moreover, if the second screen is set as the main screen and the first screen becomes the secondary screen, the sub-window needs to be displayed on the first screen;
10:13davidre: People keep asking but you dont answer
10:13davidre: Why does the window need to do that
10:13davidre: no its meant for end user configuratin
10:13davidre: * no rule its meant
10:18pq: Dami_Lu, why does the application know better that the end user or the window system where the child window should be placed? Or is it trying to do it somehow on the end user's behalf? Is it something all the application's users always want?
10:18pq: *know better than the end user
10:19pq: How does the application know which monitor the window should appear on? Why specifically there?
10:20pq: The concept of "main screen" or "primary output" is not universal across desktops, is it?
10:22pq: Dami_Lu, I'm asking, because I want to help you to make your case better. This is not going to get resolved in IRC, but I hope convey what you should explain in your filed issue.
10:43Dami_Lu: pq davidre: Thank you very much for your reply. Maybe my statement is not particularly accurate; the real user requirement of the user application is that the sub-window needs to be displayed on the second screen (not the main screen)
10:43davidre: But why does it need to do that?
10:45Dami_Lu: This is the effect the user wants :-C
10:45pq: why does the user want that?
10:46pq: so, it is the end user who wants that, and not the application, right?
10:46pq: why can't the end user just move the window to where they want it, and have the application remember the layout by using a protocol extension meant for recalling application layouts?
10:47Dami_Lu: Yes , The effect my clients want; They think that the child window should also be set in position
10:47pq: How do "your clients" know what position to set?=
10:48wlb: weston Merge request !1497 opened by Marius Vlad (mvlad) Backport fixes for Weston 12 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1497
10:49pq: Your clients do not know what else is on screen, and they cannot tell different screens apart, can they? So how could your clients know what position is good?
10:49pq: Your clients cannot even address screens by x,y position at all.
10:50emersion: pq, core protocol has x/y sadly
10:50emersion: (wlroots always leaves these zero)
10:51pq: emersion, I know. But you cannot use it, nor trust it, right?
10:51emersion: right
10:51Dami_Lu: pq: This app supports x11 and wayland. The end user believes that this effect can be achieved in x11, so this function should also be implemented in wayland. I also understand the reason, but I'm sorry for having such thoughts
10:52emersion: Dami_Lu: are you a Qt developer?
10:52pq: Dami_Lu, in the beginning, I explained that just because something is possible on X11, is not at all a justification to support the same *mechanism* on Wayland.
10:52Dami_Lu: Yes
10:54Dami_Lu: pq: Yes, I understand, that's why I asked if there are other ways to move the child window.
10:54pq: Dami_Lu, ok, why?
10:55pq: Dami_Lu, so you understand the difference between a user and an application? The end user is a person, and application is a program. How does the application know where the window should be put?
10:55pq: *do you
10:56emersion: it seems like you don't have the information we ask Dami_Lu, so maybe forward the questions we asked to your user
10:56emersion: (by that i mean to the person asking you to implement the feature)
10:58pq: I do not recall any ways to move a window.
11:00pq: Fundamentally the inability for applications to move their windows is intentional. There can be use cases where something more is needed, and it has traditionally been solved by placing a window at x,y. However, Wayland does not have such coordinate system, so the *original* problem needs to be solved somehow else.
11:02Dami_Lu: Although the mechanism is different from x11 under wayland; Under x11 there is the concept of global coordinates, users think that since applications can sub-set the default window position. But it doesn’t work under wayland; (btw, users don’t know x11 and wayland) ;
11:02pq: A big question is how did one come up with the right x,y in the first place. What does it depend on?
11:02Dami_Lu: But it is difficult to explain to users the differences in the same application under different protocol frameworks.
11:04pq: That's true. Sorry to push that pain downstream.
11:04pq: It is unavoidable that when an API has been designed for X11, very likely it will have parts that just cannot be translated to Wayland. Both the API and the applications using the API need to be partially re-designed. This is expected.
11:05pq: The alternative is to stick to X11 via Xwayland.
11:07Dami_Lu: All applications have been adapted to wayland, and xwayland will basically not be considered. :-C
11:07pq: really?
11:07pq: if apps have been adapted, why are they expecting that set window position x,y works?
11:08Dami_Lu: Before I posted this question, we have already discussed it and will not consider xwayland.
11:08pq: ok
11:09Dami_Lu: thank you very much again
11:11pq: Dami_Lu, here's a summary: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264#note_2341260
11:11Dami_Lu: I would like to ask again if Wayland will not consider the function of setting the position of the child window relative to the parent window.
11:13Dami_Lu: I haven't looked at it in detail yet ： https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264#note_2341260
11:13pq: Dami_Lu, I would say "no" if you cannot give any more justification than you did here.
11:14Dami_Lu: ok
11:14pq: All I understood so far is: Qt API has a function to set window position by x,y, and we want it to work. That's not enough, IMO.
11:14pq: not the *general* desktop
11:15pq: it might be fine in special environments
11:15Dami_Lu: yes , set_positon
11:16Dami_Lu: I have also read the logic in qtwayland in detail.
11:16pq: setting window position, and putting a window on a specific monitor are two different goals that have very little common
11:23Dami_Lu: x11 is first achieved by setting the position of the sub-window; in wayland, whether it is setting the position of the sub-window or setting it to be displayed on the second screen (non-main screen), we just try to achieve the same effect.
11:23wlb: weston Merge request !1498 opened by Loïc Molinari (molinari) gl-renderer: Improve axis alignment test https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1498
12:04pq: Dami_Lu, yes, the effect is important, and the mechanism less so. Wayland goes even further and asks "how does one determine the expected effect?" and continues with "what does the compositor need to know, to be able to choose the correct effect in all reasonable/imaginable situations?"
12:05Dami_Lu: :-)
12:06pq: that's why we are such a pain with all the questions about the use cases :-)
12:08Dami_Lu: me toooooo
12:08JEEB: yeh, so in general just "explain the use case" kind of stuff, so it can be checked how limited in scope it would be etc
12:13wlb: weston Issue #898 closed \o/ (Multiseat support, running weston on 2 different seats. https://gitlab.freedesktop.org/wayland/weston/-/issues/898)
13:41Company: a question that came up in GTK while working on black-single-pixel-backgrounds to ease direct scanout:
13:41Company: is sRGB black the same as other colorspace blacks?
13:44daniels: pq and someone else were debating the concept of black a week or two ago
13:45pq: Company, depends on your definitions of each.
13:45emersion: my mood when dealing with X11 DnD is darker than black
13:45pq: emersion, you must be using limited quantization range then.
13:45Company: pq: the thing that the compositor accepts as the kms background - that's more or less the definition I'm after
13:46pq: Company, are you asking, what color value matches the KMS default-black of CRTC areas not covered with any KMS plane?
13:46colinmarc: pq: I got this joke!
13:46daniels: emersion: desolée
13:47Company: pq: GTK wants to detect the case of a video with black bars, so that it can create 2 surfaces - one with a black pixel and one with the video
13:47emersion: aha
13:47Company: so that the compositor can use 1 plane only
13:47Company: and in a color-managed world, what does that mean for the black pixel?
13:48pq: Company, umm... you mean, a video that already contains black bars, GTK would detect those, clip them away, and the replicate them with another wl_surface with a black single-pixel?
13:48Company: no
13:48Company: a video with a different aspect ratio
13:48pq: oh
13:49Company: say a 16:9 video on a 21:9 output
13:49pq: so my first guess was right?
13:50Company: yeah, ultimately it's about the KMS background color
13:50pq: right
13:50Company: though there's the compositor inbetween
13:51Company: and my question was also about how it should work in a perfet world, not how it does work today :)
13:51pq: I kind of suspect that the default-black KMS background color is simply (0,0,0), and what that means depends on what "Colorspace" one chooses. Optionally converted to YCbCr equivalent.
13:51pq: hmm...
13:52mclasen: Company: I think this is just making things too complicated. black is black, as far as I'm concerned, for the purposes of this optimization
13:52Company: mclasen: if the compositor doesn't agree, that doesn't help you
13:53Company: mclasen: also, do you need to set a colorspace (which one?) on the black pixel?
13:54pq: I cannot think of why the simple RGB(0,0,0) would not be it, regardless of color space.
13:54mclasen: if I need to do that, I'd rather do without out that optimization
13:56mclasen: but it is a good reminder that the single-pixel protocol will need some wording around color representation when those things land
13:56Company: yeah, it'd make things trickier, because then the background color would depend on the video's colorspace
13:56pq: I can theoretically imagine mapping sRGB black to dark rather zero light on a display that has very dark blacks, but...
13:57pq: Company, because you want the video black, which might occasionally appear, to match the borders black?
13:57emersion: single-pixel will not need anything special
13:58emersion: single-pixel is equivalent to a wl_shm or DMA-BUF 1×1 buffer
13:58Company: zamundaaa[m]: related, https://wayland.app/protocols/single-pixel-buffer-v1#compositor-support claims kwin as the only compositor not supporting single-pixels - is that just lack of time or are there deeper reasons?
13:58pq: why not just make borders the darkest black you can / bother, why match video black?
13:59Company: it currently is just #000000
13:59mclasen: emersion: at the very least, it should tell us how the 32bit range gets mapped to whatever actual color depth we have
13:59Company: my question was if that's always gonna get the effect I want
14:00emersion: mclasen: nothing special there
14:01zamundaaa[m]: Company: I wrote an implementation a few weeks or so back, but it was stalled because QtWaylandScanner made some dumb assumptions about the protocol name or something, so it didn't compile
14:01pq: Company, which effect do you want? To match KMS default-black, or to match video content black?
14:01emersion: same as DRM_FORMAT_XRGB16161616 getting to DRM_FORMAT_XRGB8888
14:01zamundaaa[m]: I think that's since been resolved, so I'll try again
14:01Company: pq: to get single-plane direct scanout
14:02pq: Company, ok, so you want to match KMS default-black, and not video content black. Ok. Hmm...
14:03Company:no idea how KMS default-black is defined - does that depend on HDR settings?
14:03pq: Company, I would say, use RGB(0, 0, 0), and tag that surface with the output's image description.
14:03zamundaaa[m]: Company: oh, now I remember why it didn't compile. It has a temporary variable for a resource called "r", and the protocol has the variable name "r" for the red component
14:03pq: Company, it's not defined. That's the point.
14:04pq: Company, I suspect KMS drivers just pull out zeros out of a hat as "black", and then it's sent to a sink which will interpret it according to infoframe data.
14:04Company: zamundaaa[m]: so I'll assume it's gonna land in kwin and I don't need to add a special case to gtk for compositors not supporting it (which I really don't want)
14:05pq: RGB zeros, I mean
14:05daniels: Company: fwiw gst uses a (0,0,0,1) spb to letter/pillarbox, so just do that and you'll at least match gst behaviour
14:06Company: pq: that was my assumption, too - but that's all existing code that doesn't concern itself with color management
14:06zamundaaa[m]: Company: you'll have to special case for a while, because flatpaks are a thing
14:06wlb: weston Merge request !1499 opened by Leandro Ribeiro (leandrohrb) clients/image: use CM&HDR protocol extension to present image with embedded ICC https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1499
14:06pq: I recommend plain (0,0,0) RGB as well, either untagged, or tagged with the output image description at most.
14:06zamundaaa[m]: Probably for a few years at least to be safe
14:06pq: Company, I don't think KMS drivers ever will nor should care more than that.
14:07mclasen: emersion: so it only uses 16 bits then ?
14:07Company: pq: I'm talking to compoisitors though, not KMS
14:07mclasen: emersion: just put it in the protocol, so we don't have to guess...
14:07emersion: mclasen: you'd convert from 32-bit to 8-bit, the same way one would convert 16-bit to 8-bit
14:07pq: Company, I know, but compositors match KMS "definition" when off-loading to KMS.
14:07emersion: mceier: no, because that depends on the color encoding and stuff
14:08emersion: and has nothing to do with the protocol
14:08Company: zamundaaa[m]: I can just not support it for kwin 6.0 and fall back to regular drawing - that's fine with me, people can upgrade their kde if they want optimized rendering
14:08emersion: like, one has the same question when converting between wl_shm or DMA-BUF formats
14:08pq: mclasen, the full 32-bit range maps to (0.0, 1.0) range, with a divisor of uint32_max
14:08mclasen: "just use 32bit values for the primaries, we won't tell you how we use them and we won't tell you what other factors are involved"
14:08mclasen: great way to make a protocol :)
14:08pq: just like 8-bit full range maps with a divisor of uint8_max
14:09mclasen: at least it leaves room for interpretation, so it is future-safe
14:09emersion: protocols are not hand-holding explaining basics every time
14:09emersion: (mceier: sorry, wrong mention)
14:10Company: people are tainted from back in the days where 16bit values were interpreted as 8bit values sometimes instead of mapping the whole space to [0..1]
14:10pq: mclasen has a point, the spec should be more clear.
14:11pq: I do not appreciate mclasen's snarkyness, though.
14:11mclasen: my apologies. colors do that to me
14:12Company: it'd be VK_FORMAT_R32G32B32A32_UNORM - if that existed
14:12pq: yes, they tend to do that to everyone
14:12Company: or the equivalent dmabuf format - which also doesn't exist
14:12mceier: emersion: no problem.
14:12jadahl: pq: I appreciate your color comedy though
14:12pq: :>
14:14emersion: describing how to map r/g/b to [0..1] makes sense to me
14:14pq: Company, let's make that untagged RGB(0,0,0) for the black bars. Compositors have more freedom to map untagged content, so it could more easily map to any KMS default-black there might be.
14:15pq: emersion, yes, that.
14:15Company: pq: that might turn out problematic for GTK, because once we're color-managed, we won't do untagged anymore
14:15pq: :-p
14:16Company: and we especially won't have a way to set that color
14:16mclasen: I don't think thats true? the code I wrote will keep working just the same, and it will keep using #00000
14:17Company: Are you sure?
14:18Company: you could certainly special case it somehow, but you run into the same issue: What GdkColor do you accept as "untagged kms black"?
14:19Company: because you'll have to set that in the css
14:19Company: and "#000000" or "black" are sRGB colors
14:19wlb: wayland Merge request !381 opened by Colin Kinloch (ColinKinloch) protocol: Undefine wl_display_sync callback data https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/381
14:22mclasen: Company: yes, it will get more complicated to find the black in the node tree, but the black we pass to the compositor has nothing to do with it
14:42Company: mclasen: it's ultimately the same question though - somebody has to figure out what is "kms black" - either the compositor does it for us or we send a special "kms black" pixel
14:42Company: and then we need to figure out the mapping
14:48pq: Company, I think compositors could also help you by not requiring a too exact match between a single-pixel (0,0,0) buffer and KMS default-black.
14:49Company: ultimately, that question came up because we were wondering if we need to create >1 single pixel buffer with different values for different colorspaces
14:50Company: and also if the single-pixel surface colorspace needs to match the video surface's colorspace
14:50pq: but if this becomes a real problem, there could be a "black pixel" protocol extension that is explicit about not being too picky about what is black
14:50zamundaaa[m]: pq: that depends a lot on what the difference between the values is
14:50Company: this is gonna need some best practices, so apps and compositors agree on what they do
14:51pq: Company, since your goal is not to match video content black, I don't think the video content image description is important.
14:51Company: and then everything's fine
14:51zamundaaa[m]: If KMS black is too vaguely defined, arguably a compositor can't safely do direct scanout with buffers that don't exactly fill the whole screen
14:51zamundaaa[m]: Because it might look noticeably different vs what it does in compositing
14:52pq: ah, the seamless fallback thing
14:52Company: zamundaaa[m]: then somebody needs to define it so that doesn't happen
14:52zamundaaa[m]: looks like it, yeah
14:52mclasen: or we ask for that kms api to set the color
14:53Company: I know there were patches to set the bgcolor in kms
14:53Company: but nobody needed them
14:53pq: KMS kinda has a definition, more or less, assuming people understand "black" as RGB(0,0,0)
14:54Company: do DisplayPort and HDMI require correctly sized buffers?
14:54Company:no idea about those layers of the stack
14:54pq: KMS composition stage gets RGB(0,0,0) as input for default-black, and what happens then is up to userspace to a) set CRTC color props, and b) set connector props.
14:55zamundaaa[m]: Company: DisplayPort and HDMI don't deal with buffers
14:55pq: Company, DisplayPort and HDMI are streams. Video mode says how many pixels they carry per line and per frame.
14:55zamundaaa[m]: They just get a data stream from the scanout hardware, which can do ~whatever
14:56pq: display adapters create those streams in real-time from memory or other sources
14:56Company: right, so the scnout hardware is the one that adds the black bars iiuc
14:56zamundaaa[m]: yes
14:57Company: then we can technically define whatever and use it, it's just that so far the term "black" was working well enough for everyone
14:57pq: yeah, zeros
14:58zamundaaa[m]: Does the background color interact with the CRTC color management properties?
14:59pq: zamundaaa[m], yes, I think it should.
15:00zamundaaa[m]: That's what I think too, but I have the feeling that at least not all drivers implement it that way
15:00pq: possibly, yeah
15:22wlb: weston Merge request !1500 opened by Link Mauve (linkmauve) tests: Call open() with the right flag https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1500
16:07wlb: weston/main: Ray Smith * remoting: Handle non-fatal errors in gst_parse_launch https://gitlab.freedesktop.org/wayland/weston/commit/875d4b162674 remoting/remoting-plugin.c
16:07wlb: weston Merge request !1473 merged \o/ (remoting: Handle non-fatal errors in gst_parse_launch https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1473)
19:00wlb: weston Merge request !1501 opened by Leandro Ribeiro (leandrohrb) color: minor fixes to CM&HDR protocol implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1501 [Colour management]
21:00wlb: weston Merge request !1502 opened by Leandro Ribeiro (leandrohrb) Implement the CM&HDR protocol mechanics to support clients that want to create cprof from params https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1502 [Colour management]
21:03Xanazf: hey guys i got an issue
21:03Xanazf: could anyone help
21:07Xanazf: my chromium is transparent
21:08Xanazf: https://imgur.com/zpEhfhV
21:25vyivel: Xanazf: ask your compositor's devs
22:12bwidawsk: Xanazf: is that native wayland, or through xwayland?
22:26swick[m]: Company: fwiw, I think this isn't hard. the monitor interprets 0,0,0 as black in the color space it is in. black of another color space might not map to black in that color space. if you want the black in your content to match the output black, tag the content with the image description of the output.
22:26swick[m]: as far as KMS is concerned, black must be 0,0,0 on the cable, so whatever is black in the monitor color space
22:30Company: dunno - the thing I want to guard agaisnt is some compositor going "oh in this colorspace the black pixel needs to be 1,1,1 so I need an extra plane" and then direct scanout of the video stops working
22:30Company: and the same problem exists on the GTK level, where the application/theme needs to set a color for the black bar
22:32swick[m]: I mean, yes, black in some color spaces is different from black in others
22:33swick[m]: so an untagged surface gets you ~sRGB blacks which can be brighter than whatever the display can do
22:33swick[m]: so this can happen
22:34swick[m]: and it makes sense. if you always map any content black to the display black, independent of how much dynamic range there is, then you're messing up the constrast
22:34Company: what I want in the end is direct scanout working and there being black bars on the side that people watching the video agree are black bars
22:34Company: and the question is how to get there
22:34swick[m]: yes, so just tag the surface which uses the single pixel buffer with the output image description
22:34Company: oof
22:35Company: that's tricky because the black currently comes from CSS
22:35Company: and the output image description comes out of GStreamer
22:35Company: or more exact: the video file
22:35swick[m]: no, the output image description comes from wayland
22:36swick[m]: and for the css part, that's what color space annotations are for
22:36swick[m]: you'll need them anyway for sRGB, PQ, ...
22:36Company: yeah, but the CSS comes from libadwaita, and that comes before Wayland
22:37swick[m]: well, you can have an "output image description" color space
22:38swick[m]: in css
22:38Company: not sure if I can - I mean, I can add an extension to CSS and define a color named "kms-black" or so
22:39Company: that's tricky though once you have 2 monitors
22:39swick[m]: nah, you only need one more color space option for defining a color: sRGB(0,1,2), PQ(5,6,7), output(10,11,12)
22:40swick[m]: oh I see, it depends on the monitor and that can change...
22:40swick[m]: that's the complication you see
22:40Company: yeah
22:41Company: it also makes the rendering depend on the output
22:41Company: ie when rendering into a PNG vs a monitor
22:41swick[m]: indeed, that's bad
22:42swick[m]: the other solution is to use e.g. black with PQ which will probably always be darker than whatever anything can actually do and then hope compositors figure that out :/
22:44Xanazf: bwidawsk: native wayland with ozone-platform=wayland flag
22:44Company: color: vantablack
22:44Company: btw: https://drafts.csswg.org/css-color-4/#typedef-colorspace-params
22:44Company: css only has predefined colorspaces for now
22:45swick[m]: yes, because they can already reach everything (well, ignoring luminance)
22:46Company: but https://drafts.csswg.org/css-color-5/#custom-color has plans for custom colorspaces
22:47swick[m]: it sure does, but the usefulness is a bit questionable
22:48Company: I wonder how they would do black bars for videos
22:48swick[m]: probably just hoping that 0,0,0 does the trick
22:49swick[m]: and it probably does because everyone gets black points wrong
22:49Company: hehe
22:49Company: I think we'll all just keep using 0,0,0 until it starts breaking
22:50mclasen:claps
22:50Company: either because compositors insist on doing something or because users start complaining that the black bars aren't black
22:50Company: and then I get to reply with https://www.youtube.com/watch?v=RaN1pRbuHLg
22:52Company: how is this working now btw
22:53Company: I want to play back a video, which comes with its own color space, or rather cicp settings
22:53Company: then I ask the compositor to please configure the hardware/driver/whatever to use that
22:54Company: and then direct scanout starts working?
22:54swick[m]: if the hardware can do it, yes, that's the idea
22:56Company: is cicp just those 3 enum values?
22:56Company: transfer function, code points and matrix?
22:59swick[m]: there are more
23:00swick[m]: there is a bit for full vs limited, chroma subsampling location, and I think one more thing that I forgot
23:01Company: why is that in cicp - that goes into the pixel format description already
23:01Company: dangit, people
23:02Company: okay, full vs limited is colorspace, but chroma subsampling is pixelformat
23:02swick[m]: no, it's not
23:02swick[m]: so, the location isn't
23:02Company: I would very much say it is
23:03Company: there's also the fun stuff with linear vs nearest interpolation between the subsamples
23:03Company: and only half the gpus doing linear iirc
23:03swick[m]: the pixel format only gives you the subsampling factors, not where to sample from
23:04Company: well, you can't convert between pixel formats without that info
23:05swick[m]: correct, but that info isn't present in the pixel formats
23:05Company: and that's why I'm complaining
23:06Company: because really, it should go there
23:06swick[m]: you also need the matrix for that, and limited vs full range etc
23:07Company: if you want to convert from 4:2:0 to 4:4:4 you don't
23:07swick[m]: true, but that's one subset
23:07swick[m]: pixel formats are just inherently not always convertible between all other pixel formats
23:07Company: the fact that dmabufs encode YUV vs RGB as different pixelformats is a bug in dmabufs
23:08Company: just like GTK with premultiplied
23:08swick[m]: the premult stuff in pixel formats is just insane
23:09swick[m]: but I don't see your point
23:09Company: my point is about the data types to represent this stuff
23:09swick[m]: you also can't convert between two RGB pixel formats if they have different bit depth, or if one has alpha and the other doesn't, ...
23:09Company: is pixel format different from color space?
23:09swick[m]: yes
23:09Company: or are those just 2 properties of the image description
23:10swick[m]: I can't follow
23:11swick[m]: the pixel format describes where in memory some channels are
23:12Company: but that description is useless unless you know what those channels mean
23:12swick[m]: correct
23:12Company: so the question is if it ever makes sense to pass that format without all the other stuff
23:13swick[m]: if you implicitly have "all the other stuff" then sure
23:13swick[m]: otherwise, no
23:13Company: that's an API design question ofc
23:14Company: ie do I have GdkColorState.format or do I have GdkColorState and format as different properties of my Image type
23:16Company: currently GTK has a generic conversion routine that converts between formats
23:16Company: well, it covnerts to RGBA8 or RGBA32F just so we can upload everything to the GPU
23:17Company: but that function will need to take chroma subsampling information
23:19Company: the question then becomes if chroma subsampling info should be different from the ColorState, so that we can pass it around there without needing a full ColorState object