ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
iomari891 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Calandracas_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Calandracas has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
Moprius has quit [Quit: bye]
lsd|2 has joined #wayland
lsd|2 has quit []
Brainium has quit [Quit: Konversation terminated!]
<ellipticsaki>
Hello, wayland newbie here. I am finding a way to pass the pointer event(especially click event) to the beneath of the window. I tried to create region and subtract the entire region, and use set_input_region. But it seems not working. Is this even possible or am I approaching wrong?
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
glennk has joined #wayland
<soreau>
it should work, just make sure the compositor supports it and you're committing after setting the region. you might also have a look at the output with WAYLAND_DEBUG=1 to make sure the region is set to what you expect
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<ellipticsaki>
soreau, thanks for the reply. I've checked the debug output and it is definitely commiting after the region is created. I bet the compositor does not support this kind of feature, and I want to check if really is. Can you give me an advice where can I find the handling logic in compositor?
ellipticsaki has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
elliptic_saki has joined #wayland
kts has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
elliptic_saki has quit [Ping timeout: 480 seconds]
<MrCooper>
colinmarc: I also recommend waiting for the acquire point to signal before using the buffer for anything; if you really want to wait on the GPU though, you first need to wait for a fence to materialize in the acquire point anyway, then it's basically the same as implicit sync
bodiccea has joined #wayland
<colinmarc>
@_oftc_MrCooper:matrix.org I think I must have misunderstood something about that - right now I export the acquire point as a vulkan semaphore and then pass that to submit, and that's fast - all the waiting seems to happen on the GPU
<colinmarc>
I think I don't care about the case where the client is bugged, because my compositor is single-client and if the client dies or does something weird we tear down the compositor anyway
<colinmarc>
and it's all virtual so I do a "page flip" (send the frame to the encoder) whenever the client finishes rendering
<colinmarc>
is there any other reason to do the wait on the CPU?
<colinmarc>
(I based my gpu wait on the vulkan code in wlroots, and it seems to work well)
<colinmarc>
the reason I want to do frame scheduling in the first place is that I obviously limit the encoder to 60fps, so if the client is very fast then there's a bunch of input lag between when I get the buffer and when I encode it
rasterman has joined #wayland
fmuellner has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<latex>
Does the Wayland protocol require compositors to implement compositing? Is there no way to use the traditional stack and repaint technique?
<kchibisov>
latex: what do you mean by _compositing_ here?
<soreau>
you could make a 'compositor' that is just an IRC server :P
<kchibisov>
like how you draw is up to you, but I'm mostly curious what they mean by compositing here, since likely not what it actually means.
<soreau>
I'm curious what's meant by 'stack and repaint' method
<kchibisov>
probably some X11 impl detail.
<kchibisov>
which would be also compositing to some sort.
<kchibisov>
I feel like they mean alpha blending or not, but won't guess further here.
<soreau>
I guess the only thing visual that might not be considered compositing is a single client.. more than one on the output at a time and you're composing a scene
<kchibisov>
if you mean direct scan out path then yes, it's not compositing.
elliptic_saki has joined #wayland
<kchibisov>
but wayland compositor could render like that, as in you have a stack of full screen windows you swap betwee.n
<kchibisov>
and even then, not all clients could be scanned out.
<kchibisov>
Like if they have way too many subsurfaces, etc, etc.
<soreau>
but in wayland, clients have a way to tell the compositor that there are opaque portions where nothing needs to be rendered behind it (because the surface in front has opaque portions where alpha = 1.0), and weston uses this optimization unconditionally IIRC
<kchibisov>
yeah, I'm just saying if you have way too many subsurfaces, you won't be able to scan out.
<kchibisov>
doesn't matter whether they are opaque or not.
<kchibisov>
Like you'd need to blend them somehow regardless.
<kchibisov>
since they are in different buffers, but should be in one, or on planes in a specific order.
<kchibisov>
and you don't have that many overlay planes.
<soreau>
yea, shoulda said s/client/surface/
<soreau>
meaning no subsurfaces
<kchibisov>
like my gpu supports like 4 overlay planes iirc, so I have only like 4 terminals max scanned out at the time.
<soreau>
oh but wait, don't forget the cursor
<soreau>
have to draw that if you have a mouse or something
<kchibisov>
it's blended as well on a different level.
<kchibisov>
unless you have _software cursor_.
<kchibisov>
The thing is that scene is composed in this case as well, just all on a different level.
<kchibisov>
and with direct scan out it's also composed, but further up.
<soreau>
while we're specualting, my guess is that they want the desktop background 'beneath' all transparency and not what is 'actually' behind it
<kchibisov>
wayland doesn't block any of that, but that's speculation as well.
<kchibisov>
if you're talking about fake transparency on X11 that was done by screenshoting and making it benith the window, it's something else though.
<kchibisov>
compositor can do the exact same thing though, if they wanted to.
<soreau>
screenshotting, heh
<soreau>
but wayland xdg protocol says fullscreen surfaces must have black behind them.. seems kinda prudent
<soreau>
so if you call xdg spec 'wayland', then yea, kinda blocks stuff up
<kchibisov>
it doesn't say so though.
<soreau>
it doesn't say what?
<kchibisov>
that it should be black.
<soreau>
it doesn't anymore?
* soreau
looks
<kchibisov>
it never did.
<kchibisov>
it says that other screen content not part of the same surface tree shouldn't be shown.
<soreau>
"The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black)."
<kchibisov>
it's a border when it doesn't fit.
<kchibisov>
like when you have to center the buffer.
<kchibisov>
The last paragraph is what you're looking for.
<soreau>
oh right
<soreau>
so the black is for the non-aspect-ratio matching surfaces
<soreau>
anyway, compositors are free to serve up client buffers how it sees fit - this is an overstep of the protocol IMHO
<soreau>
regarding the last paragraph
<kchibisov>
it's also (e.g. black).
<kchibisov>
not just black.
<kchibisov>
so what you use is up to use.
<soreau>
sure, but the last paragraph is gratuitous
<kchibisov>
you just should not show anything that is below the window, but if you use wallpaper of your compositor, it probably won't violate anything.
<kchibisov>
I mean, any other window that was below.
<soreau>
it violates the spec
<soreau>
which folks can argue they rely on for e.g. security
<kchibisov>
I mean, it's not a wayland client, but default background of compositor.
<kchibisov>
it's just, default background is some png.
<kchibisov>
if compositor must always show black color under the window, it should be stated so.
Moprius has joined #wayland
<soreau>
"...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." seems like this rules out even the simplest background image too
<kchibisov>
Like in my case you won't see anything else, other than a default compositor background fill.
<soreau>
but you're free to write some shader pixels
<soreau>
doesn't really make any sense
<kchibisov>
What I'm just saying is that black is not mandated anywhere.
<soreau>
and what I'm saying is the last paragraph should be omitted entirely
iomari891 has joined #wayland
<kchibisov>
it shouldn't though.
<soreau>
it should :)
<kchibisov>
the point was to make that other wayland clients won't be rendered below the window.
<kchibisov>
if you want such behavior, you want other mode.
<soreau>
yes but that should not be enforced on a compositor
<soreau>
it's compositor policy/design decision, not protocol spec
<kchibisov>
Like there's a simple fullscreen concept usually in compositors, which is simpler.
<kchibisov>
as in you can stack above, etc, etc.
<kchibisov>
and see what is below.
<kchibisov>
it's not maximized, though, the window is fullscreen.
<soreau>
In wayfire, we ignore this altogether. Nothing stops showing what's behind a fullscreen semi-transparent surface. In addition, there's a 'force fullscreen' plugin that allows you to fullscreen windows that don't support resize/fullscreen at all. Regardless how it's fullscreened, it shouldn't matter what's behind it from spec POV
<kchibisov>
it does matter for perf.
<soreau>
but that's not for spec to decide
<soreau>
I should be able to pixman all day long if I want
<soreau>
or make a horribly slow shader
<soreau>
so it might be a good idea or a suggestion, but certainly shouldn't be enforced by some paragraph that's largely a security crutch
<kchibisov>
IIRC it was due to direct scan ou.t
<kchibisov>
But I could be wrong and it was actually a security thing.
<soreau>
yes but then it should be expanded to not enforce but suggest based on reasoning
<soreau>
not just 'hey, dont do this'
<soreau>
then a compositor dev will understand why to do this and not just blindly do it 'because spec said so'
<soreau>
(I would write a patch but I'd rather complain on IRC until someone with marge rights says 'hey, we would entertain a patch that improves the paragraph by changing it to xyz')
<soreau>
because the patch I'd like would be something like -3,+0
alarumbe has joined #wayland
ramblurr_ has joined #wayland
ramblurr has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
ramblurr_ is now known as ramblurr
<davidre>
zamundaaa tried to make a patch
<davidre>
Some people were not happy
<emersion>
this has already been discussed and a different way forward has been suggested
<emersion>
the first comment was already a way forward
<soreau>
Well hopefully it doesn't remain stagnant. It's difficult to tell if the original merge requester is to write this or if it's to be superceded by another MR
feaneron has joined #wayland
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
ramblurr has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
<pq>
kchibisov, soreau, I would assume they referred to the core X11 model: each pixel on screen is owned by some Window at any time, and the server sends expose events to those Windows to tell them to paint themselves into the server's (front) framebuffer, e.g. a when window moves, other windows' parts get exposed.
<pq>
on screen, meaning, in the server framebuffer
<soreau>
brilliant speculative assumption
<pq>
"compositing" is more like: the server (or a compositing manager) has off-screen images of each window, and composes the final framebuffer from those rather than asking clients to issue draw commands that target the framebuffer.
<pq>
soreau, hm?
<soreau>
now let's write some specification for this model and call it.. xwayland!
<emersion>
fwiw, it wasn't entirely clear whether you were criticizing the core X11 model, or pq's message :P
<pq>
latex, Wayland has no protocol for expose events, nor requests for the drawing commands.
<soreau>
emersion: no criticism, just asserting that without further input beyond the initial query is speculation
<pq>
latex, Wayland fundamentally assumes that clients provide images of windows, and the server does whatever to produce the final framebuffer on its own.
<emersion>
soreau: ah, so, there are better ways to say that
<emersion>
your wording was rude here
<soreau>
emersion: well that was not my intent..
<emersion>
maybe "i'm not sure this was what they meant" would've been another way to say it?
<pq>
yeah, I read soreau as borderline insulting me. Good to hear it wasn't intentional.
<soreau>
well if that's what it came across as, I'm sorry
* soreau
is bad at typing english
<emersion>
no worries, good to hear it wasn't intentional
<pq>
hazards of communication, no problem now
<soreau>
textual communication, even
<soreau>
but yea, I guess 'traditional' in wayland terms kinda implies X
<soreau>
but I still am wondering about the 'way forward' for the fullscreen paragraph.. how to know who will type up the suggestion into something acceptable?
<emersion>
ask if the original author has plans to do it, if not, do it?
MrCooper_ is now known as MrCooper
nerdopolis has joined #wayland
<soreau>
emersion: ok
<soreau>
now I have a question about xdg_configure event.. does it require some special request for it to be sent?
<MrCooper>
colinmarc: AFAIK a syncobj timeline point can't be converted to a Vulkan semaphore directly, presumably you mean the fence (sync_file) which materialized for the acquire point?
<soreau>
in my case, I commit a shm buffer every second and xdg_configure events are sent at this frequency. but, if I continually request frame events, then xdg_configure is called 'fluently'
<colinmarc>
MrCooper: I don't understand what you mean by "materialized", but yes, I think that's what I'm doing. exporting a sync fd and then importing that as a semaphore
<soreau>
if I try committing in xdg_configure, it still doesn't get another xdg_configure event until comitting outside of dispatch handling
<soreau>
at least, AFAICT
<colinmarc>
MrCooper: Thank you for sharing this! I feel pretty confident it doesn't apply to my case (single-client, no physical display blank to hit), is that wrong?
<MrCooper>
colinmarc: right, and exporting a sync_file works only once the fence has materialized, for which you need to wait on the CPU anyway; after that, the synchronization with the exported fence works essentially the same as implicit sync
<MrCooper>
colinmarc: I suppose that's a special case where it might not make any difference
<colinmarc>
> exporting a sync_file works only once the fence has materialized, for which you need to wait on the CPU anyway
<colinmarc>
I'm exporting right before render, which is sometimes a while after commit, so I wonder if I'm hiding a bug. what happens if it hasn't materialized yet? what is this materialization thing anyway?
<MrCooper>
colinmarc: if you don't wait for the fence to materialize, you've been getting lucky :) (actually there might be no client in the wild yet which attaches a buffer before the acquire point fence has materialized, the protocol allows it though)
<colinmarc>
how do I wait for a specific point to materialize? since I need to export the fd in order to poll it
<colinmarc>
if I need to introduce a cpu wait anyway, then yeah, I see your point about just doing all the waiting on the CPU
<MrCooper>
you can use drmSyncobjEventfd for this, the eventfd becomes readable when the syncobj timeline point fence has materialized
grinja3 has quit [Remote host closed the connection]
grinja3 has joined #wayland
<MrCooper>
but yeah, why not just wait for the acquire point to signal, can use drmSyncobjEventfd (with 0 for flags) for that as well
CuteMath has quit [Quit: Leaving]
fufexan has quit [Remote host closed the connection]
<latex>
Does Wayland require compositors to implement compositing? Or is there support for repaint messages like on X11?
<kchibisov>
in that sense you've got an answer, everything has its own buffer submitted and being composed by compositor.
<colinmarc>
@_oftc_MrCooper:matrix.org thanks for the help!
<latex>
And another thing, does compositing cause input lag compared to stacking/repainting?
<latex>
Because someone I know insists that it does
<kchibisov>
depends how it's done.
<kchibisov>
and it's also a matter of a different level.
<latex>
What does that mena?
<kchibisov>
it's a tearing/non-tearing thing.
<kchibisov>
it's true that with compositor model it's more likely to hit one frame of latency if you do things very naive.
<kchibisov>
To be more clear, if you use stacking model it also matters how your window manager (x11) communicates the buffer to the kernel.
MrCooper__ has joined #wayland
<daniels>
when you enable compositing in X11, it introduces latency because of the very specific way that it was implemented for X11
<kchibisov>
x11 having latency here is no doubt.
<daniels>
this is not true of Wayland, and it is possible to achieve latency just as low as non-composited X11
<kchibisov>
it has nothing good when it comes to frame scheduling.
<soreau>
latex: in wayland, there are frame events that are sent to clients requesting it, for the compositor to tell the client that it's a good time to submit a new buffer and in most cases, the compositor renders the client surface buffer in the next frame which is basically asap, assuming there is no tearing allowed
<kchibisov>
or anything.
<kchibisov>
and what it has, doesn't work in 99% of the time for whatever reason.
<daniels>
as kchibisov says, 'compositing' really just means that every client submits full buffer contents, instead of maintaining only partial buffer contents - the repaint chain can be in fact even more optimal than X11's
<kchibisov>
submitted buffer is most of the time is just a reference to something old and you have a delta of changes.
<kchibisov>
and in some cases, the buffer is not even composed but used directly.
<soreau>
in a wayland compositor the display server and window manager are in the same process, so there isn't the trifecta of X/wm/client, there's just compositor/client
<Ermine>
i saw an article which stated that author had higher latency in plasma wayland than in plasma x11
<kchibisov>
Could be just a plasma thing.
<kchibisov>
Like I've debugged a frame of latency on gnome recently due to how alacritty used certain api.
<kchibisov>
it used it correctly, but it caused gnome to add frame of latency just for alacritty.
<kchibisov>
Like measuring latency is a _hard thing to do_.
MrCooper_ has quit [Ping timeout: 480 seconds]
<kchibisov>
and catching such things is also hard, since it's not that obvious and you need specialized hardware setup for such things.
<Ermine>
yeah
<kchibisov>
Like plasma could just have a bug on Wayland, but generally it's not a wayland thing or compositor specific thing.
<kchibisov>
compositor model specific thing*
<Ermine>
seems like it's hard to formalize how do people perieve things
<kchibisov>
I mean, you just use a light sensor based approach to measure things.
<soreau>
you can definitely be a wayland compositor and have worse latency than X, which is probably easy to do if you really wanted to
<kchibisov>
e.g. time from it inputing something from pixel changing on screen.
<kchibisov>
so a full system latency.
pavlushka has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Ermine: then that author didn't actually do any measurements
<Ermine>
yes, it was a perception thing
<zamundaaa[m]>
I did roughly 3 years ago, and Plasma Wayland is on par with uncomposited X11 session
<zamundaaa[m]>
Since then we optimized latency more, I should redo those measurements soon
<kchibisov>
zamundaaa: it's a matter of client they used, etc, etc.
<soreau>
is it possible the cursor moves more fluently on X than wayland?
<kchibisov>
zamundaaa: I'd also suggest to examine various path in typical input cases, like text-input based ones, etc, etc.
<kchibisov>
for example, gnome (has/had) a full frame delay if you've touched text-input reposition thing, becuase it started to compose earlier than it should.
<kchibisov>
even though, it wasn't even visible.
<Ermine>
In my case, I never had any latency issues with plasma, neither on x11 nor wayland
<soreau>
me neither, but that's only because I've never used plasma ;)
<Ermine>
i'm writing this from plasma :)
<kchibisov>
if you're used to certain amount of latency you won't notice it if it's bad.
<kchibisov>
especially on high refresh rate monitors it's also not that obvious.
<kchibisov>
I remember I had a bug where I was drawing a blank frame, and I've noticed it when switched to 60fps monitor.
<kchibisov>
on 144Hz it was not that obvious for eye perception.
<Ermine>
my displays are all 60fps
<kchibisov>
I'd imagine that on e.g. 300fps monitors measuring latency is even harder, since it's all pretty much in noise range.
<soreau>
zamundaaa[m]: is it possible to run only plasma's panel in a different compositor? or is it baked into the compositor or requires nonstandard protocol(s) or some other reason it won't work as a 'standalone' client?
<kchibisov>
And frame scheduling is probably not that needed there.
Moprius has joined #wayland
<soreau>
ah, I found my issue with xdg_configure.. didn't commit after ack'ing :P
<soreau>
so I have to ack(+commit) the surface configure to get a toplevel configure event..
<kchibisov>
yeah, you have to commit to apply changes.
<kchibisov>
even when nothing relevant changes, like e.g. you've got only suspended state change.
<soreau>
right but why do toplevel configure events only come after acking the surface configure event..
<soreau>
does it sound like the compositor is correct in this case?
<kchibisov>
could be compositor specific?
<soreau>
I wonder if this is this specified in the protocol anywhere
<kchibisov>
I'd assume you commit before that as well.
<kchibisov>
just to start the initial setup sequence.
<kchibisov>
The flow is you create objects, set all the state you want, and to wl_surface.commit(), then you get the surface.configure/toplevel.configure, etc.
<kchibisov>
I know that you must ack_configure for xdg_toplevel::configure.
<kchibisov>
But the other configure is a bit vague here, it just tells to do that eventually before surface.commit.
<zamundaaa[m]>
soreau: plasmashell is only supported on KWin. Some people have made it kinda work with lots of hacks on other compositors, but it is not supported
<soreau>
zamundaaa[m]: I see, thanks
<soreau>
kchibisov: how do you know that you must ack before getting toplevel configure events?
<kchibisov>
it's not specified.
<kchibisov>
I know that you must ack toplevel configure.
<kchibisov>
i don't know about before.
<soreau>
ah, well that's where it's confusing..
<soreau>
because the spec says for toplevel.configure, you have to send surface.ack_configure but in surface.configure.. well, this is where simple-shm sends ack_configure
<kchibisov>
There's also a wording like >The client must acknowledge it and is then allowed to attach a buffer to map the surface.
<kchibisov>
I'd assume you must ack the initial configure.
<soreau>
right but ack'ing in surface.configure isn't required, right?
<kchibisov>
it's required for initial setup.
<kchibisov>
but it doesn't say where.
<soreau>
oh ok
<kchibisov>
read the xdg_surface general doc.s
<kchibisov>
"After creating a role-specific..." paragraph.
<soreau>
my point is in toplevel.configure it states "Clients must send an ack_configure in response to this event. See xdg_surface.configure and xdg_surface.ack_configure for details." but in simple-shm there is only one ack, and it's in surface.configure
<soreau>
so technically per spec, it seems simple-shm is missing an ack in toplevel.configure
<soreau>
does this make sense?
<soreau>
and it all happens to work out because surface.configure and toplevel.configure are basically emitted together?
MrCooper_ has joined #wayland
<kchibisov>
it's correct.
<kchibisov>
the surface.configure marks the end of the configure sequence.
<kchibisov>
and you can only ack the serial from it.
<soreau>
oh it needs a serial
<kchibisov>
thus, you ack from the xdg_surface.configure.
<kchibisov>
since it's the end of the sequence.
<soreau>
so why does the spec say to emit an ack in response to toplevel.configure?
<kchibisov>
idk.
<kchibisov>
you'd emit it anyway.
<kchibisov>
probably for consistency and that it'll only apply because you ack.
<soreau>
so toplevel.configure(s) always happen first followed by a surface.configure except the initial configure?
MrCooper__ has quit [Ping timeout: 480 seconds]
<kchibisov>
you can not get surface.configure -> toplevel.configure -> no surface.configure.
<kchibisov>
so the state of multiple objects applied atomically.
<kchibisov>
e.g. decoration manager + top level.
<soreau>
so simple-shm is frame event driven, but it doesn't commit after ack in surface.configure, it just relies on the frame event to commit the ack at that point..
<soreau>
(except on initial configure)
<kchibisov>
you usually commit -> loop { ack -> draw -> commit (by means of draw) }.
<soreau>
ok, untangling the confusion
<kchibisov>
the point is that you commit when you've applied the state, to inform that state got applied and compositor transitions, since you've applied already.
<kchibisov>
if you commit straight away, it's wrong, since you likely haven't accounted for a new size, etc.
<kchibisov>
The point is for state change to be atomic and you don't see window flicker.
<soreau>
unless you pass the --tear-it-up flag ;)
<kchibisov>
The only thing where you don't need to really draw, is when you got a suspended state change.
kts has quit [Quit: Konversation terminated!]
bodiccea_ has joined #wayland
selckin has quit [Quit: selckin]
selckin has joined #wayland
elliptic_saki has quit [Ping timeout: 480 seconds]
elliptic_saki has joined #wayland
bodicceaII has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
bodiccea has quit [Ping timeout: 480 seconds]
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Remote host closed the connection]
AJC_Z0 is now known as AJ_Z0
MrCooper__ has joined #wayland
Moprius has quit [Quit: bye]
MrCooper_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Rob[m]1 has joined #wayland
feaneron has joined #wayland
MrCooper_ has joined #wayland
grinja3 has quit [Remote host closed the connection]
OtzmaYehudit has quit [Remote host closed the connection]
OtzmaYehudit has joined #wayland
grinja3 has joined #wayland
MrCooper__ has quit [Ping timeout: 480 seconds]
sewn has quit [Ping timeout: 480 seconds]
sewn has joined #wayland
sewn has quit [Ping timeout: 480 seconds]
sewn has joined #wayland
sewn has quit [Ping timeout: 480 seconds]
sewn has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
Calandracas has joined #wayland
dongle has joined #wayland
<dongle>
occasionally after afk i come back and move the mouse and the screen comes back on but everything is frozen for 30 seconds. then it is ok. any ideas? gnome 43.9 wayland, debian 12
<dongle>
intel integrated gpu
Calandracas has quit [Ping timeout: 480 seconds]
<danieldg>
the 30 seconds sounds like some dbus call is timing out
Calandracas has joined #wayland
<danieldg>
perhaps running dbus-monitor on both session and system bus would help figure it out
<danieldg>
likely a gnome bug, check their bug tracker
<danieldg>
(mutter, that is)
<dongle>
i'll look into that thanks danieldg
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
feaneron has joined #wayland
Moprius has joined #wayland
checkfoc_us9 has quit []
checkfoc_us9 has joined #wayland
dongle has left #wayland [#wayland]
Moprius has quit [Quit: bye]
bluetail has quit []
bluetail has joined #wayland
elliptic_saki has quit [Read error: Connection reset by peer]