ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
zebrag has quit [Remote host closed the connection]
slattann has joined #wayland
danvet has joined #wayland
leon-p has joined #wayland
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #wayland
leon-p has quit []
hill has quit [Remote host closed the connection]
hill has joined #wayland
sstiller has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
tzimmermann has joined #wayland
pnowack has joined #wayland
rgallaispou has joined #wayland
psydroid[m]1 is now known as psydroid
rasterman has joined #wayland
slattann has quit []
hill has quit [Remote host closed the connection]
hendursa1 has joined #wayland
<pq>
DemiMarieObenour[m], you might as well just delete Weston completely. The main reason for weston existence are the Wayland protocol implementations and KMS usage. Not the end user facing parts.
<pq>
That also explains why Weston is so unfriendly as a desktop - friendlyness has never been a goal to begin with.
hendursaga has quit [Ping timeout: 480 seconds]
<kennylevinsen>
It is technically built on "something like wlroots": libweston
slattann has joined #wayland
slattann has quit []
slattann has joined #wayland
<DemiMarieObenour[m]>
<pq> "Demi Marie Obenour, you might as..." <- Does Weston still have a purpose now that wlroots exists?
<pq>
DemiMarieObenour[m], as Weston developer exclusively, I am of course biased in answering that, but yes, I believe it does. Weston makes some different fundamental design decisions, for better or worse.
<DemiMarieObenour[m]>
pq: What are they? I am genuinely curious.
<emersion>
weston _could_ be based on wlroots and still keep its DRM backend and additional protocol impls
<DemiMarieObenour[m]>
kennylevinsen: does anyone actually use libweston?
<emersion>
but like GNOME and KDE, the main hurdle is that it would take a lot of effort and introduce new bugs (big refactorings always introduce bugs)
<pq>
DemiMarieObenour[m], mostly companies that have no reason the advertising that they use Weston in their embedded products.
<DemiMarieObenour[m]>
So what are the main design differences between Weston and wlroots?
<emersion>
Weston is a midlayer, wlroots is a framework
<DemiMarieObenour[m]>
confused
<emersion>
weston gives you a working compositor quicker, but you're limited by its opinionated choices
<pq>
that's a good question, I'm thinking but it's hard for me to put it into words since I don't really know wlroots much. Maybe daniels can say something?
<pq>
what emersion is saying is certainly true of weston
<emersion>
wlroots requires you more boilerplate and logic, but you replace any part of it with your own logic/impl if you don't like it
<emersion>
think of wlroots as a set of optional helpers
<daniels>
^ all of the above is accurate
<emersion>
to give an example, if you'd want to add wobbly windows to weston, it'd either require forking weston or resorting to bad hacks
<DemiMarieObenour[m]>
For my use-case (Qubes OS in-qube compositor), my understanding is that a custom weston backend would have been the correct abstraction, but only if rootless and xdg-decoration (force server decoration without actually drawing any) support was posible.
<daniels>
end-to-end manner, or provide a more efficient display pipeline.
<daniels>
weston's main focus is on reliability - not only in terms of not crashing or looking weird, but also reliably performant. to that end a lot of its restrictive design choices try to make it as difficult as possible to end up with poor performance. it also tries to hem pretty closely to hardware capability, so often ends up as a kind of 'showcase' for new hardware features which either show how to use new capabilities in a solid
d_ed has joined #wayland
<emersion>
that's a good point!
<DemiMarieObenour[m]>
Is the main user of weston embedded systems?
<emersion>
rootless doesn't seem in scope for weston tbh
<daniels>
depends on how you define 'embedded', but yes - it's used a lot in automotive, in-flight entertainment, kiosks and other display walls, and a lot of consumer products you wouldn't necessarily expect
<daniels>
as for rootless, eh, you can just make every toplevel its own output?
<DemiMarieObenour[m]>
Hopefully Microsoft will upstream their patches.
<daniels>
emersion: subsurfaces and popups work, as long as they stay within the extents
<emersion>
yeah, and in many cases they don't
<daniels>
DemiMarieObenour[m]: they're available at https://github.com/microsoft/weston-mirror but I haven't heard a clear timeline for upstreaming (and tbh, they would need rework)
<DemiMarieObenour[m]>
emersion: How bad is it to clip out-of-bounds subsurfaces? In Qubes OS, not doing so would be significantly more work.
<emersion>
clipping subsurfaces shouldn't be too bad if you use the xdg-surface window geometry as the extents
<DemiMarieObenour[m]>
Indeed I do
<DemiMarieObenour[m]>
I also have to clip the main window to that geometry for GNOME Terminal, Weston Terminal, Zenity, and Weston to render properly.
<DemiMarieObenour[m]>
daniels: How much of one would be necessary?
<DemiMarieObenour[m]>
<daniels> "depends on how you define '..." <- Should Weston advertise this more? Which would be a better choice for me, as someone who has had to learn on the go?
<DemiMarieObenour[m]>
Perhaps? Ideally there would be a “I want to build a Wayland compositor, where do I start?” document somewhere, but that should probably be a separate project.
<DemiMarieObenour[m]>
Especially since you have people like me, who are starting out with very little knowledge about Wayland, but are stuck with a rendering API none of the existing compositors support.
<DemiMarieObenour[m]>
(And input)
<pq>
yeah, that should probably live outside of any compositor project - I'm not aware of such review having been written either.
<daniels>
(yes, we should advertise more and planning to work on docs soon)
<DemiMarieObenour[m]>
Right now I am using Smithay (which is of similar level to wlroots) and the only way I could get started was to fork their sample compositor, Anvil.
<pq>
sounds like the practical approach to me
<DemiMarieObenour[m]>
Honestly, I was hoping for something of the form “implement these callbacks and you will have a working compositor”, but didn’t find anything like it. Greedy, I know.
<DemiMarieObenour[m]>
Is it reasonable to limit shm buffers to 16384x6144? If I do, should I return `WL_DISPLAY_ERROR_IMPLEMENTATION` when that is exceeded?
leon-p has joined #wayland
<daniels>
I think out-of-memory is perfectly fine to be honest: is the client actually going to react differently to 'the compositor couldn't allocate my resources because OOM', 'the compositor couldn't allocate my resources because whilst more paged virtual memory was available, the GPU is restricted to 4096x4096 and they can't be bothered sharding textures', and 'the compositor refused to allocate my resources because of a quota'?
MrCooper has quit [Quit: Leaving]
<pq>
Right, there is no need to differentiate that in the error code. If you want to help manual troubleshooting, use the message string.
<DemiMarieObenour[m]>
<daniels> "I think out-of-memory is..." <- Gotcha. Is 16384x6144 a reasonable limitation to impose in practice?
<daniels>
absolutely, yeah
MrCooper has joined #wayland
<DemiMarieObenour[m]>
BTW, the one case I can think of where a client might actually inspect the error is if it uses short-lived connections to figure out what the compositor’s limits are.
<emersion>
yeah, hm, don't do that
<emersion>
clients aren't expected to use protocol errors like this
<pq>
definitely never do that, that's not how Wayland is designed
<pq>
if some thing is optional for compositors to support, then the protocol extension must be designed to let the client know without trying whether it will work, or at least explicitly define a graceful failure sequence if it's impractical to know beforehand.
<pq>
example 1: wl_shm interface advertises the supported pixel formats which are guaranteed to work, and any other pixel format is illegal to try.
<pq>
example 2: zwp_linux_dmabuf_v1 extension has explicit events for successful and failed buffer creation, so it does not raise protocol errors on arbitrary failure.
<pq>
granted, buffer dimension limits we don't have yet
<pq>
so that's something to fix in the protocol spec
<emersion>
hasn't really been an issue so far though
<pq>
yeah, I don't recall complaints
<pq>
also wl_shm is only limited by RAM, and there are ways to work around e.g. GL texture size limits if a compositor cares about it.
<pq>
but if texture size limits are a problem, I'm not sure the system is going to run too well in the first place
<dottedmag>
I suppose it's legal for compositor to assign different limits to different connections? Particularly devious compositor might try that repeated connections come from the same client (binary), and shrink limits on every new connection from it?
<dottedmag>
*try to find that
<emersion>
ideally the limits would not be per binary, but would be per sandbox
<pq>
dottedmag, nothing forbids that, if not common sense. ;-)
<pq>
nothing forbids clients from using short-lived probing connections either, we just think it's a bad idea
<DemiMarieObenour[m]>
Oh they are certainly a terrible idea. I just mentioned it as a reason why a client might do that.
<kennylevinsen>
And such a client would be faulty if it did that - not just a bad idea, it's incorrect. :)
<kennylevinsen>
pq: Well making assumptions about behavior not spec'd int he protocol is incorrect