ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
crazybyte has quit [Quit: Bye]
columbarius has joined #wayland
crazybyte has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
zvarde198830320677919168 has quit [Read error: No route to host]
<Dehkur>
https://gist.github.com/d3x0r/5f5487f9bd1eb0bd3bfc66c610628f2c I made this gist to demonstrate a problem with WSLg (wayland on windows); it was a sample program that drew a checkerboard, I made it draw green on keyboard.enter and red on keyboard.leave; I certain I didn't do it the right way. The next steps of the sample were to go to EGL..
Company has quit [Quit: Leaving]
newbthenewbd has joined #wayland
rv1sr has joined #wayland
Dehkur has quit [Read error: Connection reset by peer]
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
<kennylevinsen>
Dehkur: you ack the xdg_surface configure which it is bundled with
<kennylevinsen>
As xdg_toplevel.configure says, look at xdg_surface.configure and xdg_surface.ack_configure for more details.
crombie_ has joined #wayland
<kennylevinsen>
As for your code, pelase don't share as a gist - it is difficult to navigate.
<kennylevinsen>
but print something from your enter/leave handler ot make sure it is hit. You ahve code that differs between first and second execution n draw_frame, so it could just be that subsequent draws fail
<kennylevinsen>
you also damage the surface wrong - damage should be set after attach, as it applies to the pending before that attach sets
crombie__ has quit [Ping timeout: 480 seconds]
crombie has joined #wayland
<kennylevinsen>
Dehkur: you also blindly reuse your buffer - you must not write anything to a buffer you have attached until you receive buffer_release
<kennylevinsen>
so either wait until buffer release or allocate an extra buffer
<Dehkur>
but what's damaged is what was already attached - the next attach is before the next damage
<Dehkur>
the buffer never releases
kts has joined #wayland
<Dehkur>
okay so I get to double buffer myself
<Dehkur>
and I'm not sure about the enter/leave comment - WSLg doesnt' generate a keyboard leave if you set the cursor in mouse_enter. And mouseenter/leave only happen if you cross nito another wslg surface (that's the wayland system for Windows WSL) but that's entirely beside the point.
<kennylevinsen>
when you say it does not generate keyboard leave, do you mean that you validated with WAYLAND_DEBUG=1 or with debug prints, or just that you checked that your drawRed is never called?
<kennylevinsen>
The buffer does not have to release until you submit another one that replaces it on screen. *Some* compositors will release wl_shm buffers early, allowing you to use a single buffer, but this is an optional optimization.
crombie_ has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
<kennylevinsen>
Dehkur: in drawGreen, you draw, then damage, attach, commit. That is always wrong. You must draw to an unused buffer, attach, damage, commit.
<vyivel>
attach/damage order doesn't matter though as long as it's within one commit sequence, no? or am i misunderstanding this convo
<Dehkur>
okay - what actually causes configure to fire? because the draw is done in configure always
<kennylevinsen>
vyivel: technically it does - attach creates a pending buffer, damage applies to the pending buffer. If you damage before attach, there is no target for your damage. Most compositors are relaxed though.
<Dehkur>
so it gets a buffer that it draws to unattached, and then attaches it and commits it.
<kennylevinsen>
but should still be fixed
<kennylevinsen>
Dehkur: it fires when you set up the surface initially, then whenever the compositor suggests or commands a new state
<Dehkur>
that sequence of commands does trigger a new sate - I used to also get the buffer, and draw to it unattached... then attach and damage
<vyivel>
kennylevinsen: that's a pointless restriction and i don't think any compositor enforces it
<Dehkur>
but when I did that - I ended up getting a configure anyway....
<kennylevinsen>
vyivel: we were elaborating on the definition some time back, because the specification strictly states that the pending buffer is cleared after commit
<Dehkur>
which double drew - mostly because of how the original code was structured
<Dehkur>
I don't think that part of your draw loop should be in the configure? (like maybe trigger a draw, but not have your primary draw be done in a configure)
<kennylevinsen>
I wouldn't call it pointless, especially if you consider what happens if you swap the buffer afterwards before commit
<kennylevinsen>
Dehkur: you will not get a regular stream of configure events, no. It happens on setup, and if the user resizes or fullscreens the window. Those kinds of things.
<kennylevinsen>
You draw when you need to draw. If you want to draw continously, use a frame callback to drive your render loop.
<kennylevinsen>
the frame callback asks the compositor to tell you when it would be a good idea to start drawing the next frame - meant for driving simple application rendering
<Dehkur>
okay - why wouldn't you damage the attached buffer? Why does it make sense to damage against no buffer ?
<Dehkur>
as in damage, attach, commit rather than attach, damage, commit
<Dehkur>
since it's that attached buffer that has the damaged areas
<kennylevinsen>
Dehkur: It does not make sense to damage against no buffer. However, compositors currently allow it by just looking at the sum of commands during commit.
<kennylevinsen>
but the only correct sequence is attach, damage (possibly multiple times), commit.
<kennylevinsen>
and once you commit the buffer, you must not touch it before you receive the release signal
<vyivel>
and if you do attach→damage→attach→commit, damage is ignored?
<kennylevinsen>
vyivel: yeah, damage spec says it described the difference from the first attach to the current buffer
<kennylevinsen>
so attach-damage-attach-damage might mean we should only use the second damage content
<kennylevinsen>
specs ar efun aren't they
<vyivel>
i have a feeling nobody does it this way
<vyivel>
gonna test this
<kennylevinsen>
same, it only came up recently
<vyivel>
i'd rather fix the spec
<vyivel>
it's really weird for a piece of pending state to depend on another piece of pending state
<kennylevinsen>
well not sure "allowing what we do now" is a good fix
<kennylevinsen>
"attach-damage-attach-damage is a good care where just taking all the damage and the last attach makes no sense
<kennylevinsen>
the client came up with new content, damage is not necessarily just an accumulation
<kennylevinsen>
granted, probably a minor issue as the buffer must be valid, but definitely not a meaningful interpretation
<vyivel>
if a client makes two attach requests within a single commit i'm gonna assume it knows what it's doing
<kennylevinsen>
hah I'd assume the polar opposite :P
<vyivel>
ahah
<Dehkur>
ok I see - I did make changes later and the current order is reversed... because that's how I normally do it anyway because multiple damages, and it's good to already know what to draw on, but ok yes.
<Dehkur>
but still - since configure is always done, when a new or old buffer is attached, the draw seems to always be done if it's done before the ack and returning from configure; would one maybe structure a draw loop around that?
<Dehkur>
but I dunno I say seems because maybe I'm entirely wrong - I don't know that I have the sample code to back up any of that
<kennylevinsen>
configure is *not* done when a buffer is attached
<kennylevinsen>
it is done once at the beginning, then only when certain state changes
<kennylevinsen>
assuming the size stays the same, the application might never see an additional configure in its life
<vyivel>
kennylevinsen: tested weston, mutter, kwin, smithay, and wlroots; in every case, attach doesn't reset damage and the order doesn't matter
<kennylevinsen>
so you should only draw in response to configure in the same way you would raw in response to keyboard input: it might start a render because content changes, but it does not drive a loop.
<kennylevinsen>
vyivel: mutter logs a warning ot the journal
<Dehkur>
https://pastebin.com/7MapUYtR Allocates multiople buffers so it doesn't cheat and reuse the same buffer; this is on weston, just using ctrl-tab to switch windows. It does a wl_commit() in drawRed and drawGreen and successfully updates by getting a configure event and doing the draw.
<kennylevinsen>
Dehkur: I wonder if the ctrl-tab is what is causing your configures
<vyivel>
xdg_toplevel.set_activated probably
<kennylevinsen>
doesn't show - it's just plain configure's with nothing :/
<kennylevinsen>
Dehkur: for reference, weston-simple-egl's render loop debug: https://termbin.com/b409
<kennylevinsen>
note how there are no configures in response to draw. You can run weston-simple-egl yourself to see.
<Dehkur>
I can click on it - but the pointer event spam is gross
<Dehkur>
I don't get frames all that often either
<kennylevinsen>
click on what?
<Dehkur>
the window and another window - so the keyboard enter/leave happens rater than ctrl-tab
<Dehkur>
I'm just sayin it's maybe not because of the ctrl-tab happening
<kennylevinsen>
"I don't get frames all that often" well as mentioned, that is expected if you draw on configure.
<kennylevinsen>
Test with weston-simple-egl
<kennylevinsen>
it shoudl render smoothly at your display refresh rate, and should not have any configures as part of regular render - only some at the beginning, maybe when you ctrl-tab or whatever
<Dehkur>
I see - I lost the re-schedule a frame callback part. and only had a frame callback scheduled on creating the first buffer (which should trigger a redraw)
<Dehkur>
which then in drawRed and drawGreen should just be a make a frame callback
<kennylevinsen>
Dehkur: you are only meant to ask for frame callbacks as long as you still have new content to draw
<kennylevinsen>
you stop once there is nothing new, and let whatever changes to content restart it
<Dehkur>
right I realized that too - which I have to confirm I'm handling that status right. In the keyboard demo thing - it's just in the draws, not in the frame callback in that case
<Dehkur>
okay I think there's just one more thing. when I run weston I get "Unknown parameter: ?2004" very often- I recently leard that's coming from bash when it issue a prompt and has to do with setting the paste mode in xterm...
<Dehkur>
but- maybe what should the TERM be for weston-terminal?
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
tzimmermann has quit [Quit: Leaving]
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
DrNick has quit []
heapify has joined #wayland
nerdopolis has joined #wayland
<zubzub>
why is the padding border in simple-shm white and not another (random?) color? Going through the code I can't seem to find where the padding pixels are painted? Conxt: I'm porting simple-shm and my border is black instead of white.
tristianc has joined #wayland
<zubzub>
nvrmnd found it
heapify is now known as heapheap
godvino has quit [Quit: WeeChat 3.6]
nerdopolis has quit [Remote host closed the connection]
eroc1990 has quit [Remote host closed the connection]
Cyrinux9474 has joined #wayland
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
nerdopolis has joined #wayland
Moprius has joined #wayland
rv1sr has quit []
clovin has quit [Remote host closed the connection]
clovin has joined #wayland
rv1sr has joined #wayland
rasterman has quit [Remote host closed the connection]
godvino has quit [Quit: WeeChat 3.6]
Moprius has quit [Quit: bye]
Company has joined #wayland
crombie has quit [Ping timeout: 480 seconds]
The_Company has joined #wayland
Company has quit [Ping timeout: 480 seconds]
The_Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
leon-anavi has quit [Quit: Leaving]
<wlb>
weston Issue #789 opened by Derek Foreman (derekf) Moving views to inactive layers currently leads to confusing internal state https://gitlab.freedesktop.org/wayland/weston/-/issues/789 [Core compositor], [Desktop shell], [kiosk-shell]
cmichael has quit [Quit: Leaving]
bodiccea has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
lyudess has quit []
Lyude has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
rasterman has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
kasper93 has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
<mort_>
so eh, https://p.mort.coffee/FjT why is xdg-desktop-portal doing anything with org.freedesktop.impl.portal.desktop.gnome when XDG_SESSION_DESKTOP is sway
<psykose>
lemme guess, you got hit with it hanging into a timeout
<psykose>
i think there's some mr somewhere to fix it for xdp-gnome
<mort_>
I don't care though, I'm not launching gnome
<mort_>
it should just ... not do anything with xdg-desktop-portal-gnome
<psykose>
i think by default it just loads all the backends for some reason (because it's not as simple as being based on 'current session') but i forget the specifics so someone else will probably tell you
<mort_>
it just ignores the UseIn field in the .portal file?