1
0
Fork 0
mirror of https://github.com/yshui/picom.git synced 2024-10-27 05:24:17 -04:00
A lightweight compositor for X11
Find a file
Yuxuan Shui f8914dda23
backend: gl: apply postprocessing to border_color
Previously postprocessing is omitted when estimating the color of the
border (e.g. dimming, opacity, inversion, etc.), causing the border to
be drawn with the wrong color.

Related: #770

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2022-02-13 13:54:25 +00:00
.builds ci: freebsd: add missing dependency 2020-10-25 07:03:29 +00:00
.circleci circleci: rename "-Dbuild_docs" -> "-Dwith_docs" 2021-01-06 00:08:21 -03:00
.github github: update git-clang-format-lint 2021-10-25 19:42:22 +01:00
bin picom-trans: Added SPDX-License-Identifier 2021-07-23 21:15:53 +01:00
dbus-examples Update inverter.sh 2020-04-01 04:50:03 +00:00
LICENSES More license stuff... 2018-10-04 11:18:09 +01:00
man Formally deprecate --menu-opacity 2022-01-24 18:44:31 +00:00
media Added 48x48px raster of initial Compton logo 2015-09-17 21:57:11 -04:00
meson rename: replace "compton" in the codebase 2019-10-23 20:24:20 +01:00
src backend: gl: apply postprocessing to border_color 2022-02-13 13:54:25 +00:00
subprojects/test.h test.h: make sure clang-format doesn't reorder the headers 2019-11-11 21:55:23 +00:00
tests tests: set dbus request to the right path 2022-01-27 02:38:52 +00:00
.clang-format file_watch: use kqueue on *BSD platforms 2019-11-11 21:22:57 +00:00
.clang-tidy backend: rename copy -> clone_image 2021-06-14 01:58:30 +01:00
.editorconfig Coding style change 2019-02-07 21:37:13 +00:00
.gitignore gitignore: ignore language server indices 2020-08-30 17:57:05 +01:00
.gitmodules Vendor test.h 2019-08-04 13:49:28 +01:00
compton-default-fshader-win.glsl Feature: #183 custom window shader & #193 --no-fading-destroyed-argb 2014-05-16 15:18:17 +08:00
compton-fake-transparency-fshader-win.glsl Feature: #183 custom window shader & #193 --no-fading-destroyed-argb 2014-05-16 15:18:17 +08:00
compton.desktop set .desktop files to NoDisplay=true 2020-12-14 14:54:33 +01:00
CONTRIBUTORS Update CONTRIBUTORS 2022-01-27 11:21:30 +00:00
COPYING rename: documentation changes 2019-10-23 20:24:25 +01:00
desc.txt Misc: #49: Add CMake support 2012-10-03 13:34:54 +08:00
Doxyfile Fix small misspellings 2019-01-28 10:58:14 +01:00
LICENSE.spdx rename: documentation changes 2019-10-23 20:24:25 +01:00
meson.build Bump version number 2022-02-06 20:59:45 +00:00
meson_options.txt meson: Allow building without compton compat. 2020-05-28 07:05:05 -07:00
picom-dbus.desktop set .desktop files to NoDisplay=true 2020-12-14 14:54:33 +01:00
picom.desktop Support Menu Icon 2021-03-03 00:01:55 -08:00
picom.sample.conf config_libconfig: add dbus option 2022-02-04 16:02:03 +00:00
README.md Add build dependency Debian 2021-09-04 00:29:45 +02:00
README_orig.md update readme 2018-04-16 10:13:55 -04:00

picom

This is a development branch, bugs to be expected

This is forked from the original Compton because it seems to have become unmaintained.

The current battle plan of this fork is to refactor it to make the code possible to maintain, so potential contributors won't be scared away when they take a look at the code.

We also try to fix bugs.

You can leave your feedbacks or thoughts in the discussion tab.

The original README can be found here

Call for testers

--experimental-backends

This flag enables the refactored/partially rewritten backends.

Currently, new backends feature better vsync with the xrender backend and improved input lag with the glx backend (for non-NVIDIA users). The performance should be on par with the old backends.

New backend features will only be implemented on the new backends from now on, and the old backends will eventually be phased out after the new backends stabilize.

To test the new backends, add the --experimental-backends flag to the command you use to run picom. This flag is not available from the configuration file.

To report issues with the new backends, please state explicitly you are using the new backends in your report.

Rename

Rationale

Since the inception of this fork, the existence of two compton repositories has caused some number of confusions. Mainly, people will report issues of this fork to the original compton, or report issues of the original compton here. Later, when distros started packaging this fork of compton, some wanted to differentiate the newer compton from the older version. They found themselves having no choice but to invent a name for this fork. This is less than ideal since this has the potential to cause more confusions among users.

Therefore, we decided to move this fork to a new name. Personally, I consider this more than justified since this version of compton has gone through significant changes since it was forked.

The name

The criteria for a good name were

  1. Being short, so it's easy to remember.
  2. Pronounceability, again, helps memorability
  3. Searchability, so when people search the name, it's easy for them to find this repository.

Of course, choosing a name is never easy, and there is no apparent way to objectively evaluate the names. Yet, we have to solve the aforementioned problems as soon as possible.

In the end, we picked picom (a portmanteau of pico and composite) as our new name. This name might not be perfect, but is what we will move forward with unless there's a compelling reason not to.

Migration

Following the deprecation process, migration to the new name will be broken into 3 steps:

  1. All mentions of compton will be updated to picom in the code base. compton will still be installed, but only as a symlink to picom. When picom is launched via the symlink, a warning message is printed, alerting the user to migrate. Similarly, the old configuration file names and dbus interface names will still be accepted but warned.
  2. 3 major releases after step 1, the warning messages will be prompted to error messages and picom will not start when launched via the symlink.
  3. 3 major releases after step 2, the symlink will be removed.

The dbus interface and service names are unchanged, so no migration needed for that.

Change Log

See Releases

Build

Dependencies

Assuming you already have all the usual building tools installed (e.g. gcc, python, meson, ninja, etc.), you still need:

  • libx11
  • libx11-xcb
  • libXext
  • xproto
  • xcb
  • xcb-damage
  • xcb-xfixes
  • xcb-shape
  • xcb-renderutil
  • xcb-render
  • xcb-randr
  • xcb-composite
  • xcb-image
  • xcb-present
  • xcb-xinerama
  • xcb-glx
  • pixman
  • libdbus (optional, disable with the -Ddbus=false meson configure flag)
  • libconfig (optional, disable with the -Dconfig_file=false meson configure flag)
  • libGL (optional, disable with the -Dopengl=false meson configure flag)
  • libpcre (optional, disable with the -Dregex=false meson configure flag)
  • libev
  • uthash

On Debian based distributions (e.g. Ubuntu), the needed packages are

libxext-dev libxcb1-dev libxcb-damage0-dev libxcb-xfixes0-dev libxcb-shape0-dev libxcb-render-util0-dev libxcb-render0-dev libxcb-randr0-dev libxcb-composite0-dev libxcb-image0-dev libxcb-present-dev libxcb-xinerama0-dev libxcb-glx0-dev libpixman-1-dev libdbus-1-dev libconfig-dev libgl1-mesa-dev libpcre2-dev libpcre3-dev libevdev-dev uthash-dev libev-dev libx11-xcb-dev meson

On Fedora, the needed packages are

dbus-devel gcc git libconfig-devel libdrm-devel libev-devel libX11-devel libX11-xcb libXext-devel libxcb-devel mesa-libGL-devel meson pcre-devel pixman-devel uthash-devel xcb-util-image-devel xcb-util-renderutil-devel xorg-x11-proto-devel

To build the documents, you need asciidoc

To build

$ git submodule update --init --recursive
$ meson --buildtype=release . build
$ ninja -C build

Built binary can be found in build/src

If you have libraries and/or headers installed at non-default location (e.g. under /usr/local/), you might need to tell meson about them, since meson doesn't look for dependencies there by default.

You can do that by setting the CPPFLAGS and LDFLAGS environment variables when running meson. Like this:

$ LDFLAGS="-L/path/to/libraries" CPPFLAGS="-I/path/to/headers" meson --buildtype=release . build

As an example, on FreeBSD, you might have to run meson with:

$ LDFLAGS="-L/usr/local/lib" CPPFLAGS="-I/usr/local/include" meson --buildtype=release . build
$ ninja -C build

To install

$ ninja -C build install

Default install prefix is /usr/local, you can change it with meson configure -Dprefix=<path> build

How to Contribute

Code

You can look at the Projects page, and see if there is anything that interests you. Or you can take a look at the Issues.

Non-code

Even if you don't want to contribute code, you can still contribute by compiling and running this branch, and report any issue you can find.

Contributions to the documents and wiki will also be appreciated.

Contributors

See CONTRIBUTORS