qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
xantoz_ is now known as xantoz
<qyliss> So, I've got /dev/wl0 inside a VM, which is a good start
<qyliss> Sommelier says:
<qyliss> warning: virtwl-dmabuf driver not supported by host, using virtwl instead
<qyliss> no wl_shm, wl_compositor or xdg_wm_base support
<qyliss> puck: any idea what that means?
<qyliss> Oh, actually that second line is coming from the client I'm running inside the VM
<puck> qyliss: so "virtwl-dmabuf" is the one where the dmabuf that the client gives the compositor is passed into the host, "virtwl" means that sommelier copies the buffer's contents into a special virtwl buffer
<puck> wl_shm is the protocol used to get shared memory to work, wl_compositor is the protocol to get surfaces (which you can see) from a buffer, and xdg_wm_base shrug
<puck> i think you need to have a wayland compositor listening on the host side too maybe?
<qyliss> I'm just forwarding my sway socket (I think?)
<puck> hmm, right
<qyliss> crosvm run --wayland-sock=/run/user/1000/wayland-0 ...
<puck> yeah, it seems sommelier has its own wl_compositor bit
<qyliss> Should sommelier be putting something into XDG_RUNTIME_DIR?
<qyliss> It should be, right?
<puck> yeah, it is, $XDG_RUNTIME_DIR/wayland-0
<qyliss> If I run sommelier ls -l $XDG_RUNTIME_DIR there's nothing there
<qyliss> So I guess that's the problem I need to look at
<puck> try stracing it maybe
<qyliss> good plan
<puck> also it should set $WAYLAND_DISPLAY inside the runprog thing
<qyliss> It does set that
<qyliss> Here's an env:
<qyliss> PWD=/
<qyliss> HOME=/
<qyliss> TERM=linux
<qyliss> SHLVL=1
<qyliss> XDG_RUNTIME_DIR=/tmp
<qyliss> _=/nix/store/bhxian7hnryvjr3vj66am0cwaymwcsma-sommelier-78.12499.0.0-rc1/bin/sommelier
<qyliss> WAYLAND_DISPLAY=.
<qyliss> WAYLAND_SOCKET=15
<qyliss> SOMMELIER_VERSION=0.20
<puck> erm
<puck> do you set --socket on sommelier?
<Shell> the display should definitely not be a dot
<qyliss> I have not set --socket
<qyliss> /nix/store/vcy1ncy01jmd7s2flhbmr877f9v575rl-crosvm-78.12499.0.0-rc1/bin/crosvm run --wayland-sock=/run/user/1000/wayland-0 -p init=/nix/store/m0sx0z3c86lmmb36d7dzf52srbwpa1ks-init --root=/nix/store/6rzq5j8i9vrlnvbbfh4xngf6hyqp0nfg-rootfs /nix/store/gsl2gjn9z4j8gr1y0jlnn825m19mqhc7-linux-4.19.66/bzImage
<qyliss> Oh, on sommelier
<qyliss> not crosvm
<qyliss> Sommelier doesn't seem to be trying to access /tmp at all
<puck> this miiiight be right
<puck> yeah
<puck> it seems to be
<puck> oh.
<puck> qyliss: i think it's trying to run xwayland
<puck> or, well
<qyliss> oh
<puck> runprog indeed should get WAYLAND_DISPLAY=.
<puck> WAYLAND_SOCKET points at the wayland socket fd
<qyliss> strace: https://0x0.st/zl2u.txt
<puck> oh can you set WAYLAND_DEBUG=1 on the program you're running
<puck> and maybe try weston-info
<puck> qyliss: set --master
<qyliss> WAYLAND_DEBUG: https://0x0.st/zl2S.txt
<puck> or, hrmm
<puck> okay, that looks as i'd expect, it's retrieving all the globals
<qyliss> with --master it logs the following and then hangs:
<qyliss> [2882334.799] -> wl_display@1.get_registry(new id wl_registry@2)
<qyliss> [2882340.037] -> wl_display@1.sync(new id wl_callback@3)
<puck> seems about right
<puck> i think sommelier might run one client per wayland client
<puck> unsure
<qyliss> There was documentation about this
<qyliss> > Sommelier can run as service or as a wrapper around the execution of a program.
<qyliss> I was going for the wrapper
<puck> ah, i see
<qyliss> (In the README)
<puck> right
<puck> what version of sway are you running?
<puck> and maybe try running weston-info
<qyliss> 1.2
<qyliss> Working on weston-info
<puck> great, weston-info basically lists all the globals
<qyliss> Making a squashfs for this each time is slow and I should figure out 9p
<qyliss> weston-info: https://0x0.st/zl21.txt
<puck> yeah, that's the wonkiness i was afraid of
<qyliss> hmm?
<puck> hrmm, were you running the entire sommelier under WAYLAND_DEBUG?
<qyliss> I was before yeah
<puck> could you try running only the hello-wayland thing?
<qyliss> sure
<puck> i think what happens is that it's not exporting all the globals it's getting, and only exporting the ones sommelier knows about
<puck> so hello-wayland not working would be a Feature
<Shell> yes
<qyliss> I... see
<Shell> Sommelier implements a Wayland server of its own, that just so happens to use a Wayland server as an implementation detail.
<qyliss> sure
<Shell> if hello-wayland depends on something wlroots-specific then it won't work
<qyliss> OH
<puck> it doesn't depend on wlroot specific things tho
<qyliss> oh
<Shell> hmm.
<puck> sommelier doesn't support xdg_wm_base, but it does do zxdg_shell_v6
<qyliss> fwiw there's a wayland_demo program that comes with sommelier but it doesn't work for me on the host or in the guest
<qyliss> So I gave up on wayland_demo
<qyliss> Here's WAYLAND_DEBUG for hello-wayland: https://0x0.st/zl2e.txt
<puck> yeah, that returned exactly what i thought
<qyliss> ${sommelier}/bin/sommelier ${coreutils}/bin/env WAYLAND_DEBUG=1 ${hello-wayland}/bin/hello-wayland
<puck> i think they have to add support for xdg_wm_base (they should imo)
<qyliss> I see
<puck> especially since it's only one of three stable protocols
<puck> and they implement viewporter
<qyliss> So only Wayland clients that don't use that should work?
<puck> yeah, which is probably most of them
<puck> oh i see
<qyliss> Any suggestions for a small Wayland client I could use for a demo then?
<puck> xdg-shell is the *stable* version of unstable zxdg_shell_v6
<puck> does weston-terminal work?
<puck> i think implementing stable xdg_shell shouldn't be hard (it's very similar to zxdg_shell_v6) either way, if you're up for a small challenge :p
<qyliss> I feel like that might be beyond me
<puck> hrmm, do you have a sommelier .nix file somewhere?
<qyliss> you asked the wrong question :D
<puck> well yes you know the intention of that q :p
<qyliss> I have a whole chromiumOSPackages package set I had to write to get it to work with all its many dependencies
<qyliss> Let me push htat
<qyliss> Oh but first
<puck> i might give that like 30mins of trying to make it work
<qyliss> weston-terminal didn't work but we got some interesting output
<puck> lmao it needs xdg_shell too
<puck> yeah, i'll try and get a smol patch to replace zxdg_shell_v6 with xdg_shell
<qyliss> Just gonna rebase and check it all still works
<qyliss> Because this is the point where we diverge from nixpkgs and it would be good to get as many commits as we can in before that :D
<qyliss> Some future work I do plan on is trying to strip down sommelier's dependencies a bit
<qyliss> Because right now it transitively depends on two different versions of ModemManager, one of which is from 2012
<qyliss> (gj google)
<qyliss> But no point doing that until I have a working demo for reference
<puck> qyliss: anyways consider this an open thing to throw me a nix derivation that builds sommelier, and i'll make xdg_shell stable run
<qyliss> I'll have for you once uhura is done building it :)
<qyliss> wait wtf am I doing our master already diverged
<qyliss> puck: git fetch https://spectrum-os.org/git/nixpkgs master
<puck> awesome
<qyliss> sorry for the megacommit >.>
<puck> no worries lol, this is going pretty swimmingly, i think i almost have a patch (most of it is just renaming zxdg_shell_v6 to xdg_shell, and a abit of logic to pass through the version numbers properly)
<puck> i think i have it working
<puck> need to properly test it tho
<puck> oh, it needs a virtwl device, lol
<qyliss> puck: I can send you my test thing
<puck> it's compiled on uhura again, i can send you a nixpkgs patch, that might be easier?
<qyliss> Would probably be useful for you to be able to test anyway
<puck> i honestly suspect nothing is broken
<puck> except maybe negotiation
<qyliss> Okay, then. Send it to devel@spectrum-os.org an CC me?
<puck> there are no functional changes mainly between v1 and v2, and most of it is passthrough
<puck> actually yeah, if you can send me the testing setup that'd be nice
<qyliss> On it
<qyliss> puck: start-vm.nix in the crosvm-demo branch
<puck> hrmm
<puck> why does crosvm have its *own* sommelier
<qyliss> Does it?
<puck> crosvm is trying to compile sommelier itself
<qyliss> ???
<puck> oh it isn't
<puck> i was misreading
<qyliss> Was gonna say -- if it was it wouldn't have worked because it wouldn't have the patch it needs
<puck> here we go
<qyliss> is it working?
<puck> i had a few mistakes in the sommelier build lmao
<puck> i am currently building the crosvm kernel
<qyliss> that's on uhura, surely?
<puck> yes
<puck> or well
<puck> compiling it on, not yet there?
<qyliss> I should have compiled it already
<qyliss> Did you have to change something?
<puck> no? idk
<qyliss> whatever
<qyliss> maybe i did
<puck> anyways it's compiling currently
<puck> bbiab, need to eat
<puck> qyliss: "failed to fork and create pty (No such file or directory)"
<qyliss> puck: well that's a good sign
<puck> yeah, i'm trying again
<qyliss> That might be it working!
<puck> yeah, it negotiated xdg_wm_base
<qyliss> I probably haven't done whatever I need to do to make ptys work
<puck> yeah, you need some nodes and/or udev
<qyliss> Let me send you the hello-wayland package
<puck> dw, i think i have the necessary nodes
* Shell is excited about this
<qyliss> :3
<puck> it opened
<puck> aaand immediately sommelier segfaulted lmao
<qyliss> well that's progress
<qyliss> you actually saw a terminal?
<puck> for a split second
<qyliss> nice
<Shell> nice
<puck> let's see
<puck> qyliss: i had to mount devpts ftr
<qyliss> This reminds me that since the change to have colourful builds, Nix now just fails completely if it can't open a pty
<puck> lol
<puck> hrmm, i wonder if this crash is actually my fault now
<puck> oh it gets me an assertion now
<puck> so yeah i'm not entirely sure why this breaks, this is what i am running https://puck.moe/up/fihaf-kuloh.patch
<puck> i think i am going to give this a break etc, not sure how to test through the vm boundary
<qyliss> thanks a lot for your help
<qyliss> can you summarise what you know about the crash so far?
<puck> sommelier segfaulted inside of wayland-client.so for me
<puck> and setting the shm driver to noop hits an assert just after an ioctl
<qyliss> Not even a flash for me :(
<qyliss> Fontconfig error: Cannot load default config file
<qyliss> wonder if that's important
<puck> hrmm
<qyliss> gonna try with hello-wayland
<puck> yeah, trying hello-wayland maybe would give you better result (also probably remove the --shm-driver=none thing)
<qyliss> if I can get to the point where I have a cat picture that's good enough for today
<qyliss> I don't see that?
<qyliss> IT WORKS
<qyliss> PUCK
<puck> oooh
<puck> hrmm
<qyliss> (with hello-wayland)
<puck> so what if sommelier crashed because it closed during initalization
<puck> ... probably
<puck> anyways \o/
<qyliss> what does /dev/shm do btw?
<puck> weston seems to support unstable xdg-shell v6
<puck> qyliss: probably just used as a place to create files for shared memory
<puck> anyways \o/
<puck> yes that's two \o/s
<qyliss> :D
<qyliss> happy
<qyliss> you're probably sick of being told you're a genius at this point, right?
<Shell> qyliss: it is used for POSIX shared memory I think. It used to be the bane of getting Postgres to run under a container.
<puck> qyliss: ftr i just compared the zxdg-shell v6 protocol with xdg-shell and used a lot of s///
<puck> i wonder if the chromium window manager just doesn't support xdg-shell
<Shell> Probably, lol
<qyliss> How does it run applications then?
<puck> it supports zxdg-shell_v6 most probaby
<puck> and a bunch of apps will support both this and xdg_shell, but i think xdg-shell is the one most people want to support (it's more recent than v6)
<qyliss> right
<qyliss> so you just couldn't run weston-terminal with their wm, you reckon?
<puck> https://github.com/wayland-project/weston/commit/d8d9f5e6e16c8f6a3c06763d5f56c27dc9a6e52e seems to suggest that xdg_shell is more supported, and some clients will only ask for xdg_shell
<qyliss> I'm wondering how anything runs on CrOS in that case
<puck> yeah, weston-terminal seems to only work if you have stable xdg_shell v2
<qyliss> XWayland, I guess
<puck> .. most probably
<qyliss> wonderful
<puck> alacritty seems to like running in wayland more than x
<puck> so while running the weston thing alacritty just kept opening inside there
<qyliss> what
<puck> i don't use a wayland compositor, so while testing the xdg-shell changes i just kept weston open
<qyliss> oh, right
<qyliss> ====> The crosvm-demo now has a working virtio-wl demo using hello-wayland :D <===
<qyliss> I'm too hyped for more work now :D
<qyliss> wayland-terminal wants /proc too, which I don't think I currently hvae
<multi> there's a *lot* of stuff which will be unhappy if /proc isn't available
<multi> i think musl libc makes assumptions about /proc being mounted in a number of places
<qyliss> glibc does too I'm pretty sure
<qyliss> It's the blessed way to access all that stuff
<qyliss> sysctl(2) is going to removed in 5.5
<multi> wot
<multi> welp
<multi> til
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined #spectrum
<IdleBot_5e50c57d> Well, if sysctl(2) warned _since 2.6_, maybe even Linus Torvalds has limits to patience and not breaking userspace
<IdleBot_5e50c57d> (I guess sysctl is kernel-tuning userspace anyway, so it does not count as fully sacred)
<qyliss> They figure it's not actually breaking userspace
<qyliss> They made it disabled by default (behind a config option) years ago, and nobody complained
<qyliss> The kernel is in general fine with removing or changing functionality, as long nobody appears to be relying on it.
<qyliss> Oh, neat. weston-terminal is one medium-sized C file.
<qyliss> I'm printf-debugging it
<qyliss> It runs for exactly five iterations of the event loop and them exits 0
<qyliss> that could well be when it wants to render text...
<qyliss> "EPOLLHUP"