ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
yrlf has quit [Quit: Ping timeout (120 seconds)]
<danieldg>
yes, although it could end up with the client refreshing its windows unconditionally
<danieldg>
not a big issue, just don't do it every second
yrlf has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
makes sense
<orowith2os[m]>
I'd only do it on any SDL display events
<orowith2os[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...
<orowith2os[m]>
geh
<orowith2os[m]>
doesn't help that I'm doing some, uh, weird C++ stuff
<danieldg>
the fact it tangles with xdg-output is a bit annoying too
<orowith2os[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.
<danieldg>
imo it's better to handle those two together, as two views to one object
<orowith2os[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.
<orowith2os[m]>
yeah, I guess so.
<danieldg>
the rust smithay code might be of interest to you
<danieldg>
it's an alternate impl, supports no-libwayland
<orowith2os[m]>
mmmmmmaybe?
<danieldg>
I'm not sure what you're doing
<orowith2os[m]>
best way to explain it is a reverse-xwayland, on top of SDL3
<orowith2os[m]>
I'm trying to get output enumeration working first
<danieldg>
so basically be more transparent than running the application in cage on X?
<orowith2os[m]>
yeah
<orowith2os[m]>
sdl_surface maps to an xdg-surface, sdl_texture to wl-surface, etc etc
<orowith2os[m]>
each SDL_DisplayID to a wl_output object
<danieldg>
do you want to provide real outputs to the wayland clients?
<orowith2os[m]>
-ish. I can get most of the way there, just some small hiccups here n there
<danieldg>
you could just provide one "X" output and it'd be simpler
<orowith2os[m]>
I just ignore it and continue as normal
<orowith2os[m]>
only the wl_output absolute coordinates don't work, xdg-output would be fine
<danieldg>
note the output coordinates in wl_output are deprecated anyway
<orowith2os[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)?
<danieldg>
yes, just return 0
<orowith2os[m]>
oh, I'm returning the logical coordinates.
<orowith2os[m]>
logging an error every time I do
<orowith2os[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).
<orowith2os[m]>
nevermind. that might not work how I want it to.
brotofthemandel has quit [Remote host closed the connection]
<orowith2os[m]>
I'm not sure which I dislike more, electrical issues on my bike, or this...
d42 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
Company has joined #wayland
___nick___ has joined #wayland
Tom^ has quit [Remote host closed the connection]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
<orowith2os[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
rabbitcarleone has joined #wayland
yrlf has quit [Read error: Connection reset by peer]
yrlf has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
rabbitcarleone has quit [Remote host closed the connection]
<orowith2os[m]>
alright, I think I got somewhere decent. it's working now, I think
<orowith2os[m]>
I just need a client to test with
<orowith2os[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
<orowith2os[m]>
(right now I'm running wayland-info over and over again, but I need to test my event sending)
<orowith2os[m]>
it might actually be. Would be nice to have it in wayland-utils.
<orowith2os[m]>
it would need to ignore a lack of a wl_compositor though
<danieldg>
hmm, no compositor means you basically can't do anything
<orowith2os[m]>
that's the idea
<orowith2os[m]>
I can't do anything, yet
<kennylevinsen>
then the client also can't do anything - no events to monitor
<orowith2os[m]>
it can monitor wl_output events
<danieldg>
wl_output is the least important thing to get working :)
<kennylevinsen>
that's not a generic tool then, but a client that specifically binds wl_output to see it's events
<danieldg>
I think you could get useful clients without any outputs at all
<kennylevinsen>
a client that tries to bind all globals but do nothing with them is probably not a useful tool tbh
<danieldg>
especially with more recent compositor versions that tell you preferred scale, most clients don't have any need for outputs
<orowith2os[m]>
that's just wayland-info though. And this discussion was held in the past; it's useful as an intermediate for scripting
<orowith2os[m]>
I'm using it as a step-by-step to figure out for myself how I should implement things
<orowith2os[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
<orowith2os[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
Flat has quit [Quit: Rip internet]
Flat has joined #wayland
<kennylevinsen>
I think what you need is just a custom client for a custom test that doesn't make sense as a generic tool
<kennylevinsen>
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
<orowith2os[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.
<kennylevinsen>
to test something you need to make requests and do things
<kennylevinsen>
Danilen52: thats still a hyprland issue when using hyprland, kde issue when using kde. if Hyprland was a web browser, Wayland would be HTTP.
<kennylevinsen>
For hyprland, see xdg-desktop-portal-hyprland assuming you're using a portal based screen recorder
<Danilen52>
screen sharing is not working, got nothing to do with hyprland, there must be something else causing it
<orowith2os[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.
<kennylevinsen>
Danilen52: it's either hyrpland or the client you're recording with. if using portals, xdg-desktop-portal-hyprland is also involved
<kennylevinsen>
the issue under kwin would be separate
<Danilen52>
i am using open-rc could that be the problem? it was working before
<orowith2os[m]>
it could be your services not working properly, yes. But nothing will make it a generic Wayland issue.
<orowith2os[m]>
you can spawn xdg-desktop-portal-* yourself and see if that helps.
<Danilen52>
i did, i don`t get any error message, its like its workingperfectly well, but screen sharing doesn`t work
<kennylevinsen>
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
<kennylevinsen>
Wayland is a specification, and you're having an issue with an implementation like the one written by the hyprland team
<kennylevinsen>
or with the client, in case it's the recorder itself that is problematic