Haskell wlroots bindings

#42

Somehow, I seem to have suddenly lost the ability to build my own project:

$ cabal build
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] next goal: wlhs-bindings (user goal)
[__0] rejecting: wlhs-bindings-0.1.0 (conflict: pkg-config package
wayland-server-any, not found in the pkg-config database)
[__0] fail (backjumping, conflict set: wlhs-bindings)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: wlhs-bindings

Cabal says that it can’t find wayland-server in the pkg-config database, even though it clearly does exist:

$ pkg-config --modversion wayland-server
1.22.0

Does anyone have any ideas?

#43

Did you recently do a system update that updated pkg-config? This may be `pkgconf`-provided `pkg-config` does `--modversion` differently; dependency resolution fails mysteriously · Issue #8923 · haskell/cabal · GitHub, which is fixed in HEAD and should be in 3.10.3.

#44

Oh, very interesting! But I doubt this is the issue… my pkgconf was last upgraded more than a month ago (December 7, according to pacman).

#45

I’ve decided to repost this issue on /r/haskell in the hopes of getting any more responses: https://www.reddit.com/r/haskell/comments/19db56s/

#46

Just had some useful discussion with @angerman on Reddit. This revealed the following useful information from cabal build -v3:

Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --variable pc_path pkg-config
[…omitted…]
Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --list-all
[…omitted…]
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: output of /home/bradrn/Documents/wayland/wlhs/pkg-config:
hGetContents: invalid argument (invalid byte sequence)

So this is weird: hGetContents is reporting an invalid byte sequence, of all things. As an experiment I made a wrapper script which teed the output of pkg-config to a file, then checked the encoding:

$ file pkg-config-out 
pkg-config-out: ISO-8859 text

So pkg-config is outputting text in ISO-8859… which, apparently, hGetContents can’t handle. Resetting the locale to C didn’t help, though.

Upon further investigating the pkg-config output, the following line sticks out to me:

vpl                            Intel® Video Processing Library - Accelerated video decode, encode, and frame processing capabilities o     n Intel® GPUs

Could the ® be the culprit here? What’s more, pacman logs show that libvpl was installed a week ago, so the timing is suspicious. But I don’t know, yet.

#47

Amazingly enough, this does indeed seem to be the problem! I quickly tried replacing libvpl with onevpl, which was what I had installed a week ago… and which incidentally doesn’t have any ®:

$ pkg-config --list-all | grep vpl
vpl                            oneVPL - oneAPI Video Processing Library

And this was sufficient to get cabal build working again! Then, reinstalling libvpl immediately broke cabal build. So this looks like a Cabal bug, which I will report later today.

1 Like
#48
1 Like
#49

I don’t think it’s a good idea to use LANG=C, unless it is UTF-8 (MacOS?)

Does your system support C.utf8?

#50

Ah, thanks! Glad to see this is already known.

#51

This is why more of the ecosystem should be mindful about encodings.

E.g. many specifications imply that you don’t need to know the encoding, because the keywords are defined in the ASCII subset or similar.

E.g. if you look at the implementation of pkg-config, you can see that it essentially compares [Word8]:

Now, why Cabal needs to get the parsed content as interpreted unicode is beyond me.

4 Likes
#52

As far as I’ve seen, the two attempts (Onyx and L-as’) have implemented binding to the protocol. My guess is that some of the necessary functionalities would be exposed through there, and wlroots cannot cover all parts. As for me, one motivation was that it automatically provides a few types that would be used.

Well, I guess you’d prefer me not participating here anyway.

#53

I’m still really confused about what you’re saying. Could you please provide some links to the projects you’re talking about?

#54

For instance, Ongy’s haskell-wayland package has this one:

This scans the protocol and generates FFI bindings for protocol calls.
I believe there is a reason for doing this, but I do not precisely know why.

#55

I feel it’s time for another update here. Progress has been slow, but steady thanks to @bullishOnFunctional and @anarchymatt.

The following APIs are now implemented, at least in part:

  • From libwayland: wl_display, wl_list, wl_listener
  • Basic interfaces: wlr_backend, wlr_renderer, wlr_allocator, wlr_output, wlr_seat
  • Compositing: wlr_compositor, wlr_subcompositor, wlr_scene
  • Window management: wlr_xdg_shell
  • Input: wlr_input_device, wlr_keyboard
  • Pointer: wlr_pointer, wlr_cursor, wlr_xcursor_manager
  • Clipboard: wlr_data_device
  • Logging: wlr_log

Plus some others which are important mostly as dependencies for wlr_output and wlr_seat.

One thing I’d like to do now is to try porting over some of the basic parts of the tinywl compositor which comes with wlroots. It could be a little difficult, though, since wlroots makes intensive use of function pointers, which are hard to marshal. I’m sorely tempted to write the relevant C code and include it directly in the low-level bindings, because otherwise it looks like they’re completely unusable.

3 Likes
#56

I feel it’s time for another update here. Progress has been slow, but steady thanks to @bullishOnFunctional and @anarchymatt.

Do you know where this work is taking place? Is there a git repository that one can contribute to, to aid the effort for wlroots bindings?

1 Like
#57

We’ve been working on it here: GitHub - bradrn/wlhs: Haskell bindings to wlroots (and libwayland)

3 Likes
#58

If you need a primer or the README doesn’t explain enough, please feel free to ask us.

#59

Regarding wlroots bindings
Hyperland is now based on aquamarine instead of wlroots.
Is it convenient thinking about an haskell fork ?

1 Like
#60

Sorry, we haven’t been working on this. I injured my wrist and have been abstaining from personal projects, and we kind of stalled out on this PR because we weren’t sure what to do about wlroots C headers that seemingly needed to be checked into the project’s source control for it to build.

#61

I’ve kind of stalled out here because I injured my arm somehow and I was having pains when typing. I’m healing slowly, but I haven’t contributed to WLHS in a while because the little free time I can spend on personal projects is being spent on learning about web development in Haskell (my day job is a Frontend developer “React andy”).

I’m still excited about a Wayland Window Manager written in Haskell so I’d like to continue to contribute but like I mentioned in my previous post the project kind of stalled out.