03:24
saji has joined #spectrum
03:27
sudo has quit [Ping timeout: 265 seconds]
15:32
<
qyliss >
Back to crosvm today
16:44
<
qyliss >
If it doesn't use WAYLAND_DISPLAY, how does sommelier's client connect to sommelier?
17:00
<
leah2 >
inbox nntpd at spectrum-os.org down?
17:09
<
qyliss >
leah2: that better?
17:09
<
leah2 >
gnus approves!
17:10
<
qyliss >
Something weird is going on with my certificate permissions
17:10
<
qyliss >
Think a couple of services might be fighting over the
17:10
<
leah2 >
does it have starttls?
17:14
<
qyliss >
I don't recall
17:14
<
qyliss >
But it does have TLS
17:14
<
qyliss >
I think it should also have STARTTLS
17:18
<
puck >
qyliss: WAYLAND_SOCKET
17:19
<
puck >
aka pass in a file descriptor, i think
17:22
<
qyliss >
that's cool
17:25
<
puck >
so. in wayland, every protocol has a "version". and with each version you get new features etc
17:26
<
puck >
the registry is the one hard-coded resource etc, which you use to bind to any other "globals". this checks that the global that sommelier implements is equal or newer than the version that the client requests
17:27
<
puck >
e.g. one may ask for the `xdg_wm_base' interface, which is currently v2
17:27
<
puck >
so if a client were to ask for v3, sommelier will just exit, because it doesn't know what v3 changed
17:28
<
puck >
(note that a proper client wouldn't ever do this, since it gets to know which globals are available)
17:28
<
qyliss >
sway does it
17:28
<
qyliss >
I was trying to run sway in sommelier
17:28
<
puck >
do you know what it's trying to bind to?
17:28
<
qyliss >
Let me do some printf debugging and find out
17:28
<
puck >
(run sway with WAYLAND_DEBUG=client)
17:29
<
puck >
that will log all messages sent to and received from sommelier
17:32
<
qyliss >
If I'm reading this right, it's wl_output v3
17:36
<
puck >
that seems wrong
17:36
<
puck >
what's your list of bind()s?
17:36
<
qyliss >
let me send the logs
17:36
<
puck >
(wl_output v3 was committed 4 years ago)
17:40
<
puck >
what is even going on during boot
17:40
<
qyliss >
it's booting two VMs at once
17:40
<
qyliss >
interleaved into the same stream
17:41
<
qyliss >
because I'm still using the demo of inter-VM networking
17:43
<
puck >
2020-01-15 17:39:16 - [backend/wayland/backend.c:66] Remote wayland global: wl_compositor v3
17:43
<
puck >
[805695.006] -> wl_registry@2.bind(3, "wl_compositor", 4, new id [unknown]@3)
17:43
<
puck >
that's the issue there
17:44
<
puck >
it's trying to bind to wl_compositor v4, but v3 is the only available on.e
17:45
<
puck >
i think this is from ~a year ago, not sure why.
17:45
<
qyliss >
Sommelier seems to be quite far behind
17:45
<
qyliss >
Remember xdg_shell?
17:45
<
puck >
yeah, i guess
17:45
<
puck >
wl_compositor (and wl_surface) v4 are from 4yrs ago too
17:45
<
qyliss >
Is it likely to be similarly straightforward to update? Could I just do it?
17:47
<
puck >
errrr, unsure. i think (but don't quote me on this) it might be easier to downgrade the version of wl_compositor that wlroots expects
17:47
<
qyliss >
or use an old sway
17:47
<
puck >
dang, this is false
17:47
<
qyliss >
but that's not really sustainable
17:47
<
puck >
also, running sway
*inside* sommelier is a weird choice
17:47
<
puck >
since it'll just output into a single window?
17:48
<
qyliss >
That's what I want
17:48
<
qyliss >
For debugging, you understand
17:48
<
puck >
okay, so implementing a fallback damage_buffer is probably trivial, lemme see
17:48
<
qyliss >
I would like to have VM sway inside by host sway
17:51
<
puck >
i believe it'd be trivial to "faux-implement" it by e.g. just damaging the entire surface
17:52
<
puck >
then update the wl_compositor interface to v4
17:56
tilpner has quit [Quit: tilpner]
18:02
tilpner has joined #spectrum
18:30
tazjin has quit [Ping timeout: 272 seconds]
18:30
feepo has quit [Ping timeout: 252 seconds]
18:31
manveru has quit [Ping timeout: 264 seconds]
18:32
tazjin has joined #spectrum
18:33
feepo has joined #spectrum
18:35
manveru has joined #spectrum
18:40
<
puck >
this probably exists because they have to compile with v4 in the headers but found no reason to implement it
18:41
<
qyliss >
puck: I'm not really sure what I'm supposed to be looking for in sommelier.c?
18:41
<
qyliss >
I think I understand the Wayland commit message
18:41
<
qyliss >
But I don't see what that has to do with those two line numbers you said?
18:41
<
puck >
err, there's a secondary assert(0) somewhere in a same damage_buffer impl i think
18:42
<
puck >
yeah, old version nvm
18:43
manveru has quit [Ping timeout: 272 seconds]
21:06
<
qyliss >
puck: so, wouldn't implementing damage be as simple as
21:06
<
qyliss >
wl_surface_damage_buffer(wl_resource_get_user_data(resource)->proxy, x, y, width, height);
21:06
<
qyliss >
in that function that currently asserts 0?
21:06
<
puck >
err, not quite, i'd believe
21:07
<
puck >
because damaging the buffer means having to side-effect the backing surface (that sommelier keeps separate) too
21:07
<
puck >
see sl_host_surface_damage
21:07
<
puck >
this shouldn't be too hard
21:07
<
qyliss >
wait what's the difference between damage and damage_buffer?
21:08
<
puck >
damage uses surface coordinates, damage_buffer uses buffer coordinates
21:08
<
puck >
basically, in wayland, you register a "buffer", then create surfaces out of parts of that buffer
21:08
<
puck >
the cheapest way to implement this is to just damage the entire surface for now, i think
21:09
<
qyliss >
So wl_surface_damage_buffer(wl_resource_get_user_data(resource)->proxy, 0, 0, INT32_MAX, INT32_MAX); ?
21:09
<
qyliss >
(Or the same with wl_surface_damage?)
21:10
<
puck >
the same as wl_surface_damage does, but i'm not entirely sure how buffer->damage ends up getting used
21:10
<
puck >
ah, copies stuff when committing
21:10
<
qyliss >
You mean sl_host_surface_damage?
21:11
<
puck >
i think you probably want to end up calling wl_surface_damage with the full surface size.. not 100% certain on this
22:41
<
qyliss >
Just pushed a change that means we don't have to build half of Chromium OS any more just to get Sommelier
22:41
<
qyliss >
Which is nice
22:41
<
qyliss >
No weird dependencies on two different modemmanagers, etc.