I’m using EndeavourOS with KDE.
The display is correctly oriented when logged in but it doesn’t rotate correctly when I’m logged out.
EDIT: corrected the post. This happens when logged out, locking the screen has it displayed correctly.
I’m using EndeavourOS with KDE.
The display is correctly oriented when logged in but it doesn’t rotate correctly when I’m logged out.
EDIT: corrected the post. This happens when logged out, locking the screen has it displayed correctly.
Not only are you wrong, you’re wrong on a fundamental level.
You don’t even understand Wayland at all.
Wayland is not an implementation, it is a set of communication protocol specifications that specifies the communication between a display server (compositor) and its clients. There is no single implementation and that’s by design, avoiding the major pitfalls of Xorg’s inflexible fat unmaintainable ass.
More over, Weston is the reference implementation of a Wayland compositor that demonstrates how to implement the protocol specifications.
As the reference, Weston includes support for important features like screen rotation & overscan/underscan.
So obviously, other Wayland compositors, like GNOME Shell and KWin, would naturally follow Weston’s example and also implement screen rotation & overscan support.
Lastly, all major implementations other than wlroots(WIP) have the overscan feature, e.g. Mutter, Kwin, Weston, etc.
Ok, let me fix my language. Thanks for the reference definitions, I’ll freely admit that I’m a bit rusty.
I was considering Wayland to be the server, not the protocol. I’ll adjust the spirit of my argument with this correction, and take you through a sample use-case of a system I ran on X about a decade ago.
I was arguing that having many implementations of display clients maintained by many different DEs can lead to a contradictory and confusing management environment. I’ll adjust this argument to also include the fact that the display servers are also being separately maintained.
The system that I ran a decade ago was a research box that about a dozen scientists would remote into via vnc from their laptops. Each scientist had their choice of DE which they could run and manage via the
.xinitfile in their home directories. This gave them a lot of choice and freedom over how they set up their personal UI (people can be finicky and prefer specific workflows), while also allowing simultaneous resource usage of the data and analysis drives, and the hundreds of cpu cores for various runs, and the hundreds of gigs of ram.Such a system in Wayland-world would require each scientist to customize their environment using a DE-specific display-client-side configuration management scheme. Each of these would then have to talk to a different display server, as implemented by their specific DE. Sure, each client-server pair is using the Wayland protocol, but running a dozen display servers in the extreme case of a dozen different DE choices is not resource efficient. In a Wayland-world, I would probably have to enforce a standard server implementation of the Wayland protocol to cut down on all of the different display servers clogging up the memory and cpu usage. Sorry if one scientist wants KDE and another wants gnome and another wants i3 (now sway/wlroots), we have to cut down on diversity and user choice because of the fragmentation of the display environment. Under a single X server, it was easy to allow for user-facing interface diversity because of the standardization of the display server. Under my understanding of Wayland (as updated by your comment), supporting this interface diversity would require server-side diversity and server-side system resource duplication that would hinder the ability to efficiently present diverse options to the end users.
If there is anything that I am still misunderstanding, please continue to correct me and help me get caught up on missing the last several years of reality.
The clients do not care what implementation of the specification is being used.
Let me give you an analogy, say multiple people are making a sandwich, they could be making the sandwich in various ways, doing certain steps in different orders & at different speeds conducive to them and their environment, as long as the client gets the sandwich they asked for, it does not matter who and how the sandwich was made.
Infact, this is shown by the proof of concept of the upcoming compositor-handoff feature where you can hot swap your compositor and bring your clients straight over with their state completely preserved.
This is one of the many strengths of Wayland’s design, it allows for a lot of flexibility in implementation while preserving the underlying communication standard between the server/compositor and the clients.
Thanks for the info. That makes a lot of sense. You’re giving me a lot of good info for what to do the next time I have a block of time to play around with something like this.