hi all, to my understanding the above are like WINE in that they try to remedy an unideal situation and thus have to operate with older protocols. is that understanding correct or are they independent / capable of being independent
hi all, to my understanding the above are like WINE in that they try to remedy an unideal situation and thus have to operate with older protocols. is that understanding correct or are they independent / capable of being independent
Wayland replaces the older X protocol. It doesn’t have to operate with older protocols. You might be thinking of XWayland which is a proxy that receives X API calls from apps written for X, and translates those to the Wayland API so that those apps can run under Wayland implementations. Window managers can optionally run XWayland, and many do. But as more apps are updated to work natively with Wayland, XWayland becomes less important, and might fade away someday.
PipeWire replaces PulseAudio (the most popular sound server before PipeWire). Systems running PipeWire often run pipewire-pulse which does basically the same thing that XWayland does - it translates from the PulseAudio API to the PipeWire API. It’s a technically optional, but realistically necessary compatibility layer that may become less relevant over time if apps tend to update to work with PipeWire natively.
So no, both Wayland and PipeWire are capable of operating independently of other protocols.
youre right i was thinking of xwayland, tysm. also, yes i was thinking of pipewire-pulse. i was worried these compatibility layers WERE the programs in their entirety. as in, they had no protocols themselves but rather optimised older, deprecated ones.