10:15 narodnik: in this example: https://emersion.fr/blog/2020/wayland-clipboard-drag-and-drop/
10:15 narodnik: data_source_handle_cancelled(data, source) calls wl_data_source_destroy(source)
10:15 narodnik: but i'm getting a segfault there. is this code correct?
10:28 narodnik: my version looks more like: https://agorism.dev/uploads/handle_cancel.rs.txt since i'm working with raw C ffi in rust
10:28 narodnik: it crashes on this line: let version = (display.client.wl_proxy_get_version)(proxy);
12:27 wlb: weston Issue #979 closed \o/ (Weston 14 will affect the performance of glmark https://gitlab.freedesktop.org/wayland/weston/-/issues/979)
12:49 throwthecheese: Anyone have any knowledge on wlroots? I'm trying to compile laikawm and the process would always get stuck with an error about the enum zwlr_layer_surface_v1_keyboard_interactivity not being declared although said enum is provided by the wlroots headers
12:53 throwthecheese: I would like to know if the usage of zwlr_layer_surface_v1_keyboard interactivity has changed as to require redefinition in recent versions
13:33 Consolatis: throwthecheese: suggest to ask in #wlroots at libera IRC
13:37 Consolatis: narodnik: the protocol states: > The client should clean up and destroy this data source.
13:38 Consolatis: so calling wl_data_source_destroy(source) in the handler sounds like the correct thing to do
13:55 narodnik: thanks, idk why it segfaults for me...
13:59 kennylevinsen: throwthecheese: laikawm's last commit was 5 years ago, so it probably assumes wlroots 0.8 or something. There will be a *lot* of breaking changes between that and the current 0.18.2, and it probably assumes other old dependencies as well (despite not being explicit about them). You'll either need to use old deps or port it to newer deps.
15:12 narodnik: for some reason when I free wl_data_source inside data_source_handle_cancelled() I'm getting a segfault
15:13 narodnik: wl_proxy_marshal_flags(source, WL_DATA_SOURCE_DESTROY, NULL 3, WL_MARSHAL_FLAG_DESTROY);
15:13 narodnik: i'm freeing it like this, which matches what wl_data_source_destroy(source) does
15:15 narodnik: and if i try to do: wl_proxy_get_version(source) then i also get a segfault. so it seems the source was already freed somewhere else?
15:16 narodnik: am i missing anything?
15:22 davidre: try run with something sanitiizer or valgrind?
18:10 any1: emersion: I have a display that gives me an EDID with 3 preferred resolutions. Is that normal?
18:38 emersion: hm, that doesn't seem normal
18:39 emersion: would need to check the specs again
18:46 zamundaaa[m]: FWIW with my display, the kernel tells me it has two preferred modes as well
18:47 zamundaaa[m]: One it infers from the normal EDID stuff, the other from a DisplayID extension block
18:48 any1: My EDID has 3 blocks and the third one has two modes, both marked as "preferred". One is at 60Hz and the other at 30Hz, same resolution. :p
18:50 any1: Skimming the spec, it looks to me like it's just not specified
18:53 any1: Anyway, thanks for you input!
21:13 outfoxxed[m]: I'm trying to create a wl_buffer using zwp_linux_dmabuf, however I'm kind of lost. I've got my tranches from get_default_feedback but I don't know how to actually create the dmabuf to use in zwp_linux_buffer_params. I've looked at a couple clients using xf86drm.h and gbm.h, but haven't found any documentation for the process, which I'd like to read instead of blindly copying. Anyone have information on it?
21:19 soreau: there's https://wayland.app/protocols/linux-dmabuf-v1 and https://docs.kernel.org/driver-api/dma-buf.html but they don't seem to reveal where the dmabuf fd and other parameters come from
21:19 soreau: in wlroots, there are four allocators, gbm, shm, dumb and udmabuf
21:20 soreau: you can find these here https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/render/allocator
21:30 outfoxxed[m]: The kernel page seems to link to a different API than the one that seems to be commonly used by applications and wlr. Wlr itself seems to have code that does it, along with xdpw which can be copied, but I was hoping for some explanation of what it actually does, or docs for libdrm / libgbm that I haven't been able to find
23:22 RAOF: @irc_oftc_outfoxxed : In order to allocate a dma-buf you need a graphics buffer allocator. GBM is typically the buffer allocator you'd use.
23:24 RAOF: The docs for _that_ are not the best, but I don't think they're terrible? You need to allocate a buffer (with "gbm_bo_create_with_modifiers2") and then you can pull out the dma-buf fd(s) with "gbm_bo_get_fd_for_plane".
23:38 rpigott: Why does xdg-toplevel fullscreen have a mandate against transparent surfaces? Seems unnecessary. Why not just have the geometry requirements, and leave the compositor to handle opacity as usual?
23:40 danieldg: rpigott: I expect the goal of fullscreen is to allow the buffer to be directly presented as output, when possible. Transparency would prevent that, as the compositor would need to render the scene behind it and compose
23:41 rpigott: So? Surely the compositor can just make this optimization whenver possible as usual. I don't see why opacity needs to be required by the proto
23:41 rpigott: It seems like a relic from lock screens implemented before ext-session-lock
23:42 danieldg: yeah, not sure why some things are in the protocol
23:42 danieldg: lock screens generally used layer-shell then anyway
23:42 rpigott: its not like an opaque surface guarantees optimal presentation is possible anyway
23:42 rpigott: really seems like this wording could just be dropped from xdg-shell
23:44 danieldg: you'd have to replace it with 'compositor not required to draw behind fullscreen' or change compositors that do that today
23:45 danieldg: actually it seems there's no mandate?
23:46 danieldg: "If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface."
23:46 danieldg: are you referring to different text?
23:47 rpigott: no, that's what I'm talking about. It precludes showing anything beneath a fullscreened surface, like a background or bar.
23:47 soreau: I agree with rpigott
23:48 soreau: this is an overstep of the protocol documentation
23:48 danieldg: I wouldn't consider this to apply to things other than windows
23:48 danieldg: but yeah, that needs to be reflected in the text
23:48 soreau: wayfire ignores this and happily does (semi)transparent fullscreen surfaces
23:50 emersion: rpigott: changing this is a breaking change
23:50 rpigott: Why?
23:51 emersion: because some apps might rely on the currently spec'ed and widely implemented behavior
23:51 soreau: like which ones?
23:51 danieldg: this seems like something I would want to configure in the compositor (if I had infinite knobs in a compositor)
23:52 danieldg: I believe sway does as specified, except for the overlay layer shell which is above fullscreen
23:52 soreau: do you really hold back changing for the better because it might break some unknown apps?
23:52 emersion: also one of the reasons is that transparent fullscreen raises security concerns
23:52 danieldg: so technically violating it
23:52 emersion: nothing in the spec says that the fullscreen surface is presented without an overlay
23:53 emersion: so sway behaves like the spec says
23:53 soreau: the way it should be is that if the app wants to be opaque, it can render as such
23:53 soreau: it shouldn't rely on the compositor to do a certain thing
23:53 emersion: too late for that
23:53 soreau: well it's not because compositors can just ignore this
23:53 emersion: anyways, this has been discussed multiple times already
23:53 rpigott: The text was added after xdg-shell was added to stable though? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/f68bafc9c3fdd20512e5f6e2469b66a3c684f045
23:53 soreau: and we haven't had any related bug reports for wayfire at least
23:53 danieldg: if you're talking about security concerns the compositor needs to be part of that discussion anyway
23:54 emersion: i'd suggest looking at the issues etc
23:54 soreau:didn't mention security
23:54 danieldg: so you evaluate the pair (compositor, security kiosk app)
23:54 emersion: it's not about kiosk apps
23:55 danieldg: I'm unsure how else security can be relevant for fullscreening?
23:55 soreau: if the app doesn't want anything to be seen behind it, it should just render alpha = 1.0 instead of being transparent in the first place
23:55 soreau: then you're not relying on compositor behavior
23:56 emersion: it's not compositor behavior it's the spec
23:56 outfoxxed[m]: isn't there also opaque region and surfaces without alpha for this?
23:56 soreau: but it shouldn't be
23:56 emersion: danieldg: transparent fullscreen makes it easier to fake privileged UIs such as system keyring password prompts
23:59 outfoxxed[m]: With the same argument you could redraw the wallpaper and then system ui on top of it?
23:59 outfoxxed[m]: * and then (fake) system ui
23:59 rpigott: well compositors can restrict that behavior by restricting access to screen capture if they want.