ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Quit: Leaving]
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
dri-logg1r has quit [Ping timeout: 480 seconds]
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
dri-logg1r has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
dri-logger has joined #wayland
mclasen has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
elsie has joined #wayland
elsie has quit []
mxz has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
crazybyte has quit [Quit: Ping timeout (120 seconds)]
crazybyte has joined #wayland
nerdopolis has joined #wayland
kts has joined #wayland
manuel__ has quit [Read error: Connection reset by peer]
manuel__ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
test has joined #wayland
test has quit []
Leopold has joined #wayland
champions007 has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
champions007 has quit []
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
nerdopolis has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
kts has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
sima has joined #wayland
tent4051 has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
mxz has joined #wayland
Mershl[m] has quit []
Bugies has joined #wayland
glennk has joined #wayland
rasterman has joined #wayland
mvlad has joined #wayland
alatiera has joined #wayland
<poke>
Hi is this good to place to ask questions about implementing xdg-desktop-portal?
tzimmermann has joined #wayland
davidre has joined #wayland
<davidre>
#xdg-desktop-portals:matrix.org is the portal channel
<poke>
thank you sorry for bother you guys
<pq>
emersion, wouldn't libwayland-client do the wrong thing for inheriting an object interface version from a third object?
<emersion>
pq, the version for new resources is passed explicitly
<emersion>
wl_resource_create() takes a version argument
garnacho has joined #wayland
garnacho has joined #wayland
<pq>
kchibisov, any configuration change must be met with ack_configure to allow the compositor to act the new state, and ack_configure requires a commit on the xdg-toplevel, IIRC.
<kchibisov>
And some compositors don't like commits without buffer attach, but you can't attach buffer for suspended if you use vsync.
<kchibisov>
it's just...
<kchibisov>
life is hard, I guess.
<pq>
From Wayland perspective, you can always draw at any time, or not draw. Client-side library designs like EGL are another matter.
iomari891 has joined #wayland
<kchibisov>
yeah.
<kchibisov>
it's just ecosystem is kind of like that.
<pq>
indeed, ack without commit is not really an ack.
<kchibisov>
I mean, doing commit with buffer for suspend is also weird.
floof58 has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
bindu has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
<pq>
emersion, yes, the server side is ok, but the client side?
<emersion>
hm
<MrCooper>
compositors which "don't like commits without buffer attach" are just broken, aren't they?
<pq>
emersion, the only way I know that works right now for manually defining the version is to use a new_id without interface attribute in XML, and spec in the doc what the free parameters must be.
bindu has joined #wayland
<pq>
MrCooper, correct. kchibisov ^
<pq>
in general at least, maybe kchibisov can give more details how exactly they don't like it?
floof58 has joined #wayland
<MrCooper>
or maybe the issue is that the ack requires new surface dimensions, which requires a new buffer
<emersion>
the problem is about toolkit API design, i believe
<pq>
just setting the xdg geometry should suffice, right?
<kchibisov>
Hm, I wonder what should be done when you resize and get suspended at the same time.
<pq>
xdg configure drives xdg geometry, not wl_surface size, does it not?
<pq>
though having the two mismatch is not be best thing
<kchibisov>
yeah, you'll have a missmatch.
<pq>
but if you just cannot draw, then what else
<kchibisov>
my main issue is toolkit design, since commit is a wayland special concept.
<kchibisov>
And I can't really do commit on behalf of the users.
<MrCooper>
is there an issue with just doing the ack and waiting for whenever the next commit happens?
<kchibisov>
because it could break their multithreaded rendering, so I need to sync.
<kchibisov>
I mean, if you commit with EGL + use vsync you'll block indefinitely.
<kchibisov>
so suspended is kind of useless.
<pq>
can't you require toolkit used to do a "tookit commit" which on non-Wayland would be kind of unnecessary?
<pq>
*toolkit users
<kchibisov>
users won't ever call this method.
<pq>
maybe they should?
<kchibisov>
I know how to solve it in the future.
<kchibisov>
just not now.
<pq>
what about MrCooper's suggestion to ack now and let the net draw cammit it, whenever it might come? Since you have to sync resizes etc. anyway.
<pq>
*next
<kchibisov>
that's what I do though?
<kchibisov>
I ack myself and commit is done when user draws.
<pq>
what's the problem them?
<kchibisov>
drawing is not in my jurisdiction.
<pq>
so?
<pq>
what are you worried about?
<kchibisov>
And I don't want vsync users to block.
<kchibisov>
since they'll block in that case since frame callback won't ever arrive.
<MrCooper>
there's no need to commit ASAP, is there?
<kchibisov>
And if users use frame callbacks, the event is useless for them.
<kchibisov>
you need to commit the state though.
<kchibisov>
you can't just ack it, since the state won't apply.
<pq>
are you thinking you must get the commit out immediately?
<kchibisov>
I think that I won't be suspended until I commit.
<pq>
why do you need to get the ack acted on immediately?
<pq>
why would suspending be related to acking?
<emersion>
i thought that we talked at some point about disconnecting clients that don't ack in timely manner, because they can be seen as unresponsive
<kchibisov>
If I don't ack how it'll help me?
<pq>
emersion, sounds like that would need to be conditional to suspending the surface.
<MrCooper>
suspending a surface and then disconnecting the client for not doing anything would seem kind of mean
<pq>
kchibisov, what is the problem you have? What needs helping?
<kchibisov>
I mean, I know how to solve my problem.
<kchibisov>
I initially asked whether commit is really mandatory.
<kchibisov>
if it's mandatory I'll just approach it differently.
<pq>
commit is mandatory to have ack acted on. Having ack actent on immediately is not necessary.
<kchibisov>
mandatory in a way that compositor will think that my toplevel is not suspended until I ack+commit.
<pq>
what does suspending have to do with this?
<emersion>
the suspended state is not like the rest of the states
<kchibisov>
I mean, it's just an example.
<kchibisov>
but yeah, it's also different.
<pq>
is suspend using the same ack_configure as xdg-toplevel states?
<kchibisov>
I initially discovered that smithay doesn't think that my toplevel is active, until I ack + commit.
<kchibisov>
Once we were implementing wlr-foreign-toplevel-management.
<kchibisov>
The suspended is a bit special, because it means that you must commit without a buffer.
<kchibisov>
since you don't know what users of the toolkits are using, like they could draw with EGL + vsync and it's not desired to block them.
<kchibisov>
even though they can use frame callbacks...
<kchibisov>
Like in the future, I'll just ask the user to pause rendering and force a reply from them to tell whether they did that or not.
<kchibisov>
Once they pause, I commit on behalf of them, since they told me that they did so.
<pq>
where is the spec for the suspend we are talking about here?
<pq>
phew, not xdg-shell-unstable-v6.xml, I'm relieved
<kennylevinsen>
Need one more version bump to disambiguate
<pq>
ok, and if a client required to ack suspension before it actually applies?
<pq>
*is
<kchibisov>
From my understanding to state to apply it must ack + commit.
<pq>
I see no wording saying it does not need an ack?
<kchibisov>
I mean, the problem is that it needs ack+commit.
<pq>
IOW, you are free to draw as many times as you want, your surface will not be suspended until you actually ack it with a commit.
<kchibisov>
I'm fine with ack, I'm not fine with commit.
<kchibisov>
My issue is basically what happens when I _ack+commit_, but I also wait for frame callback, like mesa's vsync does?
<kchibisov>
in my understanding I'll just block.
<pq>
IOW, Mesa "vsync" will not block your draws until you actually ack+committed. If it blocks, that's a compositor bug.
<kchibisov>
because the surface is _suspended_ now, thus I won't get frame callback soon.
<pq>
no, the surface is not suspended "no"
<kchibisov>
So if I draw with vsync to apply suspended state and I block it's a bug in compositor?
<pq>
the spec needs you to ack the suspension before it becomes suspended, because I don't see wording saying otherwise.
<pq>
yes
<kchibisov>
And so if I asked for frame callback when applying the suspended state I'll actually get it?
<kchibisov>
because emersion said otherwise iirc.
<kennylevinsen>
pq: I don't think that really aligns with the intended use though - "you're not going to get repainted anymore, deal with it"
<pq>
Mesa EGL blocks for *previous* frame submission, so you can freely do the draw for the commit that acks the suspended state.
<kennylevinsen>
I don't think compositors would keep sending frame events to an occluded/minimized/whatever surface on the basis of it not having ack'ed "suspended"
<kchibisov>
I mean, I'll draw, but it'll wait for a frame to arrive to unblock?
<kchibisov>
but with toplevel being suspended, I kind of assume that it won't arrive.
<pq>
kennylevinsen, then people failed to write it in the spec. They need to live with what they wrote, or try to fix the wording.
<kchibisov>
won't arrive soon.
<pq>
kennylevinsen, the spec implies they need to.
<kennylevinsen>
kchibisov, pq: mesa blocks on previous frame callbacks, so a new buffer swap blocks if the *last* one has not received its frame callback
<kchibisov>
Ah, and previous one I'll get.
<kennylevinsen>
pq: I see your point, but if neither authors nor implementers interpreted it that way then it won't work. Spec needs to be fixed then though, yes.
<kchibisov>
So if I try to draw after suspended it'll be broken.
<pq>
yes, because the spec of suspended state does not say that the suspended state would apply without an ack.
<pq>
kennylevinsen, indeed.
<pq>
and if the spec is fixed, kchibisov is back with the problem
<kennylevinsen>
frame callbacks are already not guaranteed, so I don't see how it would be valid to assume that they would be guaranteed until suspended is acked...
<kchibisov>
pq: if mesa blocks previous frame callback I don't have problem.
<pq>
if frame callbacks were not needed to be guaranteed, there would be no reason for the suspended state
<kchibisov>
I'll just delay the occluded state sending.
<pq>
kchibisov, right, unless you lose a race.
<MrCooper>
pq: the suspended state lets the client know no frame events will be arriving
<kchibisov>
The race is that suspended is send before the previous frame's frame callback?
<pq>
MrCooper, yes, but the spec for surface state requires states to be acked before they apply.
<MrCooper>
no frame events will be arriving anyway, even without ack
<kennylevinsen>
to be pedantic about the current wording, the only documented behavior is that on wl_surface::frame saying that it is not guaranteed. Nothing in the suspended spec mentions frame events - just that no repaint will occur
<kchibisov>
yeah, but wasn't the intention to solve the blocking vsync thing in cross platform toolkits?
<kennylevinsen>
so suspended just says that it will be repainted less than before (implying fewer callbacks), not that frame callbacks were going to arrive at any rate before...
<pq>
kchibisov, the race is that you are submitting a frame while the compositor is sending the suspended event. The compositor sees your frame+commit after it sent the suspended event. When you see the suspended event, the compositor is already holding the frame callback your draw+ack commit would wait on.
<kchibisov>
Like you don't really need this state, unless you want to minimize resource consumption.
<kennylevinsen>
I recall the discussion having use-cases in all directions, but resource consumption was one of them
<kchibisov>
pq: but I won't have ack?
<pq>
have?
<kchibisov>
I mean, I must ack for it to start counting?
<pq>
that's what we're debating here
<pq>
spec wording says yes, implementations say no, I guess
<kchibisov>
Like my issue is that I need commit in the first place. I'm fine with ack.
<kchibisov>
So I have issue only when I need commit, if I need only ack, or no ack or commit, I'm fine.
<kchibisov>
If you remove ack, yes, it's a race then.
<emersion>
only ack without commit is same as doing nothing
<pq>
you cannot have a separate ack request that does not need a commit for a state in xdg_toplevel.
<pq>
it's just not how xdg_toplevel works, though technically one could be adde
<kchibisov>
it's just suspended state is weird in a way that it's just a global state.
<kennylevinsen>
just ack + commit on suspended should be fine as long as the client hasn't staged other changes in the meantime that you would accidentally apply
<kennylevinsen>
yeah it's a little weird as a state
<kchibisov>
in a sense that no matter what you do, you already know that you likely won't get frame callbacks after seeing it.
<emersion>
it's there because it was easy, but multiple people objected
<kchibisov>
there was a separate protocol for surface itself.
<kchibisov>
iirc.
<pq>
kennylevinsen, I understood that's exactly the problem, kchibisov cannot guarantee that there would not be pending arbitrary state in flight when he would commit the ack.
<kchibisov>
I'll be able in future though.
<kchibisov>
just not _now_
<pq>
Do you need to solve the problem of now? What's today's failure mode?
<kchibisov>
I just removed the handling already.
<kchibisov>
Users have frame callbacks infra in-place and can use that instead.
<kennylevinsen>
Hmm, I wonder if the suspended wording should be made stronger to imply that it *must* be set on occlusion
<kchibisov>
I just wanted to improve the cross platform situation.
<kchibisov>
Since suspended is a common concept.
<kennylevinsen>
Maybe daniels has some thoughts, being the unfortunate soul with the Author: status. :P
<kchibisov>
in the future I'll just sychroniously ask the user with the callback to tell me that they've paused their rendering.
<pq>
We've seen how toolkit API designed for other window systems have problems adapting to Wayland, but is the opposite also true?
<kchibisov>
So I can _safely_ commit without buffer.
<kchibisov>
Wayland usually has things not present anywhere else.
<kchibisov>
And concepts like _apply scale yourself or you crash_.
<kchibisov>
if you control rendering/windowing/etc it's probably just fine.
<pq>
right, but if the toolkit API already required all that, would the toolkit have problems working on other window systems?
<kchibisov>
I'd just say that you don't have that _fear of crash_ with other stuff.
<emersion>
kennylevinsen: i don't think that's a good idea
<kchibisov>
only wayland can crash you if you don't behave.
<emersion>
it would force compositors to have some special logic they can't avoid
<emersion>
there are some grey areas where the surface is kind-of visible but not really
<kennylevinsen>
emersion: well if they have logic for occlusion to stop callbacks, it would just be an extension of that
<kennylevinsen>
if it doesn't affect callbacks, it doesn't matter
<pq>
kennylevinsen, I think you forgot to write in the spec adendum: "if the compositor stops frame callbacks on occlusion, then ..." ;-)
<pq>
or something like that
<emersion>
kennylevinsen: my condition for accepting suspended is that it would be purely optional for the compositor iirc
<kennylevinsen>
"This state may sometimes be set" - problem solved
<pq>
but simply saying "must be sent when occluded" is a straight demand that compositors need to know when something is occluded
<kennylevinsen>
indeed, makes sense
<emersion>
and of course can't find back that discussion…
<emersion>
oh well
<emersion>
a previous iteration was written with the "mechanism" approach
<kchibisov>
suspended on toplevel is kind of weird due to subsurfaces, etc.
<emersion>
where the state was named "invisible"
<kchibisov>
Like if you have toplevel covered by opaque subsurfaces, and that subsurface is the only thing visible I'm not sure how it'll work.
<emersion>
the state applies to the whole toplevel surface tree, kchibisov
<kchibisov>
yeah, but it's not suspended in that case?
<kchibisov>
But I might not ever recieve frame callback if I try to draw occluded surface.
<emersion>
indeed
<emersion>
that's a good point
<kchibisov>
it all sounds like I should just do something else instead of computers.
<pq>
If the intent is to avoid indefinite blocking with Mesa's EGL implementation of *today*, then it has to be a strict mechanism tied to frame callbacks without any leeway on policy.
<kchibisov>
I'd rather see mesa stop doing the frame callback thing.
<pq>
me too, and I think things are progressing in that direction
* kennylevinsen
mumbles in anti-WSI
<pq>
one WSI implementation with known behaviour, or numerous WSI-likes that are different in each app with their own expectations, and some never going to be updated? :-p
<kchibisov>
sounds like wayland compositors, sign me up.
<kennylevinsen>
tbf, no WSI *in your userspace GPU driver* does not mean you can't have a convenience library :P
<kchibisov>
convinience library called mesa, I see.
* YaLTeR[m]
looks at how everyone stopped killing clients for not honoring maximized size
<kchibisov>
tbf, if I would be able to not use mesa wsi, I'll be free from _libwayland or die_ situation.
<emersion>
they never did in the first place i think, YaLTeR[m]
<kennylevinsen>
kchibisov: do you have a blocker for not using the WSI?
<kennylevinsen>
(other than inconvenience of some more code)
<YaLTeR[m]>
emersion: I've heard rumors that sway used to
<kchibisov>
kennylevinsen: EGLSurface?
<emersion>
i don't think we ever did
<pq>
Compositor developers have some responsibility for not regressing applications, but applications cannot regress compositors. It's not a symmetric relationship.
<kchibisov>
Like I can't implement mesa's wsi out of tree iirc.
<kchibisov>
unless the vtable hooks in dri wayland can be used out of tree?
<emersion>
kchibisov: you can, with GBM and FBOs and responsibility for wiring up everything
<emersion>
like, wlroots does
<kchibisov>
but it's different to direct screen rendering and you lose some extensions.
<kchibisov>
And some of them you can't implement yourself.
<emersion>
you loose one extension that nobody seems to see value for
<kchibisov>
since it's a driver specific ioctls.
<kennylevinsen>
which extension?
<kchibisov>
partial_update.
<kchibisov>
I'm pretty sure it's the one that lost.
<kchibisov>
Like buffer age doesn't really matter.
<emersion>
the way to fix that is just to add a new, better ext
<emersion>
however, that's blocked on someone finding a real upside to the ext
<emersion>
it's not buffer age
<kchibisov>
How wsi will work with nvidia stuff though?
<kchibisov>
wlroots also has its own wsi with vulkan, right?
<emersion>
wlroots' wsi is not tied to GL nor Vulkan
<emersion>
it's just DMA-BUFs and shm buffers
<YaLTeR[m]>
so if suspended covers the whole top-level, then you can move the window partially off-screen in such a way that only its CSD shadow subsurface is visible, then the window will not be suspended and yet the main surface won't receive frame callbacks
<emersion>
indeed
<emersion>
same for popup etc
<kchibisov>
The only benefit I see from the current suspended is that you can unload a bunch of resources.
<kchibisov>
And if you're a simple game it'll likely do just fine.
<emersion>
that might not even be appropriate, since the compositor might not debounce it
<emersion>
so if the user switches back and forth very quickly between workspoaces you see your disk usage go to 100%
<pq>
Would be awesome if someone could collect those shortcomings into a gitlab issue. No need to suggest solutions, just record the problems.
<kchibisov>
emersion: transfering from GPU to cpu memory and back :P
<emersion>
i was thinking reloading assets from disk
<kchibisov>
I was thinking about unloading textures, or something like that to free up a bit.
<kchibisov>
since you generally have pretty low amount of GPU memory.
<emersion>
do games keep textures in RAM, in addition to GPU VRAM?
<emersion>
well, in any case
<kchibisov>
Can you even load from disk to GPU?
<emersion>
well, sure, disk to RAM then to GPU
<kchibisov>
Yeah, so can probably download back from GPU.
<YaLTeR[m]>
there was some recent advertisement that PS5 can do it and then a windows API appeared for "direct from disk to GPU"
<YaLTeR[m]>
recent = 2 years
<emersion>
it is possible yeah, there were XDC presentations about SSD to GPU from AMD
<YaLTeR[m]>
Maybe we should take inspiration from JavaScript. `willFrameCallbacksArrive() -> "no" | "maybe" | "probably"`
<davidre>
"askagainlater"
<kennylevinsen>
it returns a confidence interval as a double
<kchibisov>
"whatisframecallbackanyway"
<kchibisov>
I mean compositor is the one sending them, so it's either yes or no.
<zamundaaa[m]>
<pq> "IOW, Mesa "vsync" will not block..." <- The suspended state was intentionally made to *not* be about frame callbacks in any way or form
<pq>
zamundaaa[m], ok, so it was never intended to solve the "eglSwapBuffers might block indefinitely". My bad.
<zamundaaa[m]>
Yeah
<kchibisov>
zamundaaa[m]: what should it be used for then?
<kchibisov>
Since the _pause rendering_ already solved via frame callback loop.
<zamundaaa[m]>
It's just a better hint for toolkit "window is occluded" APIs
<zamundaaa[m]>
As in, rendering is not just slowed down for the moment, but won't happen for a while. So you may even deallocate buffers and that stuff
<kchibisov>
but which buffers, since subsurface/shadow could still be visible?
<kchibisov>
I'd assume not related to presented content.
<pq>
xdg_toplevel is about the whole window and not just the one wl_surface it was created for. So.
<zamundaaa[m]>
The buffers that aren't currently held by the compositor
<zamundaaa[m]>
It's also about not doing calculations for animations, video decoding, that sort of stuff
<kchibisov>
yeah, but video decoding could be on its own subsurface which may be visible.
<kchibisov>
Or bleed a bit.
<pq>
it's still the same window
<zamundaaa[m]>
kchibisov That would be a compositor bug
<kchibisov>
so window is suspended if and only if all its tree is not visible.
<kchibisov>
So popups, etc.
<zamundaaa[m]>
I do agree it would've been better to just do it on wl_surface with guarantees about frame callbacks, but I don't really want to rehash that old discussion
jimjams has quit [Read error: Network is unreachable]
yang2 has quit [Read error: Network is unreachable]
i509vcb has quit [Read error: Network is unreachable]
bwidawsk has quit [Read error: Network is unreachable]
alatiera has quit [Read error: Network is unreachable]
zmike has quit [Write error: connection closed]
jimjams has joined #wayland
yang2 has joined #wayland
i509vcb has joined #wayland
yang2 is now known as Guest951
<kchibisov>
Like if everything belonging to toplevel must be occluded for it to be suspended that sounds like fun to implement.
alatiera has joined #wayland
bwidawsk has joined #wayland
zmike has joined #wayland
<d_ed[m]>
Occluded is not the best term, the spec calls it "suspended". We use it for "on another virtual dekstop" or "another client is fullscreen"
<d_ed[m]>
You can be occluded but not suspended
<d_ed[m]>
but never visible and not suspended
<kchibisov>
I mean, occluded means _not visible_, mostly.
<kchibisov>
Though, the correct term is suspended, yes.
glennk has joined #wayland
<kennylevinsen>
d_ed[m]: I imagine you meant "never visible and suspended" :)
mclasen has joined #wayland
<d_ed[m]>
yes, that
kts has joined #wayland
<daniels>
kennylevinsen: yeah, my thought is that you should ignore suspended and commit new state when the compositor pushes you a configure event; it's the only thing that makes sense really
<daniels>
I mean, if you ignore the configure event and don't push anything, when you alt-tab back to your window, you'll see the old content, then as it gets unsuspended and commits, it will change state again to a different size or something, which seems very not ideal
<daniels>
if you ack the configure and don't commit new state, then you'll get taken out by the xdg-toplevel state mismatch
bodiccea has quit [Quit: Leaving]
<daniels>
so yeah, I would stick to 'don't draw of your own accord, but if the compositor pushes you new state then update to match that'
<idl0r>
hm, neither with nvidia nor nouveau wayland doesn't show my third monitor which is connected via HDMI to my AV receiver and from there to my monitor. any ideas how to get it working?
paulk-bis has quit []
paulk has joined #wayland
Leopold_ has joined #wayland
<kennylevinsen>
idl0r: Wayland is a protocol - a bunch of xml files - so it's not the right place ot ask. Your Wayland server is usually provided by your desktop environment, and so how to use, configure and debug goes to them.
nerdopolis has joined #wayland
BlueDusk has joined #wayland
zvarde1988303206779191685 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
BlueDusk has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
flom84 has joined #wayland
flom84 has quit [Remote host closed the connection]
Guest951 has quit [Killed (NickServ (Too many failed password attempts.))]
yang3 has joined #wayland
yang3 is now known as Guest993
yang is now known as Guest994
Guest993 is now known as yang
yang is now known as yang2
Guest994 is now known as yang
mclasen has quit [Ping timeout: 480 seconds]
zvarde1988303206779191685 has joined #wayland
rasterman has joined #wayland
___nick___ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
Bugies has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
rv1sr has quit []
tanty has quit [Quit: Ciao!]
leon-anavi has quit [Quit: Leaving]
tanty has joined #wayland
tanty has quit []
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has joined #wayland
tanty has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
privacy has quit [Quit: Leaving]
Leopold_ has joined #wayland
mclasen has quit []
Brainium has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Brainium has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]