ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
bluepenquin has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
<repetitivestrain>
MrCooper: thanks! that's exactly what the problem was
bindu has quit [Quit: WeeChat 3.6]
bindu has joined #wayland
danvet has joined #wayland
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
manuel1985 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
jgrulich has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
mvlad has joined #wayland
<MrCooper>
repetitivestrain: \o/
<repetitivestrain>
btw, is there a program that can be used to test subsurfaces
<repetitivestrain>
that's more sophisticated than weston-subsurfaces?
<repetitivestrain>
i haven't been able to find any real world usage of the subsurface place_above and place_below stuff
<repetitivestrain>
also, can a seat's keyboard focus be set to a subsurface?
<MrCooper>
repetitivestrain: Firefox Nightly with gfx.webrender.compositor.force-enabled set to true in about:config is the most advanced real-world test case for sub-surfaces I know of
mbalmer has joined #wayland
<emersion>
if you want to just play around, wleird has a subsurface client as well
juergbi has quit []
<repetitivestrain>
MrCooper: okay, thanks
manuel1985 has joined #wayland
juergbi has joined #wayland
rasterman has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
dcz has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
fahien has joined #wayland
kurhnel has joined #wayland
kurhnel has quit []
dcz has quit [Ping timeout: 480 seconds]
op62 has joined #wayland
jmd has quit [Ping timeout: 480 seconds]
_op62 has quit [Ping timeout: 480 seconds]
devilhorns has joined #wayland
manuel_ has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
abeltramo_ has joined #wayland
adarshgm has joined #wayland
dcz has joined #wayland
fahien has quit [Quit: fahien]
adarshgm1 has joined #wayland
adarshgm has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
nerdopolis has joined #wayland
devilhorns has quit []
devilhorns has joined #wayland
abeltramo has joined #wayland
abeltramo_ has quit [Read error: Connection reset by peer]
abeltramo has quit []
fahien has joined #wayland
<zamundaaa[m]>
xdg shell says that a client must obey the size in a configure event if the compositor is making the surface fullscreen or maximized. Is that what the invalid_surface_state error is there for? It's not documented well
Net147 has quit [Read error: Connection reset by peer]
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
rv1sr has joined #wayland
cool110 has joined #wayland
cool110_ has quit [Remote host closed the connection]
Net147 has joined #wayland
Net147_ has quit [Read error: Connection reset by peer]
<zamundaaa[m]>
That's true. The "must" bit should be removed from the fullscreen description then
<daniels>
davidre: the Matrix bridge is run by matrix.org itself, we have no control over it
<daniels>
repetitivestrain: gstreamer's waylandsink uses subsurfaces with place_above and place_below
rv1sr has quit []
bittin has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
rv1sr has joined #wayland
bittin has joined #wayland
<davidre>
daniels: so we have to live with the spammers?
<daniels>
davidre: probably? I have no idea what their moderation or spam policy is like tbh
<davidre>
I wonder if one can see the spam on IRC? I guess not since they are not registered
<emersion>
nope
<DemiMarie>
I cannot see it myself tbh, but on Matrix there is a report button
ybogdano has joined #wayland
Brainium has quit [Read error: No route to host]
MajorBiscuit has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
<tleydxdy>
tbh idk why the bridge doesn't just mute unregistered users when the irc side does
<tleydxdy>
would also solve the problem where people post stuff that just get silently dropped
Brainium has joined #wayland
<kennylevinsen>
Yeah, Matrix IRC bridges are pretty broken. They can't communicate constraints, and have rather poor error handling...
bittin has quit [Read error: Connection reset by peer]
<kennylevinsen>
(Bridges for other mediums are also veeery full of magic, including calling out to ffmpeg)
bittin has joined #wayland
<kennylevinsen>
But to be fair, OFTC is quite annoying in that it doesn't support SASL for authentication, so people do end up unregistrered by surprise as they failed to reauthenticate. Happens to me at times.
<tleydxdy>
yep
bittin_ has joined #wayland
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
bittin_ has quit [Read error: Connection reset by peer]
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
bittin has quit [Read error: Connection reset by peer]
MajorBiscuit has quit [Ping timeout: 480 seconds]
bittin has joined #wayland
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
bittin_ has joined #wayland
bittin has quit [Read error: Connection reset by peer]
<pac85>
Regarding this comment " The main blocker right now is not Wayland, it's KMS. At the moment KMS doesn't support tearing with the atomic interface." (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/65) is there any work being done in the kernel side? Also I wonder whether it makes sense for the atomic api to support async_flips, I doubt they can be done atomically. Couldn't a compositor just call drmMode
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
<pac85>
Also I wonder where the documentation states that atomic commit doesn't support DRM_MODE_PAGE_FLIP_ASYNC, I remember not being able to find it in the documentation and asking here but no one was really sure it wasn't possible (and perhaps it wasn't working for me due to something else I did wrong).
<kennylevinsen>
pac85: compositors are generally written to use atomic rather than legacy API (emphasis on it being the *legacy* API), so that needs to be expanded
<pac85>
The previous message got truncated. "Couldn't the compositor switch to drmModePageFlip when tearing updates are needed, can't the compositor switch on the fly"?
<pac85>
Mmm
<emersion>
no, it can't
<pac85>
Is it being discussed by the kernel guys?
<emersion>
and even if it could, that'd be a pretty bad excuse
<kennylevinsen>
even if it could, that ain't getting near code I have to maintain lol
<pac85>
I guess one could also blit to the front buffer to get tearing though that causes other artifacts
<pac85>
Also if the point is to get a proof of concept working one could always implement it on something like the xorg backend of weston right? At least the protocol would become part of wayland and some compositors could find ways of implementing it with the current kms api
bittin_ has quit [Read error: Connection reset by peer]
rgallaispou has quit [Remote host closed the connection]
bittin has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
<emersion>
… what about doing things properly
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
<emersion>
at first we don't even need a protocol, a compositor pref would be enough
<kennylevinsen>
there is no point playing X11 games through Xwayland with an Wayland compositor using X11 as backend. It just makes puppies cry.
fahien has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
fahien has quit []
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
<pac85>
(pac85) emersion: How can a compositor option suffice? If I'm not mistaken a wayland compositor can't even tell between a swap interval of 0 or 1, or VK_PRESENT_MODE_FIFO_KHR from any other. A global options would theredore apply even to clients with a swap interval of 0 or VK_PRESENT_MODE_FIFO_KHR which would mean getting tearing in something like a video player. Clearly not desiderable
<emersion>
"at first"
<emersion>
even if there is a protocol, a user pref to override the protocol for a given app would be useful
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
<pac85>
emersion: I've done it and it's a pretty bad experience, not even good enough as a temporary solution, the protocol is imho a necessity. Time ago I remember that there was talk about a proof of concept implementation being necessary for the protocol to be merged so that's why I was talking about implementing it in the X backend, but now I guess that even if something like that was implemented the protocol still wouldn't be merg
<pac85>
ed?
<pac85>
(Sorry about the truncated messages)
buh0 has joined #wayland
<kennylevinsen>
You are misunderstanding - the all-important KMS feature can be tested as a debug pref or even permanent enablement on a branch - that is entirely sufficient to prove that it works. The protocol is mostly just to toggle it on/off.
<kennylevinsen>
It won't be shipped to end-users before everything is in place, but we don't need it to be polished during development and testing. It's fine that everything is awful and useless for day to day use...
<kennylevinsen>
There is no point in doing things backwards, merging a protocol for a feature that cannot be implemented properly yet. Proper implementations (not random tests) is a requirement for merge anyway.
<kennylevinsen>
(it would just risk realizing that the protocol was broken)
pac85 has quit [Read error: Connection reset by peer]
<pac85>
kennylevinsen: my bad, I assumed wayland was agnostic with respect to what it was being run on so an xorg or legacy kms implementation would be as good as an any other to prove the protocol wasn't broken. However I have to assume that given the current state it won't be until at least one more year until this gets implemented given that it requires kernel changes (or more if it's discussion hasn't started on the kernel side of t
danvet has quit [Ping timeout: 480 seconds]
<pac85>
(or more if it's discussion hasn't started on the kernel side of things). I wonder whether a spec exists for drm, there a lot of things that seem to work but that aren't actually supported but I've found no source to see which api usage is valid and which isn't. Does a spec exist? It's pretty hard to make compliant software without one.
<emersion>
usually software comes with docs, not a spec
<emersion>
KMS has docs, but not sure they explain whether this flag is valid or not for atomic
<emersion>
the source code does tell
abeltramo_ has joined #wayland
<pac85>
I was intrested in general, I have a piece of code that uses kms and works but that I'm not sure on whether it is valid usage (so sourcecode wouldn't tell me much in that case). In any case I don't want to expand on that because I guess it would be offtopic (I was doing stuff with X). Thanks
abeltramo_ has quit []
MajorBiscuit has joined #wayland
AndroUser2 has joined #wayland
pac85 has quit [Read error: Connection reset by peer]
ybogdano has joined #wayland
aswar002_ has quit []
aswar002 has joined #wayland
buh0 has quit [Quit: Bye!]
AndroUser2 has quit [Read error: Connection reset by peer]
<zamundaaa[m]>
I've tested the tearing protocol with both legacy and atomic modesetting before btw
<zamundaaa[m]>
With atomic on amdgpu, all that's needed is removing the check for the async flag and it works without any problems
AndroUser2 has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
<zamundaaa[m]>
I'm not quite sure about other drivers though, and if there could be interactions with overlay planes where things break
pac85 has joined #wayland
<pac85>
Wait what do you mean, where did you remove that check from? Did you make modifications to the driver itself?
<pac85>
Thought I really wonder how atomic commit is supposed to be atomic when doing async flips. I mean, usually it can update during the vblank right? If it's nor waiting for vblank then how can be changes be atomic?
<pac85>
How can the changes be atomic*
AndroUser2 has joined #wayland
<zamundaaa[m]>
"atomic" refers to how the API works, not to how display tech works
pac85 has quit [Read error: Connection reset by peer]
<kennylevinsen>
rip
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
pac85 has joined #wayland
<pac85>
Oh, I though the idea of the atomic api was to enable users to change things like offsets of multiple planes in a manner that appears simultaneous to the end user by queueing them all up before a vblank. So was that check introduced?
<pac85>
Why was*
<emersion>
at the very least we'd need a DRM_CAP_* to indicate whether this is supported
<emersion>
and yeah, need to check virtually all drivers which support ASYNC
<emersion>
zamundaaa[m]: how do you confirm that it works btw?
<emersion>
ie, how do you check that the flip is ASYNC, and not a regular flip?
mvlad has quit [Remote host closed the connection]
<zamundaaa[m]>
I used my now heavily outdated branch of KWin with the patched kernel and just looked if there was tearing
<pac85>
Did you check timing?
<pac85>
The time between the call to commit and the delivery of the event
<zamundaaa[m]>
The page flip event handler gets called pretty much immediately
<pac85>
Great
<zamundaaa[m]>
Much more importantly, measured input latency was within a single ms vs Xorg with tearing
<pac85>
Do you have that branch of kwin on your gitlab?