the DEC-XTRAP extension is deprecated since 1994, so modern X servers do
not support it
the library was removed from pkgsrc last year and is not required by
anything not-sample-client related in src
if you try to query the protocol on netbsd, you get the following:
$ xtrapproto
Display: :0.0
Warning: Can't load DEC-XTRAP extension
xtrapproto: could not initialize extension
- move from sys/arch/x86/x86/{vmt.c,vmtreg.h,vmtvar.h} to sys/dev/vmt/{vmt_subr.c,vmtreg.h,vmtvar.h},
and split the attach part of the cpufeaturebus and fdt
- add aarch64 vmware backdoor op
- add include guard to vmt{reg,var}.h
- Yet there is still some little-endian dependency. it needs to be fixed in order to work properly on aarch64eb
The GL Utility Library was formerly a core part of most OpenGL
distributions.
Originally, this version of libglut was developed as part of Mesa (the
primary OpenGL implementation used in NetBSD) before it was mostly abandoned
and work moved to the freeglut fork. It provides a platform-neutral way of
creating OpenGL contexts, something that many other libraries can also do
today (e.g. SDL, glfw).
All users in pkgsrc have been switched to the freeglut fork and there are no
remaining users of this library in src. If having a GLUT implementation in
base turns out to be particularly useful outside of compatibility with
previous NetBSD versions, we can import freeglut (which, AFAIK, is also
ABI compatible with MesaGLUT).
The code in suff.c is already hard to understand, and so were the tests
in suffixes.mk since several independent topics were merged into a
single test.
Splitting this test into a separate test per issue allows to document
the expected and actual behavior in more detail. That's complicated
enough already.
PR bin/49086
Based on a shell script which gets the DPI from the X server, and if this
fails, attempts to guess based on resolution. Taking advantage of M4 macros
in the ctwmrc, we can also scale the workspace manager and window list.
The following sizes are supported: 6x12 (<800x600) 8x16 12x24 (4k and higher)
16x32 32x64
Also makes Spleen the default font in ctwm
The vether interface simulates a normal Ethernet interface by encapsulating
standard network frames with an Ethernet header, specifically for use as
a member in a bridge(4).
To use vether the administrator needs to configure an address onto the
interface so that packets can be routed to it. An Ethernet header will
be prepended and, if the vether interface is a member of a bridge(4),
the frame will show up there.
Taken from OpenBSD.
When there is a dependency group at the end of a top-level makefile,
this dependency group is not finished properly. This allows to add
further commands to the targets of this dependency group, which was not
intended.
