00:43 wlb: wayland Merge request !360 opened by Thomas Lukaszewicz (tluk) Draft: Mitigate UAF crashes due to iteration over freed wl_resources https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/360
01:18 tomatoo: I had a qustion about libinput, just wanted to make sure this was the right place
01:28 wlb: weston Issue #863 opened by Jun (YOUNGJUN) Handling subsurface rendering https://gitlab.freedesktop.org/wayland/weston/-/issues/863
06:30 mizvekov: Regarding writing wayland clients, are the life cycles of all globals similarly unconstrained?
06:30 mizvekov: For example, basic singletons like wl_compositor, wl_shm, xdg_shell, can I safely assume they will be available immediately and will never be removed?
08:18 MrCooper: immibis: for all the reasons Wayland was created separate from X in the first place
08:19 MrCooper: orowith2os[m]: "rootful WaylandX" is just a Wayland compositor with an X backend
08:20 MrCooper: orowith2os[m]: is there a point in sandboxing clients via Wayland, if they can be spied on via X anyway?
08:22 immibis: and what are those relevant reasons?
08:22 immibis: the point is to run Wayland clients
08:23 MrCooper: e.g. atomic updates and client isolation
08:23 immibis: you know, never in my life have I wished that the programs on my desktop couldn't communicate with each other by default
08:28 kennylevinsen: rarely do end-users sit and wish for security of any kind - best case, security is invisible when it works, worst case it's a nuisance - unless it's post-mortem regret
08:29 kennylevinsen: but like an insurance plan, "I don't need it most of the time" isn't a good counter argument
08:30 immibis: Is there a point in sandboxing clients via Wayland, if they can be spied on via /dev/input anyway?
08:31 kennylevinsen: They can't be spied on via dev input as no users have access, unless your system is misconfigured
08:32 kennylevinsen: seatd and logind only grant 1 program access to those (your display server) at any given time, and revoke access when switching or terminating sessions
08:39 MrCooper: can't get access to window contents via /dev/input
08:40 Company: MrCooper: I've argued/wondered in recent times about adding a GdkGPU abstraction to GTK and if that's a good idea. Are you a good person to have opinions about pros and cons of that and if so, do you have time after/during the HDR call on Wednesday?
08:43 MrCooper: sure on the latter, not sure on the former though
08:44 Company: who would know about that?
08:45 Company: I looked a bit and there's weird hacks everywhere and everyone seems to do their own thing
09:16 orowith2os[m]: MrCooper: not having those Wayland clients be able to spy on other clients? considering security is supposed to be a goal of Wayland, and a focus for Linux as time goes on, I'm surprised you're so pushy against having more clients on Wayland.
09:17 MrCooper: I'm not against that at all, quite the opposite
09:18 MrCooper: there's no need for WaylandX for that, Wayland has critical mass already
09:18 orowith2os[m]: a little extra push couldn't hurt, though
09:18 MrCooper: there are already Wayland-only applications, even commercial ones
09:18 orowith2os[m]: especially when the reason some people are holding onto X code is that, some people still use X
09:18 MrCooper: can't see WaylandX making any significant difference
09:19 orowith2os[m]: if not, it's still a potentially fun side project
09:19 kennylevinsen: orowith2os[m]: it's not pushback against wayland, just that we don't really see a need or benefit of WaylandX
09:19 orowith2os[m]: maybe hellish, but a learning experienc
09:19 kennylevinsen: you're still free to build it
09:20 orowith2os[m]: besides, there's a 70% chance I'll end up getting busy again and overwhelmed and that I don't have the help I need, and I'll drop the project
09:20 MrCooper: by the time that works usefully enough, Wayland will most certainly be used by a dominant majority of users anyway
09:20 orowith2os[m]: maybe
09:21 orowith2os[m]: wouldn't it be nice to get rid of a bunch of X code, though?
09:21 MrCooper: we can't, we'll have to maintain Xwayland ~forever
09:21 kennylevinsen: the problem with getting rid of X code is mainly clients that are already written :/
09:21 orowith2os[m]: I mean on the client side
09:21 kennylevinsen: direct X clients, proprietary clients, abandoned toolkits, ...
09:22 kennylevinsen: proprietary games statically linking to some bundled SDL version negative 5
09:22 orowith2os[m]: clients porting to Wayland, assuming they don't rely on anything Wayland can't provide, can very well rely on a WaylandX for X compat for those two users still on X
09:22 orowith2os[m]: and even then, probably simple enough to have a WaylandX protocol to have direct access to the X resources so you can mix the two as needed
09:22 kennylevinsen: sure, that might help cases where the client can port but would have to do it manually and do not want to maintain two backends
09:24 kennylevinsen: either way, if you have the time and an urge, go ahead, we're not stopping you
09:25 orowith2os[m]: at the very least, it would give me the experience writing some of a Wayland compositor I want, without the pains of going Low Level
09:25 kennylevinsen: just not entirely clear who needs it at the current time - but hey, I maintain stuff with a maximum user pool of 1, so...
09:25 orowith2os[m]: buuut right now I have some Zola RSS feed patches to work on
09:25 orowith2os[m]: :v
09:26 orowith2os[m]: I'll pick apart someone's smithay fork intended to be a waylandx, and reimpl it from that
09:41 Company: I would totally love to have a WaylandX
09:41 Company: because I'd instantly drop the X abckend from GTK and tell people to use WaylandX if they need to run on X
09:42 Company: though the way things are going, I can do that anyway by the time GTK5 comes around
09:45 orowith2os[m]: another interesting thing to think about: a wayland-like API, but as a library, like SDL
09:47 davidre: A toolkit that models wayland API?
09:47 davidre: Like you dont know where the library ends placing widgets? :D
09:48 davidre: Or more like no "setWindowPoistion" exposed that only works on X
09:48 orowith2os[m]: so many fun things to think about, so few to actually work on that would get used
09:52 orowith2os[m]: a library that is the Wayland API
09:52 orowith2os[m]: except you don't connect to a Wayland or an X11 socket, you just "init"
09:53 orowith2os[m]: no need to specifically have a Wayland socket when the library will have the same API and run on top of whatever anyways
09:55 MrCooper: Wayland is a protocol, not an API, similar to how reimplementing libX11 doesn't cover all X clients
09:57 orowith2os[m]: you get the idea
09:57 orowith2os[m]: it's Close Enough to the protocol that it'll work as a replacement, with a few patches
09:57 orowith2os[m]: possibly
10:19 Company: orowith2os[m]: that's a pretty useless idea, isn't it?
10:20 Company: because you need the compositor anyway, and if you already have a library that implements an interface for IPC with a compositor, why wouldn't you want to run it in a different process?
10:21 Company: at least that's the argument I've always given against a GTK backend that speaks KMS directly
10:22 Company: which has been brought up by projects like anaconda or kiosks
10:26 kennylevinsen: well, it would possibly ressemble Gdk, so the idea itself isn't that unthinkable
10:26 kennylevinsen: but it would probably end up as Yet Another Toolkit
11:09 Company: kennylevinsen: there's a pretty big difference between GDK and GTK I think
11:10 Company: GDK is more about having a neat abstraction ayer over the windowing system - and I thinkyou don't get that with a libwayland
11:11 Company: a lot of tricky parts are missing - like a rendering layer that can draw text
11:16 Company: afaics there's generally about 4 layers: windowing system (ie Wayland, X11), basic primitives (GDK, QPainter, Skia), low level widgets (GTK, Qt, <divs>), high level widgets (Adwaita, KDE, React)
11:17 Company: and I don't think such a library would fit that layering model
11:23 kennylevinsen: Company: I believe orowith2os[m]'s last suggestion was indeed a Gdk-like abstraction over wayland and X11, dealing with windows but not drawing
11:23 Company: yeah, but then you're still missing the other layers
11:24 kennylevinsen: That's not necessarily an issue, some clients do their own drawing but might just want to think less about wayland vs x11
11:25 kennylevinsen: But it is a bit of a niche - wanting an abstraction but *not* a toolkit
11:25 Company: yeah, but then they need to think about the limitations of that library
11:25 Company: and while you could write your API around those, you should at least have those clients at hand
11:25 kennylevinsen: That statement is true for any library, not matter what it does
11:26 Company: yeah - and I don't think those clients exist
11:27 Company: we've essentially been having that argument with Mozilla, who've wanted to do most of what GDK does themselves while GDK wants to expose fewer internals that basically only Mozilla uses
11:28 Company: about what Mozilla could be using instead of GDK - and I don't think they'd benefit from such a generic library unless it was specifically tailored to them
11:28 Company: they'd be better off speaking straight Wayland
11:29 kennylevinsen: Well they want parts of Gtk too, e.g. widgets that they render to Cairo contexts and import into webrender
11:29 kennylevinsen: That's a bit of a mess though
11:29 Company: no, they don't want that
11:29 Company: that's not been a thing for a while
11:30 kennylevinsen: When did they remove that?
11:30 Company: ~5 years ago that went away - no idea if that code still exists
11:30 Company: but websites stopped using windowing system controls or lookalikes
11:31 kennylevinsen: That can't be right, I ran into the code just a few years ago...
11:31 kennylevinsen: It's for e.g. the Firefox scrollbar
11:32 Company: webkitgtk has removed all of it I believe in favor of implementing their own styling
11:32 Company: they have a GTK4 port, and GTK4 removed all the custom styling hooks
11:33 Company: there's also the point that Firefox doesn't want to look like a GTK application
11:33 Company: they have different UX and different styling
11:34 Company: so they're better off imitating the general styling
11:37 Company: fwiw, that's the state of the art in the 2020s
11:37 Company: styling is decided by the applications - either themselves or by picking a platform to integrate into
11:39 Company: and there's no longer any cross-platform/application styling that can be switched to depending on what platform things are run on
11:39 Company: so Firefox looks like Firefox on Gnome or KDE
11:39 Company: and so do Gnome and KDE apps
11:57 kennylevinsen: Looking around, it seems they added support for non-native theming just 2 years ago
11:58 kennylevinsen: they still have all the gtk widget paint code and configs to toggle between them, so not sure where they are decision wise
11:58 kennylevinsen: but yeah, internal theming is what Chromium has always done. Firefox has just historically put in a lot of effort to *not* do that, suggesting they didn't want to do that.
12:00 kennylevinsen: but their weird Gtk entanglement has always been a problem, so no complaints here
12:00 kennylevinsen: Either way, Chromiums Ozone might be a good example of just this kind of abstraction
12:00 kennylevinsen: .. it's just that they already have that implementation
12:05 Company: Firefox has something like that, too
12:05 Company: after all, they don't use GTK on non-Linux
12:06 Company: I understand Firefox using GTK on X11, because GTK has the whole EWMH implementation
12:06 kennylevinsen: They have nsWindow and its implementations, but I wouldn't call it a formally designed abstraction
12:07 Company: but Firefox using GTK on Wayland feels like an abstraction too much
12:08 Company: and it's especially bad because it stops Firefox from using fancy new Wayland protocols that GTK didn't add support for
12:08 kennylevinsen: The fact that Gtk is still rendering underneath firefox is testament to it being the wrong choice :)
12:08 kennylevinsen: firefox is a giant subsurface on top of gtk's toplevel, with still rendering focus change dimming underneath
12:08 kennylevinsen: well, assuming nothing else changed since I looked at it alst
12:10 Company: yeah, that all happened when the new world order happened and Firefox abandoned Cairo
12:10 Company: plonk a surface (or multiple) on top and do your own thing
12:13 kennylevinsen: note: firefox gets its own registry and uses protocols directly behind Gtk's back, so it can use protocols Gtk does not support
12:14 kennylevinsen: ... but it's a mess
12:14 Company: yeah, but it has to be careful GTK doesn't do something that breaks things in subtle ways
12:24 wlb: weston Issue #863 closed \o/ (Handling subsurface rendering https://gitlab.freedesktop.org/wayland/weston/-/issues/863)
12:34 wlb: wayland Issue #432 opened by Waider W (waider) Wayland architecture https://gitlab.freedesktop.org/wayland/wayland/-/issues/432
12:40 mceier: and firefox is not careful at all - after each cold boot from hdd, when moving mouse while starting firefox for the first time results in crash, any I/O hiccup and I need to stop interacting with firefox otherwise it will crash - all because filling up the communication buffer is a protocol error; it's kinda annoying.
15:10 m0squ3ra: hey guys
15:10 vaxry: hi
15:13 m0squ3ra: is there some wayland dev here?
15:14 vaxry: there are yes
15:16 m0squ3ra: I'm trying to set up a dev environment to start contributing to the project, who can I talk to for help?
15:26 soreau: what part do you need help with?
15:28 m0squ3ra: just need to know if building wayland directly in my system will mess my current setup (I'm using X11 with I3)
15:29 kennylevinsen: It won't
15:29 m0squ3ra: ty
15:37 m0squ3ra: any compositor you recommend for development purposes?
15:40 bl4ckb0ne: depends on what you want to do
15:41 vaxry: hyprland
15:41 kennylevinsen: if you're developing clients, anything. If you're developing protocols, whichever one whose implementation you find comfortable to edit
15:42 kennylevinsen: yes yes, they can use hyprland if they like hyprland, but they can also use weston, sway, river, mutter, kwin, hikari, labwc, yadda yadda
15:44 soreau: m0squ3ra: you have the option to install a compositor and its dependencies to a nonstandard prefix (as user). This way, it has no chance to mess with your system files
15:44 m0squ3ra: my idea is to contribute to the protocol, so I'm looking for a simple compositor that allos me to see the results easily
15:45 soreau: m0squ3ra: then look no further than your repositories
15:45 soreau: there should be plenty to pick from, that you don't have to build manually
15:46 m0squ3ra: ok, thank you guys!
16:03 immibis: MrCooper: can get access to window contents via $HOME
16:05 immibis: MrCooper: protocols are APIs
16:17 kennylevinsen: you cannot get access to window contents via $HOME, but you can pwn the system that way. Hence why sandboxing is required.
16:20 kennylevinsen: and yes protocols are APIs
16:48 vincejv:patiently waits for desktop apps to be wayland compatible
16:51 bl4ckb0ne: why patiently wait when you can contribute to make them compatible quicker
16:52 vaxry: or just rewrite them in C++ with wayland support from the beginning
17:45 kennylevinsen: Or any other language as that doesn't matter
19:05 wlb: weston Merge request !1438 opened by Colin Kinloch (ColinKinloch) clients/stacking: Fix widget user_data cast type https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1438
20:37 mizvekov: Regarding writing wayland clients, are the life cycles of all globals similarly unconstrained?
20:37 mizvekov: For example, basic singletons like wl_compositor, wl_shm, xdg_shell, can I safely assume they will be available immediately and will never be removed?
20:57 soreau: mizvekov: globals can be removed at any time, so clients should be prepared to handle this somehow. Though in practice, most compositors don't remove or destory globals AFAIK
20:57 ManMower: I guess destroying seats is a real thing...
20:58 mizvekov: yeah seats I expected, since that is not a singleton, and represents something hotpluggable
20:58 ids1024: In practice you can assume things like `wl_shm` and `xdg_shell` will be available from application start and never removed just because everyone else's clients probably don't handle that and would break if they did something different.
20:58 ManMower: ^
20:59 soreau: yea, outputs come and go too
20:59 mizvekov: afaik the singletons I mentioned, handling their absence is a PITA, as there not many good options here.
20:59 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/ext-transient-seat/ext-transient-seat-v1.xml for destroying seats
20:59 ids1024: I think there was some idea about providing more formal guarantees about that with some globals? Or maybe I'm mixing that up with another issue.
21:00 soreau: mizvekov: exit(1);
21:00 ids1024: `wl_seat` in contrast is very explicitly meant to be added and removed by design, though unfortunately the same may apply in practice, and applications won't correctly handle multiple seats or hotplugging.
21:01 soreau: the gpu could reset too, then you'd want to handle that if you want to be robust
21:02 mizvekov: Well exit(1) would be the sort of thing to do in case of internal error that you can't explain to the user, much like some assert failing.
21:03 mizvekov: But if wl_compositor could come and go by design, then you would probably want to keep your application working.
21:05 mizvekov: But wl_compositor, wl_shm and such are not tied to gpus, in fact one wayland session can have multiple gpus, and presumably some of them failing would affect a group of outputs.
21:08 soreau: if your compositor or app or whatever else is using the gpu that crashes, they have to reset context at least
21:09 ids1024: Yeah, there's not much reason for `wl_compositor` or `wl_shm` to be added or removed dynamically. And I expect if you try to modify a compositor to do that, you'll probably find essentially zero clients actually handle it. So you can probably assume that. Perhaps the protocol spec could be more explicit about that given it's already a de-facto requirement for any general purpose
21:09 ids1024: compositor.
21:09 mizvekov: I know that if you are using vulkan and such to render, that would come up through their APIs. If you are drawing to wl_buffers directly, I guess that should cause the buffer to become invalid perhaps?
21:11 ids1024: I don't think there's any way for the compositor to communicate that it's no longer able to read from an already created dmabuf wl_buffer, but presumably if you try to write to it in some way, and it's on a GPU that was removed, your system calls will error.
21:15 ids1024: (Or well, dmabuf feedback does provide a way for it to indicate a change in the devices/formats/modifiers it can accept buffers using, so I guess that amounts to the same thing, as long as the client keeps track of everything properly.)
21:15 mizvekov: I think there is a piece missing in the wayland protocol, the client being able to notify the server, after receiving a global removal notification, that it's done using that resource. Though I suspect this is only an issue for the server, as it would not be able to truly free / forget about that global.
21:18 ids1024: There's things like `wl_output::release`. But globals like `wl_shm` don't have a destructor, it seems.
21:19 ManMower: https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html is a fun read on object lifetimes