ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Guest13229 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest13262
garnacho has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Guest13262 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest13270
silverpower_ has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
Company has joined #wayland
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
mizvekov has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
TheCaptain82970403 has joined #wayland
TheCaptain8297040 has quit [Ping timeout: 480 seconds]
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<mizvekov>
Regarding writing wayland clients, are the life cycles of all globals similarly unconstrained?
<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?
TheCaptain829704031 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
TheCaptain82970403 has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
sima has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
leon-anavi has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
<MrCooper>
immibis: for all the reasons Wayland was created separate from X in the first place
<MrCooper>
orowith2os[m]: "rootful WaylandX" is just a Wayland compositor with an X backend
<MrCooper>
orowith2os[m]: is there a point in sandboxing clients via Wayland, if they can be spied on via X anyway?
<immibis>
and what are those relevant reasons?
<immibis>
the point is to run Wayland clients
<MrCooper>
e.g. atomic updates and client isolation
<immibis>
you know, never in my life have I wished that the programs on my desktop couldn't communicate with each other by default
<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
<kennylevinsen>
but like an insurance plan, "I don't need it most of the time" isn't a good counter argument
mvlad has joined #wayland
<immibis>
Is there a point in sandboxing clients via Wayland, if they can be spied on via /dev/input anyway?
<kennylevinsen>
They can't be spied on via dev input as no users have access, unless your system is misconfigured
<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
privacy has joined #wayland
<MrCooper>
can't get access to window contents via /dev/input
<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?
glennk has joined #wayland
<MrCooper>
sure on the latter, not sure on the former though
rasterman has joined #wayland
<Company>
who would know about that?
<Company>
I looked a bit and there's weird hacks everywhere and everyone seems to do their own thing
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
ofourdan has joined #wayland
<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.
<MrCooper>
I'm not against that at all, quite the opposite
<MrCooper>
there's no need for WaylandX for that, Wayland has critical mass already
<orowith2os[m]>
a little extra push couldn't hurt, though
<MrCooper>
there are already Wayland-only applications, even commercial ones
<orowith2os[m]>
especially when the reason some people are holding onto X code is that, some people still use X
<MrCooper>
can't see WaylandX making any significant difference
<orowith2os[m]>
if not, it's still a potentially fun side project
<kennylevinsen>
orowith2os[m]: it's not pushback against wayland, just that we don't really see a need or benefit of WaylandX
<orowith2os[m]>
maybe hellish, but a learning experienc
<kennylevinsen>
you're still free to build it
<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
<MrCooper>
by the time that works usefully enough, Wayland will most certainly be used by a dominant majority of users anyway
<orowith2os[m]>
maybe
<orowith2os[m]>
wouldn't it be nice to get rid of a bunch of X code, though?
<MrCooper>
we can't, we'll have to maintain Xwayland ~forever
<kennylevinsen>
the problem with getting rid of X code is mainly clients that are already written :/
<orowith2os[m]>
I mean on the client side
<kennylevinsen>
direct X clients, proprietary clients, abandoned toolkits, ...
<kennylevinsen>
proprietary games statically linking to some bundled SDL version negative 5
<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
<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
<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
floof58 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
either way, if you have the time and an urge, go ahead, we're not stopping you
<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
<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...
<orowith2os[m]>
buuut right now I have some Zola RSS feed patches to work on
<orowith2os[m]>
:v
<orowith2os[m]>
I'll pick apart someone's smithay fork intended to be a waylandx, and reimpl it from that
rgallaispou has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<Company>
I would totally love to have a WaylandX
<Company>
because I'd instantly drop the X abckend from GTK and tell people to use WaylandX if they need to run on X
<Company>
though the way things are going, I can do that anyway by the time GTK5 comes around
<orowith2os[m]>
another interesting thing to think about: a wayland-like API, but as a library, like SDL
vova_ has joined #wayland
<davidre>
A toolkit that models wayland API?
<davidre>
Like you dont know where the library ends placing widgets? :D
<davidre>
Or more like no "setWindowPoistion" exposed that only works on X
<orowith2os[m]>
so many fun things to think about, so few to actually work on that would get used
vova_ has quit [Remote host closed the connection]
glennk has joined #wayland
<orowith2os[m]>
a library that is the Wayland API
<orowith2os[m]>
except you don't connect to a Wayland or an X11 socket, you just "init"
<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
narodnik1 has joined #wayland
<MrCooper>
Wayland is a protocol, not an API, similar to how reimplementing libX11 doesn't cover all X clients
<orowith2os[m]>
you get the idea
<orowith2os[m]>
it's Close Enough to the protocol that it'll work as a replacement, with a few patches
<orowith2os[m]>
possibly
qaqland is now known as Guest13314
qaqland has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Guest13314 has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
<Company>
orowith2os[m]: that's a pretty useless idea, isn't it?
<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?
<Company>
at least that's the argument I've always given against a GTK backend that speaks KMS directly
<Company>
which has been brought up by projects like anaconda or kiosks
<kennylevinsen>
well, it would possibly ressemble Gdk, so the idea itself isn't that unthinkable
<kennylevinsen>
but it would probably end up as Yet Another Toolkit
vova has quit [Remote host closed the connection]
vova has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
<Company>
kennylevinsen: there's a pretty big difference between GDK and GTK I think
bindu has quit [Remote host closed the connection]
<Company>
GDK is more about having a neat abstraction ayer over the windowing system - and I thinkyou don't get that with a libwayland
bindu has joined #wayland
kts has quit [Quit: Leaving]
<Company>
a lot of tricky parts are missing - like a rendering layer that can draw text
<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)
<Company>
and I don't think such a library would fit that layering model
<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
<Company>
yeah, but then you're still missing the other layers
<kennylevinsen>
That's not necessarily an issue, some clients do their own drawing but might just want to think less about wayland vs x11
<kennylevinsen>
But it is a bit of a niche - wanting an abstraction but *not* a toolkit
<Company>
yeah, but then they need to think about the limitations of that library
<Company>
and while you could write your API around those, you should at least have those clients at hand
<kennylevinsen>
That statement is true for any library, not matter what it does
<Company>
yeah - and I don't think those clients exist
<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
<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
<Company>
they'd be better off speaking straight Wayland
<kennylevinsen>
Well they want parts of Gtk too, e.g. widgets that they render to Cairo contexts and import into webrender
<kennylevinsen>
That's a bit of a mess though
<Company>
no, they don't want that
<Company>
that's not been a thing for a while
<kennylevinsen>
When did they remove that?
<Company>
~5 years ago that went away - no idea if that code still exists
<Company>
but websites stopped using windowing system controls or lookalikes
<kennylevinsen>
That can't be right, I ran into the code just a few years ago...
<kennylevinsen>
It's for e.g. the Firefox scrollbar
<Company>
webkitgtk has removed all of it I believe in favor of implementing their own styling
<Company>
they have a GTK4 port, and GTK4 removed all the custom styling hooks
<Company>
there's also the point that Firefox doesn't want to look like a GTK application
<Company>
they have different UX and different styling
<Company>
so they're better off imitating the general styling
Brainium has joined #wayland
<Company>
fwiw, that's the state of the art in the 2020s
<Company>
styling is decided by the applications - either themselves or by picking a platform to integrate into
<Company>
and there's no longer any cross-platform/application styling that can be switched to depending on what platform things are run on
<Company>
so Firefox looks like Firefox on Gnome or KDE
<Company>
and so do Gnome and KDE apps
<kennylevinsen>
Looking around, it seems they added support for non-native theming just 2 years ago
<kennylevinsen>
they still have all the gtk widget paint code and configs to toggle between them, so not sure where they are decision wise
<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.
<kennylevinsen>
but their weird Gtk entanglement has always been a problem, so no complaints here
<kennylevinsen>
Either way, Chromiums Ozone might be a good example of just this kind of abstraction
<kennylevinsen>
.. it's just that they already have that implementation
<Company>
Firefox has something like that, too
<Company>
after all, they don't use GTK on non-Linux
<Company>
I understand Firefox using GTK on X11, because GTK has the whole EWMH implementation
<kennylevinsen>
They have nsWindow and its implementations, but I wouldn't call it a formally designed abstraction
<Company>
but Firefox using GTK on Wayland feels like an abstraction too much
<Company>
and it's especially bad because it stops Firefox from using fancy new Wayland protocols that GTK didn't add support for
<kennylevinsen>
The fact that Gtk is still rendering underneath firefox is testament to it being the wrong choice :)
<kennylevinsen>
firefox is a giant subsurface on top of gtk's toplevel, with still rendering focus change dimming underneath
<kennylevinsen>
well, assuming nothing else changed since I looked at it alst
<Company>
yeah, that all happened when the new world order happened and Firefox abandoned Cairo
<Company>
plonk a surface (or multiple) on top and do your own thing
<kennylevinsen>
note: firefox gets its own registry and uses protocols directly behind Gtk's back, so it can use protocols Gtk does not support
<kennylevinsen>
... but it's a mess
<Company>
yeah, but it has to be careful GTK doesn't do something that breaks things in subtle ways
<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.
lsd|2 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Brainium has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
kts has joined #wayland
Arsen has quit [Quit: Quit.]
Arsen has joined #wayland
TheCaptain8297040319 has joined #wayland
TheCaptain829704031 has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
narodnik1 has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
TheCaptain82970403198 has joined #wayland
kts has joined #wayland
floof58 has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
TheCaptain8297040319 has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
kts has quit []
vova has quit [Remote host closed the connection]
TheCaptain829704031985 has joined #wayland
vova has joined #wayland
TheCaptain82970403198 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
TheCaptain8297040319857 has joined #wayland
TheCaptain829704031985 has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
garnacho has joined #wayland
AnuthaDev has joined #wayland
AnuthaDev has quit []
m0squ3ra has joined #wayland
m0squ3ra has left #wayland [#wayland]
AnuthaDev has joined #wayland
m0squ3ra has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
<m0squ3ra>
hey guys
<vaxry>
hi
<m0squ3ra>
is there some wayland dev here?
hex[m]1 has quit [Quit: Client limit exceeded: 20000]
<vaxry>
there are yes
<m0squ3ra>
I'm trying to set up a dev environment to start contributing to the project, who can I talk to for help?
<soreau>
what part do you need help with?
<m0squ3ra>
just need to know if building wayland directly in my system will mess my current setup (I'm using X11 with I3)
<kennylevinsen>
It won't
<m0squ3ra>
ty
kts has joined #wayland
<m0squ3ra>
any compositor you recommend for development purposes?
<bl4ckb0ne>
depends on what you want to do
<vaxry>
hyprland
<kennylevinsen>
if you're developing clients, anything. If you're developing protocols, whichever one whose implementation you find comfortable to edit
<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
<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
<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
<soreau>
m0squ3ra: then look no further than your repositories
<soreau>
there should be plenty to pick from, that you don't have to build manually
<m0squ3ra>
ok, thank you guys!
<immibis>
MrCooper: can get access to window contents via $HOME
<immibis>
MrCooper: protocols are APIs
<kennylevinsen>
you cannot get access to window contents via $HOME, but you can pwn the system that way. Hence why sandboxing is required.
Hypfer is now known as Guest13363
Hypfer has joined #wayland
Guest13363 has quit [Read error: Connection reset by peer]
<kennylevinsen>
and yes protocols are APIs
m0squ3ra has quit [Remote host closed the connection]
AnuthaDev has quit [Quit: AnuthaDev]
* vincejv
patiently waits for desktop apps to be wayland compatible
leon-anavi has quit [Quit: Leaving]
<bl4ckb0ne>
why patiently wait when you can contribute to make them compatible quicker
<vaxry>
or just rewrite them in C++ with wayland support from the beginning
rgallaispou has left #wayland [#wayland]
sevz has quit [Quit: Client quit]
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
zestyluna has joined #wayland
Fxzxmic has quit [Quit: Konversation exit!]
<kennylevinsen>
Or any other language as that doesn't matter
Brainium has quit [Quit: Konversation terminated!]
qaqland has quit [Remote host closed the connection]
qaqland has joined #wayland
Brainium has joined #wayland
tlwoerner_ has quit []
tlwoerner has joined #wayland
privacy has quit [Quit: Leaving]
mokee has quit [Quit: off]
<mizvekov>
Regarding writing wayland clients, are the life cycles of all globals similarly unconstrained?
<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?
sima has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
m0squ3ra has quit [Remote host closed the connection]
<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
<ManMower>
I guess destroying seats is a real thing...
<mizvekov>
yeah seats I expected, since that is not a singleton, and represents something hotpluggable
<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.
<ManMower>
^
<soreau>
yea, outputs come and go too
<mizvekov>
afaik the singletons I mentioned, handling their absence is a PITA, as there not many good options here.
<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.
<soreau>
mizvekov: exit(1);
<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.
<soreau>
the gpu could reset too, then you'd want to handle that if you want to be robust
<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.
<mizvekov>
But if wl_compositor could come and go by design, then you would probably want to keep your application working.
<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.
<soreau>
if your compositor or app or whatever else is using the gpu that crashes, they have to reset context at least
<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
<ids1024>
compositor.
<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?
<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.
<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.)
<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.
<ids1024>
There's things like `wl_output::release`. But globals like `wl_shm` don't have a destructor, it seems.