Way to Wayland - take 1

There is an interesting discussion ongoing regarding to Waylands current memory allocation model and how this could be scoped better to be more suitable for different graphics architectures.

The rendering model with Wayland is simple and therefor powerful. The key part is the possibility to share a video memory buffer between the client and compositor. This all is currently done through DRM which also makes DRM an essential part of the whole Wayland concept.

So what has now been under the discussion in the Wayland forum is how the current model could,
a) provide interoperability between client and server. Different Wayland clients could more easily discuss with different Wayland Server solutions
b) isolate the important memory handling part away from the core protocol. Allowing Wayland to be used more easily with other memory architectures.

The proposal is to split the DRM specific part to an separate file which would solve both of these problems and would once again put Wayland closer to take the place as the future Linux graphics solution.

Some interesting statistics for the beginning of new year

Year 2010 has ended so its nice to check the couple of interesting OSS Graphics components have evolved during 2010. With the interesting ones meaning Mesa, XServer and the one that everyone is discussing about, Wayland. Surely along these components there has been a lot of activity on the Kernel side from graphics point of view by moving the logic to the Kernel side (DRI drivers, the kernel side GEM scheduler and kernel mode setting) plus there has also been a lot of activity around the toolkits but as said now sticking with these three.
So what has happened,

With Mesa we have:
157 people committing
and those people pushing in 12816 commits (of different sizes)
(where as in 2009 the figures were, 118 people pushing in 9719 commits)

With XServer we have:
99 people committing
and those people pushing in 1305 commits (of different sizes)
(where as in 2009 the figures were, 109 people pushing in 2057 commits)

With Wayland the figures are especially interesting as it has received a _lot_ of publicity lately (Unity, Fedora). Now during the year 2010 there were already close to 20 contributors for the project where as a year ago there were only two.


So a lot of things happening in the head of mainline. If we check these commits on daily basis - Mesa having average of 35 commits happening every single day and XServer having 3.5 commits on daily basis. And not to even mention the Kernel which has over 100 commits per day.

Starting to deviate from this with an custom build behind the closed doors will mean an big maintenance and development effort for the instances deciding to do so. On the other hand this is sometimes mandatory. When discussing about an commercial company which is still aiming at to make profit you are bound to keep something behind the closed doors.
So balancing between Open Sourcing code and potentially exposing the bits and pieces from the latest and greatest can get tricky and really needs to be thought carefully.


PS. with MeeGo the problem is tackled by doing the XServer development with the git head - see.

DRI2 driver for Mesa EGL

Couple of weeks ago there was an announcement that Wayland would be moving to Mesa EGL and drop its dependencies to its own Wayland specific Eagle EGL stack. The Eagle is a non-conformant EGL loader for the DRI drivers originally develped by Kristian Høgsberg as an "side product" of his DRI2 work. Eagle as an lightweight and with its way of integrating EGL directly to KMS/DRM, was the solution for Wayland - this at least until recently.

Major reason to allow Wayland to jump to Mesa EGL is Kristian's work for the work behind the DRI2 driver for EGL and to get the Eagle EGL parts as officially to Mesa. This work - EGL on DRI2 is firstly aiming to implement this support through X, but the longer term goal seems to be that the implementation would be standalone - working directly with KMS/DRM and making it suitable for Wayland purposes.

Current plan is that the DRI2 parts for the Mesa EGL would be integrated to the upcoming Mesa 7.8 - planned to be release during this month. This is good news especially for Wayland. Along the Mesa integration the Wayland enablers are now even more mainlined. This move will most definitely make Wayland it self more attractive to outside world.