Bug 28360

Thank you for this report.

Maybe to note in errata?

So this problem arise on a clean install?
I presume this also happens on an upgrade mga7 -> 8.

Picom https://github.com/yshui/picom is a fork of unmaintained Compton https://github.com/chjj/compton/ 

Arch seem to have some good general info https://wiki.archlinux.org/index.php/Picom

I see mga8 still carry Compton too.

Keywords: (none) => FOR_ERRATA8
CC: (none) => fri
Summary: compton-conf => In LxQT, Picom replace Compton for windows transparency. Settings compton-conf need handling.

Yes this problem arise on a clean install, I suppose that happens on upgrade too.

The problem is that Comtpon is'nt maintained and replace by picom and compton-conf is abandoned.

The good way could be to find an other manager to configure picom and not try to fix this or to fix it temporarily  the time to find another solution

Hello,
Some more info.
Problem can raise with migrating. picom will use compton.conf file, but some parameters are no more compatible. The file has to be adjusted. Launching picom in command line gives info on these parameters.
With a new install, there is no config file. Launching picom is OK, but has no effect.
I tried with the file picom.sample.conf from the repository. Launching picom in command line give me an error about vsync not supported.
I had to commute vsync = true; to vsync = false;
After that, transparency is managed.

Another way I didn't try : use kwin instead of openbox as window manager.
I think that we can add the default config file in the rpm, such that users have at least a default configuration file.

CC: (none) => yves.brungard_mageia

default config file added in picom-8.2-2.mga8 in Core/Updates_testing repo, please test!

CC: (none) => geiger.david68210

First removed picom.conf from /home

urpmi --media Testing picom


    ftp://ftp.free.fr//mirrors/mageia.org/distrib/8/x86_64/media/core/updates_testing/picom-8.2-2.mga8.x86_64.rpm
installation de picom-8.2-2.mga8.x86_64.rpm depuis /var/cache/urpmi/rpms
Préparation...                   #######################
      1/1: picom                 #######################
      1/1: désinstallation de picom-8.2-1.mga8.x86_64
                                 #######################
[root@localhost yves]# exit
exit

locate picom.conf
/etc/xdg/picom.conf

[yves@localhost ~]$ picom
[ 16/02/2021 08:37:13.456 vsync_init ERROR ] No supported vsync method found for this backend
[ 16/02/2021 08:37:13.456 session_init FATAL ERROR ] Failed to initialize the backend

Thus,there is just a setting to do. The default backend is xrender.
This is OK for me. 
I would prefer that we withdraw compton-conf, or at least to avoid to pull it.

In errata https://wiki.mageia.org/en/Mageia_8_Errata#LXQt

Keywords: FOR_ERRATA8 => IN_ERRATA8

Trying to summarise the bug situation: we dropped compton (unmaintained) from M8, its successor being picom. Originally with no .conf file. So we offered compton-conf as the default picom config file? But with no dependency between them.

DavidG's update (thanks for this) comment 4 now adds a default picom config file /etc/xdg/picom.conf . Does this now make the package compton-conf redundant - to remove?

Reading the bug & Errata note (thanks papoteur) I remained confused:
- Does picom use /home/user/.config/compton.conf only if it finds it ?
[c3 and Errata => yes]
- or use /home/user/.config/picom.conf always ?
- or use /home/user/.config/picom.conf if it finds it ?
[c0 and c3 => one of these]
- Should the new default /etc/xdg/picom.conf be copied to (& tweaked)
/home/user/.config/picom.conf ?
@DavidG & papoteur:
- Can the new default picom.conf be improved (comment 5)?

I ask these things to clarify the Errata

CC: (none) => lewyssmith

Is it possible to make package install/upgrade rename any existing conf file to .old and brutally put the default conf file in its place?

