ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
feaneron has quit [Quit: feaneron]
fmuellner has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
co1umbarius has joined #wayland
Brainium has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
klausvalka has quit [Remote host closed the connection]
guru_ has quit [Ping timeout: 480 seconds]
klausvalka has joined #wayland
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
klausvalka has quit [Remote host closed the connection]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
klausvalka has joined #wayland
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
licktheroom has quit [Quit: Leaving]
guru__ has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
mxz__ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz_ has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
mxz_ has joined #wayland
kts_ has joined #wayland
kts has quit [Remote host closed the connection]
guru__ has joined #wayland
cvmn has quit [Read error: Connection reset by peer]
caveman has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
kts has quit []
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
rasterman has joined #wayland
sima has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
rv1sr has joined #wayland
kts has joined #wayland
glennk has joined #wayland
guru__ has joined #wayland
mart has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
ghishadow_ has joined #wayland
iomari891 has joined #wayland
ghishadow has quit [Ping timeout: 480 seconds]
ahartmetz has joined #wayland
kts has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
cmichael has joined #wayland
iomari892 has joined #wayland
kts has joined #wayland
iomari892 has quit [Read error: No route to host]
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
sally has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
ghishadow_ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
iomari891 has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
V has quit [Ping timeout: 480 seconds]
iomari891 has quit [Quit: WeeChat 4.2.1]
iomari891 has joined #wayland
f_ has joined #wayland
tshikaboom has joined #wayland
<pq>
If I were to make a binary distribution of Weston/DRM that should be as easy to use as "download one file and run it from a VT", what tech should I look at? Arch can be limited to x86_64.
<pq>
A statically linked binary would require significant changes that I'm not ready to do for now.
<emersion>
AppImage maybe?
cmichael has quit [Remote host closed the connection]
<pq>
cool, I got the same idea after seeing my accounting software using AppImage :-)
<pq>
another comment I heard made AppImage sound like... dead tech
<emersion>
something like docker would be a bigger hammer
<emersion>
maybe flatpak could work, but it has many unnecessary pieces
<emersion>
for this use-case
<pq>
can you access host logind and devices from inside such images?
<emersion>
you can configure the image to bind-mount what you need
<emersion>
i don't think sharing the GL impl would work too well though
<emersion>
maybe that's an upside or a downside for your use-case, i don't know
<pq>
I'm not sure I'd like to bundle Mesa. I might want to bundle Xwayland.
<emersion>
bundling Xwayland sounds annoying from AppImage
<pq>
why is that?
<pq>
and why would sharing GL impl (using the host libs+drivers?) have problems?
<emersion>
hm, maybe it's not that bad
<emersion>
sharing the GL impl seems complicated with docker
<emersion>
and can't be done with flatpaj
<emersion>
flatpak*
<pq>
because I'd have to bind-mount lots of arbitrary little bits for the docker image?
<emersion>
yeah, and the location of these things may vary depending on the linux distro etc…
<emersion>
and the libc might be different…
<pq>
I'd very much don't want to bundle libc. :-)
<pq>
ok, flatpak is out, then. Wait, do you mean that all flatpak apps will always use the Mesa hardware drivers from whatever flatpak runtime they use, never from host?
<emersion>
yes
guru_ has joined #wayland
<emersion>
🙃
<pq>
nevermind NVIDIA? :-P
<emersion>
i have no idea how that works with NVIDIA
<pq>
heh
<pq>
not that I'd care about NVIDIA, just curious
mvlad has joined #wayland
<pq>
so far sounds like AppImage would be the first thing to try
<emersion>
it seems like there is a NVIDIA runtime for flatpak
<swick[m]>
we generate a oci image for mutter/gnome-shell
<emersion>
i'm annoyed that this stuff is named "freedesktop" runtime
<emersion>
when it's flatpak-specific really
<swick[m]>
the runtime is very much not flatpak specific
<swick[m]>
it is literally just an ostree repo
<swick[m]>
and the buildstream definitions
<emersion>
hm, right
guru__ has quit [Ping timeout: 480 seconds]
<emersion>
nevermind then
Dami_Lu has quit [Remote host closed the connection]
<pq>
the one thing I am sure of, is that I would want users to be able to run their apps from the host under that packaged Weston.
Guru_DE has joined #wayland
<pq>
That's kind of the main point.
<pq>
so Wayland and X11 sockets need to be accessible from the host
guru_ has quit [Ping timeout: 480 seconds]
<pq>
how would that fit with the different techs?
Dami_Lu has joined #wayland
<emersion>
i think it should be fine regardless of tech
<emersion>
with containers, you can bind-mount XDG_RUNTIME_DIR and /tmp/.X11-unix
<emersion>
X11 might be an issue because of the user ns though
<emersion>
(heard issues from people trying to use gamescope in a container with userns)
<pq>
hmm, I'd have to get something like a terminal run on the host, connecting to Weston, after Weston starts. Can't do that from inside the image, I suppose.
V has joined #wayland
<swick[m]>
I develop mutter inside toolbx which is essentially just a podman container with a few things bind-mounted
<swick[m]>
and everything, including Xwayland works
fmuellner has joined #wayland
<pq>
interesting
<swick[m]>
eh, except KMS netlink because this is bound to the user and network namespace in a weird way
<swick[m]>
we really should get an eventfd based thing instead
guru_ has joined #wayland
<pq>
My goal here would be to let people test Weston's color-management features easily using their own apps, without needing to build and install anything. I doubt my target audience would bother if they need to install dependencies, let alone build things.
<swick[m]>
I even do more crazy things and use fedora silverblue OCI container as my base to develop mutter in and then boot into that via rpm-ostree
<swick[m]>
weston doesn't require integration with other things so that should be really easy as an OCI image
<pq>
ok, that sounds nice
f_ has quit [Ping timeout: 480 seconds]
<pq>
do you know of an OCI image tutorial where I could start? I know nothing for starters.
Guru_DE has quit [Ping timeout: 480 seconds]
<swick[m]>
usually people write Containerfiles for building OCI images and then you need to figure out how to invoke docker/podman to integrate with the host system
V has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
sally has joined #wayland
<pq>
I can find lots of write-ups on the topic, but it's hard to understand which ones would be good to follow.
iomari892 has joined #wayland
mclasen has joined #wayland
<colinmarc>
I think the easiest way is to start with an existing image for the OS you want (for example: https://github.com/gezp/docker-ubuntu-desktop). And then you can layer on the stuff you need, using what that dockerfile does as an example.
<colinmarc>
I haven't tried that image, just something I found googling.
<colinmarc>
I haven't seen an app use set_cursor with a dmabuf. should I go out of my way to handle that or just handle shm buffers for cursors?
<emersion>
i think GTK might use a DMA-BUF?
<emersion>
or is it for drag-and-drop icon only?
<emersion>
can't remember details
<emersion>
but in general i'd expect them to work
<pq>
colinmarc, your compositor would be deemed broken if it doesn't handle dmabuf, or sub-surfaces or wp_viewport or any other generic wl_surface thing also on the cursor role surfaces.
<colinmarc>
emersion: Ok, thanks. I can only run gtk apps via xwayland atm because I don't support drag and drop yet, and gtk apps crash on startup if you don't offer that global :)
<emersion>
that's unfortunate
<colinmarc>
pq: Hm, I didn't even think of subsurfaces. I think I can hook into my renderer which supports all that anyway - good that I didn't try to take a shortcut.
<pq>
colinmarc, heh, yeah
<pq>
Weston's renderer and backends do not even know that a surface might have a cursor role. They handle them all the same.
<mclasen>
we don't use dmabufs for cursor in gtk, no
<emersion>
i thought jadahl mentioned something about DMA-BUFs for DnD or something
<emersion>
but it was a long time ago, maybe just a plan, maybe i misremeber
<emersion>
mclasen: can you elaborate in your comment? it's not very clear to me what the issue is about
<emersion>
vyivel: well, mclasen's point is that with today's impls, it's not possible to have a perfect first frame on HiDPI
<vyivel>
ack
<ifreund>
can the compositor just not display the first frame the client commits?
<pq>
then the client would likely never display a second frame?
<emersion>
pq, the compositor can send a configure event, and wait for an ack
<ifreund>
the compositor would still send frame done, how would the client know?
<mclasen>
if you never show any frames, every frame will be perfect
<emersion>
frame done wouldn't let the compositor know when the client has handled the change
<emersion>
so a valid client could never send a new frame
<ifreund>
right, you need configure as well
<pq>
heh
<emersion>
still, sounds a bit annoying
<ifreund>
though frame done can be used to get the client to keep rendering new frames until the ack+commit
<emersion>
tbh i think a good guess will work in almost all cases
<ifreund>
emersion: sway and river already have excatly this code for their transaction systems...
<emersion>
right, frame is required to avoid stalling the client
<mclasen>
sounds like abusing frame to extend the initial configure negotation phase
<ifreund>
the client wouldn't even know it was happening or need to care, the compositor doesn't need to render a frame at the wrong scale
<ifreund>
sure it would be cleaner if this was solved at the protocol level in a nice way, but that doesn't seem to be the case
feaneron has joined #wayland
<ifreund>
also like I said, sway and river already do exactly this to make frame-perfect resize of many clients in a tiled layout work
<ifreund>
they send a configure to all clients being resized and then drop new frames until the compositor has a buffer of the new size for all clients
<emersion>
yeah, it's a normal thing to do
<emersion>
still not great to have the client have one useless render at startup
<ifreund>
for sure, it's ugly but it would work :D
<emersion>
but if it's only in the weird edge case that it happens, shrug
<emersion>
not sure it's worth to add more complexity to the xdg_toplevel setup just for that
<mclasen>
just to be clear - the problem in the gtk issue is not about rendering with the wrong scale. it is about determining the size of the surface
<emersion>
like a request for the client "i picked this initial size for my window", then wait for the compositor to send a scale
<emersion>
mclasen: the size of the surface is in logical coords, and so is the configure_bounds
<zamundaaa[m]>
emersion: the client making a request with a size and then having the compositor respond, instead of resizing just by doing it immediately is a thing that would be nice for other things
<emersion>
none of that depends on the scale
<emersion>
if the client depends on the scale internally, it can pick "1"
<mclasen>
yet, image viewers want to configure a size that lets them show the image 1-1 in device pixels
<mclasen>
and maximize the surface if that size is too big
<emersion>
zamundaaa[m]: how many roundtrips will it take to show a window? :D
<mclasen>
I did not make use case, but thats things people want to do with gtk
<emersion>
mclasen: thanks for bringing up that use-case, it's much easier to think about this problem with a use-case in mind
<emersion>
that would be useful stuff to add in a GitLab comment
<emersion>
zamundaaa[m]: what other things were you thinking about?
xjuan has quit [Remote host closed the connection]
<emersion>
d_ed, if it wasn't OK to workaround old APIs, wayland would have global window positioning
<emersion>
"there exists an API that assumes X11 concepts" is not super helpful, i'd say
d_ed[m] has joined #wayland
<d_ed[m]>
Nor is an API that only serves hypothetical clients.
<d_ed[m]>
Toolkits are our abstraction layer, if we don't supply what they need we haven't done our requirements analysis
<emersion>
what they need isn't necessarily the old APIs that are carried over from X11 times
<emersion>
hence my question about actual use-cases
<d_ed[m]>
Not X11 times, from the common denominator of every other windowing system
<emersion>
it is highly questionable how a regular app would use output layout info, in the context of a windowing system which doesn't let you know the position of your windows
<d_ed[m]>
I can guarantee I will have an application out there that doesn't want to be bigger than the screen as it has a check in there already.
<d_ed[m]>
I can guarantee I will have an application out there that defaults to 80% of the screen size.
<d_ed[m]>
It can't be faked
<emersion>
configure_bounds is the solution
<d_ed[m]>
No.
<emersion>
the screen size is not suitable anyways, if you have panels and other desktop UI elements
<emersion>
and which screen to use
<emersion>
it falls apart pretty quickly
<ifreund>
+1 configure_bounds is the only robust answer
<d_ed[m]>
Ok, tell me how to make configure_bounds work with the examples above changing only toolkit code and not the application code
<emersion>
Qt can add new APIs
<ifreund>
tell apps the output is the size of the configure bounds?
<emersion>
it should also be possible to have workarounds for old apps in Qt, yeah
<d_ed[m]>
that's not how it works IRL
<emersion>
expose only a single screen with the size in configure_bounds
<emersion>
well, it worked for GTK
<zamundaaa[m]>
ifreund: it's not that simple. Apps first look at outputs, then create a window
<emersion>
output layout API is mechanism
<emersion>
configure_bounds is policy
<emersion>
not the first time this happens
<zamundaaa[m]>
emersion: about "what other things were you thinking about?", the main benefit would be to be able to cleanly constrain clients to the output bounds when they don't do it themselves
<zamundaaa[m]>
As in, client suggests it wants a size bigger than the output, so the compositor can just say "no", and doesn't need to resort to hacks like not painting the wrongly sized frames until the client reacts to a resize request
<emersion>
but a good client shouldn't do this?
<zamundaaa[m]>
as you know, not every client is a good client
<emersion>
not sure it's worth adding that new roundtrip just for this
<emersion>
clients accept bug reports, in general
<zamundaaa[m]>
I could also imagine it would help with tiling. You get an idea for what size the client wants before you have to decide on a tile to put it in, and set the configure bounds accordingly
<emersion>
in tiling mode, the compositor dictates the size in configure
<emersion>
(not in configure_bounds)
<emersion>
but yeah, the point is still valid regardless
coldfeet has joined #wayland
coldfeet has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
V has joined #wayland
mclasen has joined #wayland
iomari891 has quit [Remote host closed the connection]
iomari891 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
f_ has quit [Remote host closed the connection]
f_ has joined #wayland
kts has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
feaneron has quit [Remote host closed the connection]
feaneron has joined #wayland
Arsen has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
mart has quit [Quit: Konversation terminated!]
iomari891 has quit [Remote host closed the connection]
iomari891 has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
iomari891 has quit [Remote host closed the connection]
iomari891 has joined #wayland
Arsen has joined #wayland
mriesch has quit [Remote host closed the connection]