I packaged this for NixOS! (WIP)

[2xsaiko]

I packaged Louvre and SRM for NixOS. Package files here and here.

Right now this patches the hardcoded paths since Nix doesn't have /usr, hopefully that will get better in the future (#13).

To run the examples, for example louvre-views: nix shell sourcehut:~dblsaiko/nix-extras#louvre -c louvre-views. It doesn't work yet though and just exits with status 1, will have to figure out what's going on.

[ehopperdietzel]

Thank you very much! I've just updated SRM with pkgconfig support, and I am now including it in Louvre. The compositor may crash because it might not find the graphic or input backends. I am also adding a Meson option to specify paths for both the backends and assets. You can set the LOUVRE_DEBUG environment variable to 4 to see full debugging messages.

[2xsaiko]

Aha! I’ll try that env variable tomorrow. Thanks!

[ehopperdietzel]

Could you identify why it crashed? Btw I added options in Meson for specifying the default assets and backends path

[2xsaiko]

This is the log in any case: http://termbin.com/odub

Failed to create SRM core

I'll see if something changes if I package the new Meson options.

If I may ask, why did you not use the existing datadir and libdir options to determine where to place the libs? This would mean that packages (for example my Nix package) won't have to specify these special options but it will just work instead, plus that would cause it to use more standard paths (i.e. /usr/lib/Louvre and /usr/share/Louvre for backends and assets respectively), /usr/etc isn't exactly something that pretty much anything else uses and I'm pretty sure would cause problems when trying to get this included in various distros.

[ehopperdietzel]

Hmm, so it locates the backend, but SRM fails to start. Setting SRM_DEBUG=4 should allow you to observe what is happening. Are you testing it on a machine that lacks a GPU?

Regarding the second point, the library does install in Meson's default paths and should be configurable with libdir, but not the backends. As for the assets, you're absolutely right. Now that I've carefully read your other message, I apologize for not considering it initially 🤦🏻‍♂️. However, I can still make the change. So, to do it right this time, how about the following?

• Library in libdir/
• Backends in libdir/Louvre/backends
• Assets in datadir/Louvre/assets"

[2xsaiko]

Hmm, so it locates the backend, but SRM fails to start. Setting SRM_DEBUG=4 should allow you to observe what is happening. Are you testing it on a machine that lacks a GPU?

Maybe, I'm running it in a QEMU VM which I assume only has software rendering, I'm doing this since it can't acquire DRM when running it directly from the existing graphical environment. Is there a way to get it to run in a window like Weston?

I'm going to get that SRM log in a bit, but I assume this would be the reason.

Regarding the second point, the library does install in Meson's default paths and should be configurable with libdir, but not the backends. As for the assets, you're absolutely right. Now that I've carefully read your other message, I apologize for not considering it initially 🤦🏻‍♂️. However, I can still make the change. So, to do it right this time, how about the following?

• Library in libdir/
• Backends in libdir/Louvre/backends
• Assets in datadir/Louvre/assets"

No worries :P Exactly, these should be good.

Also, another suggestion (and tbh I could just PR this if you'd like): Speaking of changing paths, I would separate backends into Louvre/backends/graphics and Louvre/backends/input and then make the default backend options take a name from which it builds the actual library path. E.g. when setting default_graphic_backend=DRM it will load Louvre/backends/graphics/DRM.so. That would prevent accidentally being able to load backends for something they're not useful for since they're not in the same directory, and also maybe in the future being able to have backends which aren't tied to a shared object file (for example, maybe for a statically compiled compositor, which can't use dlopen) since you no longer have the explicit .so in the backend name. Also as you noticed I left away the lib prefix, I don't know how Meson lets you do this but CMake lets you add a library as MODULE which is exactly for this purpose and causes it to leave away the prefix when linking (you can see this used with Qt plugins for example):

SHARED libraries are linked dynamically and loaded at runtime. MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality.

(from add_library documentation)

[ehopperdietzel]

Maybe, I'm running it in a QEMU VM which I assume only has software rendering, I'm doing this since it can't acquire DRM when running it directly from the existing graphical environment. Is there a way to get it to run in a window like Weston?

SRM fails to start if it doesn't find a usable DRM/KMS device, so that must be the issue. Yes, I plan to incorporate a Wayland backend to run it nested. While I initially had an X11 backend, I updated the backend API and focused on porting only the DRM backend.

I would separate backends into Louvre/backends/graphics and Louvre/backends/input.

Good idea.

make the default backend options take a name from which it builds the actual library path. E.g. when setting default_graphic_backend=DRM it will load Louvre/backends/graphics/DRM.so. That would prevent accidentally being able to load backends for something they're not useful for since they're not in the same directory, and also maybe in the future being able to have backends which aren't tied to a shared object file (for example, maybe for a statically compiled compositor, which can't use dlopen) since you no longer have the explicit .so in the backend name. Also as you noticed I left away the lib prefix, I don't know how Meson lets you do this but CMake lets you add a library as MODULE which is exactly for this purpose and causes it to leave away the prefix when linking (you can see this used with Qt plugins for example):

I currently use dlopen to read a static struct present in each backend, providing access to its API. Consequently, these backends cannot be statically linked at the moment. I will contemplate how to enable it. Lastly, regarding the names, simplifying them sounds like a good idea. Since I'm using dlopen they don't need the lib prefix, I'll use drm.so and libinput.so (because input.so would be weird) and also lowercase just for consistency.

So if the envs look like:

LOUVRE_BACKENDS_PATH=/path/to/backends
LOUVRE_GRAPHIC_BACKEND=drm
LOUVRE_INPUT_BACKEND=libinput

The files path should be:

/path/to/backends/graphic/drm.so
/path/to/backends/input/libinput.so

[ehopperdietzel]

Also as you noticed I left away the lib prefix, I don't know how Meson lets you do this

https://mesonbuild.com/Reference-manual_functions.html#library_name_prefix

[ehopperdietzel]

Any other suggestions before I make the changes?

[2xsaiko]

I currently use dlopen to read a static struct present in each backend, providing access to its API. Consequently, these backends cannot be statically linked at the moment. I will contemplate how to enable it.

Oh yeah I assumed it wouldn't work as is, that was just an example for why not passing the library file name directly would be an improvement. No need to actually implement static linking right now. I don't need it myself, at least.

Any other suggestions before I make the changes?

Not right now, anyway :P

[2xsaiko]

Update: I got it to work on my actual PC! Also submitted a PR to include it in nixpkgs: NixOS/nixpkgs#269247

[ehopperdietzel]

Thank you! :D I've just merged the meson, examples, and documentation changes into the main branch. I addressed a minor issue that was causing compositors to crash during uninitialization. If it didn't make it to your PR, it's not a significant concern. I'm pleased that it's working on your machine. What was the root cause of the issue?

[2xsaiko]

Well, trying to run it in a VM and trying to run it from an existing compositor is what kept it from working. Once I ran it from the TTY, it worked.

Also don't worry, I can always update the PR.