ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
narodnik2 has joined #wayland
Serus has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
lsd|2 has quit [Ping timeout: 480 seconds]
narodnik2 has quit [Read error: No route to host]
narodnik2 has joined #wayland
Moprius has quit [Remote host closed the connection]
bodiccea has quit [Read error: Connection reset by peer]
bodiccea has joined #wayland
narodnik2 has quit []
narodnik2 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
narodnik2 has quit [Ping timeout: 480 seconds]
user21 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
bjorkintosh has quit [Ping timeout: 480 seconds]
bjorkintosh has joined #wayland
feaneron has quit [Quit: feaneron]
nerdopolis has quit [Ping timeout: 480 seconds]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
yshui has quit [Read error: Connection reset by peer]
yshui has joined #wayland
bim9262 has quit [Quit: ZNC - https://znc.in]
bim9262 has joined #wayland
tzimmermann has joined #wayland
glennk has joined #wayland
rgallaispou has quit [Remote host closed the connection]
rgallaispou has joined #wayland
kts has joined #wayland
sima has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
kode54 has quit [Quit: The Lounge - https://thelounge.chat]
kode54 has joined #wayland
leon-anavi has joined #wayland
garnacho has joined #wayland
rgallaispou has joined #wayland
kts has quit [Ping timeout: 480 seconds]
JakeSays1 has joined #wayland
kts has joined #wayland
rasterman has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
tzafrir has quit [Ping timeout: 480 seconds]
<narodnik> data_source_handle_cancelled(data, source) calls wl_data_source_destroy(source)
<narodnik> but i'm getting a segfault there. is this code correct?
<narodnik> my version looks more like: https://agorism.dev/uploads/handle_cancel.rs.txt since i'm working with raw C ffi in rust
<narodnik> it crashes on this line: let version = (display.client.wl_proxy_get_version)(proxy);
kts has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #wayland
Brainium has joined #wayland
Moprius has quit [Quit: bye]
fmuellner has joined #wayland
<wlb> weston Issue #979 closed \o/ (Weston 14 will affect the performance of glmark https://gitlab.freedesktop.org/wayland/weston/-/issues/979)
feaneron has joined #wayland
throwthecheese has joined #wayland
<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
<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
larunbe has joined #wayland
alarumbe has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
<Consolatis> throwthecheese: suggest to ask in #wlroots at libera IRC
<Consolatis> narodnik: the protocol states: > The client should clean up and destroy this data source.
<Consolatis> so calling wl_data_source_destroy(source) in the handler sounds like the correct thing to do
WhyNotHugo has joined #wayland
<narodnik> thanks, idk why it segfaults for me...
larunbe has quit []
glennk has quit [Quit: Leaving]
alarumbe has joined #wayland
glennk has joined #wayland
<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.
rgallaispou has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
WhyNotHugo has quit [Remote host closed the connection]
WhyNotHugo has joined #wayland
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
nerdopolis has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
MrCooper has joined #wayland
pH5 has quit [Ping timeout: 480 seconds]
shoragan has quit [Ping timeout: 480 seconds]
mtretter has quit [Ping timeout: 480 seconds]
throwthecheese has quit [Remote host closed the connection]
<narodnik> for some reason when I free wl_data_source inside data_source_handle_cancelled() I'm getting a segfault
<narodnik> wl_proxy_marshal_flags(source, WL_DATA_SOURCE_DESTROY, NULL 3, WL_MARSHAL_FLAG_DESTROY);
<narodnik> i'm freeing it like this, which matches what wl_data_source_destroy(source) does
<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?
<narodnik> am i missing anything?
<davidre> try run with something sanitiizer or valgrind?
Moprius has joined #wayland
andyrtr has quit [Quit: ZNC 1.9.1 - https://znc.in]
andyrtr has joined #wayland
mohit815822635306 has quit [Remote host closed the connection]
user21 has quit [Ping timeout: 480 seconds]
mohit815822635306 has joined #wayland
user21 has joined #wayland
mvlad is now known as Guest5427
Guest5427 has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
tzimmermann has quit [Quit: Leaving]
user21 has quit [Remote host closed the connection]
larunbe has joined #wayland
alarumbe has quit [Read error: No route to host]
leon-anavi has quit [Quit: Leaving]
mvlad is now known as Guest5431
Guest5431 has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
<any1> emersion: I have a display that gives me an EDID with 3 preferred resolutions. Is that normal?
<emersion> hm, that doesn't seem normal
<emersion> would need to check the specs again
<zamundaaa[m]> FWIW with my display, the kernel tells me it has two preferred modes as well
<zamundaaa[m]> One it infers from the normal EDID stuff, the other from a DisplayID extension block
<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
mvlad is now known as Guest5435
Guest5435 has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
<any1> Skimming the spec, it looks to me like it's just not specified
mtretter has joined #wayland
<any1> Anyway, thanks for you input!
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
tzafrir has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
sima has quit [Remote host closed the connection]
andyrtr has joined #wayland
alatiera has quit [Read error: No route to host]
alatiera has joined #wayland
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mvlad is now known as Guest5439
mvlad has joined #wayland
Guest5439 has quit [Read error: Connection reset by peer]
mvlad is now known as Guest5441
Guest5441 has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
mvlad has quit [Remote host closed the connection]
mvlad has joined #wayland
vincejv is now known as Guest5444
vincejv has joined #wayland
Guest5444 has quit [Ping timeout: 480 seconds]
<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?
<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
<soreau> in wlroots, there are four allocators, gbm, shm, dumb and udmabuf
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
<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
mvlad has quit [Remote host closed the connection]
lsd|2 has joined #wayland
nerdopolis has joined #wayland
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #wayland
rinwa has joined #wayland
balrog has quit [Quit: Bye]
balrog has joined #wayland
FreeFull has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #wayland
balrog has quit [Quit: Bye]
garnacho has quit [Ping timeout: 480 seconds]
balrog has joined #wayland
<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.
<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".
<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?
<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
<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
<rpigott> It seems like a relic from lock screens implemented before ext-session-lock
<danieldg> yeah, not sure why some things are in the protocol
<danieldg> lock screens generally used layer-shell then anyway
<rpigott> its not like an opaque surface guarantees optimal presentation is possible anyway
<rpigott> really seems like this wording could just be dropped from xdg-shell
<danieldg> you'd have to replace it with 'compositor not required to draw behind fullscreen' or change compositors that do that today
<danieldg> actually it seems there's no mandate?
<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."
<danieldg> are you referring to different text?
<rpigott> no, that's what I'm talking about. It precludes showing anything beneath a fullscreened surface, like a background or bar.
<soreau> I agree with rpigott
<soreau> this is an overstep of the protocol documentation
<danieldg> I wouldn't consider this to apply to things other than windows
<danieldg> but yeah, that needs to be reflected in the text
<soreau> wayfire ignores this and happily does (semi)transparent fullscreen surfaces
<emersion> rpigott: changing this is a breaking change
<rpigott> Why?
<emersion> because some apps might rely on the currently spec'ed and widely implemented behavior
<soreau> like which ones?
<danieldg> this seems like something I would want to configure in the compositor (if I had infinite knobs in a compositor)
<danieldg> I believe sway does as specified, except for the overlay layer shell which is above fullscreen
<soreau> do you really hold back changing for the better because it might break some unknown apps?
<emersion> also one of the reasons is that transparent fullscreen raises security concerns
<danieldg> so technically violating it
<emersion> nothing in the spec says that the fullscreen surface is presented without an overlay
<emersion> so sway behaves like the spec says
<soreau> the way it should be is that if the app wants to be opaque, it can render as such
<soreau> it shouldn't rely on the compositor to do a certain thing
<emersion> too late for that
<soreau> well it's not because compositors can just ignore this
<emersion> anyways, this has been discussed multiple times already
<rpigott> The text was added after xdg-shell was added to stable though? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/f68bafc9c3fdd20512e5f6e2469b66a3c684f045
<soreau> and we haven't had any related bug reports for wayfire at least
<danieldg> if you're talking about security concerns the compositor needs to be part of that discussion anyway
<emersion> i'd suggest looking at the issues etc
* soreau didn't mention security
<danieldg> so you evaluate the pair (compositor, security kiosk app)
<emersion> it's not about kiosk apps
<danieldg> I'm unsure how else security can be relevant for fullscreening?
<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
<soreau> then you're not relying on compositor behavior
<emersion> it's not compositor behavior it's the spec
<outfoxxed[m]> isn't there also opaque region and surfaces without alpha for this?
<soreau> but it shouldn't be
<emersion> danieldg: transparent fullscreen makes it easier to fake privileged UIs such as system keyring password prompts
<outfoxxed[m]> With the same argument you could redraw the wallpaper and then system ui on top of it?
<outfoxxed[m]> * and then (fake) system ui
<rpigott> well compositors can restrict that behavior by restricting access to screen capture if they want.