1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Why Wayland & Weston Were Forked

Scott Moreau

Published on 29 March 2013
Written by Scott Moreau
Page 4 of 4 - 131 Comments

The final item for the purpose of explaining my reasoning is candy. In order to do certain things with pixels, you need to do the calculations really fast so the eye is not displeased. The best way I have found to do this is by using OpenGL. OpenGL is the Open Graphics Language. One of the things that give even more control over pixel operations than in past versions of OpenGL, is shaders. Shaders are basically a language that you can write embedded in your C code which allows you to do per-pixel operations but with the acceleration of the graphics hardware. Clearly, this can be expensive depending on the amount of resources the hardware has available to 'spend'.

Recently, work was done to optimize the shader code and make it run faster. However, this optimization complicated the default shader code significantly. The additional speed is apparently more noticeable on less powerful devices such SoC's.

This is nice, but the motives I have are with the desktop platform first in mind. I would like to create optional simpler shader paths that we can use to manipulate certain rendering more easily. This is something that simply cannot be done from a shell plugin alone. You must touch the shader code that is built as part of the core binary.

So to recap, these are the reasons for the split:

1) Core protocol lacking very basic window management features.
2) New compositing functionalities that are not possible with a separate shell plugin alone.
3) Failure to successfully resolve these and other related problems.
4) Desire to create new features that require changes in the renderer shaders, which are not part of the shell plugin.
5) Continue to push innovative new features that will drive shell plugin API development.
6) Provide a place to include other community members that might not otherwise get the patience, time and attention they deserve.

These problems are certainly solvable ones. Unfortunately, we did not get to discuss these issues correctly because I was frustrated with the overall situation at the time and felt I was being ignored by the people I needed to help me solve the problem, and at the same time, being mocked regularly by other less-than-optimally-useful members. I am not going to point fingers here because I do not think this is the fault of any one particular individual. This is largely a misunderstanding and I think this new format will turn out for the best in the long run. The wayland project stands to make something great. However, my goals are slightly orthogonal to that of the core wayland developers. The good news is, I am confident that the wayland core developers will continue to improve wayland core functionality so that we will have a solid display server to use long-term.

I would like to see more modularity so that new features can be developed independently. Compiz solved this problem fairly well by providing a plugin API that is driven by hooks called from key places in the code. I'm not saying this is entirely feasible for weston but I think it's something that should be discussed. I would also like to see people come together and work things out despite misunderstandings and interest conflicts. This is happening already in a large way but even more people want to join in and help out.

Ohloh paints an accurate picture of the current contributor situation for Wayland and Weston.

As I've stated in previous writings, I will be making efforts to keep my code compatible with the existing wayland/weston code. My hopes are that we will end up with something awesome.

In closing, it seems logical to me that a useful step toward resolving some of the many technical issues behind this case would be to get eglSwapInterval() implemented in the mesa EGL implementation. I have not looked into the issue myself yet as it is fairly complex and I am not particularly familiar with mesa internal code. It would be nice to know if there is a way we can solve this specific problem that is relevant to not only to wayland and northfield but all programs that rely on this mesa EGL function. This includes EGL applications in X and anything that uses mesa EGL (Mir?). This is a mesa patch given to me by Kristian. It reportedly deadlocks in its current state. (see here).

Can you solve the problem?

Thank You,
Scott Moreau

Latest Linux Hardware Reviews
  1. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  2. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
  3. Radeon Graphics Yield Mixed Results With Linux 3.17 Kernel
  4. AMD's RadeonSI Driver Sped Up A Lot This Summer
Latest Linux News
  1. Re-Clocking Your NVIDIA GPU With Nouveau On Linux 3.17
  2. Radeon DRM Queues More Changes, RV6xx UVD For Linux 3.18
  3. Nouveau On Oibaf PPA Is Back To Running Well
  4. Metro 2033 Redux Will Hopefully Hit Linux Real Soon
  5. New Virtual Monitor Software Might End Up On Linux
  6. Company of Heroes 2 Might Be Coming Out For Linux
  7. NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again
  8. Plasma Active Is Mostly Ported To KDE Frameworks 5
  9. Google Chrome 37 Brings Many Security Fixes
  10. MenuetOS Updated With SMP Threads & Onscreen Keyboard
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  3. AMD Releases UVD Video Decode Support For R600 GPUs
  4. Announcing radeontop, a tool for viewing the GPU usage
  5. [DB] BIOS - ACPI - data collecting
  6. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins
  7. Users defect to Linux as OpenBSD removes Lynx from base system
  8. Chinese People Try To Patent Wine On ARM