Picom looks for /home/user/.config/picom.conf a first and if not found, it looks for /etc/xdg/picom.conf. It looks also for compton.conf, but I don't know with which priority.
The customized picom.conf can be either in  /home/user/.config/ for a personal configuration or in /etc/xdg for a system wide configuration.
(In reply to Morgan Leijström from comment #8)
> Is it possible to make package install/upgrade rename any existing conf file
> to .old and brutally put the default conf file in its place?

No, rpm doesn't touch any file in user space.

Thanks papoteur for the explanations.

@DavidG, Yves
re comment 4 comment 5:
I see that you (D) have 'pushed' the picom update including its skeleton .conf file; I wondered whether "Thus, there is just a setting to do. The default backend is xrender" is something general enough to include in the default file - whatever the setting is (Y please say).

The xrender is the backend chosen by upstream as default. I think it is on the secure side, working in most of the cases, perhaps not optimal for performance.

If you mean that our new default relates to xrender - but you tweaked it to something else -, that is fine.

@David: can this not be closed fixed?
Also, should compton-conf-0.16.0-2.mga8.src.rpm be withdrawn?

Sure it can be closed as fixed, for compton-conf I'll remove it for mga9! we can keep it for mga8.

For my part, I've tested the last version of picom package proposed by David and it works fine.

Thank you both for your feedback.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Do I understand correctly that for an upgrade user may still need to tinker and we shall keep this in errata for final?

It should only be in ERRATA if the upgrade from compton to picom will break something. I would hope this would remove compton & compton-config, replacing them with picom and its new config (perhaps no harm if compton-config remains, redundant).
Tweaking of picom's config should only be necessary if the user had previously tweaked compton's config. I prefer this sort of thing to be in RELEASE notes, being an application level change rather than a fault. But they are all wrapped & sealed.

Can Guillaume & papoteur comment sufficiently to advise Morgan? Time is short!

Hi,

There is two ways:

1) user install compton-conf (with installing compton-conf-0.16.0-2.mga8.x86_64.rpm) because he wants to make like MGA7:

In this user have to rename compton.conf as picom.conf in /home/user/.config/ and to comment lines (2;3;4;15;20;36):

- no_dnd_shadow, 
- no_dock_shadow,
- clear shadow,
- menu_opacity, 
- paint-on-overlay,
- alpha_steps,

Commute (l34) vsync = false and replace (l42) glx-swap-method by use-damage = true

Then go to configuration center => LxQt session settings and tick case Compton to activate at boot

2) use Picom without compton-conf file

Run Picom from Accessories menu, to launch picom at boot go to configuration center => LxQt session settings and create in automatic launch menu new entry with: picom 

With Papoteur, we are testing sparky-picom that is tool to configure and launch or stop Picom

I'll let Papoteur put some bring supplements if necessary.
I hope I've answered your request, Lewis

Thank you for such details, on both alternatives for a fresh Mageia 8 install.

So i guess that after upgrade Mageia 7 -> 8, user have to perform the steps for point 1).  Correct?

Will such upgraded system boot to usable desktop before the changes are made? (so the changes can be made) Maybe we should advise to disable compton before upgrade?

Nice to hear me may get sparky-picom

Yes I guess, but I didn't have upgrade but new install.
I'm not at home and in can't test with my VM.

I guess system will boot on usable desktop without Picom started

I have now updated errata with a rewritten condensate of comment 18 (minus line numbers as they did not match /usr/share/compton-conf/compton.conf.example), comment 9, and some own experiments.

(In reply to Guillaume Royer from comment #20)
> I guess system will boot on usable desktop without Picom started

Yes it seem picom will exit if it finds it does not work, and desktop wil stil work.

I can not guarantee that though...

(In reply to Lewis Smith from comment #17)
> It should only be in ERRATA if the upgrade from compton to picom will break
> something.

I believe it only break the fancy effects - but that will make users unhappy, and they go searching.

It could maybe better be documented on a separate wiki page, and linked from errata.

Yes, we still need a page "First steps with LXQt".

(In reply to Guillaume Royer from comment #18)
> With Papoteur, we are testing sparky-picom that is tool to configure and
> launch or stop Picom

How did that go?



(In reply to papoteur from comment #23)
> Yes, we still need a page "First steps with LXQt".

In progress: https://wiki.mageia.org/en/User:Guygoye

(In reply to Morgan Leijström from comment #24)
> (In reply to Guillaume Royer from comment #18)
> > With Papoteur, we are testing sparky-picom that is tool to configure and
> > launch or stop Picom
> 
> How did that go?
> 
> 
> 
> (In reply to papoteur from comment #23)
> > Yes, we still need a page "First steps with LXQt".
> 
> In progress: https://wiki.mageia.org/en/User:Guygoye

Hi Morgan,

First tests are concluding.
Papoteur has to adapt GTK dialog box with Kdialog.
With it and sparky you can load an existing cofiguration file, take default configuration file or modify configuration file.

Papoteur wants to see upstream to ask that GTK dialog Box works with Qt configuration.