Open clapbr opened 5 years ago
I definitely thought about it already when I started the project, and I still like the idea of implementing such thing.
However there are still a couple of issues I'd like to work out before attempting to make the compositor something more widely usable.. One of the major problems is how to efficiently transform the window contents to something that can be used by Vulkan. The current solution is very much a placeholder, and can be a bit of performance killer in some cases..
I'm working on a solution, and once things start looking more acceptable for something beyond an experimental setup, I will surely look how to get most out of the work already done.
I know essentially adding a comment that just expresses interest is not generally acceptable in issue tickets. However, I am curious about the status of this request in this project. I see that there have been several commits referencing this issue since the initial response. So, I have some questions:
Thanks for this cool project!
Thanks for the interest! It's still my goal to have this feature out, and hopefully soon. I think the composition works well enough for this to proceed.
The branch that I've worked on has some preliminary functionality. I've been testing with i3-gaps, and it works, but as of now there are still some breaking issues. The windows are not stacked correctly and I recall there being some problems with workspaces as well. Furthermore, at the moment i3's titlebars have to be disabled, since the compositor does not handle decorations properly.
To make the standalone compositing possible, some minor refactoring had to be done. However, this refactoring seems to have introduced a crash bug that is triggered in some events. Resolving this is the next milestone. I have a test case and I know why the crash happens, but what actually sets the conditions for it is not clear yet and needs more investigation.
Since you asked, I motivated myself to rebase the branch yesterday. I'll do some checks that it's alright and push it here today along with some details. Hopefully with some details it will be easier for interested people to look into it as well! I'll see what I can do about the bug soon when I have some time.
Awesome work. Can you write a guide for using the standalone compositor please? That will help other to do the test and report stuffs too.
Thanks! Here are some brief instructions on how to get started:
dmabuf_standalone_comp
and build it. Master branch does not have standalone features yet. For some WMs, it might be better to use plain rectangular windows, so before compiling you may want to change this line to 0 (I will make this later post-build configurable)-C
as an argument: chamfer -C --experimental --config=/path/to/config.py --shader-path=/path/to/chamfer/shaders/
I built chamfer
and ran it with chamfer -C --experimental
. I don't know what those --config
and --shader-path
parameters are and I expect there are some defaults, so I omitted those. After doing so, I got a quick segfault. Here's the full terminal log, including figuring out how to use meson, the meson and ninja build log, and subsequent running with output:
I'm willing to continue with any help. Thanks for this project.
Also, running this (with the output from the previous comment) seems to have somehow set the number of XFCE workspaces I have to 1. I didn't realize this would happen, and now all my windows are piled up in 1 workspace. I've re-added the removed workspaces manually and reorganized everything again, but that seems like an issue. I would like to be able to use all my usual workspaces in the end.
Thanks for the report! I may have identified the cause for why all the workspaces are removed, and will submit a fix for testing soon. As for the crash, are you running on nvidia by any chance? If so, you may have to enable SHM in your xorg config, as done here.
The default --config
and --shader-path
assume that chamfer was installed as indicated in the README. If you didn't install after build and have problem with those, you can point --shader-path
to the build directory, and --config
to the config directory that comes with the repository.
The nvidia documentation says this about AllowSHMPixmaps
: "These pixmaps prevent the NVIDIA driver from performing a number of optimizations and degrade performance in many circumstances." I'm going to try it, but I wonder about the surrounding details, like what optimizations are prevented and what kind of performance will be degraded. I've set it now and I'm rebooting.
OK, I enabled it and rebooted, then tried it again. I got another segfault immediately, with a different error this time. Here's the terminal log.
@AlexFolland Please try the following: gdb --args ./chamfer -C --experimental --no-host-memory-import --no-scissoring
, then inside gdb, enter the command r
, once it crashes, use bt
to grab the backtrace and paste it here.
I did that, but the behavior seemed to be different in gdb somehow. Here's my terminal log showing first running it, then running it in gdb.
Oh, I ran the wrong command in my above post. I had duplicated the gdb --args
part. OK. I tried the correct command, but the whole screen froze, so I couldn't continue using anything. I had to kill my terminal, so I don't see the output. I wonder how I can sandbox it in such a way that I can continue using the terminal. Maybe I can SSH in from my phone.
Try this: gdb -ex run -ex bt -ex quit --args ./chamfer -C --experimental --no-host-memory-import --no-scissoring
I did that and it still froze my screen, so I tried it with > output.txt
appended so that when it froze, I could at least get the output in a text file after killing the terminal. Here are the contents of my output.txt
.
Very weird. I suppose @jaelpark might be able to provide any ideas. I would try commenting out https://github.com/jaelpark/chamferwm/blob/master/src/backend.cpp#L744-L745 just to see what would happen (maybe along with the allocation code a couple lines up, but that shouldn't matter).
You linked to the master
branch instead of the dmabuf_standalone_comp
branch. Was that intentional?
Oh oops, that was by mistake. You should be able to find the same code in that branch as well.
The log says it couldn't find the DRI3 extension. Can you check if DRI3 is enabled?
I googled that and searched the nvidia documentation, but I'm not sure how to enable it. I also searched for "direct rendering" and found the AllowIndirectGLXProtocol
setting, which I have enabled in my xorg configuration. Should I disable that? I don't really know how to approach that.
I'm guessing there's no way to have the DRI3 extension loaded on proprietary nvidia drivers, since DRI is more of a mesa thing. Good news is that the code doesn't really strictly depend on this extension yet, so I can make it optional. I'll see if I can commit some changes soon. I think you can leave your configs as they are, with the exception of AllowSHMPixmaps
which is still needed for now.
Hi! I tried this again today, using gdb -ex run -ex bt -ex quit --args ./chamfer -C --experimental --no-host-memory-import --no-scissoring > output.txt
. The whole screen was frozen except for my mouse cursor, so I had to Alt+F4 the terminal to recover. The good news is it didn't seem to crash, and we have more output directly from chamfer
now. Please see the contents of my output.txt
below.
I noticed that if I run it without GDB, it crashes. If I run it with GDB, it doesn't crash. That's inconvenient. However, the crash message shows something that may be useful, since it's an exception error message from your own code. Here's that output for your analysis.
Looking forward to this tried of using the 1000 forks of picom that all have their own issues
Thanks for the interest for the project. Due to busyness with work and stuff, I haven't found much time to work on this lately. There are lots of improvements in other branches I'm looking to merge into the master eventually, including the standalone compositor, but some fixing and more work is still needed. Things are a bit too buggy at the moment to be presentable...
It would be great to use just the vulkan compositor with other WMs, like people use compton in plasma or xfce. Compton itself was considering a vulkan backend but it still didnt fly. What you think, @jaelpark ?