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 quit [Ping timeout: 480 seconds]
systwi_ has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
c7s has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: Konversation terminated!]
uu has joined #wayland
Seirdy has joined #wayland
uu has quit [Remote host closed the connection]
uu has joined #wayland
uu has quit [Remote host closed the connection]
testuu has joined #wayland
testuu has quit [Remote host closed the connection]
testuu has joined #wayland
testuu has quit [Remote host closed the connection]
testuu has joined #wayland
testuu has quit [Remote host closed the connection]
danshick has quit [Remote host closed the connection]
danshick has joined #wayland
danshick has quit [Remote host closed the connection]
danshick has joined #wayland
jgrulich has joined #wayland
lromwoo^ has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
astlep has joined #wayland
hardening has joined #wayland
dcz_ has joined #wayland
mvlad has joined #wayland
mtretter has quit [Quit: leaving]
mtretter has joined #wayland
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
lsd|2 has joined #wayland
lsd|2|2 has joined #wayland
lsd|2 has quit []
Telvana has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
danvet has joined #wayland
Telvana has joined #wayland
anarsoul|2 has joined #wayland
erc_ has quit [Remote host closed the connection]
erc_ has joined #wayland
dri-logg1r has quit [Remote host closed the connection]
rektide has quit [Remote host closed the connection]
rektide has joined #wayland
dri-logger has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
GentooPhysicist3935 has quit []
mclasen has quit []
Telvana has quit []
GentooPhysicist3935 has joined #wayland
mclasen has joined #wayland
Telvana has joined #wayland
agd5f has quit [Remote host closed the connection]
tlwoerner has quit [Remote host closed the connection]
agd5f has joined #wayland
Satan has quit [Quit: Ping timeout (120 seconds)]
tlwoerner has joined #wayland
Satan has joined #wayland
Ariadne has quit [Remote host closed the connection]
pieguy128_ has quit []
pieguy128 has joined #wayland
Ariadne has joined #wayland
manuel1985 has joined #wayland
c7s has joined #wayland
dv_ has joined #wayland
<dv_>
is it OK/valid to copy extension spec XMLs into my own project instead of directly accessing those from the wayland-protocols package?
<dv_>
for example, gstreamer's waylandsink accesses wayland-protocol XMLs via pkg-config, while Qt IIRC has its own copy of XMLs ... is there a recommendation which approach to generally prefer?
<kennylevinsen>
For those in wayland-protocols one usually uses the system version, but it's common to vendor XML files of not yet upstreamed or custom protocols. As long as the wayland-scanner version used matches libwayland, it'll work all the same.
<jadahl>
dv_: just don't make the mistake of vendoring unmerged wp_, xdg_ or ext_ prefixed protocols, as that prevents them from reaching wayland-protocols
<emersion>
also don't vendor the generated files
<dv_>
I just take xml files from the stable release
<dv_>
well, I mean from a versioned wayland-protocols release
<dv_>
some xmls I need are from the unstable/ folder
<pq>
dv_, if you take it from wayland-protocols upstream, it's fine.
<pq>
if you take it from anywhere else, then care is needed to not cause trouble to upstream
<pq>
and by wayland-protocol upstream I mean the main branch or any release. Not yet merged MRs don't count.
<pq>
dv_, so feel free to vendor in a whole wayland-protocols release, if you want.
rasterman has joined #wayland
erc has joined #wayland
erc_ has quit [Read error: Connection reset by peer]
c7s has quit [Remote host closed the connection]
c7s has joined #wayland
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
vyivel has quit [Read error: No route to host]
vyivel has joined #wayland
<elibrokeit>
dv_: I've polished over the rough edges in meson, so it should now be reasonable to simply add wayland-protocols itself as a Meson subproject and look them up via pkg-config as normal
flacks has quit [Quit: Quitter]
<elibrokeit>
so it is both vendored and guaranteed to use the correct upstream version
flacks has joined #wayland
lromwoo^ has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
<dv_>
cool
<dv_>
unfortunately though I have to use qmake in this particular project. but perhaps I can convince them to switch over to meson. they use qt heavily though.
fmuellner has joined #wayland
<dv_>
is it somehow possible to set a surface to always be on top of others?
<dv_>
didn't see anything in xdg_wm_base for this
<pq>
a compositor can do that, but I'm not aware of a client request
<dv_>
alternatively, is it possible to set a surface to always be *below* others?
<pq>
for compositors that happen to implement it, yeah
<kennylevinsen>
xdg shell clients intentionally have very limited control over compositor policy, and only really control what's going on in their window
<kennylevinsen>
And layer-shell is only intended for "special" clients, like system bars, launchers or other desktop environment widgets - normal apps should just let the compositor/user control things. :)
<dv_>
I absolutely need a video surface below UI elements
<pq>
a video surface from a separate process?
<dv_>
separate thread
<pq>
use sub-surfaces
<pq>
and share the same wl_display
<dv_>
not an option. the UI is created by Qt5.
<pq>
Qt5 doesn't let you create sub-surfaces?
<dv_>
and qt5 does not allow its UIs to be integrated into existing subsurfaces.
<dv_>
turning its widgets into subsurfaces did not work reliably
<pq>
what about the opposite?
<dv_>
the only thing that works is to set the Qt5 UI to be transparent and overlay it on top of a video surface
<pq>
let Qt5 drive its GUI totally, but ask it for a sub-surface for your own purposes?
<dv_>
<dv_>turning its widgets into subsurfaces did not work reliably
<dv_>
already tried
lromwoo^ has joined #wayland
<kennylevinsen>
That's not what pq asked
<pq>
that's not what I meant
<pq>
not a widget, no
<dv_>
"ask it for subsurface" = "turn a widget into a native subsurface" in the qt realm
<dv_>
that's how you do it
<kennylevinsen>
you can put a subsurface under your main surface if the main surface has transparency
<dv_>
QWidget::winId() does that
<pq>
so Qt5 does not allow you to access the wl_display it uses, and does not allow getting the wl_surface used for its main window?
<dv_>
oh that is possible
<pq>
yeah
<dv_>
but I cannot place a surface to always be under another surface
Company has joined #wayland
<dv_>
oh wait, *sub-*surface. ok
<kennylevinsen>
why not? Qt shouldn't interfere with a subsurface it knows nothing of.
<pq>
so get the wl_display, make your own registry, create your own wl_surface, ask Qt5 for the parent wl_surface, and make a sub-surface out of your own wl_surface.
<pq>
sub-surfaces have position and z-order control wrt. their parent
<dv_>
I also tried, but this does not reliably work either, and the wayland code is getting complex
<dv_>
isn't wlr_layer_shell available with weston?
<pq>
no
<kennylevinsen>
it is also not for this purpose
<emersion>
wlr_layer_shell is not suitable for your use-case
<dv_>
so, if the user clicks on a window in weston, it is raised. this is _not_ possible to do programmatically. do I see this correctly?
<pq>
not from clients through Wayland, correct. Unless you use sub-surfaces for everything.
<dv_>
the other concern I have is that this is an NXP fork of weston, and embedding video in subsurfaces may affect performance.
<pq>
oh, we can't help you at all with that
<dv_>
in my initial tests when I used wl_shell playback and the video surface was embedded playback was choppy. without embedding it was smooth.
<pq>
I wouldn't know if NXP wants to have video through Wayland at all.
<dv_>
so now I try to avoid subsurface based approaches.
<pq>
what do you mean by "embedded"?
<dv_>
embedding a surface into another as a subsurface with the subcompositor.
<pq>
ok. Because embedding could also be not using sub-surfaces.
<pq>
if you want to go NXP-specific, you're free to do that and on your own
<pq>
of you want to do things "upstream way", it's sub-surfaces
<pq>
*if
<dv_>
I need a solution relatively quickly, so it amounts to hacks then.
<dv_>
one idea would be to add some sort of hint to the surface to let the compositor know that this surface is to be placed in some day.
<dv_>
*way.
<pq>
Unfortunately I don't keep track of whose weston fork is how horribly butchered, or if you could just run upstream stuff instead of vendor stack. daniels might have an idea.
<dv_>
nah, can't try upstream right now. integrating that would take weeks.
<pq>
well, the compositor already has the app-id etc. which it could use to special-case window management
<dv_>
I think short term I'll do that, yeah, thanks. any hints where I could do that inside the weston code? I am very unfamiliar with that codebase.
<pq>
desktop-shell/shell.c, and sorry in advance, it's a nest
<daniels>
NXP's downstream fork is an absolute disaster
<dv_>
yeah
<dv_>
that's another reason why I hesitate to continue with subsurfaces
<dv_>
I can't know if I am hitting yet more of those NXP bugs
<dv_>
so short term I do this ugly hack. long term I try to get away from that fork.
<pq>
I don't think I can point you inside shell.c much. Things named map and activate might be good clues.
<daniels>
yeah, I would just hack whichever shell you're using to add things to different layers depending on the app-id of the weston_desktop_surface
<dv_>
alright. app_id = "video-playback" -> set surface to bottom
<dv_>
will try that, thanks
<pq>
good luck
naturalist has joined #wayland
<pq>
also good luck that having something on top the video surface does not destroy your performance
<dv_>
no this works. I already tried that. video below the translucent QML UI , that performed fine when I manually (= with mouse and keyboard) arranged it
flacks has quit [Quit: Quitter]
flacks has joined #wayland
anarsoul|2 has quit [Ping timeout: 480 seconds]
anarsoul has joined #wayland
lromwoo^ has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
<MrCooper>
should be the same with a sub-surface though in principle?
<pq>
should, but who knows how NXP hacked it
lromwoo^ has joined #wayland
bcheng has quit [Remote host closed the connection]
ppascher has joined #wayland
bcheng has joined #wayland
lromwoo^ has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #wayland
lromwoo^ has quit [Remote host closed the connection]
evon3778 has quit [Ping timeout: 480 seconds]
evon3778 has joined #wayland
caveman has quit [Remote host closed the connection]
anarsoul has quit [Read error: Connection reset by peer]
zebrag has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
anarsoul has joined #wayland
anarsoul|2 has quit [Read error: Connection reset by peer]
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Telvana2 has joined #wayland
Telvana has quit [Remote host closed the connection]
Telvana2 has quit []
Telvana has joined #wayland
<dv_>
pq, daniels: I think i've got a working patch. I modified shell_surface_update_layer() for this purpose. here: https://pastebin.com/qgp5WbYs
<dv_>
does this make sense? or am I hitting some landmines?
<daniels>
great!
<daniels>
looks fine, and if it works then I'm not going to tell you it doesn't work :P
<dv_>
=)
<dv_>
btw. do you think wl_list_prepend() would be useful in upstream libwayland?
<kennylevinsen>
wouldn't that just be wl_list_insert(&a->prev, b)?
<kennylevinsen>
well it depends on your definition of preprend, wl_list_insert already inserts at the front of the list, with the ->prev thing making it the back...
<dv_>
but ->prev would not point to the other end of the list, just to the one element behind the front element?
<kennylevinsen>
list->prev is the end of the list
<dv_>
wait, nvm, I conflated this
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #wayland
slattann has quit [Quit: Leaving.]
Telvana has quit [Ping timeout: 480 seconds]
shoragan has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
Moprius has joined #wayland
bodiccea has quit [Remote host closed the connection]