ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
guru_ has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
Guru_DE has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
checkfoc_us has quit []
checkfoc_us has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
Ojus1_ has quit [Remote host closed the connection]
CME has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
ShapeShifter499 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
jlco_ has quit []
jlco has joined #wayland
ShapeShifter499 has quit [Remote host closed the connection]
ShapeShifter499 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nurupo has quit [Quit: nurupo.ga]
glennk has joined #wayland
nurupo has joined #wayland
nurupo has quit [Remote host closed the connection]
privacy has quit [Remote host closed the connection]
julio7359 has quit [Ping timeout: 480 seconds]
alice has quit [Remote host closed the connection]
<pq>
Company, because we cannot version wl_buffer and so cannot add anything in it, it has multiple independent factories. OTOH, a buffer is not inherently transformed, but the content may or may not be. For a square buffer, changing transformation does not imply a re-allocation.
<Company>
that's a question of your mental model of what a buffer is
iomari891 has quit [Read error: Connection reset by peer]
<Company>
ie if you think about it more like vkMemory or more like vkImage
<pq>
indeed, I think that should answer your question, too
<Company>
that reminds me: does EGL (or GL) have an equivalent of VkSwapchain.preTransform?
<Company>
and also, does Vulkan take ownership of the Wayland buffer transform or is that the application's job?
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
<zzag>
daniels: gentle reminder about the governance meeting :)
<daniels>
zzag: oh thanks but I can’t actually make it today in the end
<daniels>
have fun though :)
<zzag>
okay no problem :)
privacy has quit [Quit: Leaving]
nerdopolis has quit []
iomari891 has joined #wayland
kts has joined #wayland
privacy has joined #wayland
CME has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
CME has joined #wayland
tkna has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<tkna>
Hi. Someone said this. Is it true? If a certain DAW is made by Wayland, is it not possible to use X11 plug-ins? Or is it very difficult? `you just can't draw a X11 window from inside the Wayland window/app` https://forum.cockos.com/showpost.php?p=2726617&postcount=20
<tkna>
kennylevinsen: I see. So it is not possible to have direct exchange of audio, MIDI, or other data in general, or to have parent-child relationships for windows, etc.? Perhaps it is inevitable, but it still means that third-party plug-in makers will have to switch to Wayland individually. thanks.
<kennylevinsen>
tkna: Wayland does not concern itself with anything other than graphics and input, and you cannot have relationships between Wayland and X11 windows
<pq>
tkna, parent-child window relations are not possible between Wayland-native and X11 windows. I did not expect audio, MIDI or other to go through X11 though, do they?
<pq>
I mean, they could, but with lots of pain, and why...
<mclasen>
for whatever reason, DAWs are the stronghold of xembed like approaches
<pq>
sure, but the they use X11 also for audio for some reason?
<pq>
*do they
<mclasen>
not that I know
<pq>
good
<kennylevinsen>
that would have been horrifying :)
<pq>
If it could be done with X11... Maybe not audio data per se, but perhaps routing addresses as window properties or something?
<pq>
I can actually imagine that
<tkna>
Even though it is not possible to have a parent-child relationship for windows, Audio and MIDI can be exchanged via JACK, etc., so it would be possible to use Xwayland's DAW to exchange data. It may be very difficult to operate, but not impossible.
<pq>
pulling virtual audio cables between windows of two different apps, and have them even drawn.
<pq>
tkna, yes, JACK and everything else not using X11 should work just like before.
<tkna>
Probably after 2-10 years of use together, the major plug-ins will generally be Wayland. After that, if you still want to use good old X11 plug-ins, you can use XWayland's DAW. That's probably going to be the overall policy or situation.
<tkna>
I am convinced. We can use them together. It seems I don't have much to fear. Thank you kindly.
<ofourdan>
you cannot run a rootless Xwayland by yourself, only the Wayland compositor can.
<ofourdan>
(you can run a rootful Xwayland though)
<ofourdan>
I mean, you *can*, it won't error out, but it won;t do anything as you already found out.
<carbonfiber>
Why can't I do it manually? (assuming the wayland compositor is already running). I don't understand why I can't just use/write the exact same command that the wayland compositor (mutter) uses.
<pq>
The Wayland compositor needs to know to connect to the rootless Xwayland to act as its X11 WM. Otherwise no X11 window can be visible.
<ofourdan>
because Xwayland is a prett ystandard Xserver, and requires a window manager
<pq>
You cannot use a regular X11 WM with a rootless Xwayland either, because only the Wayland compositor can show windows.
<carbonfiber>
hmm.
<Company>
pq: the DAW world works just like the video player world - the client library/plugin hands an XID to the DAW and it does with it what it needs to integrate it
<carbonfiber>
So my thought process was to start a rootless Xwayland, and then start the mutter x11 window manager (which is automatically used when --no-x11 is NOT specified).
<Company>
pq: the whole sound setup is using a different channel - the same channel that's used to exchange the XID pretty much
<carbonfiber>
I thought that the wayland compositor just communicated with Xwayland, with the x11 window manager just being another x11 application. But based on what you have written this seems to not be the case. Does the wayland compositor communicate with Xwayland, or with the "Xwayland window manager", or both?
<ofourdan>
carbonfiber: fwiw, mutter / GNOME Shell already has Xwayland on demand (i.e. it won;t spawn Xwayland until some X11 client needs it), and also have optionally terminate Xwayland whel X11 cleints are gone (that's an experimental feature tht needs to be explicitely enabled though)
<Company>
pq: note that this sometimes is in-process and sometimes it's out-of-process - which makes this real funny when you're in-process and your audio plugin draws its UI with GLX while your DAW is using EGL
<kennylevinsen>
carbonfiber: The Wayland server is the x11 window manager when running X11, as it needs to afford Xwayland some special privileges not normally available to Wayland clients
iomari891 has quit [Read error: Connection reset by peer]
<kennylevinsen>
As well as to integrate with the general window management within the Wayland server
<pq>
Company, that's good. Things could have been worse. I can imagine that some might desire the ability to late windows of virtual devies, and then connect virtual wires between them. Oh, but that would require alpha... no, shaped windows for the wires. Seems doable. :-)
<ofourdan>
carbonfiber: with Wayland, the X11 window manager is the same process as the Wayland compositor - Xwayland is a pretty standard Wayland client, and as such it doesn't access to global coordinates for example, or stackign of windows, all that X11 mechanisms rely on X11 and as such, it requires to be handled by the Wayland compositor which is the only one with a global vision over both X11 and Wayland
<pq>
"late"? uhh... "have", I think
<ofourdan>
surfaces to inter-mix them on screen, as with rootless.
<Company>
pq: I think they stopped doing that once they had to support multiple sound servers, and that was way before jack, so very long ago
<kennylevinsen>
clearly what the protocol needs is the ability to attach an arbitrary 3D model onto which the surface will be texture mapped
<kennylevinsen>
so you can shape your window as a 3d dangling cable
gutest has joined #wayland
<Company>
I think the proper way to handle this today with Wayland is the same way browsers do it
<pq>
Company, I see, I'm just late to the party. So that's what the "late" was! My hands know more than me.
gutest has quit []
<Company>
run an embedded nested Wayland server in the DAW
<Company>
pq: I started my free software career as a GStreamer developer, I still have the scars from that time ;)
<pq>
yeah, a tall order - why not stick to Xwayland?
<Company>
I am very sure they are gonna run a nested wayland compositor *with* XWayland
<pq>
I don't doubt that, but what do they gain from the migration to Wayland?
<Company>
a better platform
<pq>
they hate graphical glitches too, or?
<Company>
no, they use xembed
<pq>
point
<pq>
what makes Wayland attractive then?
<Company>
1. it's maintained
<Company>
2. it has the modern features, like fractional scaling and such
<Company>
i don't think it's gonna happen quickly, it's not that interesting, but it's gonna happen at some point
<pq>
right. Do they need to follow the toolkits they use?
<Company>
as long as they don't want to use external processes
<Company>
well, that came out wrong
<carbonfiber>
hmm. when running "mutter --wayland" I have 2 processes running. "/usr/bin/mutter" and "/usr/libexec/mutter-x11-frames", so I thought that "/usr/bin/mutter" was the wayland compositor, and "/usr/libexec/mutter-x11-frames" was the x11 window manager. But know you say that it all runs in a single process. Then why does ps show 2 processes?
<pq>
just wondering what is mostly producing the pressure, is it a stick or a carrot
<Company>
there's 2 things they need to weigh: plugins may use the same toolkit
<Company>
and their UI may want to use newer versions of the toolkit
<carbonfiber>
but now you say*
<Company>
at this stage I think it's carrot
<ofourdan>
/usr/libexec/mutter-x11-frames is just a helper application to reparent X11 windows (i.e. decorate them) usign gtk4
<pq>
good, a stick would be bad PR
<ofourdan>
(/usr/libexec/mutter-x11-frames is not an X11 WM, mutter is)
<Company>
pq: the GTK DAWs have all updated to GTK4 - unless you count Ardour, which has (first soft, then hard) forked GTK2 and been doing their own UI toolkit
<Company>
no idea what Qt version the Qt ones are on
<carbonfiber>
if it is all a single process, then it makes sense why I cannot launch a "mutter Xwayland window manager" afterwards.
<carbonfiber>
thanks for the help.
<ofourdan>
np!
cmichael has quit [Quit: Leaving]
<MrCooper>
pq: FWIW, once upon a time, some people were pushing for making the X server also a sound server, kind of like pipewire from hell :/
<ofourdan>
hahum, some even managed to make it a print server :)
<MrCooper>
right, which at least has some overlap with other X functionality :)
<ofourdan>
lol
<ofourdan>
I still wonder why it was removed…
<MrCooper>
people got bored of measuring glxgears performance in pages per minute? ;)
<ofourdan>
I'm sure that has to do with saving trees or something!
mart has quit [Quit: Konversation terminated!]
rv1sr has joined #wayland
kts has joined #wayland
rv1sr has quit []
coldfeet has joined #wayland
kts has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
kts has joined #wayland
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
iomari891 has quit [Read error: Connection reset by peer]
ecloud has quit [Read error: Connection reset by peer]
dos1 has quit [Read error: Connection reset by peer]
Sid127 has quit [Write error: connection closed]
bookworm has quit [Read error: Connection reset by peer]
pitust has quit [Remote host closed the connection]
lockywolf has quit []
Sid127 has joined #wayland
rpigott has quit [Read error: Connection reset by peer]
aleasto- has joined #wayland
elibrokeit_ has quit [Read error: No route to host]
bookworm_ is now known as bookworm
dottedmag has quit [Read error: No route to host]
dottedmag_ is now known as dottedmag
JoshuaAshton has quit [Read error: Connection reset by peer]
tsujp has quit [Ping timeout: 480 seconds]
cpli has quit [Ping timeout: 480 seconds]
tsujp_ is now known as tsujp
cpli_ is now known as cpli
ecloud has joined #wayland
staceee has quit [Ping timeout: 480 seconds]
aleasto has quit [Ping timeout: 480 seconds]
Guest4265 has quit [Ping timeout: 480 seconds]
Brainium_ has quit [Ping timeout: 480 seconds]
pitust has joined #wayland
raghavgururajan has joined #wayland
raghavgururajan is now known as Guest515
JoshuaAshton has joined #wayland
tzimmermann has quit [Quit: Leaving]
Narrat has joined #wayland
Brainium has joined #wayland
<ofourdan>
is that an hidpi screen?
Brainium has quit [Read error: No route to host]
<ofourdan>
anyway, I think this is mutter setting that cursor (mutter running within the rootful Xwayland instance), I dunno how exactly mutter decides on the size of the cursor.
fmuellner has quit [Remote host closed the connection]
aleasto has joined #wayland
Guest515 has quit [Read error: Network is unreachable]
aleasto- has quit [Read error: Connection reset by peer]
xantoz has quit [Remote host closed the connection]
xantoz has joined #wayland
JEEB has quit [Remote host closed the connection]
fmuellner has joined #wayland
JEEB has joined #wayland
tsv has quit [Remote host closed the connection]
rasterman has quit [charon.oftc.net helix.oftc.net]
JEEB has quit [charon.oftc.net helix.oftc.net]
paulk has quit [charon.oftc.net helix.oftc.net]
wb9688 has quit [charon.oftc.net helix.oftc.net]
rajveermalviya[m] has quit [charon.oftc.net helix.oftc.net]
danburd[m] has quit [charon.oftc.net helix.oftc.net]
elinor has quit [charon.oftc.net helix.oftc.net]
tsv has joined #wayland
elinor has joined #wayland
danburd[m] has joined #wayland
rasterman has joined #wayland
paulk has joined #wayland
JEEB has joined #wayland
wb9688 has joined #wayland
rajveermalviya[m] has joined #wayland
raghavgururajan_ has joined #wayland
<Company>
maybe try running yet another rootful XWayland inside that rootful XWayland?
<Company>
just to see what the cursor does?
<vyivel>
🤔 xwayland in xwayland would be just xx
<vyivel>
(xephyr)
Brainium has joined #wayland
mart has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<carbonfiber>
ofourdan: not hidpi. it is a 1200x800 screen using the vmware svga driver in virtualbox.
<Company>
stupid nested wayland compositors don't inherit the large cursor sizes
<ofourdan>
e.g. gsettings set org.gnome.desktop.interface cursor-size 16
<carbonfiber>
that seems likely to also change the cursor size of the "outer mutter instance".
<ofourdan>
yes, likely
<ofourdan>
or maybe you need to run gnome-settings-daemon to apply the gsettings
<ofourdan>
(I mean within the nested Xwayland instance)
<ofourdan>
ah, my bad, it's started by dbus nowadays
<ofourdan>
so maybe it's just a matter of running a dbus session in the nested Xwayland instance
<ofourdan>
(it's what xwayland-run does, btw)
<carbonfiber>
hmm ok. changed org.gnome.desktop.interface cursor-size to 1 just for fun lol
<carbonfiber>
did not have the expected results
<ofourdan>
that's a bit extreme!
<carbonfiber>
it did not change the cursor size of the "outer mutter instance" at all. but actually made the cursor inside of Xwayland have the same size as the "outer mutter instance". I don't know why that works at all lol.
<carbonfiber>
so it fixed it haha
rasterman has quit [Quit: Gettin' stinky!]
<ofourdan>
fwiw, mutter running in a nested Xwayland rootful instance tendst oappl ythe xrandr config from the host, so you end up with an Xwayladn rootful window as large a your actual physical setup...
<ofourdan>
anyway, g'night!
<carbonfiber>
good night
ghishadow has joined #wayland
<emersion>
jadahl, pq: should we plan a new wayland release soon?
<emersion>
i can send out a tentative release schedule if so
<emersion>
it's been a while and many pending MRs have been merged or are in a good position to be merged soon
<Company>
I'm mostly wondering if I can assume a ~25% perf drop as a rule of thumb for direct scanout failing on high gpu load
<jadahl>
emersion: sounds like a good idea
<jadahl>
Company: could be. not sure why it'd fail. or perhaps kwin is better at retrying
<Company>
it's shell 42, so who knows
<Company>
I'm mostly wondering because of GTK's GraphicsOffload and trying to use it for GL
<Company>
would be a neat way to detect it via the fps
<Company>
it could also be that source tries drm leasing and then doesn't properly fall back to direct scanout
mart has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
Narrat has quit []
rv1sr has quit []
the_sea_peoples has joined #wayland
<zamundaaa[m]>
Company: direct scanout most definitely doesn't have a 25% perf impact
neniagh has joined #wayland
<Company>
zamundaaa[m]: any guess what would be causing that difference?
<zamundaaa[m]>
The best guess I have is that there's lots of things adding together. Like, a worse format+modifier + no direct scanout + probably more, because I wouldn't expect those two things to crack even 10%
the_sea_peoples has quit [Quit: WeeChat 2.8]
the_sea_peoples has joined #wayland
Guest395 has quit []
cool110 has joined #wayland
cool110 is now known as Guest543
ghishadow has quit []
ghishadow has joined #wayland
carbonfiber has quit [Quit: Connection closed for inactivity]
feaneron has quit [Quit: feaneron]
noord has joined #wayland
noord_ has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
julio7359 has joined #wayland
vaxry was kicked from #wayland by ChanServ [Banned from FDO per CoC team decision]