Re: NEW: x11/picom
> I'm sorry but I can only say that picom invoked with the exact command > you posted is working for me on amdgpu. So I second Stuart Henderson > in thinking that this isn't a problem with the port. Have you tried > with a different shader/config? I've tested some other options and they all worked fine. My problem with the shader must be caused by something else. Thanks again! -- greetings, Florian Viehweger
Re: NEW: x11/picom
Florian Viehweger writes:
> Hi,
>
> thank you for your porting effort.
>
>> ping :)
>>
>> re-attaching your last tar for convenience.
>
> Building and running, using the default parameters, seems to be fine. I
> cannot comment about stability / reliability, as I use it relatively
> infrequently.
>
> On Linux I use these arguments to get a grayscale screen. However on
> OpenBSD the screen goes green and picom has to be killed via
> ssh,console or blindly.
>
> picom -C -G --fade-in-step=10 --fade-out-step=10 --backend glx
> --glx-fshader-win "uniform sampler2D tex;uniform float opacity;void
> main() {vec4 color = texture2D(tex, gl_TexCoord[0].xy);gl_FragColor =
> vec4(vec3(0.2126 * color.r + 0.7152 * color.g + 0.0722 * color.b) *
> opacity, color.a * opacity);}"
>
>
> The system console is filled with:
>
> drm:pid92787:evergreen_surface_check_2d *WARNING*
> evergreen_surface_check_2d:282 texture pitch 1680 invalid must be aligned
> with 32
> drm:pid92787:evergreen_cs_track_validate_texture *WARNING*
> evergreen_cs_track_validate_texture:832 texture invalid 0x1a3c3441 0x4204
> 0x0a0a 0x 0x8000 0x8002045a
> [drm] *ERROR* Invalid command stream !
>
> I'm using herbstluftwm as window manager.
I'm sorry but I can only say that picom invoked with the exact command
you posted is working for me on amdgpu. So I second Stuart Henderson in
thinking that this isn't a problem with the port. Have you tried with a
different shader/config?
; dmesg | egrep '(drm|amdgpu)'
amdgpu0 at pci8 dev 0 function 0 "ATI Radeon Vega" rev 0xc6
drm0 at amdgpu0
amdgpu0: msi
amdgpu0: 1920x1080, 32bpp
wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0
> dmesg:
>
> OpenBSD 6.7-current (GENERIC.MP) #360: Sun Jul 19 18:40:05 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16741187584 (15965MB)
> avail mem = 16218763264 (15467MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeaf40 (49 entries)
> bios0: vendor American Megatrends Inc. version "0502" date 05/22/2014
> bios0: ASUSTeK COMPUTER INC. C60M1-I
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
> acpi0: wakeup devices SBAZ(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4)
> UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4)
> RLAN(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32
> bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
> apid 0 (boot processor) cpu0: AMD C-60 APU with Radeon(tm) HD Graphics,
> 1000.17 MHz, 14-02-00 cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0:
> DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var
> ranges, 88 fixed ranges cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD C-60 APU with Radeon(tm) HD Graphics, 1000.01 MHz, 14-02-00
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1:
> DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa
> 0xfec0, version 21, 24 pins, remapped acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318180 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (PE20)
> acpiprt2 at acpi0: bus 3 (PE21)
> acpiprt3 at acpi0: bus -1 (PE22)
> acpiprt4 at acpi0: bus -1 (PE23)
> acpiprt5 at acpi0: bus -1 (BR15)
> acpiprt6 at acpi0: bus -1 (PCE6)
> acpiprt7 at acpi0: bus -1 (PCE7)
> acpiprt8 at acpi0: bus -1 (PCE8)
> acpiprt9 at acpi0: bus -1 (BR14)
> acpicpu0 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0
> extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> extent `pciio' (0x0 - 0x), flags=0
> 0x1 - 0x
> extent `pcimem' (0x0 - 0x), flags=0
> 0x0 - 0xa7ef
> 0xfec0 - 0xfec00fff
> 0xfec1 - 0xfec10fff
> 0xfed0 - 0xfed00fff
> 0xfed61000 - 0xfed70fff
> 0xfed8 - 0xfed8
> 0xfef0
Re: NEW: x11/picom
> I don't think this is a problem with picom, it works with that shader > script on inteldrm: > > inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06 > drm0 at inteldrm0 > inteldrm0: msi, HASWELL, gen 7 > inteldrm0: 1920x1200, 32bpp > wsdisplay0 at inteldrm0 mux 1 > > my OK to import this still stands. Thank you for testing this on intel. I also didn't think this is a problem with picom directly, but wanted to mention it. I do hope it gets imported. -- greetings, Florian Viehweger
Re: NEW: x11/picom
On 2020/07/21 21:28, Florian Viehweger wrote:
> Hi,
>
> thank you for your porting effort.
>
> > ping :)
> >
> > re-attaching your last tar for convenience.
>
> Building and running, using the default parameters, seems to be fine. I
> cannot comment about stability / reliability, as I use it relatively
> infrequently.
>
> On Linux I use these arguments to get a grayscale screen. However on
> OpenBSD the screen goes green and picom has to be killed via
> ssh,console or blindly.
>
> picom -C -G --fade-in-step=10 --fade-out-step=10 --backend glx
> --glx-fshader-win "uniform sampler2D tex;uniform float opacity;void
> main() {vec4 color = texture2D(tex, gl_TexCoord[0].xy);gl_FragColor =
> vec4(vec3(0.2126 * color.r + 0.7152 * color.g + 0.0722 * color.b) *
> opacity, color.a * opacity);}"
>
>
> The system console is filled with:
>
> drm:pid92787:evergreen_surface_check_2d *WARNING*
> evergreen_surface_check_2d:282 texture pitch 1680 invalid must be aligned
> with 32
> drm:pid92787:evergreen_cs_track_validate_texture *WARNING*
> evergreen_cs_track_validate_texture:832 texture invalid 0x1a3c3441 0x4204
> 0x0a0a 0x 0x8000 0x8002045a
> [drm] *ERROR* Invalid command stream !
>
> I'm using herbstluftwm as window manager.
I don't think this is a problem with picom, it works with that shader
script on inteldrm:
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06
drm0 at inteldrm0
inteldrm0: msi, HASWELL, gen 7
inteldrm0: 1920x1200, 32bpp
wsdisplay0 at inteldrm0 mux 1
my OK to import this still stands.
> dmesg:
>
> OpenBSD 6.7-current (GENERIC.MP) #360: Sun Jul 19 18:40:05 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16741187584 (15965MB)
> avail mem = 16218763264 (15467MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeaf40 (49 entries)
> bios0: vendor American Megatrends Inc. version "0502" date 05/22/2014
> bios0: ASUSTeK COMPUTER INC. C60M1-I
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
> acpi0: wakeup devices SBAZ(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4)
> UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4)
> RLAN(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32
> bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
> apid 0 (boot processor) cpu0: AMD C-60 APU with Radeon(tm) HD Graphics,
> 1000.17 MHz, 14-02-00 cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0:
> DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var
> ranges, 88 fixed ranges cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD C-60 APU with Radeon(tm) HD Graphics, 1000.01 MHz, 14-02-00
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1:
> DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa
> 0xfec0, version 21, 24 pins, remapped acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318180 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (PE20)
> acpiprt2 at acpi0: bus 3 (PE21)
> acpiprt3 at acpi0: bus -1 (PE22)
> acpiprt4 at acpi0: bus -1 (PE23)
> acpiprt5 at acpi0: bus -1 (BR15)
> acpiprt6 at acpi0: bus -1 (PCE6)
> acpiprt7 at acpi0: bus -1 (PCE7)
> acpiprt8 at acpi0: bus -1 (PCE8)
> acpiprt9 at acpi0: bus -1 (BR14)
> acpicpu0 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0
> extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> extent `pciio' (0x0 - 0x), flags=0
> 0x1 - 0x
> extent `pcimem' (0x0 - 0x), flags=0
> 0x0 - 0xa7ef
> 0xfec0 - 0xfec00fff
> 0xfec1 - 0xfec10fff
> 0xfed0 - 0xfed00fff
> 0xfed61000 - 0xfed70fff
> 0xfed8 - 0xfed8
> 0xfef0 - 0x
> 0x400 - 0x
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> "PNP0C14" at acpi0 not configured
> cpu0: 1000
Re: NEW: x11/picom
Hi,
thank you for your porting effort.
> ping :)
>
> re-attaching your last tar for convenience.
Building and running, using the default parameters, seems to be fine. I
cannot comment about stability / reliability, as I use it relatively
infrequently.
On Linux I use these arguments to get a grayscale screen. However on
OpenBSD the screen goes green and picom has to be killed via
ssh,console or blindly.
picom -C -G --fade-in-step=10 --fade-out-step=10 --backend glx
--glx-fshader-win "uniform sampler2D tex;uniform float opacity;void
main() {vec4 color = texture2D(tex, gl_TexCoord[0].xy);gl_FragColor =
vec4(vec3(0.2126 * color.r + 0.7152 * color.g + 0.0722 * color.b) *
opacity, color.a * opacity);}"
The system console is filled with:
drm:pid92787:evergreen_surface_check_2d *WARNING*
evergreen_surface_check_2d:282 texture pitch 1680 invalid must be aligned with
32
drm:pid92787:evergreen_cs_track_validate_texture *WARNING*
evergreen_cs_track_validate_texture:832 texture invalid 0x1a3c3441 0x4204
0x0a0a 0x 0x8000 0x8002045a
[drm] *ERROR* Invalid command stream !
I'm using herbstluftwm as window manager.
dmesg:
OpenBSD 6.7-current (GENERIC.MP) #360: Sun Jul 19 18:40:05 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16741187584 (15965MB)
avail mem = 16218763264 (15467MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeaf40 (49 entries)
bios0: vendor American Megatrends Inc. version "0502" date 05/22/2014
bios0: ASUSTeK COMPUTER INC. C60M1-I
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4)
UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4)
RLAN(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32
bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
apid 0 (boot processor) cpu0: AMD C-60 APU with Radeon(tm) HD Graphics,
1000.17 MHz, 14-02-00 cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0:
DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var
ranges, 88 fixed ranges cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD C-60 APU with Radeon(tm) HD Graphics, 1000.01 MHz, 14-02-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1:
DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa
0xfec0, version 21, 24 pins, remapped acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PE20)
acpiprt2 at acpi0: bus 3 (PE21)
acpiprt3 at acpi0: bus -1 (PE22)
acpiprt4 at acpi0: bus -1 (PE23)
acpiprt5 at acpi0: bus -1 (BR15)
acpiprt6 at acpi0: bus -1 (PCE6)
acpiprt7 at acpi0: bus -1 (PCE7)
acpiprt8 at acpi0: bus -1 (PCE8)
acpiprt9 at acpi0: bus -1 (BR14)
acpicpu0 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@100 io@0x1771), C1(@1 halt!), PSS
acpipci0 at acpi0 PCI0
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `pciio' (0x0 - 0x), flags=0
0x1 - 0x
extent `pcimem' (0x0 - 0x), flags=0
0x0 - 0xa7ef
0xfec0 - 0xfec00fff
0xfec1 - 0xfec10fff
0xfed0 - 0xfed00fff
0xfed61000 - 0xfed70fff
0xfed8 - 0xfed8
0xfef0 - 0x
0x400 - 0x
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6290" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 0 int
19, AHCI 1.2 ahci0: port 3: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 3 lun 0:
naa.50014ee2027a5d7c sd0: 953869MB, 512 bytes/sector, 1953525168 sectors
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 0 int
18, version 1.0, legacy support ehci0 at
Re: NEW: x11/picom
ping :)
re-attaching your last tar for convenience.
Stuart Henderson writes:
> On 2020/05/28 20:41, Omar Polo wrote:
>>
>> Bryan Steele writes:
>>
>> > On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
>> > >
>> > > Hi,
>> > >
>> > > This is a port for picom, a compositor for X11. It's an actively
>> > > developed fork of compton.
>> > >
>> > > I've been running for a month now, and it has been rock stable
>> > > (instead
>> > > of compton which would occasionally crash.)
>> > >
>> > > Build and tested on amd64, passes port-lib-depends-check and
>> > > portcheck.
>> > >
>> > > A couple of notes about the patches:
>> > >
>> > > - (AFAIK) the project was recently renamed from "compton" to
>> > > "picom",
>> > > that's the reason they install some files that can conflict with
>> > > x11/compton (like the bin/compton{,-trans} links to
>> > > bin/picom{,-trans}). I've removed (and/or renamed) them to
>> > > avoid the
>> > > conflict, since I wanted to have them both installed
>> > > side-by-side
>> > >
>> > > - moved the manpage from the (port) default share/man/man1 to
>> > > man/man1
>> > >
>> > > - the patch-src_meson_build is an hack to avoid a meson error I
>> > > cannot
>> > > understand
>> > >
>> > > Cheers!
>> > >
>> >
>> > I can't comment on the port itself, but picom looks like it needs
>> > a similar fix for vsync as compton in ports does to use the correct
>> > drm(4) device node.
>> >
>> > -Bryan.
>> >
>> > diff --git src/vsync.c src/vsync.c
>> > index 5980155..8273d28 100644
>> > --- src/vsync.c
>> > +++ src/vsync.c
>> > @@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
>> > */
>> > static bool vsync_drm_init(session_t *ps) {
>> >// Should we always open card0?
>> > - if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0", O_RDWR)) <
>> > 0) {
>> > + if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0", O_RDWR)) < 0) {
>> >log_error("Failed to open device.");
>> >return false;
>> >}
>>
>> Thanks for finding this!
>>
>> attaching an updated tarball with this and the patch by Jan Beich.
>>
>
>
>
> Here's a diff on top to avoid some duplication, put GH_* in the normal
> place, put CONFIGURE_* variables before the targets as is usually done
> in ports, and update the license marker (some of the source code files
> are MPL only so I think we should just show the most restrictive license).
> I updated DESCR a bit too.
>
> The manpage is a bit of a mess but I suppose we can't expect much better
> from asciidoc!
>
> OK sthen@ with that on top (new tar with these changes attached).
>
>
> diff 21bb08e451e5f7126e2ff8ba5827c403e7ceea34 /usr/ports/mystuff
> blob - f4a7636c5438fc26342d756bb0ccdc139ea20786
> file + x11/picom/Makefile
> --- x11/picom/Makefile
> +++ x11/picom/Makefile
> @@ -2,14 +2,13 @@
>
> COMMENT =lightweight compositor for X11
>
> -V = 8
> -PKGNAME =picom-${V}
> +GH_ACCOUNT = yshui
> +GH_PROJECT = picom
> +GH_TAGNAME = v8
>
> CATEGORIES = x11
>
> -HOMEPAGE = https://github.com/yshui/picom
> -
> -# MPL-2.0 AND MIT
> +# MPL 2.0
> PERMIT_PACKAGE = Yes
>
> WANTLIB += GL X11 X11-xcb c config dbus-1 ev m pcre pixman-1
> @@ -17,10 +16,6 @@ WANTLIB += xcb-composite xcb-damage xcb-glx xcb-image
> WANTLIB += xcb-randr xcb-render-util xcb-render xcb-shape xcb-sync
> WANTLIB += xcb-xfixes xcb-xinerama xcb
>
> -GH_ACCOUNT = yshui
> -GH_PROJECT = picom
> -GH_TAGNAME = v8
> -
> MODULES =devel/meson
>
> BUILD_DEPENDS = devel/uthash \
> @@ -34,12 +29,12 @@ LIB_DEPENDS = devel/libconfig \
> devel/pcre \
> x11/dbus
>
> -pre-patch:
> - cd ${WRKSRC}/media && mv compton.svg picom.svg
> - cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
> -
> CONFIGURE_ARGS += -Dwith_docs=true
> CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
> LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
> +
> +pre-patch:
> + cd ${WRKSRC}/media && mv compton.svg picom.svg
> + cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
>
> .include
> blob - 866af67e0f75de1c6b3f447d09d715cc505836b1
> file + x11/picom/pkg/DESCR
> --- x11/picom/pkg/DESCR
> +++ x11/picom/pkg/DESCR
> @@ -1,2 +1,4 @@
> -Picom is a lightweight compositor for X11 (previously a compton
> -fork).
> +Picom is a lightweight, standalone compositor for X11, for use with
> +window managers that do not natively provide compositing functionality.
> +Features include fading, shadows, transparency/dimming for inactive
> +windows, and flexible configuration.
picom.tar.gz
Description: Binary data
Re: NEW: x11/picom
Stuart Henderson writes:
On 2020/05/28 20:41, Omar Polo wrote:
Bryan Steele writes:
> On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
> >
> > Hi,
> >
> > This is a port for picom, a compositor for X11. It's an
> > actively
> > developed fork of compton.
> >
> > I've been running for a month now, and it has been rock
> > stable
> > (instead
> > of compton which would occasionally crash.)
> >
> > Build and tested on amd64, passes port-lib-depends-check
> > and
> > portcheck.
> >
> > A couple of notes about the patches:
> >
> > - (AFAIK) the project was recently renamed from "compton"
> > to
> > "picom",
> > that's the reason they install some files that can
> > conflict with
> > x11/compton (like the bin/compton{,-trans} links to
> > bin/picom{,-trans}). I've removed (and/or renamed) them
> > to
> > avoid the
> > conflict, since I wanted to have them both installed
> > side-by-side
> >
> > - moved the manpage from the (port) default share/man/man1
> > to
> > man/man1
> >
> > - the patch-src_meson_build is an hack to avoid a meson
> > error I
> > cannot
> > understand
> >
> > Cheers!
> >
>
> I can't comment on the port itself, but picom looks like it
> needs
> a similar fix for vsync as compton in ports does to use the
> correct
> drm(4) device node.
>
> -Bryan.
>
> diff --git src/vsync.c src/vsync.c
> index 5980155..8273d28 100644
> --- src/vsync.c
> +++ src/vsync.c
> @@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
> */
> static bool vsync_drm_init(session_t *ps) {
>// Should we always open card0?
> - if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0",
> O_RDWR)) <
> 0) {
> + if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0",
> O_RDWR)) < 0) {
>log_error("Failed to open device.");
>return false;
>}
Thanks for finding this!
attaching an updated tarball with this and the patch by Jan
Beich.
Here's a diff on top to avoid some duplication, put GH_* in the
normal
place, put CONFIGURE_* variables before the targets as is
usually done
in ports, and update the license marker (some of the source code
files
are MPL only so I think we should just show the most restrictive
license).
I updated DESCR a bit too.
Thank you. It is indeed better now, in particular the DESCR.
The manpage is a bit of a mess but I suppose we can't expect
much better
from asciidoc!
OK sthen@ with that on top (new tar with these changes
attached).
Cheers!
diff 21bb08e451e5f7126e2ff8ba5827c403e7ceea34 /usr/ports/mystuff
blob - f4a7636c5438fc26342d756bb0ccdc139ea20786
file + x11/picom/Makefile
--- x11/picom/Makefile
+++ x11/picom/Makefile
@@ -2,14 +2,13 @@
COMMENT = lightweight compositor for X11
-V = 8
-PKGNAME = picom-${V}
+GH_ACCOUNT = yshui
+GH_PROJECT = picom
+GH_TAGNAME = v8
CATEGORIES = x11
-HOMEPAGE = https://github.com/yshui/picom
-
-# MPL-2.0 AND MIT
+# MPL 2.0
PERMIT_PACKAGE = Yes
WANTLIB += GL X11 X11-xcb c config dbus-1 ev m pcre pixman-1
@@ -17,10 +16,6 @@ WANTLIB += xcb-composite xcb-damage xcb-glx
xcb-image
WANTLIB += xcb-randr xcb-render-util xcb-render xcb-shape
xcb-sync
WANTLIB += xcb-xfixes xcb-xinerama xcb
-GH_ACCOUNT = yshui
-GH_PROJECT = picom
-GH_TAGNAME = v8
-
MODULES = devel/meson
BUILD_DEPENDS = devel/uthash \
@@ -34,12 +29,12 @@ LIB_DEPENDS = devel/libconfig \
devel/pcre \
x11/dbus
-pre-patch:
- cd ${WRKSRC}/media && mv compton.svg picom.svg
- cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
-
CONFIGURE_ARGS += -Dwith_docs=true
CONFIGURE_ENV += CPPFLAGS="${CPPFLAGS}
-I${LOCALBASE}/include" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
+
+pre-patch:
+ cd ${WRKSRC}/media && mv compton.svg picom.svg
+ cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
.include
blob - 866af67e0f75de1c6b3f447d09d715cc505836b1
file + x11/picom/pkg/DESCR
--- x11/picom/pkg/DESCR
+++ x11/picom/pkg/DESCR
@@ -1,2 +1,4 @@
-Picom is a lightweight compositor for X11 (previously a compton
-fork).
+Picom is a lightweight, standalone compositor for X11, for use
with
+window managers that do not natively provide compositing
functionality.
+Features include fading, shadows, transparency/dimming for
inactive
+windows, and flexible configuration.
Re: NEW: x11/picom
On 2020/05/28 20:41, Omar Polo wrote:
>
> Bryan Steele writes:
>
> > On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
> > >
> > > Hi,
> > >
> > > This is a port for picom, a compositor for X11. It's an actively
> > > developed fork of compton.
> > >
> > > I've been running for a month now, and it has been rock stable
> > > (instead
> > > of compton which would occasionally crash.)
> > >
> > > Build and tested on amd64, passes port-lib-depends-check and
> > > portcheck.
> > >
> > > A couple of notes about the patches:
> > >
> > > - (AFAIK) the project was recently renamed from "compton" to
> > > "picom",
> > > that's the reason they install some files that can conflict with
> > > x11/compton (like the bin/compton{,-trans} links to
> > > bin/picom{,-trans}). I've removed (and/or renamed) them to
> > > avoid the
> > > conflict, since I wanted to have them both installed
> > > side-by-side
> > >
> > > - moved the manpage from the (port) default share/man/man1 to
> > > man/man1
> > >
> > > - the patch-src_meson_build is an hack to avoid a meson error I
> > > cannot
> > > understand
> > >
> > > Cheers!
> > >
> >
> > I can't comment on the port itself, but picom looks like it needs
> > a similar fix for vsync as compton in ports does to use the correct
> > drm(4) device node.
> >
> > -Bryan.
> >
> > diff --git src/vsync.c src/vsync.c
> > index 5980155..8273d28 100644
> > --- src/vsync.c
> > +++ src/vsync.c
> > @@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
> > */
> > static bool vsync_drm_init(session_t *ps) {
> > // Should we always open card0?
> > - if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0", O_RDWR)) <
> > 0) {
> > + if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0", O_RDWR)) < 0) {
> > log_error("Failed to open device.");
> > return false;
> > }
>
> Thanks for finding this!
>
> attaching an updated tarball with this and the patch by Jan Beich.
>
Here's a diff on top to avoid some duplication, put GH_* in the normal
place, put CONFIGURE_* variables before the targets as is usually done
in ports, and update the license marker (some of the source code files
are MPL only so I think we should just show the most restrictive license).
I updated DESCR a bit too.
The manpage is a bit of a mess but I suppose we can't expect much better
from asciidoc!
OK sthen@ with that on top (new tar with these changes attached).
diff 21bb08e451e5f7126e2ff8ba5827c403e7ceea34 /usr/ports/mystuff
blob - f4a7636c5438fc26342d756bb0ccdc139ea20786
file + x11/picom/Makefile
--- x11/picom/Makefile
+++ x11/picom/Makefile
@@ -2,14 +2,13 @@
COMMENT = lightweight compositor for X11
-V =8
-PKGNAME = picom-${V}
+GH_ACCOUNT = yshui
+GH_PROJECT = picom
+GH_TAGNAME = v8
CATEGORIES = x11
-HOMEPAGE = https://github.com/yshui/picom
-
-# MPL-2.0 AND MIT
+# MPL 2.0
PERMIT_PACKAGE = Yes
WANTLIB += GL X11 X11-xcb c config dbus-1 ev m pcre pixman-1
@@ -17,10 +16,6 @@ WANTLIB += xcb-composite xcb-damage xcb-glx xcb-image
WANTLIB += xcb-randr xcb-render-util xcb-render xcb-shape xcb-sync
WANTLIB += xcb-xfixes xcb-xinerama xcb
-GH_ACCOUNT = yshui
-GH_PROJECT = picom
-GH_TAGNAME = v8
-
MODULES = devel/meson
BUILD_DEPENDS =devel/uthash \
@@ -34,12 +29,12 @@ LIB_DEPENDS = devel/libconfig \
devel/pcre \
x11/dbus
-pre-patch:
- cd ${WRKSRC}/media && mv compton.svg picom.svg
- cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
-
CONFIGURE_ARGS += -Dwith_docs=true
CONFIGURE_ENV += CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
+
+pre-patch:
+ cd ${WRKSRC}/media && mv compton.svg picom.svg
+ cd ${WRKSRC}/media/icons/48x48 && mv compton.png picom.png
.include
blob - 866af67e0f75de1c6b3f447d09d715cc505836b1
file + x11/picom/pkg/DESCR
--- x11/picom/pkg/DESCR
+++ x11/picom/pkg/DESCR
@@ -1,2 +1,4 @@
-Picom is a lightweight compositor for X11 (previously a compton
-fork).
+Picom is a lightweight, standalone compositor for X11, for use with
+window managers that do not natively provide compositing functionality.
+Features include fading, shadows, transparency/dimming for inactive
+windows, and flexible configuration.
picom.tgz
Description: application/tar-gz
Re: NEW: x11/picom
Bryan Steele writes:
On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
Hi,
This is a port for picom, a compositor for X11. It's an
actively
developed fork of compton.
I've been running for a month now, and it has been rock stable
(instead
of compton which would occasionally crash.)
Build and tested on amd64, passes port-lib-depends-check and
portcheck.
A couple of notes about the patches:
- (AFAIK) the project was recently renamed from "compton" to
"picom",
that's the reason they install some files that can conflict
with
x11/compton (like the bin/compton{,-trans} links to
bin/picom{,-trans}). I've removed (and/or renamed) them to
avoid the
conflict, since I wanted to have them both installed
side-by-side
- moved the manpage from the (port) default share/man/man1 to
man/man1
- the patch-src_meson_build is an hack to avoid a meson error I
cannot
understand
Cheers!
I can't comment on the port itself, but picom looks like it
needs
a similar fix for vsync as compton in ports does to use the
correct
drm(4) device node.
-Bryan.
diff --git src/vsync.c src/vsync.c
index 5980155..8273d28 100644
--- src/vsync.c
+++ src/vsync.c
@@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
*/
static bool vsync_drm_init(session_t *ps) {
// Should we always open card0?
- if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0",
O_RDWR)) < 0) {
+ if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0",
O_RDWR)) < 0) {
log_error("Failed to open device.");
return false;
}
Thanks for finding this!
attaching an updated tarball with this and the patch by Jan Beich.
picom.tar.gz
Description: Binary data
Re: NEW: x11/picom
On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
>
> Hi,
>
> This is a port for picom, a compositor for X11. It's an actively
> developed fork of compton.
>
> I've been running for a month now, and it has been rock stable (instead
> of compton which would occasionally crash.)
>
> Build and tested on amd64, passes port-lib-depends-check and portcheck.
>
> A couple of notes about the patches:
>
> - (AFAIK) the project was recently renamed from "compton" to "picom",
> that's the reason they install some files that can conflict with
> x11/compton (like the bin/compton{,-trans} links to
> bin/picom{,-trans}). I've removed (and/or renamed) them to avoid the
> conflict, since I wanted to have them both installed side-by-side
>
> - moved the manpage from the (port) default share/man/man1 to
> man/man1
>
> - the patch-src_meson_build is an hack to avoid a meson error I cannot
> understand
>
> Cheers!
>
I can't comment on the port itself, but picom looks like it needs
a similar fix for vsync as compton in ports does to use the correct
drm(4) device node.
-Bryan.
diff --git src/vsync.c src/vsync.c
index 5980155..8273d28 100644
--- src/vsync.c
+++ src/vsync.c
@@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
*/
static bool vsync_drm_init(session_t *ps) {
// Should we always open card0?
- if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0", O_RDWR)) <
0) {
+ if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0", O_RDWR)) < 0) {
log_error("Failed to open device.");
return false;
}
Re: NEW: x11/picom
Omar Polo writes: > - the patch-src_meson_build is an hack to avoid a meson error I > cannot > understand Upstreaming as https://github.com/yshui/picom/pull/422
Re: NEW: x11/picom
On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
> This is a port for picom, a compositor for X11. It's an actively
> developed fork of compton.
>
> I've been running for a month now, and it has been rock stable (instead
> of compton which would occasionally crash.)
Rock stable here too after running for about one hour... But that is
WITH glx and box/gaussian background blur, options that would make
compton really mess things up on my (rather old) hardware.
Thank you for this port!
Erling
> Build and tested on amd64, passes port-lib-depends-check and portcheck.
$ sysctl | grep vers
kern.version=OpenBSD 6.7-current (GENERIC.MP) #197: Mon May 18 11:00:29 MDT 2020
$ dmesg | grep drm
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5770" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
radeondrm0: 1920x1080, 32bpp
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
> A couple of notes about the patches:
>
> - (AFAIK) the project was recently renamed from "compton" to "picom",
> that's the reason they install some files that can conflict with
> x11/compton (like the bin/compton{,-trans} links to
> bin/picom{,-trans}). I've removed (and/or renamed) them to avoid the
> conflict, since I wanted to have them both installed side-by-side
>
> - moved the manpage from the (port) default share/man/man1 to
> man/man1
>
> - the patch-src_meson_build is an hack to avoid a meson error I cannot
> understand
>
> Cheers!
NEW: x11/picom
Hi,
This is a port for picom, a compositor for X11. It's an actively
developed fork of compton.
I've been running for a month now, and it has been rock stable
(instead
of compton which would occasionally crash.)
Build and tested on amd64, passes port-lib-depends-check and
portcheck.
A couple of notes about the patches:
- (AFAIK) the project was recently renamed from "compton" to
"picom",
that's the reason they install some files that can conflict
with
x11/compton (like the bin/compton{,-trans} links to
bin/picom{,-trans}). I've removed (and/or renamed) them to
avoid the
conflict, since I wanted to have them both installed
side-by-side
- moved the manpage from the (port) default share/man/man1 to
man/man1
- the patch-src_meson_build is an hack to avoid a meson error I
cannot
understand
Cheers!
picom.tar.gz
Description: Binary data
