ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
ecloud has quit [Remote host closed the connection]
ecloud has joined #wayland
The_Company has quit []
<immibis>
the_company, would that be wayland-yutani?
<immibis>
the first person to call a wayland project yutani is going to get some chuckles
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
epony has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 480 seconds]
tawonga has joined #wayland
epony has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
tawonga has quit [Quit: WeeChat 4.0.1]
Brainium has quit [Quit: Konversation terminated!]
<dv_>
from what I see, the best way to show an application fullscreen on a specific display is to just pass a wl_output of the desired display to xdg_toplevel_set_fullscreen () ?
<pq>
yup
tawonga has quit [Quit: WeeChat 4.0.1]
MrCooper has quit [Remote host closed the connection]
<dv_>
but I don't know how to get the wl_output instances
<dv_>
can this be done through XDG protocols?
<dv_>
or is there a recommended protocol for this? I know there are multiple obsolete protocols in wayland by now
<emersion>
wl_outputs are exposed as globals
MrCooper has joined #wayland
<dv_>
through the registry_global_handler ?
<dv_>
I mean, the `wl_registry_listener`'s `global` callback
MrCooper has quit [Remote host closed the connection]
<kennylevinsen>
Yes, the same place you get all your other globals.
<wlb>
weston/main: Christopher Obbard * libweston: Split dbus support into seperate build option https://gitlab.freedesktop.org/wayland/weston/commit/463ebda4e43c libweston/dbus/dbus.c libweston/dbus/meson.build include/libweston/meson.build libweston/meson.build meson_options.txt
<emersion>
oops, i let through a bad apple when doing wayland-devel moderation :/
<emersion>
sorry about that
* emersion
too used to accept anything that's not clearly spam
<emersion>
maybe we can just ban this person?
tawonga has joined #wayland
epony has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2023-07-14 11:13:52)]
nerdopolis has joined #wayland
<dv_>
hmm. so, I want to have an underlying video stream (through GStreamer's `waylandsink`) and a surface with LVGL controls painted in it on top, as an overlay. that overlay surface is translucent wherever there are no LVGL controls.
<dv_>
the common way to do that is to write an application that creates one toplevel window and hosts subsurfaces inside I guess.
<dv_>
but, in this case, the video stream comes from one process, and the LVGL controls come from another process.
<dv_>
is this still doable with subsurfaces?
<dv_>
or can the kiosk shell be used for this purpose by now?
<pq>
dv_, cross-process is not doable.
<pq>
you'd need a special-purpose compositor for that
<dv_>
and I can't have two fullscreen windows, right?
<dv_>
one as overlay of the other?
<pq>
correct
<dv_>
damnb
<dv_>
perhaps I could patch weston for this somehow
<pq>
why are they separate processes to begin with?
<dv_>
it is unfortunate that I can't maximize a window on a specific wl_output
<dv_>
why not? if I maximize two windows on top of each other, on the same wl_output, I get what I want
<dv_>
and this is an existing project where UI controls and video output are done by two separate components already - changing that now is not feasible
<pq>
but you couldn't control who is on top
<kennylevinsen>
And only the top one would be visible
<dv_>
isn't there a z value for this?
<dv_>
hang on, I remember having done this in the past
<pq>
no z value that you could control from outside of the compositor
* dv_
looks
<dv_>
ah, yeah, I had to patch weston back then to explicitly move the "video" surface to the bottom of the stack
<pq>
if you cannot merge the two client processes, then you need a special-purpose compositor that knows the special window management rules you need
<pq>
patching Weston sound like a possibility indeed
<kchibisov>
I think the only protocol allowing z order is layer-shell.
<kennylevinsen>
You could do with less than a full compositor if you import all your buffers into one of the processes, or into a third process.
<pq>
I'm kinda guessing this is not a desktop use case at all, and the said patched weston could just run on DRM, which might be the quickest to get to work.
<dv_>
right - this runs on an imx8m plus
<dv_>
I did a vaguely similar project about a year ago, which is where I did patch weston to do what I said with the video surface. the UI there was done with Qt's QML, with a translucent borderless maximized window.
<dv_>
here, the added difficulty is that I now have 2 screens attached, and for each one of them, there needs to be a video surface and a UI window overlayed on top
<dv_>
the third process does sound interesting, but would require significant refactoring
<pq>
Is Qt not able to embed a GStreamer "widget" without causing copies or loss of direct scanout?
<dv_>
I tried that in the past, but this is potentially problematic, since then, all of the heavy weight compositing is 100% done by the GPU's 3D core
<dv_>
which can be suboptimal performance-wise
<pq>
I very much meant avoiding the GPU
<dv_>
(this is specific to imx, which has the rather slow vivante GPUs)
<dv_>
I am not aware of Qt supporting direct scanout like this
<pq>
all it needs is a sub-surface
<pq>
waylandsink might even be creating a sub-surface itself
<pq>
I'm not sure
<dv_>
passing on subsurfaces did not work well the last time I tried. but, note that Qt was used in that past project. it is _not_ used in this new one.
<dv_>
this new project uses LVGL for its UI controls.
<pq>
I've never heard of LVGL before.
<dv_>
but, hmm - perhaps I can adjust its wayland driver to allow for passing a subsurface into it
<dv_>
but, ah, no, subsurfaces only work within the same process
<pq>
or more like getting the window's wl_surface out, so you can ask Gst waylandsink to nest in that?
<pq>
yes, everything is always same-process, same connection
<dv_>
nesting only works with subsurfaces, does it?
<pq>
I'm suggesting to use waylandsink from inside the UI process
<pq>
nesting?
<dv_>
<pq>or more like getting the window's wl_surface out, so you can ask Gst waylandsink to nest in that?
<pq>
you have to look into the Gst API which way it works
<dv_>
I was asking in general that "nesting" a surface into another surface is only possible through subsurfaces, right? there is no other mechanism?
<pq>
you can also write your own Gst plugin to get the dmabuf and handle the Wayland side yourself, if nothing existing seem to suit
<pq>
right, for a single window, sub-surfaces are the way
<dv_>
hm okay. so, my options are:
<pq>
you could have multiple windows, like popups or related dialogs, but that's not really fitting here I think
<dv_>
1. customize weston to allow for maximizing windows on specific wl_outputs, with video surfaces always being put at the bottom
<pq>
strike "allow for", you can simply force it
<dv_>
2. establish some form of IPC between the processes to send frames (ideally with dma-buf) to the process that runs the UI controls and place waylandsink in there to show these frames
<pq>
and you can identify windows by app_id I think
<pq>
if you are going to patch weston, you don't need the controls window maximized anymore either, you can just make weston put it where you want it
<dv_>
the added complication here is that I have to use NXP's weston fork :(
<pq>
I'm sorry.
<dv_>
which hopefully is less crappy in version 10
<dv_>
the 8.x fork was awful
<pq>
that IPC could be Wayland, too
<dv_>
I'm even considering pipewire atm, since the source frames come from a V4L2 capture
<pq>
oh, that sounds good
<pq>
so, why is the video thing in a separate process?
<pq>
why not use Gst straight from the UI process?
<dv_>
this project was not started by me. they made it that way because initially they sent frames through a named pipe to the UI process.
<dv_>
I guess they wanted to fully establish separation of concerns and such.
<dv_>
ah, nah, wait, strike that. confused it with a different detail.
<pq>
what is that video process doing? Presumably more than just getting frames from V4L2 and sending to the UI process?
<dv_>
no, so far, they just rendered without weston, straight to KMS, and the whole overlay thing is marked as a TODO
<dv_>
it is doing color correction
<dv_>
but at this point I do agree that at least splitting this pipeline into multiple parts is the way to go
<pq>
yes, you cannot have multiple processes driving KMS planes on the same device at the same time - yes, I know some vendors did that by hacking the kernel to allow it
<pq>
separation of concerns is nice, if the concerns are actually separable
<dv_>
okay. I'll propose these changes to the others.
<dv_>
on a sidenote, isn't this kind of use case a rather commonly found one? UI done by one process, video by another?
<dv_>
I though this is part of why the kiosk shell exists
<daniels>
pH5: your weston pipelines are failing because shared runners are disabled for your fork - any reason in particular?
<pq>
dv_, kiosk-shell only forces whatever single window is on top to be fullscreen. It doesn't combine multiple clients into a single app.
eroc1990 has quit [Ping timeout: 480 seconds]
<dv_>
true, but to me, it sounds like it would be a natural improvement for the kiosk shell
<dv_>
to allow for easy VCR style overlays even with multiple processes
<dv_>
or does anything design wise speak against that idea
<dv_>
?
<pq>
dv_, it's not possible to combine multiple clients into a single app in general, because the rules of positioning each window depend on the use case. You need to be able to modify the window management rules as well. For that, the idea for Weston is "Lua shell".
<pq>
the only design decision speaking against that is the desktop paradigm - you don't do that on desktops. But since this is not about desktops, it doesn't apply.
<pq>
it's just a lack of interfaces to let you easily script what you need
<dv_>
but do you use a kiosk shell on desktops?
<dv_>
and, lua shell, interesting
<pq>
kiosk-shell not a regular desktop, but I guess it would be described as a special desktop lacking multi-app support.
<daniels>
right, kiosk-shell is there for the usecase of fullscreen apps and nothing else
<pq>
A desktop kind of implies that you can open and see multiple apps at the same time.
<dv_>
I associate flexible window arrangements and user driven navigation through said windows with "desktop"
<pq>
and kiosk-shell only shows one app per output at a time
<pq>
yes
<pq>
kiosk-shell has none of that
<dv_>
2 maximized/fullscreen surfaces on top of each other, without the user being able to arrange them at all, that is not desktop
<dv_>
so I guess what I am referring to is a "kiosk+"
eroc1990 has joined #wayland
<pq>
Lua shell is still just a concept, but the idea is that you script your window manager a lot more easily than hacking on C code
<dv_>
are there any known projects ongoing that aim to implement something like that? or have these been abandoned or not even started, instead focusing on the lua shell concept?
<dv_>
I'm making notes for something I could potentially work on in the future, hence that question
<dv_>
because this is not the first time I've had this usecase, and I strongly suspect I'm not alone with this
Lennon_ has quit [Quit: Lost terminal]
<pq>
I only know about Weston, and the plan there is Lua shell.
<pq>
all the details in that issue are probably outdated, but that would be the ticket to follow
<pq>
dv_, daniels might be able to tell you more about Lua shell if you're interested in maybe developing it.
nerdopolis has quit [Ping timeout: 480 seconds]
Kerma has joined #wayland
<pH5>
daniels: I hit not-enough-privileges in runner-gating.sh when I enable it. I think disabling runners was a partial attempt to disable those CI failures, I got distracted by something else.
<daniels>
pH5: oh right - fixed now
<kennylevinsen>
Heh, not enough? "You need to collect at least 10 privileges to open this door!"
MrCooper has quit [Remote host closed the connection]
kts has joined #wayland
<dv_>
daniels: the concept of lua-shell sounds interesting. but no proof of concept exists yet?
MrCooper has joined #wayland
<pH5>
daniels: ty
<pH5>
kennylevinsen: the error message did not specify the required amount :)
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
pieguy128 has joined #wayland
Guest5815 has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
Kerma has quit []
MrCooper has joined #wayland
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
MrCooper has joined #wayland
mtretter is now known as mtr[afk]
mtr[afk] is now known as mtretter
<wlb>
weston/main: Philipp Zabel * libweston: Add output parameter to weston_renderer::flush_damage() https://gitlab.freedesktop.org/wayland/weston/commit/155fa3a56a72 libweston/ compositor.c libweston-internal.h noop-renderer.c pixman-renderer.c renderer-gl/gl-renderer.c
<emersion>
jadahl: hm, so, we discussed with d_ed about whether window geometry would make sense for layer-shell, and as a result i have a xdg-shell question for you
<emersion>
on one hand, the window geometry is defined as the "visible bounds"
<emersion>
on the other hand, it's defined as being used for aligning/constraining/etc the surface
<emersion>
so, what would be the proper window geometry for, say, weston-flower
<emersion>
let's say i want weston-flower to snap to the edge of the screen, but not exactly at the flower's edge: i want to leave a bit of transparent margin
<emersion>
let's say a compositor implements window border snapping, i want other windows to snap at weston-flower, but with a bit of transparent margin
<emersion>
with that in mind, what is the proper window geometry for weston-flower? exactly match the flower border? or leave a bit of space?
<emersion>
(the "real" use-case would not be weston-flower, but a macOS-style dock)
<emersion>
basically: is the "visible bounds" a suggestion, or a requirement?
<leon-p>
emersion: btw thanks for working on this again. Probably super annoying with all the nitpicks and different opinions, mine included. So just wanted so say that your efforts on this are appreciated!
<emersion>
<3
jmdaemon has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tzimmermann has quit [Quit: Leaving]
heapify has joined #wayland
heapify has quit [Quit: heapify]
heapify has joined #wayland
heapify has quit [Quit: heapify]
heapify has joined #wayland
<jadahl>
emersion: I'd say having an invisible margin around weston-flower within the "window geometry" is "fine" if the intention is to pretend that is the intended "window". don't know how the dock in macosx works though, haven't used a mac for a decade so my memory is blurry
<jadahl>
the shadow is "visible" so using a strict interpretation of "visible bounds" is already wrong
<emersion>
jadahl: basically it displays a bunch of icons on the bottom of the screen, and maximized windows stop some distance away from the icon edges
<jadahl>
using an enlarged window geometry seems fine for that. having to add padding and margin sounds annoying
<emersion>
okay
<jadahl>
you'll end up with DOM+CSS if you don't stop at the door :P
<emersion>
aha
<emersion>
well, the question was whether we'd re-use this in layer-shell, or whether we'd use a separate concept
<jadahl>
I guess that is the alternative? a separate padding/margin?
<emersion>
yeah, something decoupled from xdg_surface.set_window_geometry's semantics
<jadahl>
can you think of any reason why just using the window geometry would not work?
<emersion>
well, i am not sure it is the right tool for the job
<emersion>
are we mis-using or abusing it?
<jadahl>
true
<jadahl>
or using it? not sure
<emersion>
also, set_window_geometry cannot go outside the bounds of the surface tree
<jadahl>
panel padding is not the original intention, I guess, but it's also a rather trivial piece of data. "inside is mine, outside is fluff"
<jadahl>
true, that is perhaps an issue
<emersion>
in the dock case, the space above the dock might not be the surface
<jadahl>
then you'd need to enlarge the surface too. a bit ugly
<emersion>
yeah, wouldn't be the end of the world
<emersion>
i wonder if there are more pathologic cases
<jadahl>
solid pixel of 0,0,0,0
<emersion>
:D
<jadahl>
are there any situations where you want to have some things align to a "inner" margin, and some other to an "outer"?
<jadahl>
e.g. you want "window geometry" to be as small as possible (e.g. touch the edge for weston-flower), and some other things touch the enlarged one only?
<emersion>
hm
<emersion>
i can't think of anything right now, but will keep thinking
heapify has quit [Quit: heapify]
<jadahl>
did anyone take notes from the call some days ago btw? I missed it
heapify has joined #wayland
heapify is now known as Guest5994
heapify has joined #wayland
Guest5994 has quit [Ping timeout: 480 seconds]
heapify has quit [Quit: heapify]
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #wayland
_DOOM_ has joined #wayland
<_DOOM_>
Is there any reason why, as a client, we wouldn't want to use libwayland-server?
<jadahl>
a client using libwayland-server to act as its own wayland server to some other client is perfectly supported
<orowith2os>
_DOOM_ as *just* a client, it's not useful
<_DOOM_>
Not even for that
<_DOOM_>
I mean there are some useful stuff in there I mean.
<orowith2os>
if you're doing something like gamescope, where you're a client of a compositor and a server to some other app, you'd want to use it
<orowith2os>
huh
<_DOOM_>
wl_signal, wl_listener, wl_event_loop.
<_DOOM_>
I feel like even as just a client these are pretty useful.
<_DOOM_>
I guess I was just wondering if for some reason libwayland-client and libwayland-server are somehow incompatible. I guess I was just checking for unknown unknowns.
natewrench has joined #wayland
natewrench has left #wayland [#wayland]
natewrench has joined #wayland
natewrench has left #wayland [#wayland]
<orowith2os>
_DOOM_ aren't the two structured differently, and have different ways of representing stuff? Rereading some bits of the docs, libwayland-server has a more server-like way of doing things, libwayland-client is structured better for the client-side of things?
<_DOOM_>
I've looked at the code.
<_DOOM_>
They don't appear to represent things differently in code.
<_DOOM_>
Although I understand what you mean.
<orowith2os>
the protocol that's specified seems pretty different for both ends