Sadeep wrote:
Hi David,
On 2026-09-28 12:15:00, David Uhden Collado wrote:
David Uhden Collado wrote:
Sadeep wrote:
Having display issues with fvwm (v2.2.5, the one in the base
system). On a 32" external monitor, it only uses the top half of
the screen. I have a 3x3 fvvwm desktop. On start-up, only the 1st
quadrant is used...
[...]
Could you tell me if this solves the problem?
https://github.com/daviduhden/wip-openbsd-src/commit/db20a58945c8aa2578562d478fc47e14f9a3a429
Replying offlist to reduce noise.
Does this build on OpenBSD 7.9 stable:
fvwm.c:155:6: error: use of undeclared identifier 'getexecpath'
155 | if (getexecpath(execpath, sizeof(execpath)) == -1)
| ^
1 error generated.
*** Error 1 in fvwm (<sys.mk>:87 'fvwm.o')
It's unlikely that I'd use a patched version of fvwm. One of main
reasons I chose fvwm is it's the default. Happy to test your patch,
however--as long as I can build it on OpenBSD 7.9 stable.
Hello Sadeep,
That error is because getexecpath(2) is a system call that was added
recently to OpenBSD. I decided to use it in my changes, so that part
currently targets OpenBSD 8.0, which is due to be released soon. It will
not build as-is on 7.9-stable.
The version of fvwm in the base system is not being actively maintained.
What I did in my fork was improve its memory handling to make it safer,
make fairly extensive use of OpenBSD's security features, and fix the
bugs that were already documented. I also rewrote the components that
were still under the GPL, but that's secondary; it's just to bring this
software into compliance with copyright policy, which stopping updates
didn't resolve.
I have not looked at the rest of the Xenocara applications, and I do not
want to. I did this mostly because I saw something that was wrong,
became obsessed with fixing it, and now I do not want to keep going and
fall into the kind of obsessive loop that is typical with OCD.
Otherwise, I would probably end up with a fork of every piece of
third-party software I run on OpenBSD, which, frankly, I am often
tempted to do and think is how it should be handled. The project
shouldn't spend time and energy compiling garbage that is not properly
maintained and properly integrated into the system.
