Weston sample clients don't run

[abooij]

A number of sample clients included with the weston reference compositor do not run correctly when using sudbury client-side.

• [x] weston-simple-egl

has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage
[1]    6970 segmentation fault (core dumped)

This might be caused by lack of dealing with null pointers in cArgToWireArg in Crap.Client.

• [x] weston-simple-dmabuf-intel

buffer allocated w 250, h 250, stride 1024, size 262144
buffer allocated w 250, h 250, stride 1024, size 262144
sudbury: IntMap.!: key 4278190080 is not an element of the map

We probably made a mistake in handling new_ids that are part of an event (ie a message from the server), in other words we can't deal with the case where the server decides to create an object.

• [x] weston-flower

sudbury: <<loop>>

I'm not sure where this originates, but I previously encountered such a loop via an STM deadlock. A number of clients have this error, and they all successfully open a window and then exit in this way. So they show a black rectangle on the screen for a split second.

• [x] weston-info

weston-info: symbol lookup error: weston-info: undefined symbol: wl_list_init

This is because we did not bake in support for wl_list. Should be an easy fix by just including some C code. (We are not planning to support wl_list on the Haskell side of things because it's not really necessary to do so: we can get away with just providing this C interface.)

• [x] weston-flower again

On mouseover:

sudbury: Message parse failed: not enough input

• [x] weston-subsurfaces

Chosen EGL config details:
        RGBA bits: 8 8 8 8
        swap interval range: 0 - 1
[1]    13663 segmentation fault (core dumped)

• [x] weston-dnd

When actually starting a drag:

[1]    5569 segmentation fault (core dumped)

• [x] weston-dnd again

When finishing the drag:

sudbury: IntMap.!: key 44 is not an element of the map

(we have to think about object lifetime, and do event handling accordingly)

• [x] others?

[abooij]

The weston-simple-dmabuf-intel issue is caused by us not actually creating Proxy objects when we receive a message with a new_id argument.

I think I'll leave the (new) weston-flower issue for now, and hopefully fix it by implementing #6.

[abooij]

I re-generated cbits/wayland-protocol.c (from the libwayland code) and added it. This resolves the weston-flower issue. But it really is a workaround since we should have had version checks or something. Something ran that shouldn't.

The underlying issue was that weston-flower used some kind of message that was only in this newer version. But since we were using an older version without that message, it grabbed a random piece of memory, that eventually resulted in this error.

If we check protocol versions between the library and the user, this might be a problem we can catch earlier. See issue #10.

[abooij]

I suspect the remaining two bugs (segfaults) are actually a GHC bug. See e.g. this (solved) GHC STM bug.

[abooij]

Ah. They are not, in fact!

One source was a potential null pointer (which we now deal with). Another is caused by the fact that we do not deal with object destruction. This will be fixed as well.

[abooij]

The remaining issue with weston-dnd is caused by us completely forgetting about objects that we destroy. When the server subsequently sends us a message on that object, we don't know how to handle the incoming data. To fix this, we need to remember protocol data of objects that are destroyed on our end, and only discard it after the server has sent a delete_id event to confirm destruction.

In fact, it seems that libwayland has a bug here: if the server sends an event containing an fd on an object that the client has deleted, the fd stream gets out of sync because fds are read in wl_connection_demarshal, which is not called on objects that are already destroyed by the client.

[abooij]

All clients now run correctly, as far as I can see. Please open a new bug report if you spot any broken clients (weston demo clients or otherwise).