cuarzosoftware / louvre Goto Github PK

• Installed louvre from the AUR
• Ran louvre-views

amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
[1]    17391 segmentation fault (core dumped)  louvre-views

Hi,
I am wondering about many raw pointers. I.e. manual pointer destruction in destructors instead of using std::unique_ptr. This can actually cause memory leaks, because the destructor is not called when an exception within the constructor is raised.
Are you aware of that? What are the reasons of using old-school C++?

Thanks a lot for the library and I'd love to hear your thoughts on this:

https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Apparently your library unfortunately doesn't solve it unless magically it's going to be used by Mutter, Kwin and all other projects.

So, I wonder if you could extend your library to the finished product (i.e. compositor) with APIs which could be reused by KDE/Gnome/IceWM/JWM/TWM and a myriad of other window managers, so of which have said strong "no" to the idea of a Wayland port.

I'm basically asking you to recreate X.org (server) because fragmentation in the Wayland field has been staggering and various desktop features are added on a per compositor basis which sounds like pure madness.

Continuing our discussion from here.

I suggest having a link rather then a full list like in smithay, as that would make the read me a little easier to skim , Also i don't think a wiki should be used because iirc it's can't be easily edited with a pull request, linking to some other file in markdown is good.

Hello there. Nice library, is there any compile / build instruction for Louvre ? Thanks.

Louvre sometimes doesn't process mouse inputs, so the cursor stays in place even though I'm moving the mouse. When it happens, it seems to stick until you stop moving it, at which point it will actually process the inputs and move the cursor. Not sure what the problem is since I haven't looked at the architecture. Looks to me like it might be getting flooded with mouse inputs events which causes it to no longer process anything else, or something like that.

I cant figure out how to fix the error, Im on Arch linux, KDE Wayland, nvidia. Thank you

Louvre error: [LCompositor::addOutput] Failed to initialize output DisplayPort-2.

src/lib/core/private/LCompositorPrivate.cpp:        if (!loadGraphicBackend("/usr/etc/Louvre/backends/libLGraphicBackendDRM.so"))
src/lib/core/private/LCompositorPrivate.cpp:            if (!loadGraphicBackend("/usr/etc/Louvre/backends/libLGraphicBackendX11.so"))
src/lib/core/private/LCompositorPrivate.cpp:        if (!loadInputBackend("/usr/etc/Louvre/backends/libLInputBackendLibinput.so"))
src/meson.build:BACKENDS_PATH = '/usr/etc/Louvre/backends'
src/meson.build:ASSETS_PATH = '/usr/etc/Louvre/assets'

So even if the asset path is changed in meson.build, all the programs still hard-reference /usr.

Reference upstream Wine: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winewayland.drv/wayland.c?ref_type=heads#L274
Reference Valve/Proton Wine: https://github.com/ValveSoftware/wine/blob/proton_9.0/dlls/winewayland.drv/wayland.c#L272

Wayland protocol: https://wayland.app/protocols/pointer-constraints-unstable-v1
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml

I know both Louvre and the Wine Wayland drivers are in it's early stages, I am just making this issue in advance so peoples reading on the project understand why the Wine Wayland driver currently cannot be used/tested on Louvre.
(Also as a reminder that zwp_pointer_constraints_v1 is not yet implemented on Louvre 2.0.0 git branch)

I didn't opened a discussion instead cause it seemed out of place.

My suggestion is to have an example dir with an example compositor, it could be used for quick prototyping and an example of how the library can be used

Hello, I'm interested on louvre-views (examples). How do I compile it without rebuilding the whole Louvre library. Is there a usable Makefile or meson.build ? Thanks.

This is very silly, GTK support KDE protocol for decoration, but not the XDG one.

Relevant code: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/gdkdisplay-wayland.c
Searching for xdg_decoration in the entire project result in nothing
Checking for org_kde_kwin_server_decoration_manager gives multiple results

Relevant protocols:

• https://wayland.app/protocols/kde-server-decoration
• https://wayland.app/protocols/xdg-decoration-unstable-v1

Since Louvre already support xdg_decoration_unstable_v1, supporting org_kde_kwin_server_decoration_manager as well shouldn't be much an issue as they are almost identical protocols.

Hello! I just found out Louvre from this post and I find it very interesting! The benchmarks also look very interesting!

I would like to ask if you plan to create C bindings?

Let me finally report this :^) I originally thought this was the same as #41 when I saw that, but I don't think it is.

Louvre isn't updating the screen correctly, one monitor has a black screen except for the info text. When the clock (or I assume any of the text on the top bar) updates, which of the ones has the broken background changes, like here, these are a minute apart:

The meaning of the inline keyword has changed for a long time, and whether a function is inlined or not is entirely determined by the compiler.