michaelforney / swc

a library for making a simple Wayland compositor
MIT License
614 stars 52 forks source link

No opening apps. #74

Closed Alleop5 closed 1 year ago

Alleop5 commented 1 year ago

When I launch velox. It wont receive any input. I can't open any apps. And when I try to use the keybind for opening a terminal. It does nothing. My mouse does move. And dwm and dwl worked on this machine. This may be because I'm using WLD_DRM_DUMB=1 to launch it because else it'll complain about Could not initialize WLD DRM renderer after it tries to use the DRM driver intel.

michaelforney commented 1 year ago

When I launch velox. It wont receive any input. I can't open any apps. And when I try to use the keybind for opening a terminal. It does nothing.

Are you sure that the terminal you're using isn't the problem? Do other shortcuts work like Super+ to change tag or Super+Shift+q to quit? If Ctrl+Alt+F works, you can try launching your terminal from another VT and see if that reveals the problem. Alternatively, you could ssh in and launch the terminal that way.

If the terminal doesn't work and doesn't print any messages indicating why, please run it with WAYLAND_DEBUG=1 and attach the log.

My mouse does move.

Sounds like input is working, then.

And dwm and dwl worked on this machine. This may be because I'm using WLD_DRM_DUMB=1 to launch it because else it'll complain about Could not initialize WLD DRM renderer after it tries to use the DRM driver intel.

That's not related.

Alleop5 commented 1 year ago

Sorry for the long wait.

I've reinstalled Linux since the last message. Do I need to manually recompile stuff to make velox apps work? Because I've figured out that quit does work now. I don't know why but I'll take it. Apps don't launch and WAYLAND_DEBUG=1 doesn't give anything extra. Still just: running on /dev/tty3 [swc:libswc/drm.c:152] DEBUG: /dev/dri/card0 is the primary GPU Using config at '/etc/velox.conf' [swc:libswc/compositor.c:686] DEBUG: Performing update [swc:libswc/compositor.c:220] DEBUG: Rendering to target { x: 0, y: 0, w: 1920, h: 1080 } I'm using a integrated intel GPU. What's ctrl+alt+f? It doesn't do anything. That's also not listed in /etc/velox.conf. TL;DR: Input works. Apps don't open and velox/swc gives no error logs.

michaelforney commented 1 year ago

Sorry for the long wait.

I've reinstalled Linux since the last message. Do I need to manually recompile stuff to make velox apps work? Because I've figured out that quit does work now. I don't know why but I'll take it. Apps don't launch and WAYLAND_DEBUG=1 doesn't give anything extra.

You don't need to recompile stuff.

