Package Details: picom-git 2189_11.172.gcc8e0a98_2024.02.29-1

Git Clone URL: https://aur.archlinux.org/picom-git.git (read-only, click to copy)
Package Base: picom-git
Description: X compositor (fork of compton) (git-version)
Upstream URL: https://github.com/yshui/picom
Licenses: MIT, MPL-2.0
Conflicts: compton, compton-git, picom
Provides: compton, compton-git, picom
Replaces: compton-git
Submitter: WorMzy
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 358
Popularity: 1.33
First Submitted: 2019-10-24 11:20 (UTC)
Last Updated: 2024-03-01 21:25 (UTC)

Required by (20)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 14 Next › Last »

p4block commented on 2018-10-17 22:01 (UTC)

Actually I cannot get it to vsync in any way right now. I've tried literally hundreds of settings permutations to no avail.

I used to be able to vsync (albeit at a high performance hit) with drm and vblank_mode=0 but not anymore for some reason.

Literally everything else still has tearing, has massive stutter and frametime issues or is just plain broken.

Worst part is this behavior is related to the kernel's amdgpu, mesa and even the xorg ddx, and "The ConfigTM" has changed over the past few months.

I'm pretty sure that at this moment to get a vsyncd desktop on my desktop right now is to run mutter or a wayland (sway) compositor.

I just had to vent a bit here, I'm following this latest fork closely and hope it ends up working great.

yshui commented on 2018-10-16 23:21 (UTC) (edited on 2018-10-16 23:21 (UTC) by yshui)

p4block, what is the problem with amdgpu? Could you not use the glx backend or --vsync opengl there?

Sounds like something worth investigating.

p4block commented on 2018-10-16 11:20 (UTC)

Please add -Dvsync_drm=true to the meson line, as upstream has it disabled by default. It's the only way to get vsync on amdgpu right now.

yshui commented on 2018-10-15 17:49 (UTC)

Cool. I guess I try just stop annotating the vNext tag. That should prevent it from showing up in git describe

WorMzy commented on 2018-10-15 12:21 (UTC)

Haha, don't worry about it. It's unusual for a project to use tags like this, but it's not unheard of. I've changed the way that the pkgver is generated, so it should increment as expected, regardless of whether the latest tag is.

yshui commented on 2018-10-15 11:43 (UTC)

Looking at the changelogs of the PKGBUILD, I noticed that my use of the vNext tag might have caused some trouble for the package maintainer.

My intention is to always use the vNext tag to track the latest commit, so I can use the github release system to keep track of the important changes I made. Besides that, there will also going to be version based tags (e.g. v3).

Now, that seems to create some difficulty in the pkgver handling. So I want to ask what is the packager's opinion on this. Is it fine if I keep using the vNext tag?

WorMzy commented on 2018-10-04 17:25 (UTC)

namcap is only an aide to packagers, some of it's warnings are fine to ignore. In this case, I feel it makes more sense to have the licence installed to a directory named after the project it is a license for, rather than the name of the package.

bidulock commented on 2018-10-04 17:07 (UTC)

You should install license file under /usr/share/licenses/${pkgname}, otherwise, namcap cannot find it.

WorMzy commented on 2018-10-04 12:57 (UTC)

Thanks for the heads up. If yshui has switched the default branch to next, then I feel that is the branch this package should be building from. It may be a bit more buggy, but if you want stability, then you should probably use community/compton anyway.

I'll try to get an updated PKGBUILD pushed out in the next few hours.

bidulock commented on 2018-10-04 11:48 (UTC)

Not really. I think you need #branch=master on the end of source=() now, because the new default branch is 'next'. Otherwise to build on the 'next' branch you will need 'libev' 'xcb-util-image' 'xcb-util-renderutil' and 'pixman' in depends=() and will have to no longer copy the LICENSE file in package=() (as it is no longer there).