abooij / haskell-wayland Goto Github PK

As the binding isn't comprehensive yet, would make sense to switch to using inline-c?.
https://www.fpcomplete.com/blog/2015/05/inline-c

me being lazy and ignoring "array" type arguments has turned against me: the KeyboardListener now doesn't have the right number of entries, causing a segfault when trying to bind to it.

Currently, when the wayland C library cannot allocate memory for e.g. new objects, it returns 0 on the C side, which ends up generating a crash when processed by Haskell. This should be dealt with in a better way.

To actually build a compositor, one needs to interface with opengl/kms/drm/... (pick one). Currently, there are kms bindings for haskell, but really we should be using libweston (which exposes some weston internals) to solve this problem once and for all.

Currently, the enums are dealt with in calls and callbacks as mere (u)integers. This is of course extremely type-unsafe.

There is a discussion to add much more type information to the core wayland protocol XML files, which would help a lot.

In the meantime, here is a scheme we should implement:

Every distinct <arg> should get its own type, and its own type class. Every <enum> gets its own type class. Callback values are passed as packaged ints (namely of the type corresponding to the <arg>), and calls arguments are passed as anything that fits in one of two corresponding type classes:

• the type class of its own <arg>
• the type class of any <enum> it is associated to by the enum attribute
  As long as the enum&bitfield attributes do not exist, the latter classes will stay empty. Using some kind of "unsafeBlabla" function, you can pass arbitrary ints into the type classes to pass values.

Now, once the type information is added to the protocol files, we simply add the <arg> types into the right type classes.

I have planned for a while to fix a memory leakage in the current implementation. Specifically, the callback mechanism (from the C wayland lib into haskell code) works by storing a struct of callback functions on the C side, but this struct is currently not getting destroyed when the object itself gets destroyed.

This can be fixed by using the void* user_data storage (make sure not to expose this functionality to the haskell API).

I noticed that my installed c2hs 0.16.5 gave me build errors like

./Graphics/Wayland/Internal/Client.chs:183: (column 56) [ERROR]  >>> Missing "in" marshaller!
  There is no default marshaller for this combination of Haskell and C type:
  Haskell type: Display
  C type      : (Display)

Installing c2hs 0.17.2 fixed the issue. Can we maybe depend on that? Otherwise a note in the README would be nice.

There are some thread safety issues going on in wayland. IIRC, server-side there is no thread safety at all, and client-side there is thread safety under some conditions. This should be shielded away from the haskell side of things: maybe make a local "C call pipeline" which is emptied in a fixed, single thread?

I was playing around with binding wlroots (the compositor library spawned out of sway) and needed some wayland values.

The specific one I found was the struct wl_display * for the server.
Currently the type exists but the newtype constructor isn't exported which makes bindings to other libraries that use the C values impossible.

To use this library when binding to oder libraries that use some wayland values, it would be important to export at least the Ptr types for wl_ structs.