ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
removeert has joined #wayland
matja has quit [Ping timeout: 480 seconds]
removeert has quit []
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #wayland
abeltramo589 has quit [Quit: The Lounge - https://thelounge.chat]
abeltramo589 has joined #wayland
kasper93 has joined #wayland
kasper93_ has quit [Ping timeout: 480 seconds]
kasper93_ has joined #wayland
kasper93 has quit [Ping timeout: 480 seconds]
kasper93 has joined #wayland
kasper93 has quit [Remote host closed the connection]
V_ is now known as V
kasper93_ has quit [Ping timeout: 480 seconds]
abeltramo589 has quit [Read error: Connection reset by peer]
abeltramo589 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
crazybyte has quit [Quit: Ping timeout (120 seconds)]
crazybyte has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
Company has quit [Quit: Leaving]
<orowith2os> I'd like some input regarding https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
<orowith2os> Is it valid for a client to force CSDs, even when the compositor says it wants SSDs and enforces that?
<orowith2os> The xdg-decoration protocol seems to be a bit lacking on this
<vyivel> orowith2os: "A configure event can be sent at any time. The specified mode must be obeyed by the client."
<vyivel> i suppose not
<vyivel> although, it's not a compositor can check if csd is present
<vyivel> it's not like *
<psykose> double sd's gang
<orowith2os> vyivel alright, thanks
perk11 has joined #wayland
jlco has quit [Quit: No Ping reply in 180 seconds.]
jlco has joined #wayland
<perk11> Hi. Sorry if this is offtopic, let me know. I am new to targeting Wayland and trying to add Wayland support to https://github.com/perk11/runwhenidle. It seems like ext-idle-notify is a perfect match for what I need, but I want to have a binary that is universal for X11 and Wayland, and since not everything supports ext-idle-notify, I'd like to try to fallback to other methods if it's not available on the system.
<perk11> I managed to get the .h file that works on my system using wayland-scanner. A couple things I am confused about are 1. How do I check that ext-idle-notify is available during runtime? I am struggling to find documentation on this topic. 2. Do I need to worry about wayland protocol for ext-idle-notify changing? Or if I target the current version it should be future-proof? If someone could point me in the right direction, I'd really appreciate t
<vyivel> perk11: 1) during the initial global objects burst, check for ext_idle_notifier_v1; if it's present, the compositor supports this procotol extension
<vyivel> 2) targeting the current version (by specifying it in wl_registry_bind()) is future-proof, yes
<perk11> vyivel: Thank you so much, this already helps me a lot. Could you please clarify what's "initial global object burst"? I can probably figure this out, but if you could link appropriate documentation, that will save me some time.
<perk11> I saw swayidle, it's a bit different from what I'm doing and it's been a great code example
<vyivel> when you get the registry (wl_display.get_registry), the compositor sends you a list of globals it has (and wants to expose)
<perk11> Got it now, thank you!
<vyivel> np
Cyrinux9 has quit []
Cyrinux9 has joined #wayland
m5zs7k has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
<emersion> orowith2os: if you cannot obey the compositor mode, don't use xdg-decoration
<orowith2os> emersion it's not a problem of not being able to, but *choosing* not to. I'm not sure which path the GTK devs will take here, but I hope they follow it.
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
carbonfiber has joined #wayland
rv1sr has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
<wlb> wayland-protocols Issue #150 opened by Matthias Schiffer (NeoRaider) xdg-activation: guidance needed on intended usage https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/150
CME_ has quit [Read error: Connection reset by peer]
CME has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
CME_ has joined #wayland
CME has quit [Ping timeout: 480 seconds]
CME has joined #wayland
CME_ has quit [Ping timeout: 480 seconds]
CME_ has joined #wayland
CME has quit []
CME_ has quit [Ping timeout: 480 seconds]
CME has joined #wayland
bodiccea has quit [Remote host closed the connection]
CME has quit [Ping timeout: 480 seconds]
CME has joined #wayland
bodiccea has joined #wayland
junaid has joined #wayland
junaid_ has joined #wayland
CME has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
junaid_ has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
CME has joined #wayland
gallo has joined #wayland
tawonga has quit [Quit: WeeChat 4.0.0]
fmuellner has joined #wayland
junaid has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
<wlb> wayland-protocols Merge request !217 opened by Simon Ser (emersion) xdg-decoration: fix configure event summary https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/217
<emersion> jadahl: i'm sorry but i'm having a lot of trouble interacting with mclasen here…
<emersion> please tell me if i should just drop it :S
<psykose> someone woke up on the 5th side of the bed eh
<emersion> it's been like this every single time i've interacted with them :(
<JEEB> ah, this SSD/CSD stuff
junaid has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
<emersion> i'm particularily offended by "wayland-protocols is not a standards body"
<wlb> wayland-protocols Merge request !218 opened by Mikhail Gusarov (dottedmag) unstable/xdg-decoration: Fix misleading description of configure https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/218
<dottedmag> emersion: ^ this should take off one issue. What would be a good place to explain the situation of unstable protocols?
junaid has joined #wayland
<dottedmag> I have learned over time that the only way to work with these people is to go and fix whatever loopholes they find. He emits sounds about "unstable"? Make it clear that "unstable" does not have a semantic meaning.
<wlb> wayland-protocols Merge request !219 opened by Mikhail Gusarov (dottedmag) README.md: Explain that "unstable" label is not semantical https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/219
<dottedmag> emersion: ^ maybe this should be enough
<emersion> "unstable" just means "version n+1 may come sometime", nothing more
<emersion> and also, many many unstable protocols are in a situation where version n+1 is very unlikely to ever come
<dottedmag> right. If you find a legist, the only way to beat them is by making everything crystal clear in the docs.
<wlb> wayland-protocols Merge request !220 opened by Simon Ser (emersion) readme: make it clear that we are a standards body https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/220
<dottedmag> emersion: Maybe it's time to also redo the "this protocol is experimental" blurb in protocol description? I'll try to come up with some wording that reflects what you said about unstable, but I'm not involved in standardization work, so I'd be grateful if you could have a look and say if it means what it should mean.
<wlb> wayland-protocols Merge request !218 closed (unstable/xdg-decoration: Fix misleading description of configure)
<wlb> wayland-protocols Merge request !221 opened by Mikhail Gusarov (dottedmag) unstable: Clarify protocols' status and update rules https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/221
junaid has quit [Quit: leaving]
junaid has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
floof58 has joined #wayland
kts_ has joined #wayland
kts_ has quit []
<MrCooper> orowith2os: a client can "force" CSD by ignoring the xdg-decoration protocol
kts has quit [Ping timeout: 480 seconds]
<emersion> as in, not use it
<emersion> (not to be confused with ignoring its events)
junaid has quit [Ping timeout: 480 seconds]
floof58 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
floof58 has joined #wayland
IndiumInLCD has joined #wayland
rederick29 has joined #wayland
junaid has joined #wayland
caveman has joined #wayland
<kchibisov> It's a bit weird to do runtime switches though, when user of some library will ask to not decorate the window at all. Since you need to unmap/destroy/map again, but I guess it fine.
cvmn has quit [Remote host closed the connection]
<kchibisov> Since not decorating at all (like even ignoring server side) is usually done by drawing neither csd nor ssd.
caveman has quit [Remote host closed the connection]
<kchibisov> Though, I've only heard such a desire to disable all sorts of decorations in client side only decorations environments, since with SSDs you can likely have settings in your compositor for that.
caveman has joined #wayland
perk11 has quit [Quit: perk11]
rasterman has quit [Remote host closed the connection]
rasterman has joined #wayland
Company has joined #wayland
Moprius has quit [Quit: bye]
IndiumInLCD_ has joined #wayland
IndiumInLCD has quit []
IndiumInLCD_ has quit [Remote host closed the connection]
IndiumInLCD has joined #wayland
IndiumInLCD has quit []
fmuellner has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
Leopold_ has joined #wayland
fmuellner has joined #wayland
rasterman has quit [Remote host closed the connection]
rasterman has joined #wayland
<jadahl> emersion: been afk today and will be most of tomorrow too, but will chime in when I get the chance
<jadahl> spent half day debugging ancient electrical wiring for a toilet waste pump and concluded the pump itself is toast *sigh*
rasterman has quit [Quit: Gettin' stinky!]
gspbirel56873408 has quit []
gspbirel56873408 has joined #wayland
sima has joined #wayland
<kennylevinsen> jadahl: sounds like a... shit task
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
xhivo97 has joined #wayland
<xhivo97> How should I draw the decorations? I am doing everything with software rendering no GPU. Do I need to use subsurface somehow to do this?
<kchibisov> xhivo97: that's entirely up to you, you could use subsurfaces.
<kchibisov> One way could be to create 4 subsurfaces around the window.
<kchibisov> Or you could use one surface and logically decide what is decorations and what not.
<xhivo97> Is there any benefit over doing it all on the same surface? The part that is confusing to me is how to treat the buffer if I do subsurfaces, is there a way to share the same buffer? (It's still a bit confusing to me how the allocations happen, do I need to allocate the buffer every frame?)
<kchibisov> You don't have to 'allocate' every frame. Unless you attach(NULL) it should work.
<kchibisov> You can attach the same buffer to multiple surfaces, I'd suggest to read wl_surface::attach docs.
<kchibisov> There's also a libdecor for C clients, it could help.
junaid has quit [Remote host closed the connection]
<xhivo97> Thanks! (I kind of wanted to avoid libdecor and do most things from scratch)
<kchibisov> Is there any benefit> only downsides from my experience, since you can't e.g. highlight a button without redrawing everything.
<xhivo97> How many ways are there to get a buffer to draw to? I followed the example in the wayland book, is that the way to go and is it the only way?
<kchibisov> You have either wl_shm or dmabuf.
<kchibisov> For software rendering you're using wl_shm most of the time.
<kchibisov> The key point here is that you need some shared resources, like shared memory with wl_shm, so compositor can read your buffer.
<kchibisov> There're also special protocols like 'single-pixel-buffer' to create buffers, but they are quite niche.
<xhivo97> I've never worked with shared resources before, and naively I guessed that the example in the wayland book is allocating every tie it calls the draw_frame function but sounds like I might be missing something
<xhivo97> (how does IRC work if I refresh page will my chat history be lost?)
<kchibisov> I haven't read the wayland book, but usually how you handle that is that you have shm pool and you ask for buffers from it.
<kchibisov> xhivo97: depends on the client, but likely remove the history. But there're public logs for this room.
sima has quit [Ping timeout: 480 seconds]
<xhivo97> Each time they draw they are creating an shm file calling ftruncate, then mmap then wl_shm_create_pool and finally wl_shm_pool_create_buffer. Should I remove any of these and call them just once?
<xhivo97> Whoever wrote the wayland book, I like their sense of humor though lol
<xhivo97> Really hope they will finish it it was ann enjoyable learning experience
<xhivo97> Also, should I handle "subcanvasing" the buffer or does wayland have a some way to get them with correct stride etc? (currently I just make a pointer pointing to where I want my subcanvas to be and calculate a stride, seems to work)
<kchibisov> I'm not sure I understand what `subcanvasing` means? Are you talking about using some offset into buffer?
<xhivo97> Yeah, a way to treat it as a surface I can draw on it's own with origin 0,0 but in buffer indices terms
<xhivo97> I can do that no problem but was wondering if wayland has an equivalent thing I can do that's built in or something but idk if that makes much sense lol
<kchibisov> you do all the drawing, you could read the core protocol for details (wayland.app).
<xhivo97> Oh wow thanks! I didn't know that site
<kchibisov> it's a community hosted one, but it's very convinient.
<kchibisov> wrt drawing, you don't need to create shm on each drawing invokation, you usually create an abscration over it and just get a buffers from the offset.
<rpigott> I don't think the first example on "wayland-book" really expects to draw more than one frame. It isn't responsive to configures (or close even) and doesn't subscribe to frame events.
<rpigott> that's fine really, its just example code.
<xhivo97> I'll try and refactor to not do that. Also, wayland has a really interesting design is there a name for it? Do you know why it's built like that?
<kchibisov> I'm not sure how to describe it, but basically you allocate e.g. some amount in shm, and then create buffers from it, maintaining some sort of linked list.
<kchibisov> Basically you have your small allocator over shm to avoid reallocations.
<kchibisov> If you can't reallocate you resize the pool.
<kchibisov> err, reallocate → allocate.
<xhivo97> @rpigott Actually I followed it through to the end and it does respond to reconfiguration I can move it and resize and close it. But I might have missed something and that might have been something I left behind from the earlier examples
* kchibisov is doing OpenGL most of the time, so can't really help with shm.
Brainium has joined #wayland
<xhivo97> (im sorry if you saw that I have no idea how to use IRC, wanted to see if you can ping or reply to someone lol)
rederick29 has quit [Remote host closed the connection]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
xhivo97 has quit [Remote host closed the connection]
Moprius has joined #wayland
carbonfiber has quit [Quit: Connection closed for inactivity]
rv1sr has quit []