Is there an EWMH equivalent for wayland compositors
Posted by IvanMalison@reddit | linux | View on Reddit | 7 comments
Is there a protocol/plan to provide the functionality provided by EWMH for wayland compositors?
It seems like this might be a good place for https://www.freedesktop.org/ to step in. I feel like a dbus protocol (that could even be wayland/X11 agnostic) might be a really good fit for this problem.
Thoughts?
habarnam@reddit
What makes you think it wouldn't be supported on wayland compositors?
IvanMalison@reddit (OP)
EWMH? Uhh, it communicates through X11. It's an X only protocol.
habarnam@reddit
The spec is not related to Xorg as far as I know, and it doesn't define a transport protocol:
IvanMalison@reddit (OP)
https://en.m.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual
ICCCM is an x window system protocol.
The '_' prefixed property names in the ewmh spec are 'atoms' an xorg concept.
As someone who has written a ton of ewmh dependent code in both xmonad and taffybar, I can tell you that ewmh is extremely tightly coupled to x11 and there is no sensible way to speak of using ewmh outside of the context of X
habarnam@reddit
OK, makes sense. Thanx for the clarification.
[edit] However looking at the concepts of EWMH, I can't really understand what makes it non suitable for implementation on top of wayland compositors/windows.
jwiede@reddit
Apologies in advance, I know this analogy is both a gross oversimplification and a "heavily contrived" but hopefully it clarifies the specific EWMH problem at issue:
--
Picture there's a standard "A" on X86_64 which standardizes how memory address ranges are used by apps by regulating how CPU "segments" get set up by apps to access those ranges, as well as what the different segments "represent" memory-range-wise.
Someone asks for the same standard on ARM. Problem is, ARM CPU doesn't have hardware "segments" like X86_64. In order to make that exact standard "A" work the same on ARM, you'd first need to implement something like "segments" -- doable, but a huge effort, and would also completely change how ARMs apps interact with memory necessitating immense retrofitting.
Since the "real purpose" of the standard "A" is about how the memory MAP is sectioned up by apps, though, you could easily use the ARM MMU and memory protection to create a similar division of memory map regions, following another standard "B" designating how the ranges are to be used by apps.
Unlike "A", "B" isn't reliant on X86_64-specific hw functionality in how it achieves that standardization, and can potentially work even with existing ARM software. "B" thus can efficiently yield the standardized outcome (whereas "A" never could on ARM).
--
It's not that you couldn't precisely make EWMH work on Wayland. You could, if you replicated the X infrastructure atop Wayland, but that also compromises Wayland's efficiency, and imposes huge impl. costs and complexity to do so.
You CAN achieve the same effective result much more efficiently through a different standard that "similarly standardizes" the taxonomy Wayland apps use to manifest their config/state, just not requiring the exact X-dependent aspects as EWMH does (instead referring to Wayland mechanisms, or better, generic proxies). It's not "EWMH" exactly, but has the same goal for Wayland as EWMH for X.
Hopefully that helps a bit.
habarnam@reddit
Heh, thanx. :) I completely forgot about this thread, though tbh I didn't become better informed in the meanwhile.