If running the applications with WAYLAND_DEBUG=1 doesn't print anything, then those aren't wayland applications (or at least, aren't using libwayland). Make sure you are trying wayland applications (and launching them with whatever flags/environment vars they need to use wayland), or you have built swc with xwayland support.

Still just: running on /dev/tty3 [swc:libswc/drm.c:152] DEBUG: /dev/dri/card0 is the primary GPU Using config at '/etc/velox.conf' [swc:libswc/compositor.c:686] DEBUG: Performing update [swc:libswc/compositor.c:220] DEBUG: Rendering to target { x: 0, y: 0, w: 1920, h: 1080 } I'm using a integrated intel GPU.

That all sounds fine.

What's ctrl+alt+f? It doesn't do anything. That's also not listed in /etc/velox.conf.

Ctrl+Alt+F1/F2/F3/... are the usual shortcuts to switch to VT1/VT2/VT3/...

This is one way you can get to a terminal to try launching whatever application isn't working for you to see the wayland protocol log (with WAYLAND_DEBUG=1). This should tell you why the application isn't starting.

The bindings are always enabled and not in velox.conf.

TL;DR: Input works. Apps don't open and velox/swc gives no error logs.

As I said earlier, it's probably the application itself that is refusing to launch, not any error in velox/swc. The error logs will likely be in the application you are trying to run. That's why I suggested running the application from another VT or ssh so that you can see its output (and launch it with WAYLAND_DEBUG=1 so you can see the protocol log).

Alleop5 commented 1 year ago

I'm using alacritty. You've put st by default but that doesn't work either.

Alleop5 commented 1 year ago

And I'm verifying that my setup works by using dwl. I don't have xwayland enabled in dwl. Also yes I know about the ctrl+alt+f1/f2/f3/f4. I was just thinking that it was maybe a built-in keybind. Actually I think you might have a point with the part where you're talking about where I need certain flags for the wayland version to open. Though I don't know which I need. I'll check in my dwl when I've installed that.

Alleop5 commented 1 year ago

Ok I've installed dwl. Though that didn't give any help. I'm sure alacritty would work with velox by default. I'm just confused at this point. Because there's no sign of life. Except for the bar.

michaelforney commented 1 year ago

Can you please go to another VT (or ssh in), run the application with WAYLAND_DEBUG=1 myapp >myapp.log 2>&1 and then upload that somewhere?

Alleop5 commented 1 year ago

myapp doesn't exist

michaelforney commented 1 year ago

Substitute myapp with whatever application you are trying to run. Sorry, I didn't think I'd need to spell that out for you.

Alleop5 commented 1 year ago

If you're talking about alacritty. Sure. I ran swc-launch alacritty. https://pastebin.com/xABgraEm I hope this is what you meant. Note: This output is the exact same as just running alacritty in a terminal without wayland/xorg running.

michaelforney commented 1 year ago

That's not what I meant.

Do this:

  1. Launch velox with swc-launch velox
  2. Switch to an available VT with Ctrl+Alt+F<n>, replacing <n> with the number of the available VT. For example, if VT2 is available, use Ctrl+Alt+F2.
  3. Run alacritty from that VT, setting the WAYLAND_DEBUG=1 environment variable, and capturing the log: WAYLAND_DEBUG=1 alacritty >alacritty.log 2>&1.
  4. Upload alacritty.log somewhere so that I can look at the wayland protocol log.
Alleop5 commented 1 year ago

I get the exact same output as last time. Velox doesn't give any logs. You can maybe check this out by installing Void Linux as I've been able to reproduce this on a VM.

michaelforney commented 1 year ago

I'm not interested in velox's logs, but alacritty's logs.

Last time you tried to run alacritty in place of velox, which doesn't make sense. You need to run it normally while velox is running. If you get the same output Wayland status: NoCompositorListening from alacritty while velox is running, then you should probably ask the alacritty developers. swc/velox can't do anything if it doesn't get any incoming connection from the application.

Another thing to try would be to launch alacritty like this: WAYLAND_DEBUG=1 strace alacritty >alacritty.log 2>&1. You should see it try to make a connection to the wayland socket.

Make sure you don't have other wayland compositors running, or set WAYLAND_DISPLAY appropriately for the wayland socket used by velox so that alacritty makes the connection to the right one.

Alleop5 commented 1 year ago

What's a terminal that supports velox? WAYLAND_DISPLAY I set to "wayland-0" when I saw dwl. So that shouldn't be an issue. strace looks like it just loads a ton of libX* libraries then just dumps the error. Wayland is not mentioned in the log. But I was looking for an alacritty alternative anyway.

WAIT THIS SEEMS IMPORTANT! My app launcher of choice fuzzel gives some useful logs. err: wayland.c:1455: wl_output: need interface version 3, but compositor only implements 2 err: wayland.c:2001: no layer shell interface err: fdm.c:132: no such FD: 4 I have some weird feeling that swc/velox is outdated with some wayland tech.

michaelforney commented 1 year ago

What's a terminal that supports velox? WAYLAND_DISPLAY I set to "wayland-0" when I saw dwl. So that shouldn't be an issue. strace looks like it just loads a ton of libX* libraries then just dumps the error. Wayland is not mentioned in the log. But I was looking for an alacritty alternative anyway.

That's a problem if alacritty doesn't try to use wayland. But you still didn't paste the log, so I can't see what's going on for sure.

WAIT THIS SEEMS IMPORTANT! My app launcher of choice fuzzel gives some useful logs. err: wayland.c:1455: wl_output: need interface version 3, but compositor only implements 2 err: wayland.c:2001: no layer shell interface err: fdm.c:132: no such FD: 4 I have some weird feeling that swc/velox is outdated with some wayland tech.

Yes! This is the type of log I was expecting for alacritty. My guess is that alacritty is also bailing out because it is missing some protocol extension or some newer global versions.

Indeed, swc doesn't implement the latest versions of every wayland object (especially when they don't add anything that'd be useful for swc/velox), or some non-core extensions popularized by wlroots. However, swc isn't the only culprit here. Often, the application could have supported the older version extremely easily with a few lines of code. For example, with the following patch, fuzzel could have supported wl_output version 2:

diff --git a/wayland.c b/wayland.c
index f9178cf..d4e6d0e 100644
--- a/wayland.c
+++ b/wayland.c
@@ -1515,7 +1515,7 @@ handle_global(void *data, struct wl_registry *registry,
     }

     else if (strcmp(interface, wl_output_interface.name) == 0) {
-        const uint32_t required = 3;
+        const uint32_t required = 2;
         if (!verify_iface_version(interface, version, required))
             return;

@@ -1618,8 +1618,12 @@ monitor_destroy(struct monitor *mon)
 {
     if (mon->xdg != NULL)
         zxdg_output_v1_destroy(mon->xdg);
-    if (mon->output != NULL)
-        wl_output_release(mon->output);
+    if (mon->output != NULL) {
+        if (wl_output_get_version(mon->output) >= 3)
+           wl_output_release(mon->output);
+   else
+       wl_output_destroy(mon->output);
+    }
     free(mon->name);
     free(mon->make);
     free(mon->model);

In this particular case, wl_output version 3 simply adds a release destructor to avoid leaking objects when wl_output globals disappear. This never happens in swc, so isn't really beneficial. However, it is easy to implement, and can be useful if the application itself is creating and destroying wl_output objects (not the case for fuzzel), so I've updated it in d730855d32fb040af8e7d872faa1e35585f0a16d.

The other errors are more critical. swc uses its own swc_panel_manager extension for launchers like dmenu/fuzzel. This predates wlroots' wlr_layer_shell, which is more flexible, but also more complicated to implement. You'll either have to port fuzzel to swc_panel_manager, or implement wlr_layer_shell in swc (I'd accept a pull request).

I don't know if any of the protocols mentioned above are relevant for alacritty. Perhaps there is some other extension or version of something it wants. If it's not printing any messages telling you what's wrong, you'll have to do some debugging on your own. Personally, I use my wayland ports of st and dmenu, which work fine in swc. Any terminal that uses the basic core wayland protocol should work fine as well. I've tested with sakura and gnome-terminal as well.

Alleop5 commented 1 year ago

Yeah so I've definitely done something wrong. I've tried to update swc by sudo make clean install. But fuzzel still complains about it being version 2 after restarting velox. Though are workarounds needed for every program? I can't get any program to boot. Except for st and dmenu I can't start any GUI app. Except for your apps.

michaelforney commented 1 year ago

Most wayland applications should work fine. It's only those that have strict requirements on the latest versions of all the protocols (please send patches to those projects when you encounter them), or require certain protocol extensions that might have problems with swc.

I haven't had issues with most GTK3 applications, and chrome works great as well.