07:36 wlb: weston/main: Marius Vlad * backend-x11: Move back-end removal to the destroy function https://gitlab.freedesktop.org/wayland/weston/commit/8d85c43355fa libweston/backend-x11/x11.c
07:36 wlb: weston Merge request !1378 merged \o/ (backend-x11: Move back-end removal to the destroy function https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1378)
07:37 wlb: weston/12.0: Derek Foreman * xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/commit/6f26c009c1db xwayland/window-manager.c
07:37 wlb: weston Merge request !1377 merged \o/ (xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1377)
07:42 wlb: weston/main: Derek Foreman * xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/commit/e193a178e806 xwayland/window-manager.c
07:42 wlb: weston Merge request !1376 merged \o/ (xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1376)
09:59 wlb: weston Issue #832 closed \o/ (VNC on imx8 https://gitlab.freedesktop.org/wayland/weston/-/issues/832)
11:03 kchibisov: How to identify that the output has fractional scaling? I'd assume one could do that based on the resolution and logical size from the xdg-output?
11:03 emersion: why do you need to know?
11:03 kchibisov: I said the same to the user of the library.
11:04 kchibisov: but they want it to contraint size.
11:04 kchibisov: They are just get confused that the `monitor` object returns scale 2, but `window` scale 1.5.
11:05 kchibisov: I just remember that GTK folks needed something like that in the past to scale their widgets.
11:05 kchibisov: Since before they used the `some monitor` as a hint, which is obviously wrong.
11:08 emersion: monitors should not be used to infer anything really
11:08 emersion: monitors are best ignored unless there is a really good reason to look at them
11:09 kchibisov: I guess I'll just update the docs and close the issue.
11:09 kchibisov: I was just curious if someone decided to add a fractional scaling information to outputs.
11:09 emersion: nope
11:10 emersion: also wl_surface.preferred_buffer_scale might not match any output's
11:11 kchibisov: I know, I know compositor which has a scaling on per-window basis.
11:11 kchibisov: So you can make some windows smaller/bigger separatelly.
11:22 kennylevinsen: wl_output.scale was superseded by preferred_buffer_scale, so if anything changes I imagine it would be deprecation rather than upgrade to fractional...
11:26 kchibisov: I meant, to xdg-output.
11:26 kchibisov: So it's more like meta data.
11:27 wlb: wayland Merge request !350 opened by Simon Ser (emersion) protocol: mention wl_surface events from wl_output.{scale,transform} https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/350 [Protocol]
12:04 kchibisov: Is it valid for compositor to send configure larger than the configure_bounds it send?
12:12 emersion: yes
12:12 emersion: configure_bounds is just a hint
12:12 kchibisov: But I can use them reliably to constraint initial window size?
12:13 kennylevinsen: it's a bit weird to explicitly request a size larger than configure_bounds, but I suppose it could happen if e.g. a user is resizing a window past output dimensions with SSD
12:13 kchibisov: Like the hint is used for users to not try to draw the window larger than compositor can present in the current state. From what I understand.
12:14 Company: GTK uses the bounds as a hint for the application as an upper limit when the application picks a size
12:14 kchibisov: Yeah, when compositor sends `0x0` I want to limit the size by the configure bounds.
12:14 Company: and the configure size to set the size when it doesn't ask the application
12:14 zamundaaa[m]: kchibisov: yes, that is the intended purpose
12:14 Company: so those numbers rarely ever meet each other in that codebase
12:15 Company: but it's expected that configure size can be largeer than bounds
12:16 kchibisov: Thanks.
12:16 Company: usually the results are inpleasant though
12:16 Company: because a bunch of code will cause a sudden shrink of the window to the bounds
12:16 kchibisov: If the user asks GTK to resize window to WxH will it use configure bounds for that or just resize?
12:16 kennylevinsen: I suppose the flow would be: if configure contains dimensions, adhere to those - if not, pick a size less than or equal to configure_bounds (infinity if not set)
12:17 Company: kchibisov: it will just resize
12:17 kchibisov: Hm, interesting.
12:17 Company: kchibisov: but the next time the app initiates a resize, it will limit itself to the bounds
12:17 Company: which is where you get the sudden shrinking
12:17 kennylevinsen: I suppose that's also fair enough - if a user wants to make the window span two outputs, why not let them? It's just not a pleasant size to pick autonomously.
12:17 Company: you can experiment with that in mutter I believe if you have 2 monitors
12:17 Company: and resize the window to be larger
12:18 kchibisov: kennylevinsen: you don't have tiles spanning 2 outputs.
12:18 emersion: in sway, configure_bounds would account for desktop UI elements like bars, but the user can resize past these bounds
12:18 emersion: in floating mode
12:18 emersion: the bar is actually displayed under the floating windows
12:18 Company: kennylevinsen: it's problematic in the sense that you need to come up with an algorithm that works both for users growing the window out of bounds and for things like output size shrinking
12:19 Company: kennylevinsen: say when you disconenct from an external monitor
12:19 kchibisov: emersion: the bar is displayed where you told it to be displayed though.
12:19 emersion: i mean, sway with default config
12:19 kchibisov: sure.
12:19 kennylevinsen: I would expect a conventional stacking compositor to set bounds to the usable visible area of the current monitor
12:19 emersion: it's just an example of when configure can go past configure_bounds
12:19 kennylevinsen: tiling is just a case where we reduce the bounds further
12:20 Company: we've had various discussions about how to handle bounds and no good conclusion
12:20 kennylevinsen: Company: Yeah I can imagine it's tricky to deal with for a toolkit :)
12:20 kchibisov: The issue I'm trying to solve is to 1) constraint the initial size 2) disallow resizing in tiling in some cases.
12:20 kchibisov: The 1) I solved.
12:20 Company: ie if compositors should send monitor bounds or root window bounds or what
12:20 kennylevinsen: on the protocol level it's trivial enough, but that's how the story goes for most things isn't it?
12:20 Company: and if apps should shrink to bounds or only use it as a limit when growing
12:21 kchibisov: The other issue I have is users want to resize, but not when their window can't resize, like on sway with tiling.
12:21 kchibisov: But tiling state doesn't mandate that it can't resize, and users on compositor I use can resize tiles.
12:21 Company: kennylevinsen: depends on how prescriptive the protocol wants to be - "here's a random number" or "if you do not stay below this number, the compositor will disconnect you"
12:21 emersion: clients are not allowed to resize when maximized
12:21 kchibisov: does sway set maximize for everything?
12:22 kennylevinsen: kchibisov: A tiling compositor should send dimensions in the configure event together with the tiled state, which should overrule bounds anyway. But I would also expect a tiling compositor to send bounds equal to the tile.
12:22 kchibisov: I remember it sets maximize or tiling.
12:22 emersion: do we not have wording to disallow resize when tiled?
12:22 kennylevinsen: clay does that
12:22 kchibisov: emersion: we don't and I'm not sure why we need it.
12:22 emersion: kchibisov: sway sets tiled when xdg-shell version is high enough, otherwise maximized
12:23 kchibisov: kennylevinsen: my tiling compositor can handle user tiles resizes.
12:23 kchibisov: because the `x` is infinite.
12:23 kennylevinsen: which should result in configure events with new dimensions
12:23 kchibisov: So it'll naturally resize and my viewport just scroll.
12:23 kennylevinsen: which should take priority over bounds
12:23 kchibisov: yes, but I'm talking about different issue.
12:23 kchibisov: user want to not resize during tiling when the compositor will crop them, like sway.
12:24 kchibisov: So in theory, I could use `configure_bounds` to limit the resizing in such case, but gtk doesn't do that for example.
12:24 emersion: some more context: https://github.com/swaywm/sway/issues/7794
12:24 emersion: sway crops because sending a protocol error trips too many clients
12:25 kchibisov: emersion: there's no wording for tiled states though.
12:25 kchibisov: so it's not like you can do so.
12:25 kennylevinsen: emersion: do we? I only see tiled for xdg and maximized for xwayland
12:25 emersion: kennylevinsen: logic is in wlroots
12:26 kchibisov: the maximized has the right wording.
12:26 emersion: kchibisov: that sounds like an oversight to me
12:26 kennylevinsen: ah, there
12:26 kchibisov: ok, what to do with tiled compositor which can resize?
12:26 kchibisov: I'd assume that if it can resize, it's not really tiled?
12:27 kchibisov: but without tiled state we can't get rid of the shadows.
12:28 kchibisov: Maybe sway should always set `maximized` then?
12:29 kchibisov: And compositor which can resize during tiling can just have `tiled`?
12:29 emersion: it's not maximized though
12:29 kchibisov: it's just `must be obeyed` doesn't work for 'us' with tiled.
12:30 kennylevinsen: for sway, tile resizing is initiated by sway itself, so whether to allow a certain resize is up to sway. What is communicated to the client would be the current size of the tile, and the client in return states its preferred min/max size which can be used as input
12:30 kchibisov: kennylevinsen: yes, but some compositors can resize tiles when user does it correctly.
12:31 kchibisov: So if user decided to resize due to some input event, it'll work normally.
12:31 kchibisov: even when everything is tiled.
12:31 kchibisov: sway can't do that, because it's `x` limited.
12:33 kchibisov: Separate `RESIZEABLE` flag sent by compositor could work though.
12:33 kennylevinsen: I don't understand why that is important. In sway, when you enlarge one tile, it shrinks another. In your case, it grows the viewport and shifts is neighbors. Potato tomato?
12:33 kchibisov: kennylevinsen: it doesn't shift anything though.
12:33 kennylevinsen: But if you are not making your windows tiled and using client-side decoration resize, then maybe that is an issue?
12:33 kchibisov: I don't want `must obey` wording.
12:33 emersion: kennylevinsen: sway doesn't support client-initiated resize when tiled, kchibisov's compositor does
12:33 kchibisov: because `must obey` => crash client.
12:34 kennylevinsen: emersion: yeah I had a feeling that was where the issue lied, but didn't seem obvious from the chat so far :)
12:35 emersion: i think tiled GTK hides the resize handles?
12:35 emersion: not sure
12:35 kchibisov: it is, but window could decide to resize itself by some other event.
12:35 kchibisov: like you opened a video of a larger size so it tried to account for it.
12:36 emersion: that sounds like a recipe for disaster tbh
12:36 kchibisov: Yeah, but the user on the sway issue really does that.
12:36 emersion: if you start allowing client-initiated resize when tiled, there's a chance you end up with an infinite feedback loop
12:36 kchibisov: even when I said them the exact same thing.
12:37 emersion: clients fighting each other for the "correct" size
12:37 kchibisov: I'll wait a bit for YaLTeR[m] since its his compositor that can handle client initiated non interactive resizes.
12:37 kchibisov: emersion: this particular compositor doesn't have an issue with fighting, the `x` is unbounded.
12:38 kchibisov: so they all can grow as large as they can.
12:38 kennylevinsen: yeah that differs from sway where there is always a correct size
12:38 emersion: not sure "tiled" is the correct state to use for them
12:38 kchibisov: emersion: it's still tiled, to some sort.
12:38 kchibisov: https://github.com/YaLTeR/niri
12:39 emersion: to me it's maybe tiled on some edges, but not on the resizable edges
12:39 kchibisov: yeah, but if you don't set tiled you have shadows, etc.
12:39 kchibisov: it can probably crop though.
12:39 emersion: shadows are used to allow the user to resize
12:39 kennylevinsen: I imagine you either have resize handles with shadows or no resize handles - if you go full tiled you'll probably need to do fully server-initated resize.
12:40 kchibisov: it uses ssd, so...
12:40 kchibisov: the problem are not with interactive resizes though.
12:40 kchibisov: but with just submitting larger buffer.
12:43 kchibisov: besides, the right wording for tiled could be hard.
12:43 kennylevinsen: yeah and probably wouldn't match your use-case regardless
12:44 kchibisov: Because you can only apply it when 'top and bottom' are tiled.
12:44 kchibisov: The same for 'left and right'.
12:44 kennylevinsen: well maybe not that hard - "if a surface is tiled on two opposing edges, the surface must adhere the window dimension between these edges"
12:45 kennylevinsen: then you'll be able to enforce height without width
12:45 kennylevinsen: but you'd get a shadow on that side most likely
12:46 wlb: wayland-protocols Merge request !257 opened by Simon Ser (emersion) xdg-shell: recommend against drawing decorations when tiled https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/257 [xdg-shell]
12:47 kennylevinsen: do we know of compositors that tile fewer than 4 edges today?
12:47 emersion: i think GNOME does?
12:47 kchibisov: yeah, snap to corner thing.
12:47 kchibisov: You still need an edge to resize with CSD.
12:48 kchibisov: with SSD you don't have to deal with all of that though.
12:48 emersion: kennylevinsen: that would make sense to me
12:48 emersion: (the wording you suggested)
12:48 kchibisov: You'd need a different wording a bit though.
12:49 kchibisov: Since you know the name of the `opposing` edge.
12:49 emersion: allowing resize on one axis when both edges are the edge of the screen doesn't make sense, for instance
12:50 emersion: i'd go as far as saying all compositors i know but niri can't handle client resize when two opposite edges are tiled
12:50 kchibisov: I mean, the wording is correct, you should just tune it a bit to say `right`/`left`.
12:51 kchibisov: since each tiled state is separate.
12:51 emersion: sure
12:53 kchibisov: I guess the said compositor is not really tiled on the `right` edge.
12:53 kchibisov: But at the same time, we don't want the shadow, since we can resize on our own.
12:53 kchibisov: basically what sway does.
12:57 emersion: it would be nice to open an issue summing everything up if you have time
12:57 emersion: maybe jadahl has some insights as well
12:58 emersion: the way i see it, right now we have two states: either ask the client to draw decos and allow resize on a given edge, either ask the client to not draw decos and not resize on that edge
12:59 emersion: and you want a third state: no decos, but resize allowed still
12:59 kchibisov: pretty much it.
12:59 kchibisov: but it's not like compositors can't crop CSDs.
12:59 emersion: that really needs to be per-edge as well, because you still can't resize vertically in niri
13:00 emersion: cropping CSDs kinda works but also doesn't look very good with e.g. border radius
13:00 kchibisov: emersion: you better not see what hack there's in niri.
13:00 emersion: ("what if i want to have tooth-shaped window borders?!?")
13:01 kchibisov: it's basically 'if client.has_csd() => draw_border_just_like_a_big_rect()'.
13:01 kchibisov: otherwise 4 rects separatelly.
13:02 kchibisov: I can probably write an issue for that once I have time. I know that YaLTeR[m] will probably tune in later, since he's in the meeting.
13:02 kchibisov: My inital questions are sort of answered though, given that winit is not GTK and we always use SSD I'll just limit resize in tiled.
13:03 kchibisov: emersion: will you send a wording suggested by kennylevinsen to add 'obey' wording?
13:07 kennylevinsen: yup
13:10 emersion: kennylevinsen: do you want to ^ or ENOTIME?
13:10 kennylevinsen: am doing
13:10 emersion: noice
13:15 wlb: wayland-protocols Merge request !258 opened by Kenny Levinsen (kennylevinsen) xdg-shell: Enforce geometry for tiled xdg_toplevel https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/258
13:16 kchibisov: kennylevinsen: thx, though, it feels like emersion's patch should go first.
13:18 emersion: it's fine, either of us can rebase whenever a patch lands
13:18 kennylevinsen: indeed
13:18 kchibisov: yeah, it's just the kennylevinsen wording feels like not-complete.
13:18 kchibisov: in the context of present wording in maximize.
13:19 kennylevinsen: feel free to add a review comment, it's what MRs are for. :)
13:23 kchibisov: btw, what groups on gitlab are for? I was added to wayland group in the past, but I have no idea why.
13:23 kchibisov: maybe because of the `spam` incedents?
13:24 emersion: shouldn't be the case
13:24 emersion: in general we add people to groups when they can contribute better that way, e.g. issue triage or merging or such
13:25 emersion: you were added by daniels on Mar 30, 2023 for issue triage purposes
13:26 kchibisov: yeah, it's just it's not like I'm very active on wayland tracker, so I don't use any powers.
13:27 emersion: please make use of your powers ;)
13:28 kchibisov: btw, while you're here, why wlroots/sway counts serials for input-method/text-input but never uses them to discard?
13:29 kchibisov: wlroots also resets the serial on input-method::commit, but I also don't know why. Probably these protocols are just a mess...
13:29 emersion: i have no idea, sorry
13:29 emersion: would need to dig into the impl again, it's been ages
13:29 kchibisov: I just have a dig a while ago.
13:29 kchibisov: I'm still not sure that I understand how it all supposed to work with serials.
13:30 kchibisov: especially when gtk commits without active text-input...
13:36 kennylevinsen: I wonder if it would have been better to just have strict min_size/max_size separate from state...
13:43 YaLTeR[m]: does this go through now?
13:43 YaLTeR[m]: yeah it does. At last
13:44 emersion: actually let me try to allow unregistered users one more time, with a secret channel
13:45 YaLTeR[m]: I tried to register on OFTC like a year ago, but NickServ wasn't responding to me. So now I tried again and it worked this time so yay
13:45 kchibisov: emersion: secret should work just fine, given that sr.ht wasn't spammed.
13:45 kchibisov: Though, some users could target this specific channel.
13:45 emersion: it's on another network though
13:46 kchibisov: the spam was there as well, no?
13:46 kchibisov: the sway was spammed a lot.
13:46 emersion: hm, didn't pay close attention
13:46 kchibisov: I know that it had `global pings`.
13:46 emersion: i'd trust libera staff to be reactive about spam a lot more than OFTC
13:46 kchibisov: the same global pings I was getting on oftc.
13:47 YaLTeR[m]: makes me wonder how many more times I thought my messages were going through when they weren't
13:47 kchibisov: just use irc directly, YaLTeR[m] .
13:47 kchibisov: always go through.
13:48 emersion: i wish someone patched the matrix bridge to at least surface back errors properly
13:48 YaLTeR[m]: don't want to set up a bouncer and keep something open just for 1-2 channels
13:48 kchibisov: Some forges provide said bouncer with the account.
13:48 kchibisov: just saying.
13:49 emersion: ^^
13:49 YaLTeR[m]: this coming from someone explaining to me earlier today how hard it is to log into gitlab :)
13:49 kchibisov: YaLTeR[m]: it was yesterday.
13:50 YaLTeR[m]: ah right
13:50 kchibisov: I mean, asking question on irc without registration is instant.
13:50 kchibisov: you just type nick and ask.
13:51 kchibisov: Though, if you just use wayland channel, you don't have to be idle here.
13:51 YaLTeR[m]: well I read this channel and generally expect to participate occasionally
13:51 kchibisov: just read the logs on the logger.
13:51 YaLTeR[m]: anyhow now it works as is, i got registered
13:52 kchibisov: yeah, some channels ask you to register, but it's kind of rare.
13:52 kchibisov: The issue is that you can get logged out and I don't think you'll get notified.
13:52 kchibisov: it's pretty common with oftc to end up like that.
13:52 YaLTeR[m]: oh that's still a thing?
13:53 YaLTeR[m]: isn't technology wonderful
13:53 kchibisov: not with libera, but with oftc it still does happen to me.
13:53 emersion: thank-you-oftc.jpg
13:53 zamundaaa[m]: NickServ does tell you. But if you overlook that and type in the channel, your messages just go into the void
13:53 kchibisov: emersion: we say no to sasl.
13:54 emersion: ;_;
14:03 Company: it's still weird to me how people try so hard to make a communication protocol designed for transient communication retain everything
14:03 Company: use a different protocol if you want that
14:04 kchibisov: yeah, for most projects retain communication is on the git forge.
14:04 Company: you can also use matrix or discourse or all the closed protocols
14:08 Company: YaLTeR[m]: while you're here, there was one thing I wanted to ask you
14:08 YaLTeR[m]: sure
14:09 Company: YaLTeR[m]: in the video apps you're hacking on, what's the alrgest number of video streams you have playing at the same time?
14:09 YaLTeR[m]: I load-tested Identity with, like, 12 FullHD 30 FPS streams at once, which ran in realtime
14:10 YaLTeR[m]: it currently easily runs into a gstreamer crash tho
14:10 Company: I'm trying to figure out how many subsurfaces we would end up with if we passthrough all the video streams
14:11 Company: so that ultiamtely I can judge how much I can automate stuff and how much we need API to toggle things
14:11 pq: Company, what do you worry about with the number of sub-surfaces?
14:12 Company: pq: dunno extensively yet - but it's coming up sometimes, like wondering about swapchains and their sizes
14:12 Company: or how hard it is to (de)compose the render tree in GTK
14:12 pq: Company, hmm. Why would you have your own swapchain for a sub-surface?
14:13 Company: and how important it is to avoid O(N^2) algorithms
14:13 Company: because I want to send dmabufs straight to the compositor
14:13 YaLTeR[m]: I also load test by loading 50+ images at once
14:13 Company: and I can't do that unless I've gotten my dmabufs accepted as wl_buffers by the compositor
14:14 YaLTeR[m]: all of those go through gstreamer
14:14 YaLTeR[m]: so there's that
14:14 Company: 50+ images at once (assuming they're large) will get you bandwidth slowdowns
14:14 pq: Company, use sub-surfaces when you *get* dmabufs readily, like from a video decoder. I would not use the GPU to create a dmabuf from something that wasn't, but just compose that to the main window image.
14:15 pq: IOW, if you need to use a GPU to make a copy of something in order to get a dmabuf you can send to the compositor, maybe it's better to just render that into the window main buffer instead of a sub-surface.
14:16 Company: pq: well, I still need to get it turned into a wl_buffer (unless I use immediate, but that seems scary, too, with how easy it is to break dmabufs)
14:16 Company: no, that's not what I'm wondering about
14:16 pq: no, immediate does not bypass any checks, it just explodes harder
14:16 Company: yeah, that's what I mean
14:16 Company: I want stuff to not explode
14:17 Company: so having a bufferpool set up in advance seems preferable
14:17 Company: and then shuffling those buffers around from the compositor to the video producer (decoder, camera, whatever)
14:17 pq: it depends
14:18 pq: ah, that way, that's cool
14:18 Company: from GTK's POV I think there's 4 rather different producers of buffers:
14:18 Company: video decoders (ie usually same hardware as compositor)
14:18 Company: cameras (different hardware)
14:18 pq: I was assuming that you let the video decoder allocate its own destination buffers, because... they often want that?
14:19 Company: VMs (ie virgl, so probably same hardware, but different settings)
14:19 Company: and OpenGL libraries, that want to render on their own buffer
14:20 Company: and for those 4 cases, GTK should just operate as a passthrough in default operation
14:20 pq: right
14:20 Company: but I'm not quite sure how to achieve that reliably
14:20 pq: you can't, not reliably
14:21 Company: like, in conforming to the protocols and APIs those things use
14:21 Company: and in not exploding various hardware limits and limitations
14:21 pq: protocol and APIs are the easy thing to get right, it's all the stuff that's not explicitly in APIs that likely fails you
14:22 Company: protocols and APIs definitely are not the easy part
14:22 pq: ok, "easiest"
14:22 Company: hehe
14:22 pq: I mean, they are defined at least, to some extent :-)
14:23 Company: yeah, and then they're incompatible
14:23 pq: but yeah, in the end, everything is trial-and-fallback
14:24 Company: bufferpools could simplify that quite a bit, because everything gets negotiated and agreed upon and then it's just a question of who uses which buffer of the pool right now
14:24 Company: basically one big swapchain that goes from producer to compositor - or for direct scanout, potentially straight from webcam to monitor
14:25 pq: ideally, yes
14:26 Company: now we just need to do the "easy" part and make all the protocols and APIs do that ;)
14:26 pq: except you have to negotiate separately for each set of specific devices involved in any particular path
14:27 Company: yeah, I need to tell the compositor and GTK and GStreamer and pipewire and v4l and they all need to agree on stuff
14:27 Company: currently my laptop's webcam produces YUYV buffers and my laptop's GPU only accepts NV12
14:27 Company: so we're almost there!
14:28 pq: heh
14:29 pq: when all else fails, CPU conversion! /o\
14:29 Company: so it's unlikely that for big videos like FullHD with YaLTeR[m] we get >10 videos at once
14:30 Company: we could easily get >10 videos when somebody scrolls in tiktok, but those won't be fullHD
14:30 Company: same for videoconferencing
14:31 pq: I think it's unlike to achieve direct scanout from a webcam anyway, so might as well use a shader to convert. A webcam probably wouldn't use a non-linear format modifier.
14:31 pq: *unlikely
14:32 Company: the question with all of that is how far I can push things
14:32 Company: like, if I get the webcam buffer to the compositor, and the compositor does the compositing/converting, that's better than if I do it
14:33 any1: Switch the camera to MJPEG and HW decode that?
14:33 pq: I wouldn't take that as a given.
14:33 Company: it's the same amount of work in the ideal case, but it's easier to find the ideal case the further downstream the conversion happens
14:34 YaLTeR[m]: switch the camera to MJPEG except it's a logitech camera which will reset all settings and go to 5 fps max when you do that
14:35 pq: is it the same amount of work? I think that might depend on the framerates in each software component.
14:36 pq: but it should be I guess, fully optimized
14:37 Company: this is the simple case anyway
14:37 pq: actually, yes, the compositor might be able to do better than the client indeed, especially if the window is partially occluded
14:38 Company: if there's any compositing happening (like occlusion or scaling or clipping or subtitles or notification overlays or buttons), you want to do the conversion there
14:39 Company: but that's another problem (to know the right thing to convert to)
15:02 MrCooper: pq: FWIW, some GPUs can scan out from linear buffers; apparently Nvidia dGPUs can even scan out from system memory, in contrast to AMD & Intel dGPUs
15:03 kennylevinsen: hmm that would actually be quite a neat trick, why can't other GPUs do that :(
15:03 pq: MrCooper, can, but is it a good idea? anyway, sysram vs. VRAM was the difference I was thinking.
15:03 kennylevinsen: direct scan-out shm buffers!
15:05 pq: I'd imagine integrated display controllers have even less problems scanning out from sysram.
15:05 MrCooper: kennylevinsen: for one thing, it probably results in rather poor utilization of the PCIe bandwidth
15:06 MrCooper: which might interfere with any drawing using the same dGPU
15:08 kchibisov: probably the use case was intel integrated + nvidia dGPU in laptops for that.
15:18 MrCooper: yeah could be
15:19 MrCooper: in which case they might even have optimized the memory fetching to avoid wasting PCIe bandwidth
15:49 DemiMarie: pq: should one always start with doing a conversion in the shader, then try more optimal approaches later?
16:27 wlb: wayland-protocols Merge request !251 closed (linux-dmabuf: mark as stable, v2)
17:09 swick[m]: pq: do you intend to get back to https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/35 at some point?
20:23 Company: does the Wayland spec specify somewhere what algorithm is used for scaling buffers?
20:23 emersion: nope
20:24 Company: hrm
20:24 Company: I'm wondering about GTK's scaling guarantees wrt passthrough
20:24 Company: in particular when downscaling videos
20:26 Company: though I'm not even sure what the best thing to do is when playing a 4k video in a window that's resized to 800x600 or so
20:27 Company: do you want to just linear downscale it or do you want to create mipmaps first - or do you even want to write a fancy shader that does cubic or lanczos or whatever
20:28 Company: question for video people I guess
20:28 emersion: we could have a wayland protocol to set the scaling algo
20:28 emersion: KMS has stuff like this
20:28 Company: might be useful to look into
20:28 emersion: no mimaps though
20:29 Company: I'm far from an expert on scaling algos anyway
20:29 Company: so no idea how video people want their videos downscaled
20:39 Company: emersion: do you ahve a link for docs about that kms property?
20:50 emersion: https://drmdb.emersion.fr/properties/4008636142/SCALING_FILTER
20:50 emersion: original kernel patch had more modes
21:01 Company: yeah, that's not very fancy yet
21:02 emersion: the extra modes were removed because no clear use-case iirc
21:03 Company: what do video players actually do when downscaling?
21:03 Company: just use LINEAR?
21:03 Company: run custom shaders?
21:03 DemiMarie: Company: How big is the performance win from trying to do passthrough instead of just using a shader?
21:03 Company: mipmap?
21:04 Company: DemiMarie: there's tons of answers to that question depending on target hardware, app and what you're actually passing through
21:05 Company: there's 2 potential wins: 1. is not hitting the GPU on mobile devices that have a custom compositing engine
21:05 Company: when playing back video
21:06 Company: the video decoder sends its frame straight to the compositing engine, because GStreamer, GTK and gnome-shell all don't need to touch it
21:06 Company: 2. is the case where you run benchmarks in a VM
21:07 Company: potentially benchmarks that hit the fill rate, so that the framerate goes down if someone does extra copies
21:07 DemiMarie: Is this because the CPU is bottlenecked on memory bandwidth?
21:07 Company: no, the GPU is
21:08 DemiMarie: Anyway, from what others (notably pq) have mentioned here, it seems that the first step is to use shaders because they will work everywhere, and only after that is done look at hardware-specific offloads.
21:08 Company: GPUs can do billions or trillions of pixels per second
21:08 Company: but if you run a benchmark you can see the difference between 500fps and 400fps
21:09 DemiMarie:shrugs
21:09 Company: yeah, the trick is to set up your APIs so that it will magically hit the fast path
21:10 DemiMarie: Who uses GTK on mobile anyway?
21:10 Company: that's the wrong question
21:10 Company: the right question is "Who doesn't use GTK when it's obviously the fastest on mobile?"
21:11 DemiMarie: Does it support Android?
21:11 Company: no
21:11 DemiMarie: Because non-Android Linux is a rounding error
21:11 DemiMarie: non-Android mobile Linux
21:11 Company: I mean, it probably coudl rather easily, but nobody cares
21:11 kennylevinsen: So is desktop Linux, but we're all here aren't we?
21:12 Company: I'm also not doing this to gain market share
21:12 Company: I'm doing this so gnome boxes has a higher framerate than native Windows
21:13 DemiMarie: How will that even be possible?
21:14 DemiMarie: kennylevinsen: desktop Linux is a development environment. For me at least, my phone is not a development environment, and Qubes OS hasn’t been ported to it yet.
21:14 Company: because the native Windows has a shitty gl driver and the VM uses virgl
21:14 DemiMarie: which hardware?
21:14 Company: Intel is known for shitty GL drivers on Windows
21:15 DemiMarie: Whereas Linux uses Mesa?
21:16 Company: yeah
21:16 Company: no idea what Windows VMs use though
21:16 Company: but it's a fun thing to attempt