00:08 wlb: wayland Issue #432 closed \o/ (Wayland architecture https://gitlab.freedesktop.org/wayland/wayland/-/issues/432)
04:13 mizvekov: So if wl_shell is deprecated, and xdg_shell supersedes it, and we even mention this in the description of wl_shell, then why not simply ship it in libwayland?
04:14 danieldg: because you need to ship the rest of wayland-protocols anyway
04:16 danieldg: I'd say it makes more sense to go the other way: wayland.xml should not be part of libwayland, or maybe it should only contain wl_display (+callback)
04:17 danieldg: but it's not useful to change that now
04:23 mizvekov: wayland-protocols just includes the xmls but does build any libraries, so it's slightly more inconvenient to use.
04:26 soreau: not really
04:26 danieldg: if you have a working build system it's not, if you don't you need one anyway
04:27 danieldg: because you will eventually want to use viewporter, dmabuf, presentation feedback, and others
04:27 mizvekov: well you have to generate the c source from it, and plop it in your build system, instead of just linking to a library. distro folks tend to frown upon this, but I don't mind it too much myself.
04:28 danieldg: a good buildsystem is capable of handling xml -> .c -> .o
04:28 danieldg: that's like the original goal of Make, though it was .y -> .c
04:29 soreau: mizvekov: if you want a wrapper library for most protocols that matter, wlroots does a pretty decent job of this
04:29 soreau: then you don't have to worry about how wayland-scanner works :P
04:31 mizvekov: sure. but I don't mind using the scanner myself, I would do this for the whole libwayland. But it is slightly more inconvenient when you are just experimenting with things and want python-like convenience.
04:33 mizvekov: fwiw, vulkan is in the same boat, and they just ship everything pre-generated from their xmls, which I think is a good model.
04:35 danieldg: it's only a model needed because C doesn't have a buildsystem
04:36 danieldg: I think some distros frown on shipping generated source artifacts too
04:38 mizvekov: Well they tend to prefer shipping things in shared libraries, to both get overall image size down, and to make things more consistent and easier to update.
04:40 mizvekov: So what I meant is, they wouldn't ship the pregenerated C source, but just the shared library build from it, and everyone would just link to it.
04:41 danieldg: but that doesn't apply
04:41 danieldg: the actual wayland protocol is just as much the header
04:42 danieldg: there's little point in making a shared library from the protocols alone
04:42 danieldg: though I guess you could
08:13 kennylevinsen: mizvekov: libwayland is a C implementation of the wire protocol, while wayland-protocols are the language and scanner agnostic protocol definitions. There are other non-C wire protocol implementations and scanners, so shipping pre-built for one of them would be slightly weird.
08:14 kennylevinsen: The mistake was how big the core protocol became. It should just have been e.g. display and registry tbh.
09:12 JoshuaAshton: kennylevinsen: I agree with that
11:01 wlb: weston Merge request !1439 opened by Marius Vlad (mvlad) desktop-shell: Control alpha with keybindings and allow fade animations for other window states https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1439 [Desktop shell]
11:04 Company: kennylevinsen: if you went the route of slimming the protocol you run into the problem of not knowing who implements which of all the extensions and can't even properly deduce what you'd need to support in your code
11:05 wlb: weston Merge request !1440 opened by Marius Vlad (mvlad) libweston/animation: Remove weston_fade_run unused argument https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1440 [libweston API]
11:05 Company: you could potentially solve that with some method where you bundle a bunch of protocols into some kind of "platform", but otherwise this turns into a mess real quick
11:06 Company: arguably it has already
11:25 kennylevinsen: you already need e.g. xdg_shell - having the abstract wl_surface doesn't help developers much in that regard
11:25 kennylevinsen: likewise, I don't think it wp_seat would be confusing compared to wl_seat
11:25 Company: yeah
11:26 Company: I agree that your idea would have been better
11:26 Company: you'd just have run into this issue earlier
11:26 kennylevinsen: I also agree that the current landscape can be a bit confusing. Everything optional has its downsides.
11:26 Company: because there'd be xdg_dnd and wp_dnd and xdg_clipboard and ext_clipboard_manager and...
11:27 Company: there'd probably be separate protocols for each type of input, too
11:29 Company: wl_input for keyboard/mouse and then xdg_touch and wp_stylus and ext_joystick and ..
11:29 Company: I expect that to hapen anyway, just like it happened with X11 over the years
11:30 kennylevinsen: well, tbf it would probably be e.g. a wp_seat, wp_keyboard, wp_touch, ... - with joystick being the likely ext candidate
11:30 Company: just that there needs to be a way to keep an overview
11:30 kennylevinsen: wayland.app was certainly a helpful addition
11:30 Company: both in terms of versions of those protocols and in which protocols are actually widely supported
11:33 Company: there also probably needs to be a way to get rid of protocol support
11:33 Company: so that things like XInput don't happen
11:33 Company: "a way" meaning best practices
11:56 YaLTeR[m]: well we did "get rid" of wl_shell
12:02 bl4ckb0ne: yes
12:12 wlb: weston/main: Marius Vlad * libweston/animation: Remove weston_fade_run unused argument https://gitlab.freedesktop.org/wayland/weston/commit/04d9f7e738ec desktop-shell/shell.c include/libweston/libweston.h libweston/animation.c meson.build
12:12 wlb: weston Merge request !1440 merged \o/ (libweston/animation: Remove weston_fade_run unused argument https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1440)
14:02 m0squ3ra: Hi guys, is there any bug to start working on?
14:10 wlb: weston Issue #864 opened by Sriharsha P V (Sriharsha) Flickering observed after coming out of Unigine heaven https://gitlab.freedesktop.org/wayland/weston/-/issues/864
14:22 m0squ3ra_: has someone tried to build weston with a prefix? I've used the same prefix as wayland, but it doesn't find libeston-14.so.0
14:25 soreau: you have to set PKG_CONFIG_PATH to point to the directory containing the .pc file of the package you want it to find
14:25 soreau: for bugs, you can review the issue reports on gitlab
14:25 m0squ3ra_: ty soreau!
14:26 soreau: np
14:34 daniels: ManMower: I think that #864 is yours ...
14:35 ManMower: even bisected to one of my commits.
15:55 wlb: wayland Merge request !361 opened by mfk530 (mfk530) server: add funtions to get globals in display https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/361
17:20 m0squ3ra_: is there an easy way to stop weston?
17:21 zmike: no, its development will continue
17:21 bwidawsk: ctrl + alt + back iirc
17:21 bwidawsk: lol zmike
17:21 m0squ3ra_: xd
17:21 m0squ3ra_: ty
18:07 m0squ3ra_: is there some wiki containing the concept of damage? (I don't know if it is a weston concept or a wayland concept)
18:09 m0squ3ra_: any* excuse my English
18:14 kennylevinsen: m0squ3ra_: damage is a graphics concept, referring to parts of the screen or a buffer which has changed and therefore needs to be repainted
18:14 m0squ3ra_: ty
18:16 kennylevinsen: A Wayland client submits buffers with damage indicating areas that contain new content, which Weston uses to only paint what is needed.
18:18 wlb: weston Merge request !1441 opened by Derek Foreman (derekf) libweston: Clip damage to paint node visible region https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1441 [Core compositor]
18:20 ManMower: weston has its own concept of damage which is currently violently distinct from the normal graphical concept.
18:37 kennylevinsen: Well isn't that great :|
18:38 ManMower: well, it's pretty normal except for the bugs
18:39 daniels: well, there’s buffer damage (for the shadow GL copies we keep of SHM buffers), which propagates into surface damage, which propagates into plane damage
18:39 daniels: they’re all damage, just you have to remember which kind of damage you’re dealing with, and (cough) not screw it up
18:40 ManMower: *^_^*
20:28 Company: YaLTeR[m]: the shell screenshot code does bad things to me - it seems it runs entirely different codepaths when screenshotting a window vs screenshotting a selected region?
20:28 Company: because it seems my selected region is 2x scaled up even though I'm screenshotting on my 1x monitor
20:29 Company: window gives me https://i.imgur.com/Efsv5eq.png - selecting gives me https://i.imgur.com/4TLbMga.png
20:29 Company: or do I need to ask swick[m] about that?
22:18 swick[m]: it does indeed run two different code paths because selecting a window is supposed to create a screenshot of the window without any other windows or shell elements influencing it
22:19 swick[m]: report an issue
23:14 Company: swick[m]: is that a mutter or shell issue?