00:28danieldg: yes, although it could end up with the client refreshing its windows unconditionally
00:28danieldg: not a big issue, just don't do it every second
00:31orowith2os[m]: makes sense
00:32orowith2os[m]: I'd only do it on any SDL display events
00:32orowith2os[m]: I'm trying to figure out how I'm supposed to keep my wl_output stuff confined, while also emitting events on the object...
00:32orowith2os[m]: geh
00:33orowith2os[m]: doesn't help that I'm doing some, uh, weird C++ stuff
00:33danieldg: the fact it tangles with xdg-output is a bit annoying too
00:33orowith2os[m]: I suppose I could send a wl_output done event twice for that. Once for the main wl_output object, once for xdg-output.
00:35danieldg: imo it's better to handle those two together, as two views to one object
00:35orowith2os[m]: I'd really like to hop into a VC with someone a bit more experienced with raw libwayland (no compositor library), but I don't suppose anybody here has the time to hold my hand for this.
00:35orowith2os[m]: yeah, I guess so.
00:35danieldg: the rust smithay code might be of interest to you
00:36danieldg: it's an alternate impl, supports no-libwayland
00:36orowith2os[m]: mmmmmmaybe?
00:37danieldg: I'm not sure what you're doing
00:37orowith2os[m]: best way to explain it is a reverse-xwayland, on top of SDL3
00:38orowith2os[m]: I'm trying to get output enumeration working first
00:38danieldg: so basically be more transparent than running the application in cage on X?
00:38orowith2os[m]: yeah
00:39orowith2os[m]: sdl_surface maps to an xdg-surface, sdl_texture to wl-surface, etc etc
00:39orowith2os[m]: each SDL_DisplayID to a wl_output object
00:39danieldg: do you want to provide real outputs to the wayland clients?
00:40orowith2os[m]: -ish. I can get most of the way there, just some small hiccups here n there
00:40danieldg: you could just provide one "X" output and it'd be simpler
00:40orowith2os[m]: I found one problem with it, which shouldn't be too bad: https://github.com/libsdl-org/SDL/issues/12748
00:40orowith2os[m]: I just ignore it and continue as normal
00:40orowith2os[m]: only the wl_output absolute coordinates don't work, xdg-output would be fine
00:41danieldg: note the output coordinates in wl_output are deprecated anyway
00:41orowith2os[m]: nice, nice. So not a problem either way, just assume clients don't use it, and throw out some garbage values (like I am now)?
00:41danieldg: yes, just return 0
00:42orowith2os[m]: oh, I'm returning the logical coordinates.
00:42orowith2os[m]: logging an error every time I do
00:43orowith2os[m]: ngh...... idea. I could check a wl_client for if it's already bound to a wl_output object. If it is, I can skip sending the done event, until the xdg-output events are done too (if it's also bound to that).
00:45orowith2os[m]: nevermind. that might not work how I want it to.
00:48orowith2os[m]: I'm not sure which I dislike more, electrical issues on my bike, or this...
02:36orowith2os[m]: I think I got it. std::unordered_map of DisplayIDs and my type containing the data, and each output has a list of wl_resources to send wl_output events to
03:59orowith2os[m]: alright, I think I got somewhere decent. it's working now, I think
03:59orowith2os[m]: I just need a client to test with
03:59orowith2os[m]: if someone knows of one that shows me an up to date state of the compositor globals, without needing a whole working session, that would be appreciated
04:00orowith2os[m]: (right now I'm running wayland-info over and over again, but I need to test my event sending)
09:39wlb: wayland-protocols Issue #252 closed \o/ (Clarify how `wp_cursor_shape_device_v1::set_shape` interacts with `wl_pointer::set_cursor` https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/252)
13:52orowith2os[m]: hmmm, are send functions from libwayland/wayland-server safe to call across threads?
13:53orowith2os[m]: like, can I call wl_output_send_*() on a resource from another thread, at the same time as another wl_output_send_*()?
16:51orowith2os[m]: Filed this on wayland-utils, if someone wants to take a look: https://gitlab.freedesktop.org/wayland/wayland-utils/-/issues/13
16:54vyivel: that's just wev (kinda)
16:56orowith2os[m]: it might actually be. Would be nice to have it in wayland-utils.
16:57orowith2os[m]: it would need to ignore a lack of a wl_compositor though
16:58danieldg: hmm, no compositor means you basically can't do anything
17:01orowith2os[m]: that's the idea
17:01orowith2os[m]: I can't do anything, yet
17:01kennylevinsen: then the client also can't do anything - no events to monitor
17:01orowith2os[m]: it can monitor wl_output events
17:02danieldg: wl_output is the least important thing to get working :)
17:02kennylevinsen: that's not a generic tool then, but a client that specifically binds wl_output to see it's events
17:02danieldg: I think you could get useful clients without any outputs at all
17:03kennylevinsen: a client that tries to bind all globals but do nothing with them is probably not a useful tool tbh
17:03danieldg: especially with more recent compositor versions that tell you preferred scale, most clients don't have any need for outputs
17:03orowith2os[m]: that's just wayland-info though. And this discussion was held in the past; it's useful as an intermediate for scripting
17:03orowith2os[m]: I'm using it as a step-by-step to figure out for myself how I should implement things
17:04orowith2os[m]: so far, I've figured out how I should react to, and send, events, binding and destroying a global, and now, I want to figure out how to behave with globals that can be added and removed, and change, a bunch, like wl_outputs
17:05orowith2os[m]: you can discuss how useful wl_output is all you want, but printing out that information is something clients can and will do, especially for things like games
17:06kennylevinsen: I think what you need is just a custom client for a custom test that doesn't make sense as a generic tool
17:08kennylevinsen: there is no such thing as just "listening to events" - you can bund globals, but resulting events are a very small bit of their respective protocols and not particularly interesting
17:08orowith2os[m]: I think the exact opposite, and it isn't out of scope for wayland-utils. If I write a custom client, it'll end up being submitted to wayland-utils anyways.
17:08kennylevinsen: to test something you need to make requests and do things
17:09danieldg: orowith2os[m]: https://github.com/Smithay/client-toolkit/blob/master/examples/list_outputs.rs
17:09danieldg: a client that just lists outputs
17:10orowith2os[m]: yes, I'm also using wayland-info to do that. I need it to stay connected and print changes, hence the filed issue in wayland-utils
17:11danieldg: just write one, I doubt it's usefulto anyone else.
18:24Danilen52: ok i am not being able to share my screen, on both hyprland or KDE, it doesn`t work at all
18:27wlb: wayland-protocols Issue #248 closed \o/ (Request for a Global Shortcut Standard in Wayland to Improve Linux Desktop Consistency https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/248)
18:28kennylevinsen: Danilen52: thats still a hyprland issue when using hyprland, kde issue when using kde. if Hyprland was a web browser, Wayland would be HTTP.
18:29kennylevinsen: For hyprland, see xdg-desktop-portal-hyprland assuming you're using a portal based screen recorder
18:30Danilen52: screen sharing is not working, got nothing to do with hyprland, there must be something else causing it
18:31orowith2os[m]: yeah, wayland itself can't do anything here. Your compositor implements it, and your compositor also deals with the details on screensharing. You need to go to their issue trackers.
18:31wlb: wayland.freedesktop.org Issue #8 opened by yay me (yayme) Dead links https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/8
18:32kennylevinsen: Danilen52: it's either hyrpland or the client you're recording with. if using portals, xdg-desktop-portal-hyprland is also involved
18:33kennylevinsen: the issue under kwin would be separate
18:33Danilen52: i am using open-rc could that be the problem? it was working before
18:33orowith2os[m]: it could be your services not working properly, yes. But nothing will make it a generic Wayland issue.
18:34orowith2os[m]: you can spawn xdg-desktop-portal-* yourself and see if that helps.
18:35Danilen52: i did, i don`t get any error message, its like its workingperfectly well, but screen sharing doesn`t work
18:35kennylevinsen: Danilen52: for all intents and purposes you don't run Wayland, but hyprland or KDE. anything about setting things up and running the desktop environment is 100% a hyprland or KDE question
18:36kennylevinsen: Wayland is a specification, and you're having an issue with an implementation like the one written by the hyprland team
18:37kennylevinsen: or with the client, in case it's the recorder itself that is problematic
18:37Danilen52: it will go insane
18:37Danilen52: ok bye
19:32wlb: wayland Issue #535 closed \o/ (Memory leak from wl_display_read_events when display connection is lost https://gitlab.freedesktop.org/wayland/wayland/-/issues/535)
19:51vyivel: there was at least one tool to run a program with a security context i think, can someone remind me of them?
19:58orowith2os[m]: vyivel: https://git.sr.ht/~whynothugo/way-secure ?
19:59vyivel: i think there was something even simpler to use
20:00danieldg: iirc that's about as simple to use as it gets?
20:00danieldg: flatpak has it built in too
20:00vyivel: i expected like "path/to/program <command…>"
20:00orowith2os[m]: that's basically what way-secure is
20:00vyivel: (i just need to test updated global filtering logic)
20:10emersion: https://git.sr.ht/~emersion/wlsecctx
20:11vyivel: yep, that's what i had in mind, thanks!
20:15emersion: :P