02:11 <esotericwarfare> hi all

02:11 <esotericwarfare> hi all

02:12 <esotericwarfare> I cannot play videos with mpv in tinywl wayland

02:12 <esotericwarfare> [vo/wlshm/wayland] Compositor doesn't support the required wp_viewporter protocol!

02:12 <esotericwarfare> [vo/dmabuf-wayland/wayland] Compositor doesn't support the required wp_viewporter protocol!

02:12 <esotericwarfare> is there any way to fix this?

02:12 <Ermine> not a bug, use actual compositor, not the educative material

02:13 <Ermine> tinywl can't do a lot of things because it enables only a few protocols

02:14 <karenw> wp_viewporter is pretty basic, if your compositor doesn't have it at all, it's really minimalist and not suitable for general use.

02:14 <Ermine> but the purpose of tinywl is to show how to use wlroots library, not to be a full-fledged wayland compositor

02:16 <Ermine> (you can notice btw that you can't switch out of tinywl by using e.g. ctrl-alt-f3 if you run it on a tty)

02:17 <esotericwarfare> yes I notice that

02:18 <Ermine> But if you're looking for an excercise on compositor development, wp_viewporter protocol is enabled by one line of code in wlroots, try to figure out which one

02:19 <esotericwarfare> okay thannks

02:21 <Ermine> and if you're looking for a compositor for your daily needs, there is a list of wlroots-based compositors: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Projects-which-use-wlroots

02:22 <esotericwarfare> Nice. I will look into that.

02:24 <Ermine> and, since we're on #wayland and not #wlroots, there are also Weston, Kwin (part of Plasma), Mutter (part of GNOME) and whatever Cosmic uses

02:26 <esotericwarfare> I used dwm for a long time then I got tired and only use the framebuffer (I can watch videos with mpv --vo=drm) and run QT apps like falkon and qutebrowser. But now I wanna try wayland lol: dwl is wayland version of dwm, but I'm tired of tiling window manager LOL

02:26 <esotericwarfare> from the framebuffer I can run games like 0ad, gzdoom, I think diablo too

02:27 <esotericwarfare> or maybe its not framebuffer I don't know, from the tty

02:27 <esotericwarfare> Ermine: Thank you so much!

02:59 <soreau> Wayfire FTW - https://streamable.com/chmhn4

02:59 <soreau> zzag: ^^

03:02 <soreau> see y'all next year..

03:10 <zzag> speaking for kwin, we would like to know the title bar rect in order to confine a window during interactive move better, e.g. to avoid placing the title behind a panel. regarding window shade, I think more is needed in order to support it properly (e.g. a shade request in xdg_toplevel), but then again, speaking for kwin, we're considering dropping support for it

03:13 <soreau> zzag: AFAIU, you already can get the shadow margins for CSD toplevels, so you should be able to use this to avoid placing it somewhere undesired (like a panel)

03:15 <zzag> it's not enough. we also need to know the height of the headerbar

03:16 <zzag> ... or the width of the headerbar depending on its orientation

03:16 <soreau> I don't really see why..

03:16 <soreau> if you know the shadow margins, you can just use these values to compute where to put it (or not)

03:19 <soreau> because you know where the input region/rect is, within the buffer (which is larger by the size of the margins)

03:22 <zzag> soreau: the confinement algorithm in kwin attempts to keep the titlebar in the workarea. there must be visible at least some part of the titlebar so the user can still initiate an interactive move, etc

03:22 <soreau> zzag: yes, I understand this - perfectly reasonable

03:23 <zzag> if the shadow margins work for you in wayfire, great, but in kwin, we need to know the titlebar rect to keep the confinement algorithm working the same way as for ssd windows

03:23 <soreau> ah, ssd...

03:23 <soreau> now that sounds like you're trying to involve personal problems ;)

03:24 <soreau> if you want it to work the same, you need to adjust whatever algorithms to be conditional for ssd/csd most likely

03:25 <zzag> well what I'm trying to say is that if somebody proposes a set_title_rect request, kwin would be on board :)

03:25 <soreau> meh..

03:25 <soreau> it's a problem solvable in kwin ssd impl

03:25 <soreau> or the assumptions thereof

03:26 <zzag> soreau: there are no issues with server side decorations, we need to know the titlebar rect when a client uses client side decorations

03:26 <soreau> maybe this would mean huge changes because it still supports x11 or something?

03:26 <soreau> zzag: my argument is that you simply do not

03:26 <soreau> except for stuff like shade effect, which is quite niche

03:27 <zzag> soreau: no, we need it and we would support adding such a hint

03:27 <soreau> zzag: you get the buffer geometry, and the input rect/region extents and compare these two to get l/t/r/b margins and work from there

03:28 <soreau> this can especially work for ssd since you know everything, including titlebar height

03:29 <soreau> https://github.com/soreau/filters/blob/master/src/filters.cpp#L191-L193

03:29 <soreau> bg is the buffer geometry and vg is the view geometry

03:32 <zzag> soreau: as I said it already, we need to know the headerbar height in order to keep certain amount of pixels vertically in the work area when the user tries to push the window down

03:32 <soreau> zzag: you mean during a titlebar move drag?

03:33 <zzag> yes, during interactive move, i.e. after calling xdg_toplevel.move, etc

03:34 <soreau> you could use some sort of clamping to achieve this AFAIU

03:34 <soreau> but anyway, if you can write some MR/issue with enough information to get others on board, maybe it will make more sense :)

03:37 <soreau> don't get me wrong, I'm all for more information about CSD to the compositor like titlebar height, I just don't think kwin needs this infomration for the purpose you describe

03:42 <soreau> zzag: if you get a wild hair, maybe shoot a video of the problem that you want to solve

03:44 <soreau> aside from getting a call into xdg protocol, the other half of the battle is getting clients to actually use the call and set it correctly ;)

03:45 <soreau> would be nice if they called a function on scroll-on-titlebar too, like the menu function expected to be called on titlebar right-click

04:33 <Consolatis> zzag, why not just treat everything outside of shadows as titlebar? do you want users to allow moving a few pixels of the headerbar out of screen as long as $some amount is still onscreen?

04:34 <Consolatis> having the titlebar rect could be interesting though, some random compositor could theoretically use that information to simply cut it off from the client buffer and replace it with an SSD :)

06:52 <zzag> Consolatis: "why not just treat everything outside of shadows as titlebar" then you won't be able to move the window partially offscreen

07:18 <pavlushka> any gui image viewer suggestion other than swayimage?

10:37 <llyyr> pavlushka: mpv

10:38 <llyyr> https://github.com/guidocella/mpv-image-config/

10:54 <soreau> llyyr: nice, I just use `mpv -loop=inf screenshot.png`

16:36 <iomari891> quit

19:16 <wlb> wayland-protocols Merge request !372 opened by () Draft: staging: Add xdg-occlusion protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/372