starting on Wayland development

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.

About these ads

Tags: , , , , ,

12 Responses to “starting on Wayland development”

  1. saulo Says:

    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…

  2. nerdopolis Says:

    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.

  3. Diego Viola Says:

    I love Wayland, I hope we can use KDE with Wayland and without X soon.

  4. M Grant Says:

    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

  5. vignatti Says:

    @ 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=

    • mike Says:

      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.

  6. Anonymous Says:

    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.

  7. Linux Graphics / GPU / X / Wayland Architecture | Life in Linux Kernel Says:

    […] http://vignatti.com/2012/01/18/starting-on-wayland-development/ […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: