Language Selection

English French German Italian Portuguese Spanish

The What Why and How of Wayland and Weston on Linux

Filed under
Software

Let's start from the beginning, because even though Wayland has been in development for over five years there is still a lot of misunderstanding of what it is. Wayland is a display server protocol that is intended to replace the X Window System. We've had X for 27 years, and computing has changed a wee bit in that time. Back in the olden days we had text terminals and every little pixel was precious. Now we have great honking graphics cards with more processing power than the servers and workstations of yesteryear, multiple displays, smartphones and tablets, embedded devices, and users who are not going to settle for colorful ANSI displays, but want complex 3D graphics. And why shouldn't Linux lead the way in graphics rendering? Are we not overdue for holodecks? And who would ever want to leave their holodeck? Though, as figure 1 shows, you can make some cool color images with ANSI.

The Evolution of X

X has been showing its age for the past 10-12 years, and has acquired a considerable cruft base in that time, to the point that it is more in the way than useful. You younguns might not remember, but back in the olden days of Linux we had to configure X manually, and it controlled displays, mice and keyboards. Yes, keyboards and mice. Why? Darned if I know. This is what I wrote in my awesome Linux Cookbook, published in 2004:

"XF86Config requires that you know configuration data about your mouse, keyboard, video adapter, and monitor. It takes you through setup line by line, asking questions until you're ready to explode. Most important are the name of your video card, the amount of video RAM, and the horizontal/vertical refresh rates for your monitor."

Rest here




More in Tux Machines

Android/ChromeOS/Google Leftovers

Games: SC-Controller 0.4.2, Campo Santo, Last Epoch and More

Android Leftovers

Ryzen 7 2700X CPUFreq Scaling Governor Benchmarks On Ubuntu Linux

With this week's Ryzen 5 2600X + Ryzen 7 2700X benchmarks some thought the CPUFreq scaling driver or rather its governors may have been limiting the performance of these Zen+ CPUs, so I ran some additional benchmarks this weekend. Those launch-day Ryzen 5 2600X / Ryzen 7 2700X Ubuntu Linux benchmarks were using the "performance" governor, but some have alleged that the performance governor may now actually hurt AMD systems... Ondemand, of course, is the default CPUFreq governor on Ubuntu and most other Linux distributions. Some also have said the "schedutil" governor that makes use of the kernel's scheduler utilization data may do better on AMD. So I ran some extra benchmarks while changing between CPUFreq's ondemand (default), performance (normally the best for performance, and what was used in our CPU tests), schedutil (the newest option), and powersave (if you really just care about conserving power). Read more