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.
<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.
<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>
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?
<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]