Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2
On Mon, 3 Oct 2022, Alexandre Ratchov wrote: On Sun, Sep 25, 2022 at 04:17:06PM +, adr wrote: This patch does that, following the alsa and oss drivers. I CC'd it to ports@ could you provide a quick hint on how to test it? I rebuild xine-lib (add a debug printf to make sure changes of the .so are used by xine). I don't think you need to recompile xine-ui, but it is fast to compile it anyway. You don't need to add printf, if the plugin is loaded correctly you'll have a new option in the audio section to select the speakers. If you don't see this option, something went wrong. Note that there is an option in the gui section to select the level of configuration presented to the user. I would avoid editing by hand .xine/config until you are sure things are ok. Note that xine is unstable in openbsd, prepare yourself for unexpected segfaults (I suspect openbsd doesn't like xine optimizations). Use unscaled ttf fonts for subtitles. Also you can't seek correctly on mkv files (this bug affects other OSes), copy the streams into a different container. But as I said before, no other player performs better with no hardware acceleration. I tried to play this file: $ ffprobe ~/Downloads/Surround\ Sound\ Test\ PCM\ 5.1.m2ts 2>&1 | grep Audio Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, 5.1(side), s16, 4608 kb/s I haven't tried multichannel PCM, but I've tested AAC and A/52 streams. By the way, there is an internal A/52 downmixer but I can't remember if it is available with liba52 disabled. In respect to force the downmix into sndiod, yes I'm with you. But until the developers agree on how to implement it, better to be able to hear an audio stream correctly, don't you think? The patch is really small. Now I think is better to not ask upstream but to keep it as a patch until sndiod is fixed.
Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2
From sio_open(3):
If the device is exposed by the sndiod(8) server, which is the default
configuration, a transparent emulation layer will automatically be set
up, and in this case any combination of rate, encoding and numbers of
channels is supported.
Apparently the emulation layer (which I don't know anything about)
is downmixing badly the channels (the sound downmixed by xine
forcing stereo is perfect). Anyway I think it is a good idea
to add the audio.output.speaker_arrangement option to the driver,
so I'm going to contact the xine devs.
I would prefer to hear first if not from the maintainer, at least
from some other dev, so I'll try again: any thoughts?
On Sun, 25 Sep 2022, adr wrote:
Date: Sun, 25 Sep 2022 16:17:06 + (UTC)
From: adr
To: m...@openbsd.org
Cc: ports@openbsd.org
Subject: Re: xine's ffmpegaudio doesn't downmix,
sio_getpar() reports 6 channels instead of 2
On Thu, 22 Sep 2022, adr wrote:
Hi,
first of all, I've never contributed to the xine project, and
I don't have any experience with sndio, so bear with me...
Frustrated with the bad sound playing a 6 channels aac audio I decided to
take a look. The device is a usb one:
$ dmesg | grep -i audio
uaudio0 at uhub2 port 3 configuration 1 interface 1 "GeneralPlus USB Audio
Device" rev 1.10/1.00 addr 6
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
audio0 at uaudio0
uhidev2 at uhub2 port 3 configuration 1 interface 3 "GeneralPlus USB Audio
Device" rev 1.10/1.00 addr 6
It has only 2 channels for playback.
The file has 5.1 aac audio:
$ ffprobe file.mp4
[...]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp,
224 kb/s (default)
[...]
Xine's ffmpegaudio plugin is supposed to do downmix (please, correct
me if I'm wrong), but:
$ xine --verbose=2 file.mp4
[...]
audio_out: ao_open (0x585415540)
audio_sndio_out: ao_sndio_open bits=16 rate=48000, mode=128
audio_sndio_out: ao_sndio_open 6 channels output
[...]
The code in xine-lib-1.2.12/src/audio_out/audio_sndio_out.c by Brad
Smith is following the recommendations at sio_open(3), there is no
problem there.
sio_getpar() is returning 6 channels as valid, so the sound ends
messed up. The right speaker gets mostly ambient sound and the
voices are almost only audible through the left speaker.
mplayer and mpv have means to force downmix, but xine is the only
media player which can play 1080p h264 video with a decent performance
(if the bitrate is not too high) on an rpi4 (no hardware acceleration,
cpu at 2.2Gz)
One workaround for this particular case could be adding the
configuration setting "audio.output.speaker_arrangement" to
audio_sndio_out.c.
This patch does that, following the alsa and oss drivers.
I CC'd it to ports@
Index: src/audio_out/audio_sndio_out.c
--- src/audio_out/audio_sndio_out.c.orig
+++ src/audio_out/audio_sndio_out.c
@@ -37,6 +37,8 @@
#include
#include "bswap.h"
+#include "speakers.h"
+
#define GAP_TOLERANCEAO_MAX_GAP
#define PCT_TO_MIDI(p) (((p) * SIO_MAXVOL + 50) / 100)
@@ -248,11 +250,15 @@ static void ao_sndio_exit(ao_driver_t *this_gen)
{
sndio_driver_t *this = (sndio_driver_t *) this_gen;
+ this->xine->config->unregister_callbacks (this->xine->config,
"audio.output.speaker_arrangement", NULL, this, sizeof (*this));
+
xprintf (this->xine, XINE_VERBOSITY_DEBUG,
"audio_sndio_out: ao_sndio_exit called\n");
if (this->hdl != NULL)
sio_close(this->hdl);
+
+ free (this);
}
static int ao_sndio_get_property (ao_driver_t *this_gen, int property)
@@ -316,13 +322,27 @@ static int ao_sndio_ctrl(ao_driver_t *this_gen, int cm
return 0;
}
+static void sndio_speaker_arrangement_cb (void *user_data,
+ xine_cfg_entry_t *entry);
+
static ao_driver_t *open_plugin (audio_driver_class_t *class_gen, const void
*data)
{
sndio_class_t *class = (sndio_class_t *) class_gen;
+ config_values_t *config = class->xine->config;
sndio_driver_t *this;
lprintf ("audio_sndio_out: open_plugin called\n");
+ AUDIO_DEVICE_SPEAKER_ARRANGEMENT_TYPES;
+ int speakers;
+
+ speakers = config->register_enum (config,
+ "audio.output.speaker_arrangement",
+ STEREO,
+ (char **)speaker_arrangement,
+ AUDIO_DEVICE_SPEAKER_ARRANGEMENT_HELP,
+ 0, sndio_speaker_arrangement_cb, this);
+
this = calloc(1, sizeof (sndio_driver_t));
if (!this)
return NULL;
@@ -333,10 +353,16 @@ static ao_driver_t *open_plugin (audio_driver_class_t
* Set capabilities
*/
this->capabilities = AO_CAP_MODE_MONO | AO_CAP_MODE_STEREO |
-AO_CAP_MODE_4CHANNEL | AO_CAP_MODE_4_1CHANNEL |
-AO_CAP_MODE_5CHANNEL | AO_CAP_MODE_5_1CHANNEL |
AO_CAP_MIXER_VOL | AO_CAP_MUTE_VOL | AO_CAP_8BITS |
AO_CAP_16BITS;
+ if (speakers == SURROUND4)
+
Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2
On Thu, 22 Sep 2022, adr wrote:
Hi,
first of all, I've never contributed to the xine project, and
I don't have any experience with sndio, so bear with me...
Frustrated with the bad sound playing a 6 channels aac audio I decided to
take a look. The device is a usb one:
$ dmesg | grep -i audio
uaudio0 at uhub2 port 3 configuration 1 interface 1 "GeneralPlus USB Audio
Device" rev 1.10/1.00 addr 6
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
audio0 at uaudio0
uhidev2 at uhub2 port 3 configuration 1 interface 3 "GeneralPlus USB Audio
Device" rev 1.10/1.00 addr 6
It has only 2 channels for playback.
The file has 5.1 aac audio:
$ ffprobe file.mp4
[...]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp,
224 kb/s (default)
[...]
Xine's ffmpegaudio plugin is supposed to do downmix (please, correct
me if I'm wrong), but:
$ xine --verbose=2 file.mp4
[...]
audio_out: ao_open (0x585415540)
audio_sndio_out: ao_sndio_open bits=16 rate=48000, mode=128
audio_sndio_out: ao_sndio_open 6 channels output
[...]
The code in xine-lib-1.2.12/src/audio_out/audio_sndio_out.c by Brad
Smith is following the recommendations at sio_open(3), there is no
problem there.
sio_getpar() is returning 6 channels as valid, so the sound ends
messed up. The right speaker gets mostly ambient sound and the
voices are almost only audible through the left speaker.
mplayer and mpv have means to force downmix, but xine is the only
media player which can play 1080p h264 video with a decent performance
(if the bitrate is not too high) on an rpi4 (no hardware acceleration,
cpu at 2.2Gz)
One workaround for this particular case could be adding the
configuration setting "audio.output.speaker_arrangement" to
audio_sndio_out.c.
This patch does that, following the alsa and oss drivers.
I CC'd it to ports@
Index: src/audio_out/audio_sndio_out.c
--- src/audio_out/audio_sndio_out.c.orig
+++ src/audio_out/audio_sndio_out.c
@@ -37,6 +37,8 @@
#include
#include "bswap.h"
+#include "speakers.h"
+
#define GAP_TOLERANCEAO_MAX_GAP
#define PCT_TO_MIDI(p) (((p) * SIO_MAXVOL + 50) / 100)
@@ -248,11 +250,15 @@ static void ao_sndio_exit(ao_driver_t *this_gen)
{
sndio_driver_t *this = (sndio_driver_t *) this_gen;
+ this->xine->config->unregister_callbacks (this->xine->config,
"audio.output.speaker_arrangement", NULL, this, sizeof (*this));
+
xprintf (this->xine, XINE_VERBOSITY_DEBUG,
"audio_sndio_out: ao_sndio_exit called\n");
if (this->hdl != NULL)
sio_close(this->hdl);
+
+ free (this);
}
static int ao_sndio_get_property (ao_driver_t *this_gen, int property)
@@ -316,13 +322,27 @@ static int ao_sndio_ctrl(ao_driver_t *this_gen, int cm
return 0;
}
+static void sndio_speaker_arrangement_cb (void *user_data,
+ xine_cfg_entry_t *entry);
+
static ao_driver_t *open_plugin (audio_driver_class_t *class_gen, const void
*data)
{
sndio_class_t *class = (sndio_class_t *) class_gen;
+ config_values_t *config = class->xine->config;
sndio_driver_t *this;
lprintf ("audio_sndio_out: open_plugin called\n");
+ AUDIO_DEVICE_SPEAKER_ARRANGEMENT_TYPES;
+ int speakers;
+
+ speakers = config->register_enum (config,
+ "audio.output.speaker_arrangement",
+ STEREO,
+ (char **)speaker_arrangement,
+ AUDIO_DEVICE_SPEAKER_ARRANGEMENT_HELP,
+ 0, sndio_speaker_arrangement_cb, this);
+
this = calloc(1, sizeof (sndio_driver_t));
if (!this)
return NULL;
@@ -333,10 +353,16 @@ static ao_driver_t *open_plugin (audio_driver_class_t
* Set capabilities
*/
this->capabilities = AO_CAP_MODE_MONO | AO_CAP_MODE_STEREO |
-AO_CAP_MODE_4CHANNEL | AO_CAP_MODE_4_1CHANNEL |
-AO_CAP_MODE_5CHANNEL | AO_CAP_MODE_5_1CHANNEL |
AO_CAP_MIXER_VOL | AO_CAP_MUTE_VOL | AO_CAP_8BITS |
AO_CAP_16BITS;
+ if (speakers == SURROUND4)
+this->capabilities |= AO_CAP_MODE_4CHANNEL;
+ if (speakers == SURROUND41)
+this->capabilities |= AO_CAP_MODE_4_1CHANNEL;
+ if (speakers == SURROUND5)
+this->capabilities |= AO_CAP_MODE_5CHANNEL;
+ if (speakers == SURROUND51)
+this->capabilities |= AO_CAP_MODE_5_1CHANNEL;
this->ao_driver.get_capabilities = ao_sndio_get_capabilities;
this->ao_driver.get_property = ao_sndio_get_property;
@@ -352,6 +378,32 @@ static ao_driver_t *open_plugin (audio_driver_class_t
this->ao_driver.control = ao_sndio_ctrl;
return >ao_driver;
+}
+
+static void sndio_speaker_arrangement_cb (void *user_data,
+ xine_cfg_entry_t *entry) {
+ sndio_driver_t *this = (sndio_driver_t *) user_data;
+ int32_t value = entry->num_value;
+ if (value == SURROUND4) {
+this->capabilities |= AO_CAP_MODE_4CHANNEL;
+
Re: Add u-boot-tools flavor
On Tue, 1 Mar 2022, Stuart Henderson wrote: Date: Tue, 1 Mar 2022 18:08:39 + From: Stuart Henderson To: adr Cc: ports@openbsd.org Subject: Re: Add u-boot-tools flavor On 2022/03/01 16:18, adr wrote: On Tue, 1 Mar 2022, Stuart Henderson wrote: I suggest doing this as a separate port. That was my first intention but somehow I thought it would be easer to mantain keeping it in the same port. If you (the developers, specially the arm ones) think this is better I could write another port when I have some time. Some advise about the distfile? Should I stick to the same version? I would stick to the same version. There is an alternative way to handle it, rearrange the layout e.g. ports/sysutils/u-boot/aarch64 ports/sysutils/u-boot/arm ports/sysutils/u-boot/riscv64 ports/sysutils/u-boot/tools sharing common parts in sysutils/u-boot/Makefile.inc The current u-boot port isn't making standard use of the FLAVORS mechanism (which is really meant for ports which can be built with different options but essentially produce the same thing; i.e. most files have the same name between the different flavours and they can't be installed together). It made more sense doing it that way at first as it grew from just an arm build, but as the port gets more complex there are more reasons to separate them out. (I'd be happy enough with a totally separate port, but if you did feel like having them so they could be maintained together, that's the obvious way how). I followed the above layout, builds ok on aarch64. Could someone test it in another arch? And please revise the port, I'm not really familiar with the port system. For example I'd to copy the distinfo file and the patches to all the subdirs. I really dislike using links but maybe they are ok for you. Another thing I don't really like is the use of FILES, it makes the makefile shorter but it generates errors (ignored) in the fake stage. Maybe it would be better to group the boards by their compiled files and use those different lists in the install target. This also would make the makefile reflect the wanted result of the build stage. adr. u-boot.tar.bz2 Description: Binary data
Re: Add u-boot-tools flavor
On Tue, 1 Mar 2022, Stuart Henderson wrote: I suggest doing this as a separate port. That was my first intention but somehow I thought it would be easer to mantain keeping it in the same port. If you (the developers, specially the arm ones) think this is better I could write another port when I have some time. Some advise about the distfile? Should I stick to the same version?
Add u-boot-tools flavor
Hi,
this patch adds a flavor to sysutils/u-boot so tools like mkimage
can be installed in openbsd.
https://u-boot.readthedocs.io/en/latest/build/tools.html
Regards,
adr.
==
Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.90
diff -u -p -u -r1.90 Makefile
--- Makefile15 Jan 2022 11:56:50 - 1.90
+++ Makefile1 Mar 2022 14:30:07 -
@@ -3,7 +3,7 @@
BROKEN-sparc64=Error: the specified option is not accepted in ISB at
operand 1 -- isb sy
BROKEN-arm=lib/time.c:187:1: internal compiler error: Bus error
-FLAVORS= aarch64 arm riscv64
+FLAVORS= aarch64 arm riscv64 tools
FLAVOR?= arm
COMMENT= U-Boot firmware
@@ -150,6 +150,11 @@ BOARDS=\
BOARDS=\
qemu-riscv64_smode \
sifive_unmatched
+.elif "${FLAVOR}" == "tools"
+WANTLIB += c crypto ssl
+MAKE_FLAGS+= KBUILD_CFLAGS+="-I/usr/include"
+MAKE_FLAGS+= CC="${CC}"
+BOARDS= tools-only
.endif
FILES=\
@@ -169,6 +174,16 @@ FILES=\
spl/sunxi-spl.bin \
spl/u-boot-spl.bin
+TOOLS=\
+ dumpimage \
+ fdtgrep \
+ fit_check_sign \
+ gen_eth_addr \
+ gen_ethaddr_crc \
+ img2srec \
+ mkenvimage \
+ mkimage
+
do-build:
.for BOARD in ${BOARDS}
cd ${WRKSRC} && \
@@ -176,8 +191,11 @@ do-build:
${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig
-.if "${BOARD:M*-rk3399*}"
+.if "${BOARD}" == "tools-only"
cd ${WRKSRC} && \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
+ O="build/${BOARD}" -f ${MAKE_FILE} ${BOARD}
+.elif "${BOARD:M*-rk3399*}"
${SETENV} ${MAKE_ENV} BL31=${RK3399_BL31} ${MAKE_PROGRAM} \
${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} ${ALL_TARGET}
@@ -232,11 +250,17 @@ do-build:
.endfor
do-install:
+.if "${FLAVOR}" == "tools"
+.for f in ${TOOLS}
+ ${INSTALL_PROGRAM} ${WRKSRC}/build/tools-only/tools/${f} ${PREFIX}/bin/
+.endfor
+.else
${INSTALL_DATA_DIR} ${PREFIX}/share/u-boot
.for BOARD in ${BOARDS} ${SUNXI64}
${INSTALL_DATA_DIR} ${PREFIX}/share/u-boot/${BOARD}
-cd ${WRKSRC}/build/${BOARD} && \
cp ${FILES} ${PREFIX}/share/u-boot/${BOARD}/
.endfor
+.endif
.include
Index: pkg/PFRAG.tools
===
RCS file: pkg/PFRAG.tools
diff -N pkg/PFRAG.tools
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/PFRAG.tools 1 Mar 2022 14:30:08 -
@@ -0,0 +1,9 @@
+@comment $OpenBSD: PLIST,v 1.6 2021/04/28 04:03:28 jsg Exp $
+@bin bin/dumpimage
+@bin bin/fdtgrep
+@bin bin/fit_check_sign
+@bin bin/gen_eth_addr
+@bin bin/gen_ethaddr_crc
+@bin bin/img2srec
+@bin bin/mkenvimage
+@bin bin/mkimage
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/u-boot/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -r1.6 PLIST
--- pkg/PLIST 28 Apr 2021 04:03:28 - 1.6
+++ pkg/PLIST 1 Mar 2022 14:30:08 -
@@ -2,3 +2,4 @@
%%aarch64%%
%%arm%%
%%riscv64%%
+%%tools%%Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.90
diff -u -p -u -r1.90 Makefile
--- Makefile 15 Jan 2022 11:56:50 - 1.90
+++ Makefile 1 Mar 2022 14:30:07 -
@@ -3,7 +3,7 @@
BROKEN-sparc64= Error: the specified option is not accepted in ISB at operand 1 -- isb sy
BROKEN-arm= lib/time.c:187:1: internal compiler error: Bus error
-FLAVORS= aarch64 arm riscv64
+FLAVORS= aarch64 arm riscv64 tools
FLAVOR?= arm
COMMENT= U-Boot firmware
@@ -150,6 +150,11 @@ BOARDS=\
BOARDS=\
qemu-riscv64_smode \
sifive_unmatched
+.elif "${FLAVOR}" == "tools"
+WANTLIB += c crypto ssl
+MAKE_FLAGS+= KBUILD_CFLAGS+="-I/usr/include"
+MAKE_FLAGS+= CC="${CC}"
+BOARDS= tools-only
.endif
FILES=\
@@ -169,6 +174,16 @@ FILES=\
spl/sunxi-spl.bin \
spl/u-boot-spl.bin
+TOOLS=\
+ dumpimage \
+ fdtgrep \
+ fit_check_sign \
+ gen_eth_addr \
+ gen_ethaddr_crc \
+ img2srec \
+ mkenvimage \
+ mkimage
+
do-build:
.for BOARD in ${BOARDS}
cd ${WRKSRC} && \
@@ -176,8 +191,11 @@ do-build:
${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig
-.if "${BOARD:M*-rk3399*}"
+.if "${BOARD}" == "tools-only"
cd ${WRKSRC} && \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
+ O="build/${BOARD}" -f ${MAKE_FILE}
mame on arm64
I managed to compiled emulators/mame in an rpi4. Some thoughts about the port: In patch-makefile ifeq ($(OS),windows) ifeq (posix,$(SHELLTYPE)) -GCC_VERSION := $(shell $(TOOLCHAIN)$(subst @,,$(CC)) -dumpversion 2> /dev/null) -CLANG_VERSION:= $(shell $(TOOLCHAIN)$(subst @,,$(CC)) --version 2> /dev/null| head -n 1 | grep clang | sed "s/^.*[^0-9]\([0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\).*$$/\1/" | head -n 1) +GCC_VERSION := $(shell cc -dumpversion 2> /dev/null) +CLANG_VERSION:= $(shell cc --version 2> /dev/null | head -n 1 | grep -e 'version [0-9]\.[0-9]\.[0-9]' -o | sed -e 's,version ,,' | tail -n 1) PYTHON_AVAILABLE := $(shell $(PYTHON) --version > /dev/null 2>&1 && echo python) GIT_AVAILABLE:= $(shell git --version > /dev/null 2>&1 && echo git) else This doesn't make any sense, this part is only processed on windows. But you'd need 'grep clang' anyway or CLANG_VERSION would be set even if the compiler is gcc. Note that if this weren't the case, you could just use -dumpversion. CC ends up defined to gcc by default by makefile, but using OVERRIDE_CC isn't sufficient because CLANG_VERSION is left out of the conditional code: [...] ifdef OVERRIDE_CC GCC_VERSION := $(shell $(TOOLCHAIN)$(subst @,,$(OVERRIDE_CC)) -dumpversion 2> /dev/null) else GCC_VERSION := $(shell $(TOOLCHAIN)$(subst @,,$(CC)) -dumpversion 2> /dev/null) endif ifeq ($(findstring emcc,$(CC)),emcc) CLANG_VERSION:= $(shell $(TOOLCHAIN)$(subst @,,$(CC)) -v 2>&1 >/dev/null | grep 'clang version' | head -n 1 | grep -e 'version [0-9]\+\.[0-9]\+ \(\.[0-9]\+\)\?' -o | grep -e '[0-9]\+\.[0-9]\+\(\.[0-9]\+\)\?' -o | tail -n 1) else CLANG_VERSION:= $(shell $(TOOLCHAIN)$(subst @,,$(CC)) --version 2> /dev/null | head -n 1 | grep -e 'version [0-9]\+\.[0-9]\+\(\.[0-9]\+\)\?' -o | grep -e '[0-9]\+\.[0-9]\+\(\.[0-9]\+\)\?' -o | tail -n 1) endif PYTHON_AVAILABLE := $(shell $(PYTHON) --version > /dev/null 2>&1 && echo python) GIT_AVAILABLE := $(shell git --version > /dev/null 2>&1 && echo git) endif ifeq ($(CLANG_VERSION),) $(info GCC $(GCC_VERSION) detected) else $(info Clang $(CLANG_VERSION) detected) ifneq ($(TARGETOS),asmjs) ifeq ($(ARCHITECTURE),_x64) ARCHITECTURE := _x64_clang else ifneq ($(filter arm64%,$(UNAME_M)),) ARCHITECTURE := _arm64_clang else ARCHITECTURE := _x86_clang endif endif endif endif [...] Even correcting this, CLANG_VERSION is not detected because grep is using gnu basic regular expression syntax, in openbsd BRE there is no + nor ? [re_format(7)]. Here is a diff only tested on arm64. I left out emcc of the ifdef OVERRIDE_CC statement, add it if you think it will be of any use in the future. Regards, adr = Index: Makefile === RCS file: /cvs/ports/emulators/mame/Makefile,v retrieving revision 1.57 diff -u -p -r1.57 Makefile --- Makefile1 Dec 2021 14:55:20 - 1.57 +++ Makefile27 Feb 2022 10:49:37 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.57 2021/12/01 14:55:20 fcambus Exp $ BROKEN-i386 = broken on 32-bit; enum in src/frontend/mame/ui/videoopt.h starting at 0x8000 -ONLY_FOR_ARCHS = amd64 i386 +ONLY_FOR_ARCHS = amd64 i386 arm64 DPB_PROPERTIES = parallel USE_WXNEEDED = Yes Index: patches/patch-makefile === RCS file: /cvs/ports/emulators/mame/patches/patch-makefile,v retrieving revision 1.20 diff -u -p -r1.20 patch-makefile --- patches/patch-makefile 1 Oct 2021 12:13:51 - 1.20 +++ patches/patch-makefile 27 Feb 2022 10:49:37 - @@ -27,14 +27,51 @@ Index: makefile # set the symbols level ifdef SYMBOLS PARAMS += --SYMBOLS='$(SYMBOLS)' -@@ -995,8 +990,8 @@ endif - - ifeq ($(OS),windows) - ifeq (posix,$(SHELLTYPE)) --GCC_VERSION := $(shell $(TOOLCHAIN)$(subst @,,$(CC)) -dumpversion 2> /dev/null) --CLANG_VERSION:= $(shell $(TOOLCHAIN)$(subst @,,$(CC)) --version 2> /dev/null| head -n 1 | grep clang | sed "s/^.*[^0-9]\([0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\).*$$/\1/" | head -n 1) -+GCC_VERSION := $(shell cc -dumpversion 2> /dev/null) -+CLANG_VERSION:= $(shell cc --version 2> /dev/null | head -n 1 | grep -e 'version [0-9]\.[0-9]\.[0-9]' -o | sed -e 's,version ,,' | tail -n 1) - PYTHON_AVAILABLE := $(shell $(PYTHON) --version > /dev/null 2>&1 && echo python) - GIT_AVAILABLE:= $(shell git --version > /dev/null 2>&1 && echo git) +@@ -1024,14 +1019,15 @@ endif + else + ifdef OVERRIDE_CC + GCC_VERSION := $(shell $(TOOLCHAIN)$(subst @,,$(OVERRIDE_CC)) -dumpversion 2> /dev/null) ++CLANG_VERSION:= $(shell $(TOOLCHAIN)$(subst @,,$(OVERRIDE_CC)) --version 2> /dev/null | head -n 1 | grep -Ee 'version [0-9]+\.[0-9]+(\.[
[update] xine-ui-0.99.13
I've been using it for a while, I only see improvements. Maybe someone
wants to try it.
https://sourceforge.net/projects/xine/files/xine-ui/0.99.13/
xine-ui (0.99.13)
* Add audio control window.
* Add some menu shortcuts.
* Add build optimizations.
* Better keyboard and mouse wheel support.
* Improved key binding editor.
* Massive code cleanup.
* Massive graphics optimizations.
* Drop mrl path length limit.
* Add utf8 and clipboard support for text input fields.
* Add skin shared pixmap and text position features.
* Xinetic skin update.
* Many small fixes and optinizations.
* Update german translation.
* Update french translation.
* Build fixes.
* Faster build.
* Separate xitk and X11 stuff pt 1.
==
diff -Nur /usr/ports/multimedia/xine-ui/Makefile
/usr/ports/mystuff/multimedia/xine-ui/Makefile
--- /usr/ports/multimedia/xine-ui/Makefile Tue Feb 15 18:19:30 2022
+++ /usr/ports/mystuff/multimedia/xine-ui/Makefile Thu Feb 17 00:49:47 2022
@@ -2,8 +2,8 @@
COMMENT= multimedia player
-DISTNAME= xine-ui-0.99.12
-REVISION= 2
+DISTNAME= xine-ui-0.99.13
+REVISION= 0
CATEGORIES=multimedia
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=xine/}
EXTRACT_SUFX= .tar.xz
diff -Nur /usr/ports/multimedia/xine-ui/distinfo
/usr/ports/mystuff/multimedia/xine-ui/distinfo
--- /usr/ports/multimedia/xine-ui/distinfo Tue Dec 24 18:16:05 2019
+++ /usr/ports/mystuff/multimedia/xine-ui/distinfo Wed Feb 16 23:35:49 2022
@@ -1,2 +1,2 @@
-SHA256 (xine-ui-0.99.12.tar.xz) = VL/EnY5ourqE4WJZUb02NSwKWIMYCJW9lA9VOLSu9YM=
-SIZE (xine-ui-0.99.12.tar.xz) = 1980672
+SHA256 (xine-ui-0.99.13.tar.xz) = sjgtB1xysbEAOeDpAxDMhsjZEDWMU1We2C09WEIB9cU=
+SIZE (xine-ui-0.99.13.tar.xz) = 2156892
diff -Nur /usr/ports/multimedia/xine-ui/patches/CVS/Entries
/usr/ports/mystuff/multimedia/xine-ui/patches/CVS/Entries
--- /usr/ports/multimedia/xine-ui/patches/CVS/Entries Sat Dec 28 18:16:04 2019
+++ /usr/ports/mystuff/multimedia/xine-ui/patches/CVS/Entries Thu Jan 1
00:00:00 1970
@@ -1,3 +0,0 @@
-/patch-src_xitk_network_c/1.1/Sat Dec 28 10:08:17 2019//
-/patch-src_xitk_playlist_c/1.1/Sat Dec 28 10:08:17 2019//
-D
diff -Nur /usr/ports/multimedia/xine-ui/patches/CVS/Repository
/usr/ports/mystuff/multimedia/xine-ui/patches/CVS/Repository
--- /usr/ports/multimedia/xine-ui/patches/CVS/RepositorySat Dec 28
18:16:04 2019
+++ /usr/ports/mystuff/multimedia/xine-ui/patches/CVS/RepositoryThu Jan
1 00:00:00 1970
@@ -1 +0,0 @@
-ports/multimedia/xine-ui/patches
diff -Nur /usr/ports/multimedia/xine-ui/patches/patch-src_xitk_network_c
/usr/ports/mystuff/multimedia/xine-ui/patches/patch-src_xitk_network_c
--- /usr/ports/multimedia/xine-ui/patches/patch-src_xitk_network_c Sat Dec
28 10:08:17 2019
+++ /usr/ports/mystuff/multimedia/xine-ui/patches/patch-src_xitk_network_c
Thu Jan 1 00:00:00 1970
@@ -1,27 +0,0 @@
-$OpenBSD: patch-src_xitk_network_c,v 1.1 2019/12/28 10:08:17 ajacoutot Exp $
-
-Fix some crashes.
-
-Eg, when starting a playlist while already playing something else.
-
-Index: src/xitk/network.c
src/xitk/network.c.orig
-+++ src/xitk/network.c
-@@ -2016,7 +2016,7 @@ static void do_playlist(const commands_t *cmd, client_
- if(j >= 0) {
-
- if((gui->playlist.cur == j) && ((xine_get_status(gui->stream) != XINE_STATUS_STOP)))
--gui_stop(NULL, NULL);
-+gui_stop(NULL, gui);
-
- mediamark_free_entry(j);
-
-@@ -2044,7 +2044,7 @@ static void do_playlist(const commands_t *cmd, client_
- enable_playback_controls (gui->panel, 0);
-
- if(xine_get_status(gui->stream) != XINE_STATUS_STOP)
-- gui_stop(NULL, NULL);
-+ gui_stop(NULL, gui);
-
- gui_set_current_mmk(NULL);
- }
diff -Nur /usr/ports/multimedia/xine-ui/patches/patch-src_xitk_playlist_c
/usr/ports/mystuff/multimedia/xine-ui/patches/patch-src_xitk_playlist_c
--- /usr/ports/multimedia/xine-ui/patches/patch-src_xitk_playlist_c Sat Dec
28 10:08:17 2019
+++ /usr/ports/mystuff/multimedia/xine-ui/patches/patch-src_xitk_playlist_c
Thu Jan 1 00:00:00 1970
@@ -1,45 +0,0 @@
-$OpenBSD: patch-src_xitk_playlist_c,v 1.1 2019/12/28 10:08:17 ajacoutot Exp $
-
-Fix some crashes.
-
-Eg, when starting a playlist while already playing something else.
-
-Index: src/xitk/playlist.c
src/xitk/playlist.c.orig
-+++ src/xitk/playlist.c
-@@ -260,7 +260,7 @@ void playlist_delete_entry(int j) {
- enable_playback_controls (gui->panel, 0);
-
- if(xine_get_status(gui->stream) != XINE_STATUS_STOP)
-- gui_stop(NULL, NULL);
-+ gui_stop(NULL, gui);
-
- gui_set_current_mmk(NULL);
- xitk_inputtext_change_text(playlist->winput, NULL);
-@@ -294,7 +294,7 @@ void playlist_delete_all(xitk_widget_t *w, void *data)
- playlist_update_playlist();
-
- if(xine_get_status(gui->stream) != XINE_STATUS_STOP)
--gui_stop(NULL,
xine can't play ac3 with ffmpeg libs
Hi, Xine can't play ac3 audio correctly (anyone I've tried) with ffmpeg. Compiling it with the internal a/52 solves the problem (the ports' liba52 is incompatible, xine will end up using the internal anyway). Just add --enable-a52dec=internal and update PLIST. Regards, adr.
Re: Update xine-lib to 1.2.11
On Thu, Jan 14, 2021 at 07:48:02PM -0500, Brad Smith wrote: > This is missing patch removals. Here is a more appropriate diff.. Oh, sorry about that...
Update xine-lib to 1.2.11
Hello,
This update xine-lib to version 1.2.11.
A lot of code from patches had been applied upstream.
Tested in arm64.
xine-lib/1.2.11/README.txt:
xine-lib (1.2.11) 2020-12-06
* Add gopher input plugin.
* Add user settings for IPv6.
* Split a52 spdif output to separate decoder.
* Code cleanup.
* More engine optimization.
* Small optimizations (opengl2, dvb subtitles, png, mpeg-ts).
* Better A/V sync.
* Fix a few crashes.
* Fix bluray playback.
* Fix VAAPI picture jitter and green flashes.
* Fix Opus and EAC3 audio playback.
* Fix text subtitles.
* Fix mpeg-ts (hdmv mode, detection of cut TV recordings).
* Fix mpeg layer 1-4 audio timing.
* Fix some VDR issues.
* Fix HLS VOD mode.
* Many small fixes.
* Build fixes.
* BSD fixes.
* Update german translation.
* Update internal libdca to upstream 0.0.7.
Regards,
adr.
? multimedia_xine-lib.diff
Index: Makefile
===
RCS file: /cvs/ports/multimedia/xine-lib/Makefile,v
retrieving revision 1.145
diff -u -p -r1.145 Makefile
--- Makefile20 Mar 2020 16:44:25 - 1.145
+++ Makefile14 Jan 2021 00:20:50 -
@@ -2,7 +2,7 @@
COMMENT= multimedia decoding library
-DISTNAME= xine-lib-1.2.10
+DISTNAME= xine-lib-1.2.11
CATEGORIES=multimedia
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=xine/}
EXTRACT_SUFX= .tar.xz
@@ -28,7 +28,7 @@ WANTLIB += xcb-dri2 xcb-dri3 xcb-glx xcb
WANTLIB += xcb-sync xcb-xfixes xcb-xv xdg-basedir xml2 xshmfence
WANTLIB += xvidcore z
-XINEAPI_REV= 2.8
+XINEAPI_REV= 2.9
SUBST_VARS+= XINEAPI_REV
COMPILER= base-clang ports-gcc
Index: distinfo
===
RCS file: /cvs/ports/multimedia/xine-lib/distinfo,v
retrieving revision 1.31
diff -u -p -r1.31 distinfo
--- distinfo25 Dec 2019 15:50:45 - 1.31
+++ distinfo14 Jan 2021 00:20:50 -
@@ -1,2 +1,2 @@
-SHA256 (xine-lib-1.2.10.tar.xz) = nLPwadPB/7dFbqkak2qFu7B6wqt74enQ0slP/kEQ3Fc=
-SIZE (xine-lib-1.2.10.tar.xz) = 5226116
+SHA256 (xine-lib-1.2.11.tar.xz) = 71GyHRDdoQRfp9cRvZFxz9rwpaKHQjO88W/98o7AcAU=
+SIZE (xine-lib-1.2.11.tar.xz) = 5282204
Index: patches/patch-configure_ac
===
RCS file: /cvs/ports/multimedia/xine-lib/patches/patch-configure_ac,v
retrieving revision 1.22
diff -u -p -r1.22 patch-configure_ac
--- patches/patch-configure_ac 25 Dec 2019 15:50:45 - 1.22
+++ patches/patch-configure_ac 14 Jan 2021 00:20:50 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-configure_ac,v 1.22 2019
Index: configure.ac
--- configure.ac.orig
+++ configure.ac
-@@ -891,9 +891,7 @@ AC_ARG_ENABLE([optimizations],
+@@ -888,9 +888,7 @@ AC_ARG_ENABLE([optimizations],
[AS_HELP_STRING([--disable-optimizations], [Don't try to guess
what optimization to enable])],
[], [test x"$enable_debug" != x"no" &&
enable_optimizations="no"])
AM_CONDITIONAL([DISABLE_OPTIMIZATIONS], [test x"$enable_optimizations" =
x"no"])
@@ -14,7 +14,7 @@ Index: configure.ac
dnl For multi-pass compilation: never when cross-compiling
if test x"$cross_compiling" != x"yes"; then
if test x"$GCC" = x"yes"; then
-@@ -914,7 +912,7 @@ AC_SUBST(O0_CFLAGS)
+@@ -911,7 +909,7 @@ AC_SUBST(O0_CFLAGS)
AC_SUBST(PASS1_CFLAGS)
AC_SUBST(PASS2_CFLAGS)
@@ -23,7 +23,7 @@ Index: configure.ac
dnl xineutils.h:dlist_*
-@@ -1297,9 +1295,9 @@ t q
+@@ -1324,9 +1322,9 @@ t q
b
:q
q"
Index: patches/patch-m4_decoders_m4
===
RCS file: /cvs/ports/multimedia/xine-lib/patches/patch-m4_decoders_m4,v
retrieving revision 1.6
diff -u -p -r1.6 patch-m4_decoders_m4
--- patches/patch-m4_decoders_m425 Dec 2019 15:50:45 - 1.6
+++ patches/patch-m4_decoders_m414 Jan 2021 00:20:50 -
@@ -14,175 +14,3 @@ Index: m4/decoders.m4
if test x"$have_external_libmpcdec" != x"yes"; then
AC_MSG_RESULT([*** no usable version of libmpcdec found,
using internal copy ***])
else
-@@ -538,48 +538,42 @@ a52_init ();
-
-
- dnl Ogg/Speex (optional; enabled by default; external)
--AC_ARG_WITH([speex],
--[AS_HELP_STRING([--with-speex], [Enable Speex audio decoder
support (default: enabled)])],
--[test x"$withval" != x"no" && with_speex="yes"])
-+AC_ARG_WITH([speex], [AS_HELP_STRING([--with-speex], [Enable Speex audio
decoder support (default: enabled)])],
-+[], [with_speex="try"])
- if test x"$with_speex" != x"no"; then
--PKG_CHECK_MODULES([SPEEX], [ogg speex], [have_speex=yes],
[have_speex=no])
--if test x"$with_speex" = x"
Re: stlink port?
I applied your corrections. Regards, adr. devel_stlink.tgz Description: application/tar-gz
Re: stlink port?
Hi, thanks for the feedback.
On Mon, Oct 26, 2020 at 05:39:35PM +, Stuart Henderson wrote:
> : post-build:
> : @cd ${WRKBUILD}/bin/; strip -s st-flash st-info st-util stlink-gui
>
> Don't unconditionally strip, this should only be done under control of
> ports. Normally this is handled automatically in the "make install"
> stage by ports infrastructure.
The executables aren't stripped. I should keep the post-build target?
stlink port?
Hello, this is a port of https://github.com/stlink-org/stlink: "STLink is an open source toolset to program and debug STM32 devices and boards manufactured by STMicroelectronics. It supports several so called STLINK programmer boards (and clones thereof) which use a microcontroller chip to translate commands from USB to JTAG/SWD." I could separate the gui in another package or use flavors if there is any interest in the port. I'm not offering myself as the maintainer because I'm not a cmake user. Regards, adr. devel_stlink.tgz Description: application/tar-gz
Re: fix sdl2 build on arm
On Fri, Oct 23, 2020 at 11:45:55PM -0400, Brad Smith wrote: > > #0 0x759109fc in __driDriverGetExtensions_kms_swrast () > > from /usr/X11R6/lib/modules/dri/swrast_dri.so > > To me it looks like something that should be fixed in Mesa. Sure, but in the meanwhile, as the arm port doesn't use opengl better to disable it. Those unaligned problems can be very tricky, as you will see with your new board. I will take a look if I find time. Regards, adr
ffmpeg & x264 on arm
Hi Brad,
we talked about this last year (and tested some other codecs).
Can you apply this?
Regards,
adr.
==
multimedia/x264:
--- Makefile.orig Thu Oct 15 09:02:38 2020
+++ MakefileThu Oct 15 09:04:07 2020
@@ -42,7 +42,8 @@
--disable-swscale
.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "mips64" || \
-${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc"
+${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc" || \
+${MACHINE_ARCH} == "arm"
CONFIGURE_ARGS+=--disable-asm
.endif
==
graphics/ffmpeg:
--- Makefile.orig Fri Oct 16 14:20:11 2020
+++ MakefileThu Oct 15 13:55:18 2020
@@ -130,6 +130,10 @@
--objcc="/usr/bin/false" \
--optflags="${OPTFLAGS}"
+.if ${MACHINE_ARCH} == "arm"
+CONFIGURE_ARGS+=--disable-asm
+.endif
+
CONFIGURE_ENV+=TERM=${TERM} \
TMPDIR=${WRKBUILD}
Re: fix sdl2 build on arm
Hello,
Opengl, opengles must be disabled or strict alignment errors
will occur.
Only tested with ffplay for now.
[...]
Program terminated with signal 10, Bus error.
[...]
#0 0x759109fc in __driDriverGetExtensions_kms_swrast ()
from /usr/X11R6/lib/modules/dri/swrast_dri.so
I don't see a reason to try to fix it now.
Regards,
adr.
--- Makefile.orig Thu Oct 15 09:50:24 2020
+++ MakefileThu Oct 15 20:08:12 2020
@@ -54,9 +54,11 @@
CONFIGURE_ARGS+= --disable-atomic
.endif
-# clang can't handle simd asm
.if ${MACHINE_ARCH} == "arm"
+# clang can't handle simd asm
CONFIGURE_ARGS+= --disable-arm-simd
+CONFIGURE_ARGS+= --disable-video-opengl
+CONFIGURE_ARGS+= --disable-video-opengles
.endif
# tests in test subdir, but interactive and not hooked up to build
Re: x11/qt5/qtbase on arm
On Wed, Oct 14, 2020 at 10:06:34AM +0100, Stuart Henderson wrote: > What is the actual port you are trying to build, is it something where > it might be possible to remove qt5 from the chain instead of fixing > qt5 build? ===> poppler-20.09.0 depends on: qttools-* In print/poppler/Makefile you have NOT_FOR_ARCHS-qt5 = arm But there is no condition to this MODULES+= x11/qt5 so qttools is pulled in. But I'm here, lets take a look, qt is popular and it could fix a lot of packages, QtWebkit|QtWebengine could be useful in a machine with more ram... etc. > I am asking because bulk builds on armv7 already take about 40 days - it > is pretty much pointless building snapshot packages on an architecture > with that kind of latency (OpenBSD library ABI is not really stable > so you will be lucky to get packages that work with a given snapshot > unless you save snaps from before each library bump). > > Fixing things to enable qt5 will make this situation even worse. Even if > you don't care about snapshots, this would further delay packages being > available after "base release" of a new OS version. You don't have a way to blacklist ports in the bulk build system? Just for curiosity, what machine are you using to build the armv7 packages? adr.
x11/qt5/qtbase on arm
Hello,
>From other ports I arrived to x11/qt5/qtbase.
The first broken dependency of qtbase is from pulseaudio:
audio/pulseaudio
sysutils/consolekit2
sysutils/polkit
devel/spidermonkey68 *
In Makefile it reads:
=
# Nothing in qtbase links to pulseaudio, but configure checks
# are recorded.
# The atspi is checked at configure time and used via D-Bus.
BUILD_DEPENDS =audio/pulseaudio \
=
This means that qt5 will not support pulse audio if it's not
installed before compilation?
If that is the case, as it is broken for now on arm, it wouldn't
be better to make a port flavor, or remove the dependency for arm
until pulseaudio is fixed?
I don't want to mess with mozilla for now, so I just removed the
pulseaudio dependency.
Now, the problem with qtbase is that clang is not implementing
some neon intrinsics on arm, e.g. vcvt_f16_f32.
I had problems in the past with neon in ports on arm, so I just
disabled all neon support:
===
--- Makefile.orig Tue Oct 13 23:24:26 2020
+++ MakefileTue Oct 13 23:24:13 2020
@@ -116,8 +116,8 @@
# Nothing in qtbase links to pulseaudio, but configure checks
# are recorded.
# The atspi is checked at configure time and used via D-Bus.
-BUILD_DEPENDS =audio/pulseaudio \
- geo/geoclue \
+#BUILD_DEPENDS = audio/pulseaudio \
+BUILD_DEPENDS =geo/geoclue \
x11/gnome/at-spi2-core
RUN_DEPENDS-main = ${RUN_DEPENDS} \
@@ -256,8 +256,19 @@
post-extract:
mkdir -p ${WRKDIST}/mkspecs/openbsd-clang
+# Some FP16 instrinsics aren't available on arm.
+.if ${MACHINE_ARCH} == "arm"
+ grep -v 'load(qt_config)' ${FILESDIR}/clang-qmake.conf \
+ > ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo QMAKE_CFLAGS = -U__ARM_NEON__ -U__ARM_NEON -DPNG_ARM_NEON_OPT=0 \
+ >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo QMAKE_CXXFLAGS = 'QMAKE_CFLAGS' \
+ >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo 'load(qt_config)' >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+.else
cp ${FILESDIR}/clang-qmake.conf \
${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+.endif
cp ${WRKDIST}/mkspecs/openbsd-g++/qplatformdefs.h \
${WRKDIST}/mkspecs/openbsd-clang/
===
I used an orange pi one, so I had to add 2G of swap.
The data size limit has to be increased. I used
ulimit -d 1048576
but maybe just around 600M will be sufficient.
I had to shave twice before it finished, but it compiled.
I will try in the future disabling just FP16 intrinsics with
-U__ARM_FP16_FORMAT_IEEE
Regards,
adr.
Re: nvi problems with '|' in exrc
Or as I said before, make Control-V| input the sequence 0x16|. Escaping with will produce the character, which is CH_LITERAL, 0x16. So the sequence "Control-VControl-V|" in edit mode will produce a valid | for a mapping as typing one in a :map command and saving it with :mkexrc. Looking at the code, just documenting this seems to be the best option. End of my monologue. adr
Re: nvi problems with '|' in exrc
Well, the patch is not correct because the sequence CH_LITERAL| must be used only in a map command. I thought that it would not be a problem when parsing the file, I don't know what I tested that made me think that. This is what you get with dirty hacks. At least a comment in the man page noting that 0x16 must be inserted before a '|' inside a map when writing an exrc file would be of help. Note that this is done when using :mkexrc. Or as I said before, make Control-V| input the sequence 0x16|. In my opinion the way this is implemented is a mess. But all this time no one has complained, so I suppose it's just me. Regards, adr.
Re: nvi problems with '|' in exrc
A quick check confirms that '|' also works as a command separator in exrc, so it's not clear to me if there is an actual bug or if you are fighting against a poorly documented feature. Hi, this is some kind of feature of nvi. You can take a look at the sources. Apart of the traditional command separator, you can use it in some other contexts, making life easiest. The part of the code that make that possible is somewhat, let's say _funny_. For example, you can make a map like this: map =c yEo^[p:.,.! tr -d '\n' | wc -m^M to count the following word, because after the !, vi will treat '|' like part of the shell command. But if you put that in exrc, it will treat the '|' like a command separator. The magic is in common/seq.c, there I saw that when constructing the sequence from input, it inserts before a CH_LITERAL (0x16). Indeed you can use Control-X to insert 0x16 before '|' in exrc, and the map will work. If you mind correctness you have several choices: One is to make the loading of exrc behave like the typed commands (that is what the patch does). another is to add a comment in the man page about inserting 0x16 before '|' in exrc when you don't want to use it like a command separator (I really don't like this option). Well, another solution could be to use Control-V to insert the pair 0x16| when used before |, and document the different behavior when loading a configuration file, or better, make that the common behavior typing commands and loading them. Of course the more sensible aproach to me is just to use another character for command separation, but that would be a big change for this venerable companion... Or maybe I'm just missing something and the best option is just to ignore me. Regards, adr
Re: nvi problems with '|' in exrc
I forgot to update the length of the new string.
$OpenBSD$
Index: ex/ex_source.c
--- ex/ex_source.c.orig
+++ ex/ex_source.c
@@ -38,8 +38,8 @@ int
ex_source(SCR *sp, EXCMD *cmdp)
{
struct stat sb;
- int fd, len;
- char *bp;
+ int fd, len, i;
+ char *bp, c;
char *name, *np;
size_t nlen;
CHAR_T *wp;
@@ -64,8 +64,19 @@ ex_source(SCR *sp, EXCMD *cmdp)
errno = ENOMEM;
goto err;
}
-
- MALLOC(sp, bp, char *, (size_t)sb.st_size + 1);
+ i = 0;
+ for (len = 0; len < sb.st_size; ++len) {
+ if ((rc = read(fd, , 1)) <= 0) {
+ if (rc == 0)
+ errno = EIO;
+ (void)close(fd);
+ goto err;
+ }
+ if (c == '|')
+ ++i;
+ }
+ lseek(fd, 0, SEEK_SET);
+ MALLOC(sp, bp, char *, (size_t)sb.st_size + 1 + i);
if (bp == NULL) {
(void)close(fd);
return (1);
@@ -73,18 +84,28 @@ ex_source(SCR *sp, EXCMD *cmdp)
bp[sb.st_size] = '\0';
/* Read the file into memory. */
- len = read(fd, bp, (int)sb.st_size);
+ np = bp;
+ for (len = 0; len < sb.st_size; ++len, ++np) {
+ if ((rc = read(fd, np, 1)) <= 0) {
+ len = rc;
+ if (len == 0)
+ errno = EIO;
+ break;
+ }
+ if (*np == '|') {
+ *np = CH_LITERAL;
+ *++np = '|';
+ }
+ }
(void)close(fd);
- if (len == -1 || len != sb.st_size) {
- if (len != sb.st_size)
- errno = EIO;
+ if (len != sb.st_size) {
free(bp);
err: msgq_str(sp, M_SYSERR, name, "%s");
return (1);
- }
+ }
np = strdup(name);
- if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1, wp, wlen))
+ if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1 + i, wp, wlen))
msgq(sp, M_ERR, "323|Invalid input. Truncated.");
/* Put it on the ex queue. */
rc = ex_run_str(sp, np, wp, wlen - 1, 1, 0);
nvi problems with '|' in exrc
I found that '|' can't be used in exrc files, unless a 0x16 precedes
it. This is what the code does in seq.c. The problem is in both
editors/nvi and base.
This is a dirty hack if someone is interested. It's for editors/nvi,
but for base would be almost identical.
adr
$OpenBSD$
Index: ex/ex_source.c
--- ex/ex_source.c.orig
+++ ex/ex_source.c
@@ -38,8 +38,8 @@ int
ex_source(SCR *sp, EXCMD *cmdp)
{
struct stat sb;
- int fd, len;
- char *bp;
+ int fd, len, i;
+ char *bp, c;
char *name, *np;
size_t nlen;
CHAR_T *wp;
@@ -64,8 +64,19 @@ ex_source(SCR *sp, EXCMD *cmdp)
errno = ENOMEM;
goto err;
}
-
- MALLOC(sp, bp, char *, (size_t)sb.st_size + 1);
+ i = 0;
+ for (len = 0; len < sb.st_size; ++len){
+ if ((rc = read(fd, , 1)) <= 0) {
+ if (rc == 0)
+ errno = EIO;
+ (void)close(fd);
+ goto err;
+ }
+ if (c == '|')
+ ++i;
+ }
+ lseek(fd, 0, SEEK_SET);
+ MALLOC(sp, bp, char *, (size_t)sb.st_size + 1 + i);
if (bp == NULL) {
(void)close(fd);
return (1);
@@ -73,15 +84,25 @@ ex_source(SCR *sp, EXCMD *cmdp)
bp[sb.st_size] = '\0';
/* Read the file into memory. */
- len = read(fd, bp, (int)sb.st_size);
+ np = bp;
+ for (len = 0; len < sb.st_size; ++len, ++np){
+ if ((rc = read(fd, np, 1)) <= 0) {
+ len = rc;
+ if (len == 0)
+ errno = EIO;
+ break;
+ }
+ if (*np == '|'){
+ *np++ = CH_LITERAL;
+ *np = '|';
+ }
+ }
(void)close(fd);
- if (len == -1 || len != sb.st_size) {
- if (len != sb.st_size)
- errno = EIO;
+ if (len != sb.st_size){
free(bp);
err: msgq_str(sp, M_SYSERR, name, "%s");
return (1);
- }
+ }
np = strdup(name);
if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1, wp, wlen))
Re: x264 on ARM
Pay attention, it's not legacy, there are real actual reasons to do that. Read again thru Theo's mail, carefully. Pay attention, this wasn't a response to Theo's mail. What I get from Theo's email is a detailed description of a cross-platform OS robustness issue, given limited testing resources. Legacy would suggest to me more of a historical burden that could go away if the offending software were removed. Anyways, this particular example seems like it should be simple. Huh??? I really, really don't want to have this conversation, but somehow words of mine appears here out of context. The word legacy doesn't have anything to do with the mail that Theo de Raadt sent. It was a response I sent to Stuart Henderson talking about __this__ thread he sent me: https://marc.info/?t=15193363063=1=2 My impression was that the port was first develped for an architecture before ARMv6, without hardware support for unaligned memory access, that is why I used the word legacy. I know, the mail arrived after that, but sometimes I have to stop composing a mail to do something, then I came back, etc. Now, about "Theo's mail" (good title for a movie, by the way): I understand the advantages of the diverse environment, and I read before about the good it has done to the OpenBSD code, specially sparc. So yes, I understand that you like to have ports with strict alignment memory access. But that has to be made when the architecture demands it. I know that aligned access would be faster, and if you craft code made explicitly with that in mind, and if what the code does, it does it without loosing performance for being restricted in an aligned paradigm, the code will be faster. But you install an OS to run code in it, and even if that code is made taking on account strict alignment, I doubt that the performance, especially with multimedia applications would be better with the jiggle that code would have to do in software to achieve the same it would be done in hardware using unaligned access. And permitting unaligned access doesn't mean that you can't choose when to use it. Do not clang or gcc take on acount that when placing variables for example? Maybe that was the situation before or even with ARMv6, I don't know, but I don't think that is the case for the processors you support in the armv7 port. I mean, even for the stm32f the arm library uses unaligned access for performance reasons. So the only reason I see here is the canary in the coal mine. But you are cutting legs and stapling wings to this poor bastard... That is my opinion. Now let me out of this. Please. adr.
Re: x264 on ARM
Pay attention, it's not legacy, there are real actual reasons to do that. Read again thru Theo's mail, carefully. Pay attention, this wasn't a response to Theo's mail.
Netsurf: get rid of xxd
Hello,
I found a little annoying having to install vim to compile
netsurf. If you like you can try this patch, and maybe make it
less ugly, I'm not a make expert.
By the way, I've compiled netsurf on armv7. It works good.
Regards,
adr
$OpenBSD$
Index: content/handlers/javascript/duktape/Makefile
--- content/handlers/javascript/duktape/Makefile.orig
+++ content/handlers/javascript/duktape/Makefile
@@ -9,11 +9,18 @@ content/handlers/javascript/duktape/dukky.c: $(OBJROOT
BINDINGS := $(wildcard content/handlers/javascript/duktape/*.bnd)
# Generator for the C include representing the generics.js
-$(OBJROOT)/duktape/generics.js.inc:
content/handlers/javascript/duktape/generics.js
+GENERICJS := content/handlers/javascript/duktape/generics.js
+NAME != echo $(GENERICJS) | sed s';[/.];_;g'
+ARRAY != hexdump -v -e '/1 "%d,"' $(GENERICJS)
+LEN != echo $(ARRAY) | awk -F"," '{print NF-1}'
+$(OBJROOT)/duktape/generics.js.inc: $(GENERICJS)
$(Q)$(MKDIR) -p $(OBJROOT)/duktape
$(VQ)echo " XXD: $<"
- $(Q)xxd -i $< $@.tmp
+# $(Q)xxd -i $< $@.tmp
+ $(Q)echo "unsigned char $(NAME)[] = { $(ARRAY) };" > $@.tmp
+ $(Q)echo "unsigned int $(NAME)_len = $(LEN);" >> $@.tmp
$(Q)sed -e
's/content_handlers_javascript_duktape_generics_js/generics_js/' $@.tmp > $@
# ensure genbind generates debugging files
GBFLAGS+=-D
~
Re: x264 on ARM
And disabling asm is unappealing on an arch which needs as much help with speed as it can get. Even worst if you have to play video without hw acc. I thought that the decision of using --no_unaligned_access was a security one, but it seems from the thread that is more like a legacy one. So there is no point to talk to someone to change his/her code to take into account the arm conventions when unalignment access is not permitted, if there is no real reason for doing that. Look, don't get me wrong. I'm not a guy that is been using this OS some days and now he things is a member of the developer core. I didn't want to have this conversation, because I don't have any idea of the things that are being going on. I'm just trying to build my cabin here, without bothering anyone trying to figure out things by myself. The first thing I recommended to the ffmpeg maintainer, I think it was in a private mail, was to talk to some developer of the arm port because I knew that this wasn't an small issue. Regards, adr
Re: x264 on ARM
It's not clear to me that assembly code is the culprit here. No, I bet it is their memory managment functions. I agree with Stuart's statement. It may be terse but I don't find it pedantic. And I agree too, that's why I found it pedantic. Any way, I'm out of place here.
Re: x264 on ARM
Switching a bunch of ports to gcc is not the answer. The answer is to talk with the developers of each of these ports and show them the problems they'll find with llvm, so maybe they re-implement the assembly optimization following the ARM conventions. That was my advice to the ffmpeg and x264 maintainer. Or study each of these ports and rewrite yourself the code, if you like. Meanwhile, the only thing you can do is to disable the assembly if that is possible, or try to compile it with gcc. That was the case of mupdf. If that is for you "Switching a bunch of ports to gcc"... good for you. I'm been using OpenBSD for two weeks or so. I'm just reporting things that I found wrong. If what I receive in response is this kind of pedantic statements, don't worry, I will not report anything more.
Re: x264 on ARM
Please CC the port maintainer, He knows about it already. Can you provide more details? It's good if people can reproduce issues and understand the issue at hand before commiting anything... arm + bus error + assembly this is going to be must all the time access of words or half words unaligned. You are going to have a lot of these problems porting assembly from gas to llvm, specially with old code. Regards, adr.
Re: CVS: cvs.openbsd.org: ports
echo unsigned int $name_len = $len ;
upps!, just in case: ${name}_len
Re: CVS: cvs.openbsd.org: ports
Just a suggestion, you can use something like this
name=$(echo $1 | sed s';[/.];_;g')
array=$(hexdump -v -e '/1 "%d,"' $1)
len=$(echo $array | awk -F"," '{print NF-1}')
#len=$(echo $array | sed s'/[^,]//g' | wc -L)
echo unsigned char $name[] = {\
$array };
echo unsigned int $name_len = $len ;
hexdump is in base.
Regards,
adr.
On Sun, 11 Aug 2019, Anthony J. Bentley wrote:
Date: Sun, 11 Aug 2019 09:16:22 -0600 (MDT)
From: Anthony J. Bentley
To: ports-changes@openbsd.org
Subject: CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: bent...@cvs.openbsd.org 2019/08/11 09:16:22
Modified files:
www/netsurf/netsurf-fb: Makefile
www/netsurf/browser: Makefile
Log message:
Missing build dependency on vim (for xxd).
Noticed by naddy@
x264 on ARM
Hello,
multimedia/x264 assembly will generate bus errors.
Tested with ffmpeg.
Regards,
adr.
RCS file: /cvs/ports/multimedia/x264/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile22 Jul 2019 06:56:33 - 1.51
+++ Makefile9 Aug 2019 17:21:46 -
@@ -40,7 +40,7 @@ CONFIGURE_ARGS+=--prefix=${PREFIX} \
--disable-lavf \
--disable-swscale
-.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc"
+.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} ==
"arm"
CONFIGURE_ARGS+=--disable-asm
.endif
Re: mupdf on arm
In the attachment are the bt, the disas sembly of the function of interest
until the bus error, and the state of the registers. I'm completely new to
llvm, and I'm trying to build my cabin here, so I can't be of any help
(I'm not familiar with the restrictions you are imposing here), altough I
bet the problem is in their memory management: source/fitz/memory.c.
Good luck!
adr.
$ mupdf somefile.pdf
Bus error (core dumped)
$ gdb mupdf mupdf-x11.core
[...]
(gdb) bt
#0 0x07e332dc in fz_paint_glyph () from /usr/local/bin/mupdf
#1 0x in ?? ()
(gdb) disassemble
Dump of assembler code for function fz_paint_glyph:
0x07e31a44 : stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11,
lr}
0x07e31a48 : add r11, sp, #28; 0x1c
0x07e31a4c : sub sp, sp, #4 ; 0x4
0x07e31a50 : fstmdbd sp!, {d8-d15}
0x07e31a54 : sub sp, sp, #264; 0x108
0x07e31a58 : undefined
0x07e31a5c : str r3, [sp, #244]
0x07e31a60 : str r2, [sp, #256]
0x07e31a64 : ldr r3, [r1, #44]
0x07e31a68 : ldr r4, [r11, #20]
0x07e31a6c : ldr r2, [r11, #12]
0x07e31a70 : cmp r3, #0 ; 0x0
0x07e31a74 : beq 0x7e31f2c
0x07e31a78 : ldrbr6, [r1, #24]
0x07e31a7c : ldrblr, [r1, #26]
0x07e31a80 : str r0, [sp, #260]
0x07e31a84 : sub r8, r6, lr
0x07e31a88 : ldrbr7, [r0, r8]
0x07e31a8c : cmp r7, #0 ; 0x0
0x07e31a90 : beq 0x7e32288
0x07e31a94 : ldr r10, [r11, #24]
0x07e31a98 : mov r5, r2
0x07e31a9c : mov r2, r4
0x07e31aa0 : cmp r7, #255; 0xff
0x07e31aa4 : bne 0x7e32298
0x07e31aa8 :cmp r10, #0 ; 0x0
0x07e31aac :ldr r0, [r1, #28]
0x07e31ab0 :ldrne r1, [r10]
0x07e31ab4 :str r0, [sp, #220]
0x07e31ab8 :cmpne r1, #0 ; 0x0
0x07e31abc :bne 0x7e328a0
0x07e31ac0 :cmp r8, #4 ; 0x4
0x07e31ac4 :beq 0x7e32f4c
0x07e31ac8 :cmp r8, #3 ; 0x3
0x07e31acc :beq 0x7e332bc
0x07e31ad0 :cmp r8, #1 ; 0x1
0x07e31ad4 :bne 0x7e338f0
0x07e31ad8 :cmp lr, #0 ; 0x0
0x07e31adc :beq 0x7e35540
0x07e31ae0 :cmp r5, #0 ; 0x0
0x07e31ae4 :beq 0x7e32288
0x07e31ae8 :ldr r0, [sp, #260]
0x07e31aec :bicnv r2, r7, #95 ; 0x5f
0x07e31af0 :mov r9, #1 ; 0x1
0x07e31af4 :ldrhr8, [r0]
0x07e31af8 :ldr r0, [sp, #244]
0x07e31afc :add lr, r0, #32 ; 0x20
0x07e31b00 :mcr 11, 5, r8, cr0, cr0, {5}
0x07e31b04 :str lr, [sp, #224]
0x07e31b08 :ldr r0, [lr, r2, lsl #2]
0x07e31b0c :sub r5, r5, #1 ; 0x1
0x07e31b10 :str r2, [sp, #248]
0x07e31b14 :str r5, [sp, #252]
0x07e31b18 :cmp r0, #0 ; 0x0
0x07e31b1c :blt 0x7e31be8
0x07e31b20 :ldr r1, [sp, #244]
0x07e31b24 :ldr r2, [r11, #16]
0x07e31b28 :add r0, r1, r0
0x07e31b2c :ldr r4, [sp, #256]
0x07e31b30 :add r7, r0, #32 ; 0x20
0x07e31b34 :mov r1, #0 ; 0x0
0x07e31b38 :cmp r2, #0 ; 0x0
0x07e31b3c :beq 0x7e31bf0
0x07e31b40 :ldr r5, [sp, #260]
0x07e31b44 :mov r1, #0 ; 0x0
0x07e31b48 :ldrbr6, [r7], #1
0x07e31b4c :and r0, r6, #3 ; 0x3
0x07e31b50 :cmp r0, #2 ; 0x2
0x07e31b54 :beq 0x7e31b7c
0x07e31b58 :cmp r0, #1 ; 0x1
0x07e31b5c :beq 0x7e31b94
0x07e31b60 :cmp r0, #0 ; 0x0
0x07e31b64 :bne 0x7e31bac
0x07e31b68 :mov r1, r6, lsr #2
0x07e31b6c :mov r3, #0 ; 0x0
0x07e31b70 :subsr2, r2, r3
0x07e31b74 :bne 0x7e31b48
0x07e31b78 :b 0x7e31bd8
0x07e31b7c :orr r0, r9, r1, lsl #5
0x07e31b80 :and r12, r6, #4 ; 0x4
0x07e31b84 :add r3, r0, r6, lsr #3
0x07e31b88 :cmp r3, r2
0x07e31b8c :ble 0x7e31bc4
0x07e31b90 :b 0x7e31c0c
0x07e31b94 :orr r0, r9, r1, lsl #6
0x07e31b98 :mov r1, #0 ; 0x0
0x07e31b9c :add r3, r0, r6, lsr #2
0x07e31ba0 :cmp r3, r2
0x07e31ba4 :ble 0x7e31bd0
0x07e31ba8 :b 0x7e31c1c
0x07e31bac :orr r0, r9, r1, lsl #5
0x07e31bb0 :and r12, r6, #4 ; 0x4
0x07e31bb4 :add r3, r0, r6, lsr #3
0x07e31bb8 :cmp r3, r2
0x07e31bbc :bgt 0x7e31c30
0x07e31bc0 :add r7, r7, r3
0x07e31bc4 :mov r1, #0 ; 0x0
0x07e31bc8 :cmp r12, #0 ; 0x0
0x07e31bcc :bne 0x7e31c00
0x07e31bd0 :subsr2, r2, r3
0x07e31bd4 :bne 0x7e31b48
0x07e31bd8 :mov r12, #0 ; 0x0
0x07e31bdc :mov r6, r4
0x07e31be0 :ldr r10, [r11, #8]
0x07e31be4 :b 0x7e31c40
0x07e31be8 :ldr r4, [sp, #256]
0x07e31bec :b 0x7e31f08
Re: mupdf on arm
On Wed, 31 Jul 2019, Stuart Henderson wrote: conflict between C++ standard libraries) so it would be good to have some more details about what's happening. Could you send a backtrace please? Sure, I'll do it when I have time. I'm pretty sure it is about accessing memory unaligned. I'm having problems making my own assembly work in llvm|OpenBSD. Regards, adr.
Re: mupdf on arm
I've tested 1.16.0. You still need to compile it with gcc. adr.
Re: ffmpeg on arm
I've compiled ffmpeg with ports-gcc, and all is working as expected. The performance is much better than disabling neon with llvm. I strongly recommend you to change the port to use gcc on this arch. Regards, adr.
Re: mupdf on arm
On Tue, 30 Jul 2019, Stuart Henderson wrote: Date: Tue, 30 Jul 2019 14:18:36 +0100 From: Stuart Henderson To: adr Cc: ports@openbsd.org Subject: Re: mupdf on arm On 2019/07/30 14:00, Stuart Henderson wrote: On 2019/07/30 11:03, adr wrote: Mupdf needs to be compiled with gcc on armv7. With llvm it will fail with a bus error. I think the problem is in the memory management functions. I'm not attaching patches because I'm not familiar with the ports system. I added COMPILER= ports-gcc; estdc++ to WANTILB; lang/gcc/8,-libs>=8,<9 to LIB_DEPENDS and make plist. adr. Are things any different with 1.16.0rc2? https://junkpile.org/mupdf-1.16.0rc2.diff Or if you are on 6.5, https://junkpile.org/mupdf-1.16.0rc2.stable.diff Actually I see 1.16.0 is released now, I'll commit it to -current, if you want to try it on 6.5 just update the V line in the port Makefile after patching and run "make makesum" before building to test. I'll try it when it arrives (and I get time). I'm on current. Regards, adr.
mupdf on arm
Mupdf needs to be compiled with gcc on armv7. With llvm it will fail with a bus error. I think the problem is in the memory management functions. I'm not attaching patches because I'm not familiar with the ports system. I added COMPILER= ports-gcc; estdc++ to WANTILB; lang/gcc/8,-libs>=8,<9 to LIB_DEPENDS and make plist. adr.
ffmpeg on arm
First of all, hello to everyone. ffmpeg needs to be configured with --disable-fast-unaligned and --disable-neon, or it will fail (and any application using libav) with a bus error. Also, I had to eliminate all the check-clean-src target from the Makefile (the one of the source) of python (2.7 and 3.7) to be able to compile it. Tested in 6.5 and current, on armv7 (allwinner h3). I've been using openbsd just for a few days, so I'll let someone with more (any) experience to fixed it in the best way. adr.
