<Ariadne>
so, we make ourselves a root window microservice, and give wayback-comp xdg shell
<Ariadne>
i looked into it last night, i think it has promise as an approach
abbe has joined #wayback
<Ariadne>
one problem though is that in the xwayland rootless model, the compositor is expected to act as WM. we need something more like apple's X11.app, where a WM is running with an injected root window
<Ariadne>
one option could be to spawn the WM directly, and then provide that as the WM FD, then use our injected rootwindow to tell the compositor what changes to make
<Ariadne>
trying to think about how we might plumb that
<emersion>
the compositor doesn't have to be a WM AFAIK
<Ariadne>
are you sure? xwayland(1) talks about the need for `-wm` option
<emersion>
i think the flag is just named this way because that's what all wayland compositors use it for, but that xserver doesn't treat that socket in any special way
<emersion>
xwayland.c just calls AddClientOnOpenFD and then forgets about -wm
<Ariadne>
interesting. i wonder why i don't get video output in rootless mode then
<Ariadne>
humm, experimenting with a labwc session (with xwayland disabled), Xwayland -rootless with external WM also displays nothing
<Ariadne>
i wonder what i am missing
<Ariadne>
i would expect without WM integration for the surfaces provided by Xwayland to be rendered at say, 0x0
<Ariadne>
instead of just not at all
grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
<yshui>
would things running inside wayback be able to drm lease (e.g. vr)? i guess if wayback implements randr eventually everything would just work?
<Ariadne>
if you want VR, why wouldn't you just use wayland natively?
<Ariadne>
X seems like an awful fit for VR use-case
<yshui>
for all the other reasons why people are still running X? the ones you listed in your talk...
<yshui>
and vr doesn't have much to do with the display server anyway, thanks to direct display.
<Ariadne>
i guess my question is -- all the VR-specific environments seem to be wayland-oriented. is this about running VR games on VR headsets which are parented to an X session or something?
<f_>
Ariadne: I did the same test a long time ago, trying -rootless and I also saw nothing shown
<f_>
if you figure out why, that'd be interesting
<Ariadne>
yshui: anyway, what i can say is -- if wayback itself needs modifications to support this usecase, and someone provides patches, we will review/merge them. but there are likely to be other enablement work needed in xwayland, and i can't make any promises there.
<Ariadne>
the patch part is important, i don't have VR hardware and thus cannot test it
<Ariadne>
alternatively, if someone can convince me to buy VR hardware with a use-case i will find amusing, then i might work on it down the line :p
<dramforever[m]>
Ariadne: i hope it isn't too inappropriate to ping you for this. i saw you mention, essentially, getting wayland up to par with ddx support for 2d gpus.
<dramforever[m]>
this reminded me that i had a related idea earlier to make a wlroots rendering backend for Vivante GC3xx, which only has 2D capabilities. i was thinking of doing this to run Wayland stuff on a T-Head TH1520
<dramforever[m]>
however, i have zero clue on what i could be doing, other than feeling that this should be sort of possible. do you have any recommendations on where i could start poking around?
<Ariadne>
there is a proposal for a new library called libg2d
<Ariadne>
so our path would be to try to help that materialize, and then write a wlroots renderer with it
<Ariadne>
and then finally we can delete the damn DDXes from alpine :p
<Ariadne>
which is good, because they are bit-rotting :p
<dramforever[m]>
wow i've never heard of libg2d
<Ariadne>
it does not exist yet
<Ariadne>
it is simply a proposal
<dramforever[m]>
oh, i was excited for a sec because apparently vivante already provides a library called libg2d
<dramforever[m]>
somewhere
<dramforever[m]>
it's proprietary though so probably not related
<dramforever[m]>
the main motivation for wanting to do this is that i could call this project "waywante" and annoy a lot of people
<yshui>
Ariadne, yes, vr runtimes only need to setup a direct context by leasing from the display server, afterwards it doesn't really need anything from the display server. i think xwayland needs to function as a drm leasing proxy of some sort.
<dramforever[m]>
the secondary motivation is that the th1520 has an imagination gpu, and we're basically blocked on imagination to upstream their vulkan drivers and stuff to mesa for open source use. there's a lot already done but also a lot to do and there's basically nothing the community can do to make it go faster
<dramforever[m]>
whereas the gc320, while puny in terms of functionality, and not great in terms of open source support, is at least workable with fully open source sw (a friend of mine has confirmed it working using some kernel patches and ddx patches)
<dramforever[m]>
(yes they put two gpus in this thing presumably in case one of those didn't work)
<f_>
May as well put two SoCs too in case one of them doesn't work
<f_>
(/j)
<dramforever[m]>
they do actually do two cpus in one soc, partly for that, you know
<f_>
yeah but I mean two SoCs :p
<f_>
It's not rare for SoCs to have two CPUs, that said
<dramforever[m]>
this has to be a thing right, not that this is graphics related
<f_>
like Amlogic S912 has two Cortex cpus
<f_>
Err, A311D
<dramforever[m]>
i mean like, putting one risc-v cpu and one arm cpu on the same chip
<f_>
ah
<f_>
Amlogic SoCs typically have at least Cortex-A and Cortex-M :P
<dramforever[m]>
select at packaging time with some fuse stuff
<f_>
teeeeechnically not quite the same :p
<dramforever[m]>
can't run both together
<dramforever[m]>
but back on topic
<f_>
wayback machine?
<dramforever[m]>
we could run the gc320 and imagination (i forgot) together
<dramforever[m]>
and on the imagination one, with the open source stuff rendering works, but display requires more things that are not implemented
<dramforever[m]>
(can you tell i know nothing about the graphics stack)
<Ariadne>
me too
vkareh has joined #wayback
<emersion>
yshui: yeah, Xwayland can forward DRM lease requests via Wayland
<ConanKudo[m]1>
also, xwayland-run does the rootful Xwayland for applications, so we don't need wayback-session for that purpose
<f_>
wouldn't it be nice to have one tool for both? IMO
<ConanKudo[m]1>
no
<f_>
the nested xwayback is basically free, comes directly from wlroots
<f_>
and it does not depend on wayback-session
<ConanKudo[m]1>
yes, but it means everyone needs wlroots
<f_>
are there any plans to move away from wlroots?
<f_>
I heard of api breakage but no concrete plans AFAIK
<ConanKudo[m]1>
not currently? but xwayland-run will leverage your existing wayland environment to run Xwayland rootfully and connect things up for running applications in a rootful window
<ConanKudo[m]1>
it's generally a better tool for this rather than abusing wayland-session for it
<ConanKudo[m]1>
s/wayland/wayback/
<f_>
Personally I find it convenient to be able to run wayback nested for development
<f_>
it's more for that that I use it that way sometimes, than for any actual kind of work
<ConanKudo[m]1>
sure, but I don't think we should expressly advocate for it
<f_>
sure thing
<ConanKudo[m]1>
and it's not a good reason to keep wayback-session around instead of using xinit like we actually want to do for Xwayback
<f_>
My point is it's not even a reason
<f_>
because even with xinit it works
<ConanKudo[m]1>
sure, I'm specifically refuting the point of keeping wayback-session around
<ConanKudo[m]1>
for this purpose
<f_>
¯\_(ツ)_/¯
<ConanKudo[m]1>
it was in the presentation recording
<f_>
that's true
<ConanKudo[m]1>
someone asked about it, and I'm reacting to that 😅
<f_>
heh, yeah
<ConanKudo[m]1>
either xinit or xwayland-run are the options here
<ConanKudo[m]1>
depending on how much X11 session stuff you need
<ConanKudo[m]1>
if you just need to run an app, xwayland-run is better
<ConanKudo[m]1>
if you need X11 session-y stuff, xinit is better
<f_>
what I would say is if you just want to try out things wayback+xinit works just fine
<ConanKudo[m]1>
sure
<f_>
but for actual production work bare Xwayland(-run, I think that's just a script?) will do just fine
<ConanKudo[m]1>
yup
<ConanKudo[m]1>
the main advantage of xwayland-run is that it handles connecting auxiliary services to the xwayland
<f_>
Like in the usecase that person was asking I would just use xwayland-run
<ConanKudo[m]1>
yup
<Ariadne>
f_: hallway track answer: we have to register as a compositor with xwayland to get the surfaces
<f_>
right
<Ariadne>
ConanKudo[m]1: i don't think a lot of people know about xwayland-run. i didn't know about it, for example. i also assume the person in the audience did not.
<ConanKudo[m]1>
probably should mention it in the project site or readme or something
<Ariadne>
yes, and the 12to11 thing i guess
<f_>
omw
<f_>
Actually wondering, you two are basically asking for an FAQ page, right?
<f_>
Because the "can I run wayland apps on Wayback" thing for example, that's a question that's quite frequently asked
<f_>
I think I saw some sourceforge (why is this still alive) link with it but uh
<ConanKudo[m]1>
I don't think there's a canonically live implementation
<ConanKudo[m]1>
they're all various states of dead
<f_>
that one was last updated 3 months ago
<ConanKudo[m]1>
one PR by one person 3 months ago and no response in the bug reports
<ConanKudo[m]1>
that sounds dead-ish to me
<f_>
true
<ConanKudo[m]1>
I'm kind of hesitant to really mention 12to11 personally, partly because the code looks awful and partly because it's a program that ages badly because wayland protocols continue to evolve and wayland applications will use capabilities it doesn't have (and either break or fail in various ways because of it)
<f_>
I know of rxwl and waylandx also
__0x1eaf has quit [Quit: Lost terminal]
<ConanKudo[m]1>
waylandx is a 12to11 fork in a similar state of disrepair
<f_>
but at least the person who forked it is here :p
<ConanKudo[m]1>
lol
<f_>
that's an improvement over the other one :p
<ConanKudo[m]1>
rxwl is the interesting SDL-based one