ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
number0ne_ has joined #wayland
number0ne has quit [Read error: Connection reset by peer]
alatiera has quit [Read error: Connection reset by peer]
alatiera has joined #wayland
number0ne_ has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
feaneron has quit [Quit: feaneron]
nerdopolis has quit [Ping timeout: 480 seconds]
<DemiMarie> orowith2os[m]: why not Rust?
<DemiMarie> Serious question
<DemiMarie> orowith2os[m]: this is for the compositor work, obviously
<DemiMarie> changing the signature of a function is technically an API-breaking (but not ABI-breaking I believe) change because of function pointers, but I would be fine making users add explicit casts if they need them.
<danieldg> correct, so long as it's not C++ (the consts end up in the symbols due to mangling there)
tent4052 has joined #wayland
<orowith2os[m]> DemiMarie: I don't want to deal with SDL3 and Rust for Wayland right now.
<DemiMarie> orowith2os[m]: had not considered the SDL3 requirement
<DemiMarie> there are mature Rust crates for Wayland, though
<orowith2os[m]> I could very well also use GTK4, I just need a cross-platform GUI toolkit that lets me access enough of the system to expose an equivalent Wayland API.
<orowith2os[m]> Not even GUI, actually? Windowing library is just fine.
<orowith2os[m]> I won't be relying on smithay or wlroots or libweston because I want to do the work myself, as a learning experience, and because I probably wouldn't even need all that with a simple windowing library.
<orowith2os[m]> I'm actually having troubles with SDL3 right now because it doesn't give me absolute display information; the DisplayBounds I get from it are in logical form, and it's a pain to convert them to absolute. So wl_output positioning is broken, and clients will have to rely on xdg-output if they're running under my compositor.
FreeFull has quit []
Brainium has joined #wayland
karenw has joined #wayland
andymandias has quit [Remote host closed the connection]
<DemiMarie> orowith2os[m]: What about winit in Rust? That’s assuming you prefer Rust to C++, which is my understanding from other discussions.
<orowith2os[m]> DemiMarie: I still need to write the actual wayland compositor, and wayland-rs isn't the *best*? Maybe once I have a working demo with C++, I'll move over to Rust.
<DemiMarie> orowith2os[m]: Is this a rootful or rootless compositor?
<orowith2os[m]> rootless.
<orowith2os[m]> it'll be running on X11 and, if possible, non-Linux platforms as well.
andymandias has joined #wayland
<whot> orowith2os[m]: I ... don't know? I generally really don't want to touch the API unless absolutely necessary. in the past having const has bitten me too but that depends on the exact use-case
<whot> set_points looks like it can be constified with no impact though
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
glennk has joined #wayland
<zzxyb[m]> Are there any breaking commits from wayland 0.17.0 to 0.21.0?
kts has joined #wayland
mripard has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
bwbuhse has quit [Ping timeout: 480 seconds]
bwbuhse has joined #wayland
tzimmermann has joined #wayland
<DemiMarie> orowith2os[m]: you will absolutely need to have _NET_WM_SYNC_REQUEST in the X11 window manager
<DemiMarie> I tried working without that and failed after maybe a year of work.
<DemiMarie> Even with that you might run into problems because Wayland and X11 disagree on whose state for window szes is authoritative.
sima has joined #wayland
kts has joined #wayland
leon-anavi has joined #wayland
garnacho has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
rasterman has joined #wayland
<pq> orowith2os[m], signal handling? Async-signal safe context required?
<pq> orowith2os[m], 'man 7 signal-safety' is a good reading if you weren't aware yet, and noting that e.g. free() is not safe.
Company has quit [Quit: Leaving]
zorowk has joined #wayland
zorowk has left #wayland [#wayland]
mriesch has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
kestrel has joined #wayland
feaneron has joined #wayland
kts has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
kts has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
Moprius has joined #wayland
mriesch has joined #wayland
rgallaispou has joined #wayland
mriesch has quit [Remote host closed the connection]
mriesch has joined #wayland
mriesch has quit [Remote host closed the connection]
mriesch has joined #wayland
mriesch has quit [Remote host closed the connection]
mriesch has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
yrlf has quit [Ping timeout: 480 seconds]
mriesch has quit []
mriesch has joined #wayland
yrlf has joined #wayland
mriesch has quit [Remote host closed the connection]
mriesch has joined #wayland
mriesch has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
rgallaispou has left #wayland [#wayland]
mriesch has joined #wayland
kts has joined #wayland
kestrel has quit [Quit: The Lounge - https://thelounge.chat]
kestrel has joined #wayland
feaneron has quit []
<orowith2os[m]> pq: haven't gotten that far yet
feaneron has joined #wayland
<orowith2os[m]> I very well could rewrite it in Rust if all that is a problem though.
<pq> orowith2os[m], it depends on how you handle signals. signalfd is fine, but in a traditional signal handler you'd best just set a global flag variable and do nothing else.
<orowith2os[m]> fwiw my current state of it is up at https://gitlab.com/orowith2os/rxwl
<orowith2os[m]> feel free to rip it apart however you like
<mclasen> gtk now has an easy way to opt out of certain protocols
<mclasen> useful for debugging, if nothing else
<orowith2os[m]> could libwayland hide certain protocols too?
<pq> libwayland-server already can, libwayland-client not without ugly hacky things
rgallaispou has joined #wayland
Brainium has quit []
nerdopolis has joined #wayland
<paulk> hi, back to drm backend multi-device support, one thing seems to be that the renderer and weston_compositor are created per-backend
<paulk> when the renderer needs a gbm handle created from the drm device
<paulk> so in turn dependent on the drm_device, not the backend
gfxstrand has joined #wayland
<paulk> does the current weston design support having a different renderer for each backend running in parallel?
<paulk> or is the renderer expected to be the same for all backends/outputs?
karenw has joined #wayland
<pq> paulk, I believe the renderer must be the same for all backends. Renderer features determine features exposed to clients, and they cannot sometimes fail.
<pq> the weston_compositor instance is shared across all backends
<orowith2os[m]> You could expose the minimum supported features across all backends, would just need rework within Weston, no?
<paulk> mhh
<pq> orowith2os[m], yeah, "just".
<paulk> so the problem here is that e.g. gbm requires a drm device fd
<pq> I don't see what benefit there would be.
<swick[m]> emersion: would appreciate a review on https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/465
<paulk> so if there's two outputs with two different drm devices we really need a different gbm instance for each
<paulk> and in turn a dedicated renderer
<paulk> or maybe gbm can be decorelated from renderer
<emersion> drm devices can be hot-plugged, and you can know in advance what features they will support
<orowith2os[m]> otherwise you'll be rendering on one device, and copying (or using a dmabuf) everything over to the other output, right?
<pq> paulk, or, use the other DRM device GBM instance only for allocation and import the buffer into the renderer's instance, or do a copy.
<emersion> you can't know*
<emersion> swick[m]: yup, on my todo list
<swick[m]> great, thanks!
<paulk> pq: yeah I guess gbm is only really ever useful for allocating scanout buffers
<orowith2os[m]> emersion: while you're here, did you have any thoughts on landing https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/389 ?
<emersion> i'm still unsure about this
<pq> paulk, the problem with having two renderers on different devices is that yoou'd have to duplicate textures between them, and they might support different formats and features.
<paulk> yes I think duplicating renderer would be a pretty bad path to follow
<paulk> and in practice the renderer per-se is typically a gpu that's not tied to a particular display engine
<paulk> so it makes sense to assume a single renderer for all backends/outputs
<pq> paulk, I thought Weston already supports additional KMS devices, does it not?
<orowith2os[m]> emersion: I'd like to use it in my own code to build some warnings in that the available libwayland provides us newer interfaces than what we provide, instead of having to manually go and check for protocol updates otherwise. I know the wl_interface struct has a version field, but that's only for runtime.
<paulk> pq: yes it does but there is still a "main drm device"
<pq> paulk, right, the rendered has to have a device.
<pq> *renderer
kts has quit [Ping timeout: 480 seconds]
<paulk> pq: I don't think the drm device is really used in the gl render but it of course needs the gbm pointer derived from it
<paulk> it's not very clear to me yet how additional drm devices manage allocation
<paulk> I guess they would allocate on that main drm device and then import buffers
<paulk> but I haven't found the code that does that yet
<pq> Migration to a different rendering device is not very feasible, all clients need to migrate as well or re-establish the Wayland connection to discover the feature set.
<paulk> right
<paulk> pq: btw my final use case here is to support a client wanting output clone on 2 different drm devices, using the weston-imx code that has vivante g2d supporty
<pq> Scanout memory is tricky enough that it should be allocated on the KMS device where it will be used. That is much more likely to work than the opposite.
<paulk> yeah especially due to lack of iommu (contig alloc) + sometimes memory area constraints
<daniels> paulk: there's actually an MR upstream for g2d-renderer support, which is probably a more fruitful path than relying on weston-imx
<paulk> daniels: oh nice, I didn't see it, thanks! It's still using the proprietary verisilicon g2d library?
<daniels> yeah
<wlb> weston Issue #925 closed \o/ (Forever painted client buffer on a transparent background https://gitlab.freedesktop.org/wayland/weston/-/issues/925)
<paulk> that one?
<paulk> seems to be etnaviv actually :)
<wlb> weston Merge request !1711 opened by Loïc Molinari (molinari) gl-renderer: Init output borders with transparent pixels https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1711 [GL renderer]
<paulk> glad to see there's still interest in mainline 2d acceleration though, maybe eventually we'll talk about having a unified library (mesa-ish) and API and that could be used by weston
<paulk> and have support for all those 2d accelerators there, with drm render drivers
<paulk> (something I would be really glad to work on if given the opportunity :)
mclasen has quit [Remote host closed the connection]
DemiMarie is now known as Guest12630
DemiMarieObenour[m] is now known as DemiMarie
peeterm has quit [Quit: Leaving]
<wlb> weston Issue #528 closed \o/ (Support seperated video overlays with weston https://gitlab.freedesktop.org/wayland/weston/-/issues/528)
<wlb> weston Issue #9 closed \o/ (Support punch-through underlays in DRM backend https://gitlab.freedesktop.org/wayland/weston/-/issues/9)
Drakulix has quit [Ping timeout: 480 seconds]
number0ne_ has joined #wayland
mclasen has joined #wayland
Drakulix has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
number0ne_ has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
karenw has quit [Ping timeout: 480 seconds]
gallo has joined #wayland
gallo has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
Tedesco has joined #wayland
Tedesco has quit [Quit: WeeChat 2.8]
Company has joined #wayland
leon-anavi has quit [Quit: Leaving]
user21 has joined #wayland
___nick___ has joined #wayland
FreeFull has joined #wayland
___nick___ has quit [Remote host closed the connection]
akimoto has joined #wayland
karenw has joined #wayland
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mripard_ has joined #wayland
mripard has quit [Ping timeout: 480 seconds]
akimoto has quit [Remote host closed the connection]
ramblurr has quit [Remote host closed the connection]
ramblurr has joined #wayland
Brainium has joined #wayland
__nick__ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
__nick__ has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit []
Brainium has joined #wayland
FreeFull has quit [Quit: Lost terminal]
Brainium has quit [Quit: Konversation terminated!]
vsyrjala has quit [Ping timeout: 480 seconds]
vsyrjala has joined #wayland
aelius has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
FreeFull has joined #wayland
sima has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
sewn has quit [Read error: Connection reset by peer]
sewn has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
DodoGTA is now known as Guest12656
DodoGTA has joined #wayland
Guest12656 has quit [Ping timeout: 480 seconds]
tagr has quit [Remote host closed the connection]
sewn has quit [Read error: Connection reset by peer]
sewn has joined #wayland
cptaffe has quit [Ping timeout: 480 seconds]
aelius has joined #wayland
karenw has joined #wayland
JakeSays1 has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]