ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<emersion>
Consolatis: i haven't heard anything against it
<emersion>
compared to object IDs, global names are type-unsafe
<emersion>
but that's about it, apart from that, both are uint32_ts
fmuellner_ has quit [Ping timeout: 480 seconds]
<Consolatis>
the only potential issue I can come up with is that it might make it harder for e.g. GTK applications to use the GDK abstraction of the outputs, I don't know if they expose the global so that the application could match it in a output_enter/leave handler
<Consolatis>
on the other side I also don't know if they expose the object id for that matching
glennk has quit [Ping timeout: 480 seconds]
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
<Consolatis>
hm.. there seems to be gdk_wayland_monitor_get_wl_output(). Now the question becomes if there is anything in libwayland that returns a global 'name' based on a wl_proxy, similar to what wl_proxy_get_id() is doing for the object id. I couldn't find anything but I am also not that familiar with libwayland
<Consolatis>
it seems like the only place the global could be stored is in wl_registry_bind() though. And that one just serializes and writes it out to the compositor
<soreau>
Consolatis: I'm not sure if it's any consolation, but you can struct wl_display *display = gdk_wayland_display_get_wl_display(gdk_display_get_default()); and from there wl_display_get_registry(display); to do your own roundtrip for global stuff
<Consolatis>
right, but you couldn't match a global you get via output_enter/leave argument with an existing gdk_monitor (and I assume its the same for other GUI frameworks)
psykose has quit [Ping timeout: 480 seconds]
<Consolatis>
obviously creating your own objects is fine and allows the app developer to attach the global via wl_proxy_set_user_data() or whatever floats their boat
<Consolatis>
this is about getting e.g. '15' on a output_enter event and then finding a gdk_monitor based on that global name 15. I don't think this is currently possible. You could bind your own wl_output of global id 15 but that looks like its all that can be done currently.
<Consolatis>
so this might speak against using global ids as arguments.. at least as long as libwayland doesn't provide something to fetch the global from a wl_proxy (if created by a wl_registry_bind call)
<Consolatis>
although from the compositor side using globals for output enter/leave events is theoretically very much superior compared to the current object based argument. If it doesn't work in practice that might be worse. Guess that leaves using the output name as argument
<soreau>
seems like the problem there is 'the compositor can either lie and send a done event even though it didn't actually send the corresponding output resource' because if the compositor is lying, you have bigger issues :P
<soreau>
I view the compositors as trusted robust processes, and the clients can be silly all they want. Kinda like the kernel handles its 'children' processes
<Consolatis>
agree, but that is just impossible in this case as the compositor can only send wl_output object ids that the client has already bound
<Consolatis>
that gets amplified with multiple independent parts (e.g. GTK + app logic) sharing a single wayland connection
karl1fox has joined #wayland
<karl1fox>
hey guys, is someone familiar with the rdp backend code around that I could ask a question of?
nerdopolis has quit [Ping timeout: 480 seconds]
<soreau>
karl1fox: you might as well just ask your question and link any issues you might have filed
<karl1fox>
I was thinking Soreau, I think these changes are actually only in the MS mirror of Weston, but I'll ask all the same. In the Weston log I see my 3 monitors detected by the RDP plugin, but it seems like the compositor is only presented with one and I'm trying to grasp how that piece works :)
garnacho has quit [Ping timeout: 480 seconds]
mxz__ has joined #wayland
<soreau>
karl1fox: I have no idea about the MS world of weston but have you tried running it with something like `-B drm,rdp`?
<soreau>
hm, looks like only vnc and pipewire backends can be used as secodnary
<soreau>
karl1fox: what does `weston --version` say?
mxz has joined #wayland
<karl1fox>
weston 9.0.0
<soreau>
yea, that's pretty old
<karl1fox>
yeah the problem is that to get the graphics acceleration that wslg offers, you have to use the rdprail-shell
<karl1fox>
I think if I was a bit smarter and more experienced I could switch to the upstream Weston mirror and figure it out, but alas I must eat the MS table crumbs :)
<karl1fox>
Soreau, is a wayland display the sum of all display outputs?
<soreau>
karl1fox: the wayland display I know is an object that represents the underlying socket connection
<soreau>
IIRC in X, I think all outputs collectively were called a 'screen'
<karl1fox>
What would happen if I forced Xwayland to run in rootful mode here? /usr/bin/Xwayland :0 -rootless -core -listen 37 -wm 38 -terminate -nolisten local -ac
<soreau>
which weston shell are you using btw?
<karl1fox>
the rdprail-shell
<karl1fox>
This is what their wslgd plugin runs, /usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwayland --socket=wayland-0 --shell=rdprail-shell
<soreau>
and is your rdp client configured to support multiple outputs?
<soreau>
if so, it might be time to consider upgrading weston (to 13.0 or better)
<soreau>
if that's even an option
<karl1fox>
I'm certainly willing to try :)
<karl1fox>
Does the newer version have multimon support for RDP?
<soreau>
It seems like you want multi-backend support but details are foggy on the web
<soreau>
(WSL2_WESTON_SHELL_OVERRIDE seems like it might be interesting?)
<soreau>
according to google's AI results: "Multi-monitor support: Weston 13.0 and later versions include support for multiple backends, including the RDP backend. This allows you to create multiple outputs corresponding to the monitors connected to your Windows machine."
<karl1fox>
so id basically do drm, rdp to setup the 3 monitors and then rdp to allow remote to it? Is that the gist of it?
<soreau>
karl1fox: what if you try `/usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwayland --socket=wayland-0 --shell=desktop-shell`
<soreau>
because apparently, "The RAIL-shell is a Weston shell specifically designed for remoting individual windows from Linux to Windows using the Remote Desktop Protocol (RDP)."
<karl1fox>
You get a wayland desktop shell but it disables multimonitor support
<soreau>
but if I were you, I'd try upgrading first and if you can get weston 13.0, maybe there's a chance there's a path to make it work
<karl1fox>
cool, ill work on that, and circle back with you
<karl1fox>
I need to figure out a way to upgrade the Meson version in the wsl system distro
<karl1fox>
its not in their official repo which is making it tough to do in the Dockerfile they give you
<soreau>
if you have python3 pip, it should be as easy as 'pip3 install .` from the meson source directory
<soreau>
(but I'm guessing with windows, it's not that straightforward)
<karl1fox>
oh I have a full arch install... the problem is that the system distro where weston lives, is read only after you build it in docker and you cant run it in docker because it has no kernel of its own
<karl1fox>
I think that's what I'll work on, finding a way to make the distro rw
<karl1fox>
because then customization and testing is much easier
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
CodeSpelunker has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
danieldg has quit [Ping timeout: 480 seconds]
balrog has quit [Ping timeout: 480 seconds]
CodeSpelunker has quit [Ping timeout: 480 seconds]
CuteMath has joined #wayland
kabaka101 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
glennk has joined #wayland
kts has quit []
<soreau>
DemiMarie: I was thinking, if you want a secure system and to guard against potentially malicious clients, you could do what some platforms do and ship the display server with clients that have been vetted and ignoring any non-trusted client
<soreau>
i.e. package the compositor and select clients that you know are trusted because you ship them
<soreau>
also you could ignore clients that aren't launched by the compositor (or some shell) itself
<emersion>
Consolatis: this is a GTK issue not a libwayland one
<emersion>
libwayland cannot provide functions to return an output based on global name, because it doesn't track that
<emersion>
Consolatis: anyways, protocol design should not be guided by some missing/non-existing API in a single toolkit (it's not a show-stopper here)
<Consolatis>
right, but libwayland could return the global for a wl_proxy if it was created by wl_registry_bind() but as you said it currently doesn't seem to track that
<Consolatis>
in theory I agree to the protocol design part but in practice it will make the protocol less usable with the current environment that app devs need to support
<Consolatis>
and such it is an argument against using the global in output_enter/leave for me
<Consolatis>
which IMHO leaves two options for the ext-workspace MR (and ext-foreign-toplevel-info), using the output name and relying on its unique among globals property or keep using object ids with their known flaws
Fxzxmic has joined #wayland
leon-anavi has joined #wayland
juergbi has joined #wayland
<emersion>
Consolatis: libwayland cannot, it's generated code (and out of scope)
<emersion>
Consolatis: i disagree
<emersion>
it's not hard to keep track of outputs yourself if you are using GTK
<emersion>
also another protocol is already using the global name
sima has joined #wayland
JakeSays has joined #wayland
JakeSays1 has quit [Ping timeout: 480 seconds]
<dviola>
soreau: just bisected linux.git (stable)
<dviola>
This means the bug has been fixed between ffc253263a1375a65fa6c9f62a893e9767fbebfa and [9b5aad3a7498c261116a0251fe57f14ba9c4c6cf].
<soreau>
so it's already fixed in newer kernels or it broke somewhere along the way?
<dviola>
I'm a bit confused about it to be honest
<dviola>
latest master is bad, 6.6.60 is good, 6.6 is bad
<soreau>
did they make it all the way to .60? :P
<dviola>
that bisect log makes no sense, sigh
<soreau>
https://lwn.net/Articles/997527/ -> "I'm announcing the release of the 6.6.60 kernel. All users of the 6.6 kernel series must upgrade." <- sounds almost scary
<dviola>
ha :P
<dviola>
trying 6.7
<soreau>
dviola: if latest master and 6.6 is bad, I would think 6.7 would be bad too..
<soreau>
are you able to bisect between 6.6 and 6.6.60?
<dviola>
yes
<dviola>
let me try that
mcf has quit [Ping timeout: 480 seconds]
mcf has joined #wayland
tzimmermann has joined #wayland
<dviola>
"Some good revs are not ancestors of the bad rev. git bisect cannot work properly in this case. Maybe you mistook good and bad revs?"
<llyyr>
reverse the good and bad revs
<dviola>
ok, let me check how to do that
<llyyr>
if 6.6.0s is bad and 6.6.60 is good then mark 6.6.60 bad and 6.6.0 good
karl1fox has quit [Remote host closed the connection]
<llyyr>
if you find the bug then do git bisect good, since you're looking for a commit that fixes something, not a commit that introduces a bug
<llyyr>
I don't know why it works this way
<dviola>
makes sense, thanks
<soreau>
what I usually do instead of git bisect start foo bar, is git bisect start, then git bisect good some-hash and git bisect bad some-hash
<dviola>
here we go... ~12 steps to bisect
paulk has joined #wayland
paulk-bis has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
danieldg has joined #wayland
balrog has joined #wayland
garnacho has joined #wayland
feaneron has joined #wayland
<MrCooper>
dviola: sounds like it's probably not a kernel regression / not 100% reproducible
<MrCooper>
if it's the latter, you may need to wait longer before declaring a kernel commit good
iomari891 has quit [Read error: Connection reset by peer]
<soreau>
MrCooper: I thought the problem was pretty cut and dry - hw cursor plane upside down
<MrCooper>
the inconsistent bisect results disagree
<dviola>
MrCooper: yeah, it was working fine with recent kernels, e.g. 6.11.x
<dviola>
then it broke
<dviola>
I'll finish the bisect anyway
rgallaispou has joined #wayland
iomari891 has joined #wayland
rasterman has joined #wayland
<dviola>
this happens inside the QEMU VM only btw
JakeSays1 has joined #wayland
<pq>
kennylevinsen, while ExecStartPost=+chvt 7 seems a little hacky to me, in lack of a login manager I think it's still slightly better than auto-activating all new sessions. My 2c FWIW.
JakeSays has quit [Ping timeout: 480 seconds]
<pq>
emersion, Consolatis, re: wl_output global names; did we have something to forbid name re-use after remove_global?
<emersion>
i don't think it matters? client gets global_remove events
<emersion>
so clients always have synced up-to-date state about wl_output
<emersion>
if anything wl_output.name is more racy
<pq>
assuming clients process global_remove and events referring to global names in order. That's not guaranteed, the client can funnel those via different queues.
<pq>
hmm, this is essentially the same problem as the plain global_remove race against bind.
<emersion>
you can always assign a wl_registry to the queue you're interested in
iomari891 has quit [Ping timeout: 480 seconds]
<emersion>
but yeah, it's not a new problem and we've put a solution in place already
<pq>
indeed
karenw has joined #wayland
pochu has quit [Quit: reboot]
pochu has joined #wayland
bnason2 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
pq: yeah, what I had in mind was a `libseat_get_session` so that one could explicitly do a session switch to self if they so desired
<pq>
cool
<pq>
Does logind d-bus API generally allow any session owner to activate their session at will?
<kennylevinsen>
for logind, you need to pass a polkit `org.freedesktop.login1.chvt` permission check, but that appears to be it
<pq>
alright
<kennylevinsen>
The pre-installed rule for that allows both active and inactive (but logged in) users
fmuellner has joined #wayland
<dviola>
MrCooper: I *think* the commit will make more sense this time
<dviola>
llyyr: yes, but I still need to test that
<llyyr>
well seems like cursor plane probably got re-enabled at some point later in the tree then, that's why you got the regression back
<llyyr>
but it doesn't seem like a fix, you can force weston or sway to use software cursor on your end too
<dviola>
right, I've been using WLR_NO_HARDWARE_CURSORS=1 before to "fix" that issue in the VMs
<llyyr>
>gnome-shell or kwin, which put virtualized drivers on a deny-list when running in atomic context to make them fallback to legacy kms and avoid this issue
<llyyr>
huh didn't know
<llyyr>
That check is still there on master, so I don't understand why it's broken on master for you
feaneron has quit [Quit: feaneron]
<dviola>
yes, good question
<dviola>
could that commit that got skipped have something to do with it?
<dviola>
that's still there on master as well
<llyyr>
possibly, you can try removing that yourself on master
<dviola>
I'll try that
<llyyr>
the commit you skipped shouldn't cause a build failure though I think
<dviola>
building master without 1055077473e3448a13cc002fcad2adb08865e084
<dviola>
llyyr: yeah, I don't know why I got that build error
<llyyr>
oh I know why
<llyyr>
the patchset got applied in reverse order in the linux tree (??)
<llyyr>
the commit that uses supports_virtualized_cursor_plane member is applied before the commit that adds supports_virtualized_cursor_plane
<llyyr>
dviola: removing the not just makes it so that the condition never evaluates to true
<llyyr>
effectively the same as removing the line altogether
<llyyr>
since I don't believe any of the vm drivers implement that feature
<dviola>
makes sense
<dviola>
so that's essentially the same as running in software cursor mode?
<zamundaaa[m]>
<llyyr> "since I don't believe any of the..." <- That line checks the compositor's caps, not anything from the driver
<llyyr>
ah
<zamundaaa[m]>
dviola: Yes, it removes the cursor planw
<dviola>
makes sense, I guess I'll just live with WLR_NO_HARDWARE_CURSORS=1 then
<llyyr>
or legacy drm driver
<zamundaaa[m]>
dviola: in case there's no such bug report already, it would be good to make one for the virtio driver
<llyyr>
wlroots at least seems to claim to support DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT
<llyyr>
wonder if the issue is with wlroots then?
<dviola>
zamundaaa[m]: I've been thinking about where to report this but I've had a difficult time just figuring out where the prolem is, qemu, wlroots, sway, mesa, the kernel, etc
<zamundaaa[m]>
If both kwin and sway are affected, it's unlikely that it's anything except a driver bug
<llyyr>
I don't believe they're tried kwin, and kwin seems to have a deny list for virtual drivers where it'll automatically fall back to legacy DRM anyway
<zamundaaa[m]>
No, it doesn't
<zamundaaa[m]>
That's from before the cursoe hotspot cap existed
<llyyr>
ah
karenw has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Also see the bug report I linked
<dviola>
I'm still puzzled about why it works with 6.6.60 and not previous or newer versions
<dviola>
but yeah I agree that it would be nice to see this fixed
<llyyr>
it just uses software cursor
<dviola>
llyyr: ah, makes sense
<dviola>
I'm fine with that actually
kts has joined #wayland
rasterman has joined #wayland
exkc has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
akallabeth[m] has quit [Quit: Bridge terminating on SIGTERM]
zebrag[m] has quit [Quit: Bridge terminating on SIGTERM]
YaLTeR[m] has quit []
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
idkrn[m] has quit [Quit: Bridge terminating on SIGTERM]
Orko[m] has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit []
davidre has quit [Quit: Bridge terminating on SIGTERM]
deknos82[m] has quit [Quit: Bridge terminating on SIGTERM]
swick[m] has quit []
colinmarc has quit [Quit: Bridge terminating on SIGTERM]
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
zzxyb[m] has quit [Quit: Bridge terminating on SIGTERM]
drakulix[m] has quit [Quit: Bridge terminating on SIGTERM]
sberz[m] has quit [Remote host closed the connection]
d_ed[m] has quit [Remote host closed the connection]
qyliss has quit [Quit: bye]
qyliss has joined #wayland
qyliss has quit [Remote host closed the connection]
<dviola>
looks like MrCooper was right ("not a kernel regression / not 100% reproducible")
<ofourdan>
MrCooper is usually right :þ
<MrCooper>
except when I'm not :)
<ofourdan>
of course, there are to be exceptions to all rules!
rgallaispou has quit [Ping timeout: 480 seconds]
<dviola>
yeah, not that I doubt his judgement, I just want to understand why the behavior is inconsistent, what makes it not reproducible
<ofourdan>
I was just teasing, nevermind my comment :)
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
Dirtysand has joined #wayland
<dviola>
I think it's probably sway not going into soft cursors every time
<dviola>
I have another wayland issue that I'd like to investigate also, when closing a native game (e.g. Factorio) the steam window will close (swaymsg -t get_tree doesn't show up the window anymore) but the process is still there
<kennylevinsen>
that's not by itself an isssue - maybe there's something configurable about staying alive/going to tray? idk
tokyo4j has quit [Read error: Connection reset by peer]
tokyo4j has joined #wayland
<dviola>
good point, seems to not be a problem with Steam's big picture mode
nerdopolis has quit [Ping timeout: 480 seconds]
Net147 has quit [Remote host closed the connection]
<dviola>
I wonder if sway will accept a patch similar to the kwin's one, that detects it's running in a VM and enable software cursors
Net147 has joined #wayland
<dviola>
not that I'll do it, I don't know how, but I could look into it at least
<kennylevinsen>
that sounds like a kernel bug workaround rather than a fix...
<kennylevinsen>
there's a bug in either the kernel or wlroots, and going to software cursor just pretends it isn't there
<dviola>
right
kabaka101 has joined #wayland
iomari891 has joined #wayland
<dviola>
it will probably distract from getting the real issue fixed and you'll have to do it for every single compositor, not good
coldfeet has quit [Remote host closed the connection]
DemiMarieObenour[m] has joined #wayland
<DemiMarieObenour[m]>
soreau: That is basically what Qubes OS does, but one of those clients (the GUI daemon) must cause the compositor to draw something that is similar to what the (untrusted) applications in the VM would have caused the compositor to draw, as long as those applications are _not_ being malicious. It’s fine to break malicious or badly-behaved applications, but users expect well-behaved applications to work.
heftig has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
robertmader[m] has joined #wayland
psydroid[m] has joined #wayland
agx has joined #wayland
exkc has joined #wayland
psykose has joined #wayland
coldfeet has joined #wayland
<dviola>
soreau: yeah, I can't tell if it was upstreamed though
coldfeet has quit [Remote host closed the connection]
<soreau>
dviola: you can use `git log` on linux git and then `/commit\ message` to see if anything turns up
<dviola>
yeah, the commits in that patchset are all upstreamed
<soreau>
so I'd probably check linux git log and /4e3b70da64a53784683cfcbac2deda5d6e540407 to make sure you have it, and if that doesn't work, file an issue
<soreau>
(I mean if you have the commit and build it and it doesn't work)
<dviola>
is the mesa bugtracker fine to file the issue?
<dviola>
I can probably reference the old bug report also
<soreau>
since it's apparently a kernel issue, you'd have to file an issue against the kernel, unless you can otherwise prove that mesa is also somehow involved
<dviola>
yeah, I'm not sure where to report the kernel bug though, looks like I'll need to email the people involved?
melnary has quit [Remote host closed the connection]
melnary has joined #wayland
mohit81582263530 has quit [Quit: mohit81582263530]
kabaka101 has joined #wayland
mohit81582263530 has joined #wayland
mohit81582263530 has quit []
mohit81582263530 has joined #wayland
mohit81582263530 has quit []
mohit81582263530 has joined #wayland
<dviola>
there's another issue with mouse cursor on sway (happens everywhere, host and VM) -- this one started to appear with the latest update and probably have nothing to do with the other bug, when you open up a terminal the cursor changes from an arrow to an "i-beam", after closing the terminal the cursor never updates anymore (to an arrow)
<dviola>
it updates after I move it again
<dviola>
I'd bisect but newer sway requires newer wlroots, makes things difficult :(
<soreau>
dviola: maybe try another compositor to see if it happens there. if it does, probably points to wlroots
<soreau>
if it doesn't, might be a sway thing
<dviola>
or rather, bisecting is not easy because different versions require different wlroots versions
<dviola>
soreau: I'll try that later today, thanks
<dviola>
actually, let me try weston real quick
<dviola>
nope, weston is fine
adamtajti has joined #wayland
<dviola>
hyprland is also fine
<dviola>
hyprland no longer uses wlroots so it's probably wlroots issue
kabaka101 has quit [Ping timeout: 480 seconds]
<dviola>
I think I'll just wait since some of those issues are a PITA to debug, what else can I do anyway
rdiffender has joined #wayland
rdiffender has quit [Remote host closed the connection]
rdiffender has joined #wayland
karenw has joined #wayland
<soreau>
dviola: try two different wlroots compositors
rdiffender has quit [Remote host closed the connection]
<soreau>
if they both have the same issue, more likely a wlroots bug, but if only sway has it and another does not with same wlroots version..
rdiffender has joined #wayland
rdiffender has quit [Remote host closed the connection]
rdiffender has joined #wayland
rdiffender has quit [Remote host closed the connection]
mohit81582263530 has quit [Quit: mohit81582263530]
mohit81582263530 has joined #wayland
<dviola>
soreau: sure, I'll try that
CuteMath has quit [Ping timeout: 480 seconds]
kabaka101 has joined #wayland
kabaka101 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<emersion>
leandrohrb56: thanks!
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
glennk has quit [Ping timeout: 480 seconds]
<dviola>
soreau: just tried river which is also wlroots-based, and the issue is not present
sima has quit [Ping timeout: 480 seconds]
pounce has quit [Read error: Connection reset by peer]
pounce has joined #wayland
mupuf has quit [Remote host closed the connection]