Do you wanna contribute to a funky open-source project? Are you tired of your nerdy and boring community of developers? Are you the one that wants to get rid of X because it’s a giant, old and fat dinosaur in your system? :) Cool, I have a project to solve your problems!
—
While there’s still lot of churn in the protocol, and yet our goal is soon to wrap up all we’ve been doing to a steady and settle-on-the-stone one description, there’s a lot on the implementation side that needs love. And that mainly concern Weston compositor, which is becoming the de facto compositor on several systems targeting Wayland.
In past months I was accumulating a TODO list for Weston and libraries that I think wouldn’t require any exceptional knowledge on core graphics or Wayland internals. These are good items for people that want start hack or just do some contribution on Wayland:
1. log facility (easy)
Back in July, I had already warmed up a discussion how we could log on Wayland. So now we spit everything to stdout but we want to do it similarly as Xorg, i.e. redirecting to its own file. It turned out that we might want only on Weston compositor and implement our own way of logging for sake of simplicity. Ideally it has to be very simple, without verbosity levels probably, etc. This task should be quite easy to finish.
2. launcher for Weston (medium)
Weston is meant to run as a normal user. Now we have to set manually input devices, DRM and tty with root permissions, so Weston can happily be started. Ideally we should have a setuid helper script doing all this tricky, and in fact I started something here. For a real system though, we need to enhance a bit this program with the policykit, specially for dealing with hotplugs. Probably zero understanding on Wayland internals is needed but an overall knowledge of OS is required.
3. libxkbcommon X merge (medium)
Actually that’s not much Wayland work, but it most definitely would help its development. xkbcommon is the library that exposes the keyboard mapping logic to clients, converting keycodes in keysyms. Weston clients are using for evdev convertion. The library is an adaptation of a bunch of X11 modules to fit in a non-X11 world and as such, it still requires xproto, kbproto and libX11. One task would be to untie such dependencies with X and the other to proper merge libxkbcommon with Xorg. I’d classify as medium-size task due the involvement with the community and the hairy understanding of XKB in general, although Daniel, Kristian and other guys already made a nice progress there.
4. xwayland on X (hard)
xwayland is the implementation on Xorg to make it run as a Wayland client. That works well on Intel chipsets and might work as well with other drivers through the shm X driver. In principle, basic X11 applications work with some WM control lacking, input grab as well and things like Xrandr don’t. One would also forward port xwayland and driver to upstream, once the work is shaped up. I bet WM developers would have an ecstasy and delight themselves hacking around.
—
Hopefully you get excited with some of the items. I definitely can give a hand with any, so just poke me on #wayland at freenode.
Tags: compositor, developer, development, Intel, open source project, wayland
January 19, 2012 at 10:00 am |
I think the problem to get start with it is to set an dev environment running everything clean and perfect, most of opensource have a TODO list detailed but not a how-to manual teaching how to real get start with code.
I am a C developer and I am using OpenSuse and I couldnt find wayland to it and an ease way to install…
January 19, 2012 at 4:49 pm |
Did you check the website:
http://wayland.freedesktop.org/building.html
try that and let me know whether you find problems.
January 25, 2012 at 8:42 am
mesa build stops with error (in master and orgin/8.0)
rbug/rbug_context.c:76:28: error: unknown type name ‘rbug_context_t’
in file src/gallium/auxiliary/rbug/rbug_context.c
January 19, 2012 at 3:03 pm |
I think there already is wlshm for xwayland on non-intel hardware
http://cgit.freedesktop.org/~iksaif/xf86-video-wlshm/ .
The thing is, it right now hasn’t been touched since June, and displays mostly solid windows.
January 19, 2012 at 4:50 pm |
yep, that’s what I meant with “shm X driver”. Thanks for the link though.
January 21, 2012 at 5:25 pm |
I love Wayland, I hope we can use KDE with Wayland and without X soon.
January 22, 2012 at 12:28 am |
Instead of syslog, how about aiming towards “the journal” upcoming in systemd – sounds like it might have some nice features for handling debug binary data, etc..
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1
January 23, 2012 at 7:50 am |
thanks for pointing out. Definitely got to check.
January 25, 2012 at 12:19 pm |
@ mike: if you are on intel platform then you don’t need gallium. Use something like this for the configuration: –disable-gallium-egl –with-gallium-drivers=
January 26, 2012 at 6:51 pm |
I’m on radeon but I managed to compile it. Some *proto are pain to configure because they have specs folders that collide with gcc specs file. Disabling environment and config with ./autogen.sh –prefix=/home/user/install helped. Now i’m playing with weston clients.
June 15, 2012 at 3:36 pm |
I compiled wayland, weston, xwayland, how to run the demo with X apps like you did in the video “X on Wayland”? Some guide to the setup would be great! Thanks.