Re: Term::Cap full revamp
() {
> - next if /^\\t/ || /^#/;
> - if ($_ =~ m/(^|\\|)${termpat}[:|]/o) {
> +my $TERMCAP;
> +while ($state != 0) {
> +if ($state == 1) {
> +# get the next TERMCAP or get ready for infocmp
> +$TERMCAP = shift @termcap_path or $state = 3;
> +} elsif ($state == 3) {
> + croak "failed termcap lookup on $tmp_term";
> + } else {
> +# do the same file again
> +# prevent endless recursion
> +$state = 1;# ok, maybe do a new file next time
> +}
> +
> + my ($fh, $child);
> + if ($state == 3) {
> + my $child = open($fh, "-|");
> + # TODO this breaks on !UNIX
> + # not do anything, or let it break here
> + croak "cannot fork: $!" if !defined $child;
> + if (!$child) {
> + open(STDERR, ">", "/dev/null");
> + system('infocmp', '-CTr', $tmp_term);
> + exit(1);
> + }
> + } else {
> + open($fh, "<", $TERMCAP ) || croak "open $TERMCAP: $!";
> + }
> + undef $_;
> + while (<$fh>) {
> + next if /^\t/ || /^#/;
> + if (m/(^|\|)\Q$tmp_term\E[:|]/) {
> chomp;
> s/^[^:]*:// if $first++;
> $state = 0;
> - while ($_ =~ s/$//) {
> - defined(my $x = ) or last;
> + $seen->{$tmp_term} = 1;
> + while (s/\\$//) {
> + defined(my $x = <$fh>) or last;
> $_ .= $x; chomp;
> }
> + if (defined $entry) {
> + $entry .= $_;
> + } else {
> + $entry = $_;
> + }
> last;
> }
> }
> - defined $entry or $entry = '';
> - $entry .= $_ if $_;
> -};
> -
> -while ( $state != 0 )
> -{
> -if ( $state == 1 )
> -{
> -
> -# get the next TERMCAP
> -$TERMCAP = shift @termcap_path
> - || croak "failed termcap lookup on $tmp_term";
> -}
> -else
> -{
> -
> -# do the same file again
> -# prevent endless recursion
> -$max-- || croak "failed termcap loop at $tmp_term";
> -$state = 1;# ok, maybe do a new file next time
> -}
> -
> -open( TERMCAP, "< $TERMCAP\0" ) || croak "open $TERMCAP: $!";
> -eval $search;
> -die $@ if $@;
> -close TERMCAP;
> +close($fh);
> + waitpid($child, 0) if defined $child;
> + next if !defined $entry;
>
> # If :tc=...: found then search this file again
> -$entry =~ s/:tc=([^:]+):/:/ && ( $tmp_term = $1, $state = 2 );
> -
> -# protect any pattern metacharacters in $tmp_term
> -$termpat = $tmp_term;
> -$termpat =~ s/(\W)/\\$1/g;
> +while ($entry =~ s/:tc=([^:]+):/:/) {
> + $tmp_term = $1;
> + if ($seen->{$tmp_term}) {
> + next;
> + }
> + $state = 2;
> + last;
> + }
> }
>
> -croak "Can't find $term" if $entry eq '';
> +if (!defined $entry) {
> + if ($self->{TERM} eq 'dumb') {
> + $entry = 'dumb|80-column dumb
> tty::am::co#80::bl=^G:cr=^M:do=^J:sf=^J:';
> + }
> +}
> +croak "Can't find $term" if !defined $entry;
> $entry =~ s/:+\s*:+/:/g;# cleanup $entry
> $entry =~ s/:+/:/g; # cleanup $entry
> $self->{TERMCAP} = $entry; # save it
>
--
Matthieu Herrb
Re: Use after free in X config parser
On Sun, Oct 08, 2023 at 02:50:10PM -0300, Crystal Kolipe wrote:
> Hi,
>
> On Sun, Oct 08, 2023 at 07:07:27PM +0200, Matthieu Herrb wrote:
> > I can confirm that there's an issue here. However in my tests, I don't
> > see a garbled error message.
> > If I set MALLOC_OPTIONS=F then a double free is reported, which I
> > tracked down to the realloc() calls in getNextLine() that will make
> > the xf68_lex_val.str pointer point to already free()d memory.
> >
> > So the following patch, which invalidates this pointer before reading
> > more data from the config file fixes the issue I'm seeing. Can you
> > confirm that it also fixes it for you ?
>
> Unfortunately it doesn't :-).
>
> Or rather, yes and no... Your patch does fix most cases, but I'm
> still able to read free'd memory with a specially crafted config
> file that contains bare 0x0d bytes as line separators instead of 0x0a.
>
Ok, after some more attempts, I have to agree that copying the token
like you proposed originally is the only way to completely fix the
issue.
Here's a patch that also free()s the copy after it's been consumed, to
avoid the (minor) leaks.
Also submitted upstreams:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1176
Comments, ok?
Index: hw/xfree86/parser/DRI.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/DRI.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 DRI.c
--- hw/xfree86/parser/DRI.c 8 Dec 2017 15:02:01 - 1.8
+++ hw/xfree86/parser/DRI.c 9 Oct 2023 05:56:22 -
@@ -77,6 +77,8 @@ xf86parseDRISection(void)
break;
case COMMENT:
ptr->dri_comment = xf86addComment(ptr->dri_comment,
xf86_lex_val.str);
+free(xf86_lex_val.str);
+xf86_lex_val.str = NULL;
break;
default:
Error(INVALID_KEYWORD_MSG, xf86tokenString());
Index: hw/xfree86/parser/Device.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/Device.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 Device.c
--- hw/xfree86/parser/Device.c 27 Jul 2019 07:57:18 - 1.10
+++ hw/xfree86/parser/Device.c 9 Oct 2023 05:56:22 -
@@ -106,6 +106,8 @@ xf86parseDeviceSection(void)
switch (token) {
case COMMENT:
ptr->dev_comment = xf86addComment(ptr->dev_comment,
xf86_lex_val.str);
+free(xf86_lex_val.str);
+xf86_lex_val.str = NULL;
break;
case IDENTIFIER:
if (xf86getSubToken(&(ptr->dev_comment)) != STRING)
Index: hw/xfree86/parser/Extensions.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/Extensions.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 Extensions.c
--- hw/xfree86/parser/Extensions.c 8 Dec 2017 15:02:01 - 1.5
+++ hw/xfree86/parser/Extensions.c 9 Oct 2023 05:56:22 -
@@ -67,6 +67,8 @@ xf86parseExtensionsSection(void)
case COMMENT:
ptr->extensions_comment =
xf86addComment(ptr->extensions_comment, xf86_lex_val.str);
+free(xf86_lex_val.str);
+xf86_lex_val.str = NULL;
break;
default:
Error(INVALID_KEYWORD_MSG, xf86tokenString());
Index: hw/xfree86/parser/Files.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/Files.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 Files.c
--- hw/xfree86/parser/Files.c 8 Dec 2017 15:02:01 - 1.9
+++ hw/xfree86/parser/Files.c 9 Oct 2023 05:56:22 -
@@ -89,6 +89,8 @@ xf86parseFilesSection(void)
switch (token) {
case COMMENT:
ptr->file_comment = xf86addComment(ptr->file_comment,
xf86_lex_val.str);
+free(xf86_lex_val.str);
+xf86_lex_val.str = NULL;
break;
case FONTPATH:
if (xf86getSubToken(&(ptr->file_comment)) != STRING)
Index: hw/xfree86/parser/Flags.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/Flags.c,v
retrieving revision 1.11
diff -u -p -u -r1.11 Flags.c
--- hw/xfree86/parser/Flags.c 11 Nov 2021 09:03:09 - 1.11
+++ hw/xfree86/parser/Flags.c 9 Oct 2023 05:56:22 -
@@ -98,6 +98,8 @@ xf86parseFlagsSection(void)
switch (token) {
case COMMENT:
ptr->flg_comment = xf86addComment(ptr->flg_comment,
xf86_lex_val.str);
+free(xf86_lex_val.str);
+xf86_lex_val.str = NULL;
break;
/*
* these old keywords are turned into standard generic options.
@@ -436,17 +438,21 @@ xf86parseOpt
Re: Use after free in X config parser
On Thu, Oct 05, 2023 at 08:11:39PM -0300, Crystal Kolipe wrote:
> This is an interesting one...
>
> There is a use after free bug in the X config parser, which can be trivially
> demonstrated by creating a config file with the first line being a comment and
> the second line containing invalid syntax:
>
> $ echo "#foo\nfoo" > custom_config
> $ X -config custom_config
>
> [...]
>
> (++) Using config file: "custom_config"
> (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
> Parse error on line 3 of section InputClass in file custom_config
> "on" is not a valid keyword in this section.
> (EE)
> Fatal server error:
> (EE) no screens found(EE)
>
> [...]
>
> So part of the error message is reading 0xdf bytes, which are obviously from a
> buffer which has been free'd.
Hi,
I can confirm that there's an issue here. However in my tests, I don't
see a garbled error message.
If I set MALLOC_OPTIONS=F then a double free is reported, which I
tracked down to the realloc() calls in getNextLine() that will make
the xf68_lex_val.str pointer point to already free()d memory.
So the following patch, which invalidates this pointer before reading
more data from the config file fixes the issue I'm seeing. Can you
confirm that it also fixes it for you ?
Index: hw/xfree86/parser/scan.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/parser/scan.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 scan.c
--- hw/xfree86/parser/scan.c27 Jul 2019 07:57:18 - 1.12
+++ hw/xfree86/parser/scan.c8 Oct 2023 17:03:21 -
@@ -278,9 +278,11 @@ xf86getToken(const xf86ConfigSymTabRec *
if (!c) {
char *ret;
-if (numFiles > 0)
+if (numFiles > 0) {
+/* invalidate lex token */
+xf86_lex_val.str = NULL;
ret = xf86getNextLine();
-else {
+} else {
if (builtinConfig[builtinIndex] == NULL)
ret = NULL;
else {
--
Matthieu Herrb
Re: malloc write after free error checking
On Wed, Sep 20, 2023 at 08:08:23AM +0200, Otto Moerbeek wrote:
>
> The other, a write after free that crashed the X server when running
> picard was diagnosed by me. This one was a bit nasty, as it required
> instrumenting malloc to print some extra info to find the root cause.
>
> The bug is that the call in
> https://github.com/openbsd/xenocara/blob/master/xserver/Xext/xvdisp.c#L1002
> overwrites the first 4 bytes of the chunk next to the one allocated on
> line 995.
>
> A workaround is to allocate 4 bytes extra, matthieu@ will be looking
> for a proper fix, as it requires knowledge of the X internals.
>
Hi,
Thanks again for finding it. Can you try this patch ?
===
Fix overflow in glamor_xv_query_image_attributes for NV12 image format
This is a format with num_planes == 2, we have only 2 elements in
offsets[] and pitches[]
Bug found by Otto Moerbeek on OpenBSD using his strict malloc checking.
---
glamor/glamor_xv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index a3d6b3bc3..e0e8e0ba9 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -291,10 +291,10 @@ glamor_xv_query_image_attributes(int id,
pitches[0] = size;
size *= *h;
if (offsets)
-offsets[1] = offsets[2] = size;
+offsets[1] = size;
tmp = ALIGN(*w, 4);
if (pitches)
-pitches[1] = pitches[2] = tmp;
+pitches[1] = tmp;
tmp *= (*h >> 1);
size += tmp;
break;
---
2.42.0
--
Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 11:58:03PM +0200, Mark Kettenis wrote: > > Date: Thu, 7 Sep 2023 22:02:12 +0200 > > From: Matthieu Herrb > > > > basically just define the CARDnn types in terms on uint_nn everywhere. > > Like for signal.h all systems still supported by X have stdint and the > > uintnn_t types. > > The problem with this is that you're changing the type of CARD32 and > CARD64. Which means that if these types are used in C++ code, the > mangling changes, and therefore you risk breaking the ABI. And I bet > you there is C++ code that uses the CARD32 and CARD64 types. > > How did the commit break the tree? The actual error messages were > never mailed out as far as I can tell. > > I think you should simply revert to the pre-hackathon state. Done. Indeed this needs more thinking. I've reverted those commits. Here are the errors with llvm 16 on the tree before p2k23 (and -current) in xserver/glamor_egl: libtool: compile: /usr/local/bin/clang-16 -DHAVE_CONFIG_H -I. -I/local/OpenBSD/xenocara/xserver/hw/xfree86/glamor_egl -I../../../include -I/local/OpenBSD/xenocara/xserver/hw/xfree86 -I/local/OpenBSD/xenocara/xserver/hw/xfree86/include -I/local/OpenBSD/xenocara/xserver/hw/xfree86/common -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bus -I/local/OpenBSD/xenocara/xserver/os -I/local/OpenBSD/xenocara/xserver/dri3 -I/local/OpenBSD/xenocara/xserver/glamor -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing -I/usr/X11R6/include -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/X11R6/include/X11/dri -I/usr/X11R6/include/libdrm -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include/freetype2 -I/local/OpenBSD/xenocara/xserver/include -I../../../include -I/local/OpenBSD/xenocara/xserver/Xext -I/local/OpenBSD/xenocara/xserver/composite -I/local/OpenBSD/xenocara/xserver/damageext -I/local/OpenBSD/xenocara/xserver/xfixes -I/local/OpenBSD/xenocara/xserver/Xi -I/local/OpenBSD/xenocara/xserver/mi -I/local/OpenBSD/xenocara/xserver/miext/sync -I/local/OpenBSD/xenocara/xserver/miext/shadow -I/local/OpenBSD/xenocara/xserver/miext/damage -I/local/OpenBSD/xenocara/xserver/render -I/local/OpenBSD/xenocara/xserver/randr -I/local/OpenBSD/xenocara/xserver/fb -I/local/OpenBSD/xenocara/xserver/dbe -I/local/OpenBSD/xenocara/xserver/present -fvisibility=hidden -I/usr/X11R6/include -DHAVE_XORG_CONFIG_H -fvisibility=hidden -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/libdrm -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include/libdrm -I/usr/X11R6/include -O2 -pipe -pthread -c /local/OpenBSD/xenocara/xserver/glamor/glamor_egl.c -fPIC -DPIC -o .libs/glamor_egl.o /local/OpenBSD/xenocara/xserver/glamor/glamor_egl.c:849:24: error: incompatible function pointer types initializing 'dri3_pixmap_from_fds_proc' (aka 'struct _Pixmap *(*)(struct _Screen *, unsigned char, const int *, unsigned short, unsigned short, const unsigned int *, const unsigned int *, unsigned char, unsigned char, unsigned long)') with an expression of type 'PixmapPtr (ScreenPtr, CARD8, const int *, CARD16, CARD16, const CARD32 *, const CARD32 *, CARD8, CARD8, uint64_t)' (aka 'struct _Pixmap *(struct _Screen *, unsigned char, const int *, unsigned short, unsigned short, const unsigned int *, const unsigned int *, unsigned char, unsigned char, unsigned long long)') [-Wincompatible-function-pointer-types] .pixmap_from_fds = glamor_pixmap_from_fds, ^~ 1 error generated. *** Error 1 in xserver/obj/hw/xfree86/glamor_egl (Makefile:635 'glamor_egl.lo') in xserver/hw/xfree86/drivers/modesetting: source='/local/OpenBSD/xenocara/xserver/hw/xfree86/drivers/modesetting/dri2.c' object='dri2.lo' libtool=yes DEPDIR=.deps depmode=none /bin/sh /local/OpenBSD/xenocara/xserver/depcomp /bin/sh ../../../../libtool --tag=CC --mode=compile /usr/local/bin/clang-16 -DHAVE_CONFIG_H -I. -I/local/OpenBSD/xenocara/xserver/hw/xfree86/drivers/modesetting -I../../../../include -I/local/OpenBSD/xenocara/xserver/hw/xfree86 -I/local/OpenBSD/xenocara/xserver/hw/xfree86/include -I/local/OpenBSD/xenocara/xserver/hw/xfree86/common -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support -I/local/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bus -I/local/OpenBSD/xenoca
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > CVSROOT: /cvs
> > > Module name: xenocara
> > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > >
> > > Modified files:
> > > driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h
> > > xserver/glamor : glamor.h glamor_egl.c
> > >
> > > Log message:
> > > unbreak build with clang-16 by fixing up function definitions to match
> > >
> > > our uint64_t is an unsinged long long, but CARD64 is defined as unsigned
> > > long
> > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > mismatched and clang-16 treats that as an error
> > >
> > > ok matthieu@
> >
> > This broke the tree. Here's a potential fix.
>
> Hmm no, this one reverts parts of the llvm 16 diffs.
>
> What about this that gets rid of CARD64 completely in this context ?
>
> hint for the X developpers: CARD64 and friends are normally reserved
> for the X protocol specification and implementation
>
> All other uses as cheap substites for uint64_t or similar are just
> historical artefacts from an era where there was no standard integer
> types with known fixed lengths.
This is still not enough.
I've deciced to cure the problem at its root.
Whith this patch, the tree builds with both base llvm and llvm 16 on
amd64. I've started a build i386 to double check 32 bit arches.
And it will allow to revert some other patches to reduce the number of
local changes. I also think that it has some chances to be accepted
upstreams.
basically just define the CARDnn types in terms on uint_nn everywhere.
Like for signal.h all systems still supported by X have stdint and the
uintnn_t types.
Index: proto/xorgproto/include/X11/Xmd.h
===
RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
retrieving revision 1.2
diff -u -p -u -r1.2 Xmd.h
--- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
+++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
@@ -57,6 +57,8 @@ SOFTWARE.
# include /* Solaris: defines _LP64 if necessary */
# endif
+#include
+
#if defined(__SIZEOF_LONG__)
# if __SIZEOF_LONG__ == 8
# define LONG64 /* 32/64-bit architecture */
@@ -107,15 +109,10 @@ typedef short INT16;
typedef signed charINT8;
-# ifdef LONG64
-typedef unsigned long CARD64;
-typedef unsigned int CARD32;
-# else
-typedef unsigned long long CARD64;
-typedef unsigned long CARD32;
-# endif
-typedef unsigned short CARD16;
-typedef unsigned char CARD8;
+typedef uint64_t CARD64;
+typedef uint32_t CARD32;
+typedef uint16_t CARD16;
+typedef uint8_t CARD8;
typedef CARD32 BITS32;
typedef CARD16 BITS16;
>
> Index: src/drmmode_display.c
> ===
> RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> retrieving revision 1.4
> diff -u -p -u -r1.4 drmmode_display.c
> --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> * version and DRM kernel module configuration, the vblank
> * timestamp can either be in real time or monotonic time
> */
> -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> {
> uint64_t cap_value;
> int ret;
> @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> ret = clock_gettime(CLOCK_MONOTONIC, );
> if (ret)
> return ret;
> - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> 1000);
> return 0;
> }
>
> /*
> * Get current frame count and frame count timestamp of the crtc.
> */
> -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc)
> {
> ScrnInfoPtr scrn = crtc->scrn;
> uint32_t seq;
> @@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> ScrnInfoPtr scrn = crtc->scrn;
> AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
> - CARD64 ust;
> + uint64_t ust;
> int ret;
>
> if (drmmode_crtc->d
Re: Diff for evaluation (WACOM tablet driver)
HCOLL_PHYSICAL))) {
> + DPRINTF("found tablet keys collection\n");
> + pad_buttons_hid_parser(ms, tablet_keys_col, );
> + }
> + if ((battery_col = hid_get_collection_data(desc, dlen,
> + HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_WACOM_BATTERY),
> + HCOLL_PHYSICAL))) {
> + DPRINTF("found battery collection\n");
> + /* parse and set the battery info */
> + /* not yet used */
> + hid_end_parse(battery_col);
> + }
> + /*
> + * Ignore the device config, it's not really needed
> + * Ignore the usage 0x10AC which is the debug collection, and
> + * ignore firmware collection and other collections for now
> + */
> + }
> +
> + /* Map the pad and stylus buttons to mouse buttons */
> + for (i = 0; i < ms->sc_num_stylus_buttons; i++)
> + memcpy(&(ms->sc_loc_btn[i]), &(ms->sc_loc_stylus_btn[i]),
> + sizeof(struct hid_location));
> + for (; i < ms->sc_num_pad_buttons + ms->sc_num_stylus_buttons; i++)
> + memcpy(&(ms->sc_loc_btn[i]), &(ms->sc_loc_pad_btn[i]),
> + sizeof(struct hid_location));
> + ms->sc_num_buttons = i;
> + DPRINTF("Buttons inf\n");
> +#ifdef HIDMS_DEBUG
> + for (i = 0; i < ms->sc_num_buttons; i++)
> + printf("size: 0x%x, pos: 0x%x, count: 0x%x\n",
> + ms->sc_loc_btn[i].size, ms->sc_loc_btn[i].pos,
> + ms->sc_loc_btn[i].count);
> +#endif
> + return 0;
> +}
> +
> +
> int
> hidms_setup(struct device *self, struct hidms *ms, uint32_t quirks,
> int id, void *desc, int dlen)
> @@ -74,6 +278,10 @@ hidms_setup(struct device *self, struct
> ms->sc_rawmode = 1;
>
> ms->sc_flags = quirks;
> +
> + /* We are setting up a WACOM tablet, not a mouse */
> + if (quirks == HIDMS_WACOM_SETUP)
> + return hidms_wacom_setup(self, ms, quirks, id, desc, dlen);
>
> if (!hid_locate(desc, dlen, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_X), id,
> hid_input, >sc_loc_x, ))
> Index: dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.769
> diff -u -p -r1.769 usbdevs.h
> --- dev/usb/usbdevs.h 12 Jun 2023 11:26:54 - 1.769
> +++ dev/usb/usbdevs.h 3 Jul 2023 09:04:50 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: usbdevs.h,v 1.769 2023/06/12 11:26:54 jsg Exp $ */
> +/* $OpenBSD$ */
>
> /*
> * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
> @@ -2117,6 +2117,8 @@
> #define USB_PRODUCT_GARMIN_DAKOTA20 0x23c0 /* Dakota 20 */
> #define USB_PRODUCT_GARMIN_GPSMAP62S0x2459 /* GPSmap 62s */
>
> +/* Gaomon */
> +
Strange... looks like you edited the file instead of re-generating it.
--
Matthieu Herrb
Re: Diff for evaluation (WACOM tablet driver)
->parent, , );
> repid = uha->reportid;
> -
> sc->sc_hdev.sc_isize = hid_report_size(desc, size, hid_input, repid);
> + #ifdef UWACOM_DEBUG
> + printf("Wacom packet max size: %d\n",sc->sc_hdev.sc_isize);
> + #endif
> sc->sc_hdev.sc_osize = hid_report_size(desc, size, hid_output, repid);
> - sc->sc_hdev.sc_fsize = hid_report_size(desc, size, hid_feature, repid);
> -
> - ms->sc_device = self;
> - ms->sc_rawmode = 1;
> - ms->sc_flags = HIDMS_ABSX | HIDMS_ABSY;
> - ms->sc_num_buttons = 3;
> -
> - ms->sc_loc_x.pos = 8;
> - ms->sc_loc_x.size = 16;
> - ms->sc_loc_y.pos = 24;
> - ms->sc_loc_y.size = 16;
> -
> - ms->sc_tsscale.minx = 0;
> - ms->sc_tsscale.miny = 0;
> -
> - ms->sc_loc_btn[0].pos = 0;
> - ms->sc_loc_btn[0].size = 1;
> - ms->sc_loc_btn[1].pos = 1;
> - ms->sc_loc_btn[1].size = 1;
> - ms->sc_loc_btn[2].pos = 2;
> - ms->sc_loc_btn[2].size = 1;
> -
> - if (uha->uaa->product == USB_PRODUCT_WACOM_ONE_S) {
> - static uByte reportbuf[2] = { 0x02, 0x02 };
> - uhidev_set_report(uha->parent, UHID_FEATURE_REPORT, 2,
> - , 2);
> - ms->sc_tsscale.maxx = 15200;
> - ms->sc_tsscale.maxy = 9500;
> + sc->sc_hdev.sc_fsize
> + = hid_report_size(desc, size, hid_feature, repid);
> + /* If a more modern tablet */
> + if (uha->uaa->product == USB_PRODUCT_WACOM_ONE_S
> + || uha->uaa->product == USB_PRODUCT_WACOM_INTUOS_S) {
> + static uByte report_buf[2] = { 0x02, 0x02 };
> + uhidev_set_report(
> + uha->parent, UHID_FEATURE_REPORT,
> sc->sc_hdev.sc_report_id, _buf, sizeof(report_buf));
> + hidms_setup((struct device *)sc, ms, HIDMS_WACOM_SETUP, repid,
> desc, size);
> }
>
> if (uha->uaa->product == USB_PRODUCT_WACOM_INTUOS_DRAW) {
> @@ -174,40 +186,64 @@ uwacom_intr(struct uhidev *addr, void *buf, u_int len)
> {
> struct uwacom_softc *sc = (struct uwacom_softc *)addr;
> struct hidms *ms = >sc_ms;
> - u_int32_t buttons = 0;
> + u_int32_t pad_buttons = 0;
> + u_int32_t stylus_buttons = 0;
> uint8_t *data = (uint8_t *)buf;
> - int i, x, y, pressure;
> + int x, y, pressure,distance;
>
> + #ifdef UWACOM_DEBUG
> + UWACOM_PACKET_PRINTF(data, len);
> + #endif
> if (ms->sc_enabled == 0)
> return;
>
> - /* ignore proximity, it will cause invalid button 2 events */
> - if ((data[0] & 0xf0) == 0xc0)
> - return;
> -
> x = hid_get_data(data, len, >sc_loc_x);
> y = hid_get_data(data, len, >sc_loc_y);
> + pressure = hid_get_data(data, len, >sc_loc_z);
> + distance = hid_get_data(data, len, >sc_loc_w);
> +
> + if (!sc->sc_moved)
> + {
> + sc->sc_x = x;
> + sc->sc_y = y;
> + sc->sc_z = pressure;
> + sc->sc_w = distance;
> + sc->sc_moved = 1;
> + }
> +
> + int dx = sc->sc_x - x;
> + int dy = sc->sc_y - y;
> + int dz = sc->sc_z/32 - pressure/32; // Clamp the sensetivity to be in
> the range of -127 to 127
> + int dw = sc->sc_w - distance;
> +
> + sc->sc_x = x;
> + sc->sc_y = y;
> + sc->sc_z = pressure;
> + sc->sc_w = distance;
>
> if (sc->sc_flags & UWACOM_BIG_ENDIAN) {
> x = be16toh(x);
> y = be16toh(y);
> }
> -
> - for (i = 0; i < ms->sc_num_buttons; i++)
> - if (hid_get_data(data, len, >sc_loc_btn[i]))
> - buttons |= (1 << i);
> -
> - if (sc->sc_flags & UWACOM_USE_PRESSURE) {
> - pressure = hid_get_data(data, len, >sc_loc_tip_press);
> - if (pressure > 10)
> - buttons |= 1;
> - else
> - buttons &= ~1;
> - }
> -
> - if (x != 0 || y != 0 || buttons != ms->sc_buttons) {
> - wsmouse_position(ms->sc_wsmousedev, x, y);
> - wsmouse_buttons(ms->sc_wsmousedev, buttons);
> +
> + for (int i = 0; i < ms->sc_num_stylus_buttons; i++)
> + if (hid_get_data(data, len, >sc_loc_stylus_btn[i]))
> + stylus_buttons |= (1 << i);
> +
> + for (int i = 0; i < ms->sc_num_pad_buttons; i++)
> + if (hid_get_data(data, len, >sc_loc_pad_btn[i]))
> + pad_buttons |= (1 << i);
> +
> +
> + #ifdef UWACOM_DEBUG
> + UWACOM_BUTTON_EVENT(pad_buttons);
> + UWACOM_BUTTON_EVENT(stylus_buttons);
> + #endif
> +
> + if (x != 0 || y != 0 || pressure != 0 || distance != 0
> + || pad_buttons != ms->sc_buttons || stylus_buttons !=
> ms->sc_buttons) {
> + wsmouse_buttons(ms->sc_wsmousedev, (pad_buttons |
> stylus_buttons));
> + wsmouse_motion(ms->sc_wsmousedev, -dx, dy, dz, dw);
> wsmouse_input_sync(ms->sc_wsmousedev);
> }
> }
>
--
Matthieu Herrb
Re: cwm: add fvwm and tvm as default wm entries
On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote:
> Both fvwm(1) and twm(1) have a restart menu that contains other window
> managers by default, which is useful if you want to switch around
> without restarting X and/or custom window manager config.
>
> cwm(1) only offers to restart into itself by deafult.
> Add the other two we ship by default so users can round trip between
> them.
>
> Feedback? OK?
Last year I mentionned that I think we should retire twm. It's really
too old and missing support for the modern window managers hints.
People still using it should switch to cwm or maybe ctwm from ports
(to keep the same configurarion system), or someone should step up to
maintain it and enhance it with exwmh support. (but this is somehow
just wasting time imho).
Otherwise ok to add this and fix the other WM menus for other window
managers (those parts of the configs are already local changes in
Xenocara)
>
> PS: fwvm and twm menus more programs we don't ship, e.g. "wm2", and
> twm dies when failing to execute them (fvwm and cwm keeps running);
> do we want to keep those default-broken entries around?
>
> Index: conf.c
> ===
> RCS file: /cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.255
> diff -u -p -r1.255 conf.c
> --- conf.c26 Feb 2022 15:19:18 - 1.255
> +++ conf.c15 May 2023 06:11:01 -
> @@ -307,6 +307,8 @@ conf_init(struct conf *c)
> conf_cmd_add(c, "lock", "xlock");
> conf_cmd_add(c, "term", "xterm");
> conf_wm_add(c, "cwm", "cwm");
> + conf_wm_add(c, "fvwm", "fvwm");
> + conf_wm_add(c, "twm", "twm");
>
> c->font = xstrdup("sans-serif:pixelsize=14:bold");
> c->wmname = xstrdup("CWM");
>
--
Matthieu Herrb
Re: Patch to stop tearing on Intel modesetting in Xenocara
On Sat, Mar 25, 2023 at 09:58:31PM +, Igor Petruk wrote: > Hi, > > I noticed the "TearFree" patch was merged upstream in the XOrg > modesetting driver. Long time ago when it was sent I patched it into > my local Xenocara and used it ever since. Zero issues, zero tearing. > > Maybe let's consider adding it to Xenocara too? I am attaching the > patch, commit message is from my local git repo, I am of course NOT an > author. It adds the "TearFree" option to the modesetting section of > your xorg.conf. > > Feel free to fetch it directly from the Merge Request, the real author > is https://gitlab.freedesktop.org/kerneltoast: > > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006 > > I am just sending this as is, but I don't know enough about XOrg to > follow up with extra fixes to the code. I can only confirm that it > worked flawlessly on my Intel NUC 11 for a really long time. > > Thanks, > Igor. Hi, This will be merged in OpenBSD sometime after the next major X server version (based on the current main branch of the gitlab repository) will be released. We try to avoid merging parts of the main branch because it then makes merging full releases more complex. -- Matthieu Herrb
Re: AMD 17h/1xh HD Audio testers wanted!
On Sun, Mar 05, 2023 at 09:59:49AM +0100, Matthieu Herrb wrote: > On Sun, Mar 05, 2023 at 08:53:00AM +0100, Alexandre Ratchov wrote: > > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please > > test this diff and report regressions. Especially audio lock ups that > > require reboot. > > > > IIRC, MSI was disabled few years ago to "fix" such lockups, and now > > this diff suggests we need MSI on certain boards. > > > > Context and diff below: > > > > Seems to work fine on my X395. > > -azalia1 at pci5 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: apic 33 > int 30 > +azalia1 at pci5 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: msi I spoke too soon. After ~ 1hour of music playing, it did hang. No message in dmesg, but all process trying to do audio fail to run. -- Matthieu Herrb
Re: AMD 17h/1xh HD Audio testers wanted!
Intel Dual Band Wireless-AC 9260" rev 0x29, msix ppb1 at pci0 dev 1 function 3 "AMD 17h/1xh PCIE" rev 0x00: msi pci2 at ppb1 bus 2 nvme0 at pci2 dev 0 function 0 vendor "Toshiba", unknown product 0x011a rev 0x00: msix, NVMe 1.3 nvme0: KXG6AZNV512G TOSHIBA, firmware 5108AGLA, serial 99BF71MQFU0N scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 488386MB, 512 bytes/sector, 1000215216 sectors ppb2 at pci0 dev 1 function 4 "AMD 17h/1xh PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0e: RTL8168EP/8111EP (0x5000), msi, address f8:75:a4:26:0f:0d rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 "Realtek RealManage Serial" rev 0x0e at pci3 dev 0 function 1 not configured "Realtek RealManage Serial" rev 0x0e at pci3 dev 0 function 2 not configured "Realtek RealManage IPMI" rev 0x0e at pci3 dev 0 function 3 not configured ehci0 at pci3 dev 0 function 4 "Realtek RealManage USB" rev 0x0e: apic 33 int 15 ehci0: pre-2.0 USB rev ppb3 at pci0 dev 1 function 7 "AMD 17h/1xh PCIE" rev 0x00: msi pci4 at ppb3 bus 4 rtsx0 at pci4 dev 0 function 0 "Realtek RTS522A Card Reader" rev 0x01: msi sdmmc0 at rtsx0: 4-bit, dma pchb1 at pci0 dev 8 function 0 "AMD 17h PCIE" rev 0x00 ppb4 at pci0 dev 8 function 1 "AMD 17h/1xh PCIE" rev 0x00 pci5 at ppb4 bus 5 amdgpu0 at pci5 dev 0 function 0 "ATI Picasso" rev 0xd2 drm0 at amdgpu0 amdgpu0: msi azalia0 at pci5 dev 0 function 1 "ATI Radeon Vega HD Audio" rev 0x00: msi azalia0: no supported codecs ccp0 at pci5 dev 0 function 2 "AMD 17h/1xh Crypto" rev 0x00 xhci0 at pci5 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 xhci1 at pci5 dev 0 function 4 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10 usb1 at xhci1: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 "AMD 17h/1xh I2S Audio" rev 0x00 at pci5 dev 0 function 5 not configured azalia1 at pci5 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: msi azalia1: codecs: Realtek ALC257 audio0 at azalia1 piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x61: SMI iic0 at piixpm0 iic1 at piixpm0 pcib0 at pci0 dev 20 function 3 "AMD FCH LPC" rev 0x51 pchb2 at pci0 dev 24 function 0 "AMD 17h/1xh Data Fabric" rev 0x00 pchb3 at pci0 dev 24 function 1 "AMD 17h/1xh Data Fabric" rev 0x00 pchb4 at pci0 dev 24 function 2 "AMD 17h/1xh Data Fabric" rev 0x00 pchb5 at pci0 dev 24 function 3 "AMD 17h/1xh Data Fabric" rev 0x00 pchb6 at pci0 dev 24 function 4 "AMD 17h/1xh Data Fabric" rev 0x00 pchb7 at pci0 dev 24 function 5 "AMD 17h/1xh Data Fabric" rev 0x00 pchb8 at pci0 dev 24 function 6 "AMD 17h/1xh Data Fabric" rev 0x00 pchb9 at pci0 dev 24 function 7 "AMD 17h/1xh Data Fabric" rev 0x00 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pms0: Elantech Clickpad, version 4, firmware 0x7f3001 wsmouse1 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm0 at mainbus0: SVM/RVI efifb at mainbus0 not configured uhub2 at uhub1 port 2 configuration 1 interface 0 "Genesys Logic USB2.0 Hub" rev 2.00/60.52 addr 2 uvideo0 at uhub2 port 1 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 3 video0 at uvideo0 uvideo1 at uhub2 port 1 configuration 1 interface 2 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 3 video1 at uvideo1 sdmmc0: can't enable card vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd1 at scsibus3 targ 1 lun 0: sd1: 243512MB, 512 bytes/sector, 498713727 sectors root on sd1a (03acaca77ababaff.a) swap on sd1b dump on sd1b iwm0: hw rev 0x320, fw ver 46.50fdb42f.0, address 7c:b2:7d:f0:d6:51 amdgpu0: PICASSO GC 9.1.0 8 CU rev 0x01 amdgpu0: 1920x1080, 32bpp wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) -- Matthieu Herrb
Re: pf(4) drops valid IGMP/MLD messages
On Mon, Feb 27, 2023 at 12:04:54AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > > 8<---8<---8<--8<
> > > diff --git a/sys/net/pf.c b/sys/net/pf.c
> > > index 8cb1326a160..c328109026c 100644
> > > --- a/sys/net/pf.c
> > > +++ b/sys/net/pf.c
> > > @@ -6847,7 +6847,7 @@ pf_walk_header(struct pf_pdesc *pd, struct ip *h,
> > > u_short *reason)
> > > /* IGMP packets have router alert options, allow them */
> > > if (pd->proto == IPPROTO_IGMP) {
> > > /* According to RFC 1112 ttl must be set to 1. */
> > > - if ((h->ip_ttl != 1) || !IN_MULTICAST(h->ip_dst.s_addr)) {
> > > + if ((h->ip_ttl != 1) && IN_MULTICAST(h->ip_dst.s_addr)) {
> > > DPFPRINTF(LOG_NOTICE, "Invalid IGMP");
> > > REASON_SET(reason, PFRES_IPOPTIONS);
> > > return (PF_DROP);
> > > @@ -7101,8 +7101,8 @@ pf_walk_header6(struct pf_pdesc *pd, struct ip6_hdr
> > > *h, u_short *reason)
> > >* missing then MLD message is invalid and
> > >* should be discarded.
> > >*/
> > > - if ((h->ip6_hlim != 1) ||
> > > - !IN6_IS_ADDR_LINKLOCAL(>ip6_src)) {
> > > + if ((h->ip6_hlim != 1) &&
> > > + IN6_IS_ADDR_LINKLOCAL(>ip6_src)) {
> > > DPFPRINTF(LOG_NOTICE, "Invalid MLD");
> > > REASON_SET(reason, PFRES_IPOPTIONS);
> > > return (PF_DROP);
> > >
> >
> > Unless I'm missing more context, this hunk looks wrong to me. Valid
> > MLD packets must have a ttl of 1 *and* come from a LL address. The
> > initial logic seems ok to me.
> >
>
> yes you are right. Your comment made me to take better look
> at RFC 1112 [1]. Section 'Informal Protocol Description'
> reads as follows:
>
>Multicast routers send Host Membership Query messages (hereinafter
>called Queries) to discover which host groups have members on their
>attached local networks. Queries are addressed to the all-hosts
>group (address 224.0.0.1), and carry an IP time-to-live of 1.
>
> I think I've confused all-hosts group (224.0.0.1) with any multicast
> address (any class-D 224.0.0.0). I think the diff below is what we
> actually need to get IPv4 IGMP working again:
>
> [1] https://www.ietf.org/rfc/rfc1112.txt
>
> 8<---8<---8<--8<
> diff --git a/sys/net/pf.c b/sys/net/pf.c
> index 8cb1326a160..c50173186da 100644
> --- a/sys/net/pf.c
> +++ b/sys/net/pf.c
> @@ -6846,8 +6846,12 @@ pf_walk_header(struct pf_pdesc *pd, struct ip *h,
> u_short *reason)
> pd->proto = h->ip_p;
> /* IGMP packets have router alert options, allow them */
> if (pd->proto == IPPROTO_IGMP) {
> - /* According to RFC 1112 ttl must be set to 1. */
> - if ((h->ip_ttl != 1) || !IN_MULTICAST(h->ip_dst.s_addr)) {
> + /*
> + * According to RFC 1112 ttl must be set to 1 in all IGMP
> + * packets sent do 224.0.0.1
> + */
> + if ((h->ip_ttl != 1) &&
> + (h->ip_dst.s_addr == INADDR_ALLHOSTS_GROUP)) {
> DPFPRINTF(LOG_NOTICE, "Invalid IGMP");
> REASON_SET(reason, PFRES_IPOPTIONS);
> return (PF_DROP);
>
Hi,
The expression look wrong to me again.
I read in RFC1112 that correct packets should have:
(h->ip_ttl == 1 && h->ip.ip_dst.s_addr == INADDR_ALLHOST_GROUP)
so the test to drop invalid IGMP should be:
if (h->ip_ttl != 1 || h->ip.ip_dst.s_addr != INADDR_ALLHOST_GROUP) {
...
return (PF_DROP
}
Again I may be missing something
--
Matthieu Herrb
update: xf86-video-amdgpu 23.0.0
pDraw)
+{
+ ScreenPtr pScreen = pDraw->pScreen;
+ RRCrtcPtr crtc = NULL;
+ BoxRec box;
+
+ box.x1 = pDraw->x;
+ box.y1 = pDraw->y;
+ box.x2 = box.x1 + pDraw->width;
+ box.y2 = box.y1 + pDraw->height;
+
+ crtc = amdgpu_crtc_covering_box(pScreen, , TRUE);
+#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0)
+ if (!crtc) {
+ crtc = amdgpu_crtc_covering_box_on_secondary(pScreen, );
+ }
+#endif
+ return crtc;
}
xf86CrtcPtr
-amdgpu_pick_best_crtc(ScrnInfoPtr pScrn, Bool consider_disabled,
+amdgpu_pick_best_crtc(ScreenPtr pScreen,
int x1, int x2, int y1, int y2)
{
- xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
- int coverage, best_coverage, c, cd;
- BoxRec box, crtc_box, cover_box;
- RROutputPtr primary_output = NULL;
- xf86CrtcPtr best_crtc = NULL, primary_crtc = NULL;
+ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
if (!pScrn->vtSema)
return NULL;
+ RRCrtcPtr crtc = NULL;
+ BoxRec box;
+
box.x1 = x1;
box.x2 = x2;
box.y1 = y1;
box.y2 = y2;
- best_coverage = 0;
- /* Prefer the CRTC of the primary output */
- if (dixPrivateKeyRegistered(rrPrivKey))
- {
- primary_output = RRFirstOutput(pScrn->pScreen);
+ crtc = amdgpu_crtc_covering_box(pScreen, , TRUE);
+ if (crtc) {
+ return crtc->devPrivate;
}
- if (primary_output && primary_output->crtc)
- primary_crtc = primary_output->crtc->devPrivate;
-
- /* first consider only enabled CRTCs
-* then on second pass consider disabled ones
-*/
- for (cd = 0; cd < (consider_disabled ? 2 : 1); cd++) {
- for (c = 0; c < xf86_config->num_crtc; c++) {
- xf86CrtcPtr crtc = xf86_config->crtc[c];
-
- if (!cd && !amdgpu_crtc_is_enabled(crtc))
- continue;
-
- amdgpu_crtc_box(crtc, _box);
- amdgpu_box_intersect(_box, _box, );
- coverage = amdgpu_box_area(_box);
- if (coverage > best_coverage ||
- (coverage == best_coverage &&
-crtc == primary_crtc)) {
- best_crtc = crtc;
- best_coverage = coverage;
- }
- }
- if (best_crtc)
- break;
- }
-
- return best_crtc;
+ return NULL;
}
void AMDGPUInitVideo(ScreenPtr pScreen)
Index: src/compat-api.h
===
RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/compat-api.h,v
retrieving revision 1.2
diff -u -p -u -r1.2 compat-api.h
--- src/compat-api.h3 Aug 2021 05:35:52 - 1.2
+++ src/compat-api.h27 Feb 2023 20:09:46 -
@@ -42,6 +42,9 @@
#define current_primary current_master
#define primary_pixmap master_pixmap
#define secondary_dst slave_dst
+#define secondary_list slave_list
+#define secondary_head slave_head
+#define is_output_secondary is_output_slave
#endif
#endif
--
Matthieu Herrb
Re: pf(4) drops valid IGMP/MLD messages
On Sun, Feb 26, 2023 at 12:09:13AM +0100, Alexandr Nedvedicky wrote:
> Hello,
Hi,
one remark at the end.
I usually add explicit pass rules for multicast IPv6 traffic on my
boxes where IPv6 matters, because otherwise I've seen issues in the
past, but I don't have details anymore.
So I'm happy if pf starts behaving better by default with IPv6, but
see my comment below.
>
> the issue has been discovered and analyzed by Luca di Gregorio
> on bugs@ [1]. The thread [1] covers all details. People who
> wish to read brief summary can skip to Luca's email [2].
>
> To wrap it up the current handling IGMP/MLD messages in pf(4)
> is exact opposite. I failed to translate English words from
> RFC standards into correct C code. Patch below are two one-liners
> which make multicast for IPv4/IPv6 to work again with pf(4) enabled.
>
> Let me quote Luca's summary for IPv6 here:
>
> If the IP Destination Address is multicast, then the TTL
> should be 1.
>
> If the IP Destination Address is not multicast, then
> no restrictions on TTL.
>
> and Luca's summary for IPv4:
>
> If the IP Destination Address is 224.0.0.0/4, then the TTL
> should be 1.
>
> If the IP Destination Address is not 224.0.0.0/4, then no
> restrictions on TTL.
>
> As I've said all details and references to RFCs can be found
> in Luca's emails on bugs@ [1].
>
> Diff below to fix IGMP/MLD handling has been essentially proposed
> by Luca [3]. OK to commit?
>
> thanks and
> regards
> sashan
>
> [1] https://marc.info/?t=16771405962=1=2
>
> [2] https://marc.info/?l=openbsd-bugs=167727244015783=2
>
> [3] https://marc.info/?l=openbsd-bugs=167722460220004=2
>
> 8<---8<---8<--8<
> diff --git a/sys/net/pf.c b/sys/net/pf.c
> index 8cb1326a160..c328109026c 100644
> --- a/sys/net/pf.c
> +++ b/sys/net/pf.c
> @@ -6847,7 +6847,7 @@ pf_walk_header(struct pf_pdesc *pd, struct ip *h,
> u_short *reason)
> /* IGMP packets have router alert options, allow them */
> if (pd->proto == IPPROTO_IGMP) {
> /* According to RFC 1112 ttl must be set to 1. */
> - if ((h->ip_ttl != 1) || !IN_MULTICAST(h->ip_dst.s_addr)) {
> + if ((h->ip_ttl != 1) && IN_MULTICAST(h->ip_dst.s_addr)) {
> DPFPRINTF(LOG_NOTICE, "Invalid IGMP");
> REASON_SET(reason, PFRES_IPOPTIONS);
> return (PF_DROP);
> @@ -7101,8 +7101,8 @@ pf_walk_header6(struct pf_pdesc *pd, struct ip6_hdr *h,
> u_short *reason)
>* missing then MLD message is invalid and
>* should be discarded.
>*/
> - if ((h->ip6_hlim != 1) ||
> - !IN6_IS_ADDR_LINKLOCAL(>ip6_src)) {
> + if ((h->ip6_hlim != 1) &&
> + IN6_IS_ADDR_LINKLOCAL(>ip6_src)) {
> DPFPRINTF(LOG_NOTICE, "Invalid MLD");
> REASON_SET(reason, PFRES_IPOPTIONS);
> return (PF_DROP);
>
Unless I'm missing more context, this hunk looks wrong to me. Valid
MLD packets must have a ttl of 1 *and* come from a LL address. The
initial logic seems ok to me.
--
Matthieu Herrb
Re: [xenocara] xenodm.man fix
On Sat, Feb 18, 2023 at 12:15:54PM +0300, Mikhail wrote: > On Sat, Feb 18, 2023 at 08:00:26AM +0100, Matthieu Herrb wrote: > > On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote: > > > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote: > > > > > > Hello Mikhail, > > > > > > > /etc/X11/xenodm/Xsession file has a check for x bit > > > > > > Yes, this one caught me out a few years back: > > > > > > https://marc.info/?l=openbsd-bugs=162737223625768=2 > > > > > > In subsequent discussions with Matthieu and Theo, I *think* the > > > eventual thought was that it would be better to get rid of the `-x` > > > check. I might be misremembering that, though. > > > > > > > I'm fine with not runing the script if not executable. I don't > > remember exactly why I didn't do it when you brought the issue up in > > 2021. But I prefer to use the fallback session when the script exists > > and isn't executable rather than letting the session fail immediatly. > > > > ok? > > It will break setups which people have working now, but what do we get > in return? Just to be complaint with the docs? > As Klemens and Laurence have mentionned it, the current code leads to subtle behaviour changes depending on whether the user .xsession file is executable or not. It has always been documented that the file needs to be executable, so people who rely on the undocumented feature need to fix their setups. I'll add an entry in current.html if I get oks for the diff. -- Matthieu Herrb
Re: [xenocara] xenodm.man fix
On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote: > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote: > > Hello Mikhail, > > > /etc/X11/xenodm/Xsession file has a check for x bit > > Yes, this one caught me out a few years back: > > https://marc.info/?l=openbsd-bugs=162737223625768=2 > > In subsequent discussions with Matthieu and Theo, I *think* the eventual > thought was that it would be better to get rid of the `-x` check. I might be > misremembering that, though. > I'm fine with not runing the script if not executable. I don't remember exactly why I didn't do it when you brought the issue up in 2021. But I prefer to use the fallback session when the script exists and isn't executable rather than letting the session fail immediatly. ok? Index: config/Xsession.in === RCS file: /local/cvs/xenocara/app/xenodm/config/Xsession.in,v retrieving revision 1.2 diff -u -p -u -r1.2 Xsession.in --- config/Xsession.in 1 Jul 2022 20:42:06 - 1.2 +++ config/Xsession.in 18 Feb 2023 06:56:22 - @@ -58,12 +58,8 @@ esac startup=$HOME/.xsession resources=$HOME/.Xresources -if [ -s "$startup" ]; then - if [ -x "$startup" ]; then - "$startup" - else - /bin/sh "$startup" - fi +if [ -s "$startup" -a -x "$startup" ]; then + "$startup" else if [ -f "$resources" ]; then @XRDB_PROGRAM@ -load "$resources" -- Matthieu Herrb
update xterm to version 378
Hi, The patch below updates xterm to version 378. As always testing (especially for specific use cases) is welcome. Apply in /usr/xenocara/app/xterm and rebuild xterm doas make obj doas make build Patch #378 - 2023/01/09 * improve descriptions of XTQMODKEYS and XTQALLOWED features in ctlseqs.ms (reports by Bram Moolenaar, Thomas Wolff). * add bracketed+paste and report+version building blocks to terminfo, from ncurses 6.4 * improve check for unsupported formatting characters, e.g., zero-width space, to properly ignore them (report by Thomas Wolff). * improve/document error-checking for some of the controls which return responses: DECRQSS, XTGETXRES, XTSETTCAP, XTGETTCAP (prompted by discussion with David Leadbeater). * improve limit-checks for fallback font cache (report by Dimitrije Erdeljan). * improve check for too-wide glyph in fallback font by allowing xterm to continue searching for a suitable font rather than just failing on the first. Also add limitFontWidth to allow changing the amount by which a glyph must extend outside the font's bounding box to disallow it. Patch #377 - 2022/11/25 * add control sequences for reporting the current state of the modified keys options (XTQMODKEYS) and allowed/disallowed operations (XTQALLOWED), (prompted by discussion with Bram Moolenaar). * amend modifyOtherKeys case 2 to distinguish the escape character with modifiers, e.g., shift-escape, from a plain escape character (suggested by Bram Moolenaar). * improve parsing and error-recovery in the case where a list of X11 bitmap fonts is given in the -fn and related options. * change default for xftTrackMemUsage to false, because libXft does not handle certain fonts. Patch #376 - 2022/11/16 * modify configure script to always check for gcc attributes, * update install-sh. * fix parsing of result -u in vttests/halves.pl. * add a note in ctlseqs.ms about compatibility of TBC. * fix a copy/paste error in manual (patch by Grady Martin). * add null-pointer checks in x_strcasecmp and x_strncasecmp, to help with error-recovery for a missing font (Debian #1022942). Index: COPYING === RCS file: /cvs/OpenBSD/xenocara/app/xterm/COPYING,v retrieving revision 1.4 diff -u -p -u -r1.4 COPYING --- COPYING 25 Apr 2022 19:20:37 - 1.4 +++ COPYING 28 Jan 2023 17:16:53 - @@ -1,7 +1,7 @@ $XTermId: COPYING,v 1.5 2022/01/30 19:30:32 tom Exp $ +--- $XTermId: COPYING,v 1.6 2023/01/02 15:46:55 tom Exp $ --- -Copyright 1996-2021,2022 by Thomas E. Dickey +Copyright 1996-2022,2023 by Thomas E. Dickey All Rights Reserved Index: MANIFEST === RCS file: /cvs/OpenBSD/xenocara/app/xterm/MANIFEST,v retrieving revision 1.52 diff -u -p -u -r1.52 MANIFEST --- MANIFEST9 Nov 2022 21:55:14 - 1.52 +++ MANIFEST28 Jan 2023 17:16:53 - @@ -1,4 +1,4 @@ -MANIFEST for xterm, version xterm-375 +MANIFEST for xterm, version xterm-378 MANIFESTthis file 256colres.h resource-definitions for 256-color mode Index: NEWS === RCS file: /cvs/OpenBSD/xenocara/app/xterm/NEWS,v retrieving revision 1.12 diff -u -p -u -r1.12 NEWS --- NEWS9 Nov 2022 21:55:15 - 1.12 +++ NEWS28 Jan 2023 17:16:53 - @@ -1,13 +1,22 @@ The NEWS file was generated from xterm.log.html, which serves as the changelog for xterm. -Patch #375 - 2022/10/23 +Patch #378 - 2023/01/09 - * improve error-recovery when setting a bitmap font for the VT100 - window, e.g., in case OSC 50 failed, restoring the most recent - valid font so that a subsequent OSC 50 reports this correctly - (report by David Leadbeater). - * exclude MC_XDG_OPEN from environment variables trimmed on startup - (report by Gabor Hauzer). - * check for null pointer in isSelect() (report by Column Paget). + * improve descriptions of XTQMODKEYS and XTQALLOWED features in + ctlseqs.ms (reports by Bram Moolenaar, Thomas Wolff). + * add bracketed+paste and report+version building blocks to terminfo, + from ncurses 6.4 + * improve check for unsupported formatting characters, e.g., + zero-width space, to properly ignore them (report by Thomas Wolff). + * improve/document error-checking for some of
Re: qt.qpa.xcb: xcb_shm_attach() failed
On Wed, Nov 16, 2022 at 10:15:41PM +0100, Matthieu Herrb wrote: > Below is a sample program to demonstrate how to use this with xcb. Hmm no this exemple I sent is pure Xlib. I have an xcb based example somewhere but I can't find it right now, sorry. -- Matthieu Herrb
Re: qt.qpa.xcb: xcb_shm_attach() failed
On Wed, Nov 16, 2022 at 06:52:04PM +0100, Rafael Sadowski wrote:
> On Sun Nov 13, 2022 at 08:37:55PM +0100, Rafael Sadowski wrote:
> > I don't know if this has worked in the past, but when debugging some Qt
> > applications I saw the following debug messages:
> >
> > $ gwenview
> > qt.qpa.xcb: Has MIT-SHM : true
> > qt.qpa.xcb: Has MIT-SHM FD : true
> > qt.qpa.xcb: xcb_shm_attach() failed
> > qt.qpa.xcb: failed to create System V shared memory segment (remote X11
> > connection?), disabling SHM
> > qt.qpa.xcb: Using XInput version 2.2
> > qt.qpa.screen: Output DP-1 is not connected
> > qt.qpa.screen: Output HDMI-1 is not connected
> >
> > The code that fails is here. xcb_shm_attach_checked and/or
> > xcb_request_check failed with all my Qt applications.
> >
> > pobj/qtbase-5.15.6/qtbase-everywhere-src-5.15.6/src/plugins/platforms/xcb/qxcbbackingstore.cpp
> >
> > bool QXcbBackingStoreImage::createSystemVShmSegment(xcb_connection_t *c,
> > size_t segmentSize,
> > xcb_shm_segment_info_t
> > *shmInfo)
> > {
> > const int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0x1C0);
> > if (id == -1) {
> > qCWarning(lcQpaXcb, "shmget() failed (%d: %s) for size %zu", errno,
> > strerror(errno), segmentSize);
> > return false;
> > }
> >
> > void *addr = shmat(id, nullptr, 0);
> > if (addr == (void *)-1) {
> > qCWarning(lcQpaXcb, "shmat() failed (%d: %s) for id %d", errno,
> > strerror(errno), id);
> > return false;
> > }
> >
> > if (shmctl(id, IPC_RMID, nullptr) == -1)
> > qCWarning(lcQpaXcb, "Error while marking the shared memory segment
> > to be destroyed");
> >
> > const auto seg = xcb_generate_id(c);
> > auto cookie = xcb_shm_attach_checked(c, seg, id, false);
> > auto *error = xcb_request_check(c, cookie);
> > if (error) {
> > qCWarning(lcQpaXcb(), "xcb_shm_attach() failed");
> > free(error);
> > if (shmdt(addr) == -1)
> > qCWarning(lcQpaXcb, "shmdt() failed (%d: %s) for %p", errno,
> > strerror(errno), addr);
> > return false;
> >
> >
> > If you want to test it run any Qt application with
> > QT_LOGGING_RULES="qt.qpa.xcb.debug=true" exported.
> >
> > Should SHM with XCB generally work on OpenBSD?
> >
Since on OpenBSD the X server and client will generally not run under
the same uid (except if you use startx(1)), you will need to create
the shared memory segment with mode 666 or similar for the X server to
be able to access it (via 'other' rights).
An alternative was introduced in the MIT-SHM extension revision 1.2 a
few years ago. You can use shm_open() and mmap() to create the shared
memory segement and pass the resulting file descriptor to the X
server.
Below is a sample program to demonstrate how to use this with xcb.
/*
* Copyright (c) 2019 Matthieu Herrb
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
Display *d;
XShmSegmentInfo shminfo;
XImage *image, *image2;
Pixmap pixmap;
XEvent e;
#define WIDTH 100
#define HEIGHT 100
#define HAVE_SHM_MKSTEMP
/* shminfo->shmid contains the file descriptor */
Bool
XShmAttachFd(Display *dpy, XShmSegmentInfo *shminfo)
{
xcb_connection_t *xcb_conn = XGetXCBConnection(dpy);
shminfo->shmseg = xcb_generate_id(xcb_conn);
xcb_shm_attach_fd(xcb_conn, shminfo->shmseg,
shminfo->shmid, shminfo->readOnly);
return 1;
}
int
main(int argc, char *argv[])
{
int major, minor, i;
Bool pixmaps;
XGCValues gcval;
GC gc;
int fd;
unsigned char *addr;
struct stat statb;
char name[128];
size_t len;
d = XOpenDisplay(
libXft updated to 2.3.7 in -current
Hi, Note that OpenBSD 7.2 shipped with version 2.3.4 of libXft which is not affected by the bug. - Forwarded message from Matthieu Herrb - Date: Wed, 16 Nov 2022 13:25:46 -0700 (MST) From: Matthieu Herrb To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: xenocara CVSROOT:/cvs Module name:xenocara Changes by: matth...@cvs.openbsd.org2022/11/16 13:25:46 Modified files: lib/libXft : ChangeLog compile configure configure.ac lib/libXft/src : xftglyphs.c xftrender.c Log message: Update libXft to version 2.3.7. This is a fix for a stack overflow that was introduced in 2.3.5. - End forwarded message - -- Matthieu Herrb
Re: libX11 patch for X*IfEvent() API issues, take #2
On Fri, Nov 11, 2022 at 03:17:21PM +0100, Walter Alejandro Iglesias wrote:
> On Nov 11 2022, Matthieu Herrb wrote:
> > Hi,
> >
> > So the patch provided by Adam Jackson upstreams is completely buggy.
> >
> > - the logic to setup the new locking function was busted
> > - I've observed cases where even the XGetIfEvent() function gets
> > re-rentered. So the flags does in fact need to be a counter.
> >
> > New patch which works for me with fvwm2...
> >
> > Testing is welcome...
>
> Unfortunately I still can reproduce the bug.
>
> This patch also makes firefox crash, (I'm not sure if it's because of
> firefox or cwm). After reinstalling xenocara from the snapshots
> packages I could run firefox again.
>
> fvwm is giving a lot of problems lately, there's also this drm bug I
> reported:
>
> https://marc.info/?l=openbsd-bugs=166332904632232=2
>
> Now FvwmIcons is crashing on fvwm3... I'm giving up with fvwm, I'm more
> comfortable with cwm.
Ok, I've figured out the cwm + firefox issue. There's also a
XInternalLock that needs to be neutered in the X*IfEvent() callbacks.
New diff, on which I've left my debug printfs. If you get other
crashes it may be interesting to look in .xsession-errors...
Index: Makefile.bsd-wrapper
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/Makefile.bsd-wrapper,v
retrieving revision 1.29
diff -u -p -u -r1.29 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper3 Sep 2022 06:55:25 - 1.29
+++ Makefile.bsd-wrapper11 Nov 2022 15:13:59 -
@@ -14,7 +14,6 @@ SHARED_LIBS= X11 18.0 X11_xcb 2.0
CONFIGURE_ARGS= --enable-tcp-transport --enable-unix-transport --enable-ipv6 \
--disable-composecache \
- --disable-thread-safety-constructor \
--without-xmlto --without-fop --without-xsltproc
.include
Index: include/X11/Xlibint.h
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/include/X11/Xlibint.h,v
retrieving revision 1.15
diff -u -p -u -r1.15 Xlibint.h
--- include/X11/Xlibint.h 21 Feb 2022 08:01:24 - 1.15
+++ include/X11/Xlibint.h 11 Nov 2022 15:14:00 -
@@ -207,6 +207,7 @@ struct _XDisplay
XIOErrorExitHandler exit_handler;
void *exit_handler_data;
+CARD32 in_ifevent;
};
#define XAllocIDs(dpy,ids,n) (*(dpy)->idlist_alloc)(dpy,ids,n)
Index: src/ChkIfEv.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/src/ChkIfEv.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 ChkIfEv.c
--- src/ChkIfEv.c 30 May 2011 19:19:38 - 1.4
+++ src/ChkIfEv.c 11 Nov 2022 15:14:00 -
@@ -49,6 +49,7 @@ Bool XCheckIfEvent (
unsigned long qe_serial = 0;
int n; /* time through count */
+dpy->in_ifevent++;
LockDisplay(dpy);
prev = NULL;
for (n = 3; --n >= 0;) {
@@ -60,6 +61,7 @@ Bool XCheckIfEvent (
*event = qelt->event;
_XDeq(dpy, prev, qelt);
_XStoreEventCookie(dpy, event);
+dpy->in_ifevent = False;
UnlockDisplay(dpy);
return True;
}
@@ -78,6 +80,7 @@ Bool XCheckIfEvent (
/* another thread has snatched this event */
prev = NULL;
}
+dpy->in_ifevent--;
UnlockDisplay(dpy);
return False;
}
Index: src/IfEvent.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/src/IfEvent.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 IfEvent.c
--- src/IfEvent.c 30 May 2011 19:19:38 - 1.4
+++ src/IfEvent.c 11 Nov 2022 15:14:00 -
@@ -48,6 +48,7 @@ XIfEvent (
register _XQEvent *qelt, *prev;
unsigned long qe_serial = 0;
+dpy->in_ifevent++;
LockDisplay(dpy);
prev = NULL;
while (1) {
@@ -59,6 +60,7 @@ XIfEvent (
*event = qelt->event;
_XDeq(dpy, prev, qelt);
_XStoreEventCookie(dpy, event);
+dpy->in_ifevent--;
UnlockDisplay(dpy);
return 0;
}
Index: src/OpenDis.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/src/OpenDis.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 OpenDis.c
--- src/OpenDis.c 28 Nov 2020 14:39:48 - 1.12
+++ src/OpenDis.c 11 Nov 2022 15:14:00 -
@@ -189,6 +189,7 @@ XOpenDisplay (
dpy->xcmisc_opcode = 0;
dpy->xkb_info = NULL;
dpy->exit_handler_data = NULL;
+dpy->in_ifevent = 0;
/*
*
Re: libX11 patch for X*IfEvent() API issues, take #2
On Fri, Nov 11, 2022 at 03:17:21PM +0100, Walter Alejandro Iglesias wrote: > On Nov 11 2022, Matthieu Herrb wrote: > > Hi, > > > > So the patch provided by Adam Jackson upstreams is completely buggy. > > > > - the logic to setup the new locking function was busted > > - I've observed cases where even the XGetIfEvent() function gets > > re-rentered. So the flags does in fact need to be a counter. > > > > New patch which works for me with fvwm2... > > > > Testing is welcome... > > Unfortunately I still can reproduce the bug. > > This patch also makes firefox crash, (I'm not sure if it's because of > firefox or cwm). After reinstalling xenocara from the snapshots > packages I could run firefox again. > I'll try harder to reproduce then. It was firefox under cwm ? > fvwm is giving a lot of problems lately, there's also this drm bug I > reported: > > https://marc.info/?l=openbsd-bugs=166332904632232=2 > > Now FvwmIcons is crashing on fvwm3... I'm giving up with fvwm, I'm more > comfortable with cwm. I can't really help with this one, sorry. drm is too complex. -- Matthieu Herrb
libX11 patch for X*IfEvent() API issues, take #2
ng revision 1.8
diff -u -p -u -r1.8 locking.c
--- src/locking.c 28 Nov 2020 14:39:48 - 1.8
+++ src/locking.c 11 Nov 2022 12:10:17 -
@@ -455,6 +455,32 @@ static void _XDisplayLockWait(
static void _XLockDisplay(
Display *dpy
XTHREADS_FILE_LINE_ARGS
+);
+
+static void _XIfEventLockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
+)
+{
+/* assert(dpy->in_ifevent); */
+}
+
+static void _XIfEventUnlockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
+)
+{
+if (dpy->in_ifevent == 0) {
+dpy->lock_fns->lock_display = _XLockDisplay;
+dpy->lock_fns->unlock_display = _XUnlockDisplay;
+UnlockDisplay(dpy);
+} else
+return;
+}
+
+static void _XLockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
)
{
#ifdef XTHREADS
@@ -478,6 +504,10 @@ static void _XLockDisplay(
#endif
_XIDHandler(dpy);
_XSeqSyncFunction(dpy);
+if (dpy->in_ifevent) {
+dpy->lock_fns->lock_display = _XIfEventLockDisplay;
+dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
+}
}
/*
--
Matthieu Herrb
Re: update to libpciaccess 0.17
On Mon, Nov 07, 2022 at 02:32:44PM +0100, Theo Buehler wrote:
> On Mon, Nov 07, 2022 at 12:41:14PM +0000, Matthieu Herrb wrote:
>
> [...]
>
> > Fix a small leak in pci_system_openbsd_destroy() while there.
>
> Similar leaks exist in pci_system_openbsd_create() which I think should
> call pci_system_openbsd_destroy() in both early returns instead of
> duplicating it in the second one.
>
> pci_system_init() returning non-zero will hit an err(), so these leaks
> don't really matter.
>
> compile-tested only since I don't know how to exercise this code.
>
Hmm you made me look closer at the common code. for
pci_system_cleanup() which calls the OS specific destroy function
free(pci_sys) is done in the common code. So adding those in the OS
specific functions is dumb. (and I don't know why the libpciaccess
0.17 patch add them to freebsd...)
OTOH there no such code in pci_system_init() so your patch makes
sense, even though in most cases the caller will exit on failure
anyways.
> Index: src/openbsd_pci.c
> ===
> RCS file: /cvs/xenocara/lib/libpciaccess/src/openbsd_pci.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 openbsd_pci.c
> --- src/openbsd_pci.c 3 Sep 2021 07:19:13 - 1.28
> +++ src/openbsd_pci.c 7 Nov 2022 13:25:09 -
> @@ -338,6 +338,8 @@ pci_system_openbsd_destroy(void)
> for (domain = 0; domain < ndomains; domain++)
> close(pcifd[domain]);
> ndomains = 0;
> + free(pci_sys);
> + pci_sys = NULL;
> }
>
> static int
> @@ -651,8 +653,10 @@ pci_system_openbsd_create(void)
> ndomains++;
> }
>
> - if (ndomains == 0)
> + if (ndomains == 0) {
> + pci_system_openbsd_destroy();
> return ENXIO;
> + }
>
> ndevs = 0;
> for (domain = 0; domain < ndomains; domain++) {
> @@ -676,11 +680,7 @@ pci_system_openbsd_create(void)
> pci_sys->num_devices = ndevs;
> pci_sys->devices = calloc(ndevs, sizeof(struct pci_device_private));
> if (pci_sys->devices == NULL) {
> - free(pci_sys);
> - pci_sys = NULL;
> - for (domain = 0; domain < ndomains; domain++)
> - close(pcifd[domain]);
> - ndomains = 0;
> + pci_system_openbsd_destroy();
> return ENOMEM;
> }
>
>
--
Matthieu Herrb
update to libpciaccess 0.17
Hi again, the patch below updates libpciaccess to version 0.17. Most of the changes are for other operating systems. There is a minor library version bump because a new function pci_device_disable() has been added (not implemented for OpenBSD). Fix a small leak in pci_system_openbsd_destroy() while there. comments? oks? Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libpciaccess/ChangeLog,v retrieving revision 1.11 diff -u -p -u -r1.11 ChangeLog --- ChangeLog 30 Aug 2021 12:13:33 - 1.11 +++ ChangeLog 7 Nov 2022 12:32:08 - @@ -1,3 +1,324 @@ +commit 935f0b4d6983f77c4f35e6d492f9f2c2d1ed57f9 +Author: Alan Coopersmith +Date: Mon Oct 17 18:41:02 2022 -0700 + +libpciaccess 0.17 + +Signed-off-by: Alan Coopersmith + +commit d193fa690415333420b435edb5782789a6f3ea57 +Author: Samuel Thibault +Date: Tue Aug 23 19:27:27 2022 +0200 + +hurd: Fix pci_device_hurd_map_legacy + +It was not passing a proper region number to pci_device_hurd_map_range, +and that would not make sense anyway since the rom is not a region for +instance, and the video memory, interrupt vector etc. aren't a region or +the rom. + +So this uses pci_device_hurd_map_range for the rom, and +pci_system_x86_map_dev_mem for non-rom. Unfortunately pci-arbiter +currently cannot get the rom_base from libpciaccess, so we can only +guess that we are trying to map a rom. + +commit 361356b08003f5e3c606e16eeb6a17fe02ff2726 +Author: Moritz Fischer +Date: Mon Mar 8 12:02:33 2021 -0800 + +Add pci_device_disable() function + +This implements a pci_device_disable() function, currently only for +the linux_sysfs() backend. + +This mirrors the implementation for pci_device_enable() + +Signed-off-by: Moritz Fischer + +commit a8abf913ad6b60492ef7b6ae512c4f879604a6a7 +Author: zhanghongtao +Date: Mon Aug 1 16:20:28 2022 +0800 + +Delete redundant symbols ';' + +Signed-off-by: zhanghongtao + +commit ab475c645ff9fc40e18af739eb4b81a5eb7f783c +Author: zhanghongtao +Date: Mon Aug 1 16:13:40 2022 +0800 + +Add header protection macro in linux_devmem.h + +Signed-off-by: zhanghongtao + +commit b8de959615449fdf5b58ef08d881a77d397e86e2 +Author: zhanghongtao +Date: Mon Aug 1 15:53:57 2022 +0800 + +pci_sys set NULL after free + +Signed-off-by: zhanghongtao + +commit f93c0dae5a837404a48ea7f3609c6c5c30691a7b +Author: zhanghongtao +Date: Mon Aug 1 15:28:14 2022 +0800 + +Add parentheses to the macro definition + +Signed-off-by: zhanghongtao + +commit 1fa5d4bdfcc6fea44f9abf353d25f3a5d013f5d7 +Author: Satadru Pramanik +Date: Tue Jun 21 20:44:30 2022 + + +Add support for building on macOS w/o X11, using endian code from "portable_endian.h"... + +commit 22a93f8b9b4a79eefbdd0b2c412526f6141ac7a8 +Author: Alan Coopersmith +Date: Wed Apr 6 11:46:45 2022 -0700 + +configure.ac: Use pkg-config to find zlib dependency info + +Matches what we already do in meson.build + +Signed-off-by: Alan Coopersmith + +commit 0ae62706c34e4abc581d4c42ce9807e2898fac1d +Author: Alan Coopersmith +Date: Wed Apr 6 16:30:51 2022 -0700 + +gitlab CI: stop requiring Signed-off-by in commits + +Signed-off-by: Alan Coopersmith + +commit 831b467b2e3876c4e0c307d1e3eae2746ce805a7 +Author: Chester Gillon +Date: Sun Sep 5 13:37:56 2021 +0100 + +Obtain correct value of is_64 and is_prefetchable PCI device fields + +Correct setting of the is_64 and is_prefetchable pci_device fields in +pci_device_linux_sysfs_probe(). +The pci_device struct defines is_64 and is_prefetchable as single bits, +but the previous code was attempting to store the result of a bit-masked +field in a single bit which always resulted in is_64 and is_prefetchable +being zero regardless of the actual capabilities of the PCI device. + +Fixes: #15 + +Signed-off-by: Chester Gillon + +commit 28d6dd72e5d6fa907dbccd310cc516e7012a60bd +Author: Alan Coopersmith +Date: Sat Apr 2 16:00:56 2022 -0700 + +gitlab CI: add a basic build test for both autotools and meson + +Signed-off-by: Alan Coopersmith + +commit 465aecdce47040a211fddc29186a4b1aa2ad5648 +Author: Alan Coopersmith +Date: Sat Apr 2 15:27:10 2022 -0700 + +meson: install man page in mandir/man1/, not mandir/1/ + +But don't install it by default, since neither meson nor autotools +installs the scanpci program by default + +Signed-off-by: Alan Coopersmith + +commit 5cf85c28ad5f0811d53e5d70eac384dfe8e86cd6 +Author: Alan Coopersmith +Date: Sat Apr 2 14:54:06 2022 -0700 + +Fix spelling/wording issues + +Found by using: +codespell --builtin clear,rare,usage,informal,code,names + +Signed-off-by: Alan Coopersmith + +commit 9ad16d4da14905abfac50e41105dd1ceba877b07 +Author: Alan Coopersmith +Date:
Update to xterm 375
374
-#define XTERM_DATE2022-10-10
+#define XTERM_PATCH 375
+#define XTERM_DATE2022-10-23
#ifndef __vendorversion__
#define __vendorversion__ "XTerm/OpenBSD"
Index: xterm.appdata.xml
===
RCS file: /cvs/xenocara/app/xterm/xterm.appdata.xml,v
retrieving revision 1.10
diff -u -p -u -r1.10 xterm.appdata.xml
--- xterm.appdata.xml 7 Nov 2022 11:15:27 - 1.10
+++ xterm.appdata.xml 7 Nov 2022 12:13:03 -
@@ -35,7 +35,7 @@
terminal
-
+
https://invisible-island.net/xterm/
dic...@invisible-island.net
Index: xterm.h
===
RCS file: /cvs/xenocara/app/xterm/xterm.h,v
retrieving revision 1.52
diff -u -p -u -r1.52 xterm.h
--- xterm.h 7 Nov 2022 11:15:27 - 1.52
+++ xterm.h 7 Nov 2022 12:13:03 -
@@ -1,4 +1,4 @@
-/* $XTermId: xterm.h,v 1.918 2022/10/06 19:48:28 tom Exp $ */
+/* $XTermId: xterm.h,v 1.919 2022/10/23 13:37:56 tom Exp $ */
/*
* Copyright 1999-2021,2022 by Thomas E. Dickey
@@ -1009,7 +1009,7 @@ extern Bool CheckBufPtrs (TScreen * /* s
extern Bool set_cursor_gcs (XtermWidget /* xw */);
extern char * vt100ResourceToString (XtermWidget /* xw */, const char * /*
name */);
extern int VTInit (XtermWidget /* xw */);
-extern void FindFontSelection (XtermWidget /* xw */, const char * /* atom_name
*/, Bool /* justprobe */);
+extern Bool FindFontSelection (XtermWidget /* xw */, const char * /* atom_name
*/, Bool /* justprobe */);
extern void HideCursor (XtermWidget /* xw */);
extern void RestartBlinking(XtermWidget /* xw */);
extern void ShowCursor (XtermWidget /* xw */);
Index: xterm.log.html
===
RCS file: /cvs/xenocara/app/xterm/xterm.log.html,v
retrieving revision 1.52
diff -u -p -u -r1.52 xterm.log.html
--- xterm.log.html 7 Nov 2022 11:15:27 - 1.52
+++ xterm.log.html 7 Nov 2022 12:13:04 -
@@ -30,7 +30,7 @@
* sale, use or other dealings in this Software without prior written*
* authorization.*
*
- $XTermId: xterm.log.html,v 1.2447 2022/10/11 00:04:21 tom Exp $
+ $XTermId: xterm.log.html,v 1.2453 2022/10/24 00:25:20 tom Exp $
-->
@@ -70,6 +70,8 @@
CHANGELOG).
+Patch #375 - 2022/10/23
+
Patch #374 - 2022/10/10
Patch #373 - 2022/09/25
@@ -1024,6 +1026,23 @@
Patch #2 - 1996/1/7
Patch #1 - 1996/1/6
+
+
+ Patch #375 -
+ 2022/10/23
+
+
+improve error-recovery when setting a bitmap font for the
+VT100 window, e.g., in case OSC50 failed,
+restoring the most recent valid font so that a subsequent
+OSC50 reports this correctly (report by David
+Leadbeater).
+
+exclude MC_XDG_OPEN from environment variables
+trimmed on startup (report by Gabor Hauzer).
+
+check for null pointer in isSelect() (report
+by Column Paget).
Patch #374 -
Index: package/xterm.spec
===
RCS file: /cvs/xenocara/app/xterm/package/xterm.spec,v
retrieving revision 1.35
diff -u -p -u -r1.35 xterm.spec
--- package/xterm.spec 7 Nov 2022 11:15:27 - 1.35
+++ package/xterm.spec 7 Nov 2022 12:13:04 -
@@ -1,11 +1,11 @@
-# $XTermId: xterm.spec,v 1.151 2022/09/27 08:18:41 tom Exp $
+# $XTermId: xterm.spec,v 1.152 2022/10/21 00:45:30 tom Exp $
Summary: X terminal emulator (development version)
%global my_middle xterm
%global my_suffix -dev
%global fullname %{my_middle}%{my_suffix}
%global my_class XTermDev
Name: %{fullname}
-Version: 374
+Version: 375
Release: 1
License: X11
Group: User Interface/X
Index: package/debian/changelog
===
RCS file: /cvs/xenocara/app/xterm/package/debian/changelog,v
retrieving revision 1.36
diff -u -p -u -r1.36 changelog
--- package/debian/changelog7 Nov 2022 11:15:27 - 1.36
+++ package/debian/changelog7 Nov 2022 12:13:04 -
@@ -1,3 +1,9 @@
+xterm-dev (375) unstable; urgency=low
+
+ * maintenance updates
+
+ -- Thomas E. Dickey Thu, 20 Oct 2022 20:45:30
-0400
+
xterm-dev (374) unstable; urgency=low
* maintenance updates
Index: package/freebsd/Makefile
===
RCS file: /cvs/xenocara/app/xterm/package/freebsd/Makefile,v
retrieving revision 1.25
diff -u -p -u -r1.25 Makefile
--- package/freebsd/Makefile7 Nov 2022 11:15:27 - 1.25
+++ package/freebsd/Makefile7 Nov 2022 12:13:04 -
@@ -1,4 +1,4 @@
-# $XTermId: Makefile,v 1.95 2022/09/27 08:18:41 tom Exp $
+# $XTermId: Makefile,v 1.96 2022/10/21 00:45:30 tom Exp $
# $FreeBSD: head/x11/xterm/Makefile 492827 2019-02-13 06:43:36Z ehaupt $
# This is adapted from the FreeBSD port, installing as "xterm-dev" with
@@ -7,7 +7,7 @@
# and "make makesum".
PORTNAME= xterm
-PORTVERSION= 374
+PORTVERSION= 375
CATEGORIES=x11
MASTER_SITES= ftp://ftp.invisible-island.net/xterm/:src1 \
https://invisible-mirror.net/archives/xterm/:src1
Index: package/pkgsrc/Makefile
===
RCS file: /cvs/xenocara/app/xterm/package/pkgsrc/Makefile,v
retrieving revision 1.7
diff -u -p -u -r1.7 Makefile
--- package/pkgsrc/Makefile 7 Nov 2022 11:15:28 - 1.7
+++ package/pkgsrc/Makefile 7 Nov 2022 12:13:04 -
@@ -1,6 +1,6 @@
# $NetBSD: Makefile,v 1.117 2018/03/12 11:18:00 wiz Exp $
-DISTNAME= xterm-374
+DISTNAME= xterm-375
PKGREVISION= 1
CATEGORIES=x11
MASTER_SITES= ftp://ftp.invisible-island.net/xterm/
--
Matthieu Herrb
libX11 patch for X*IfEvent() API issues
@@ XPeekIfEvent (
unsigned long qe_serial = 0;
LockDisplay(dpy);
+dpy->in_ifevent = True;
prev = NULL;
while (1) {
for (qelt = prev ? prev->next : dpy->head;
@@ -63,6 +64,7 @@ XPeekIfEvent (
_XStoreEventCookie(dpy, );
*event = copy;
}
+dpy->in_ifevent = False;
UnlockDisplay(dpy);
return 0;
}
Index: src/locking.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libX11/src/locking.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 locking.c
--- src/locking.c 28 Nov 2020 14:39:48 - 1.8
+++ src/locking.c 1 Nov 2022 09:21:35 -
@@ -455,6 +455,32 @@ static void _XDisplayLockWait(
static void _XLockDisplay(
Display *dpy
XTHREADS_FILE_LINE_ARGS
+);
+
+static void _XIfEventLockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
+)
+{
+/* assert(dpy->in_ifevent); */
+}
+
+static void _XIfEventUnlockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
+)
+{
+if (dpy->in_ifevent)
+return;
+
+dpy->lock_fns->lock_display = _XLockDisplay;
+dpy->lock_fns->unlock_display = _XUnlockDisplay;
+UnlockDisplay(dpy);
+}
+
+static void _XLockDisplay(
+Display *dpy
+XTHREADS_FILE_LINE_ARGS
)
{
#ifdef XTHREADS
@@ -478,6 +504,10 @@ static void _XLockDisplay(
#endif
_XIDHandler(dpy);
_XSeqSyncFunction(dpy);
+if (dpy->in_ifevent) {
+dpy->lock_fns->lock_display = _XIfEventLockDisplay;
+ dpy->lock_fns->unlock_display = _XIfEventUnlockDisplay;
+}
}
/*
--
Matthieu Herrb
Re: [please test] pvclock(4): fix several bugs
PCI-PCI" rev 0x00 pci7 at ppb6 bus 7 ppb7 at pci5 dev 3 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci8 at ppb7 bus 8 ppb8 at pci5 dev 4 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci9 at ppb8 bus 9 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 ahci0: port 1: 1.5Gb/s scsibus2 at ahci0: 32 targets cd0 at scsibus2 targ 1 lun 0: removable ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 16 iic0 at ichiic0 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhidev0 at uhub1 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" rev 2.00/0.00 addr 2 uhidev0: iclass 3/0 ums0 at uhidev0: 3 buttons, Z dir wsmouse1 at ums0 mux 0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (b581cd31c0dbf4dd.a) swap on sd0b dump on sd0b -- Matthieu Herrb
libX11: disable thread safety constructor in 1.18.1
Hi again, So libX11 1.8.1 introduced a constructor to call XInitThreads(3) unconditionnaly at library load time, to make sure all multithreaded X applications would have correct locks around Xlib calls. Of course this behaviour change also exposes some bugs in existing code. A first one was found and fixed in xfsettingsd, the XFCE settings daemon. There is a 2nd one in x11/fvwm2 and x11/fvwm3 which is more complex to fix. I've sent patches to ports@ but I'm not confident that they are correct. So I propose that for OpenBSD 7.2 this change gets reverted in libX11. This is done with the patch below. Apply in /usr/xenocara/lib/libX11 and rebuild xenocara, following instructions in release(8). Ok, comments ? Index: Makefile.bsd-wrapper === RCS file: /cvs/OpenBSD/xenocara/lib/libX11/Makefile.bsd-wrapper,v retrieving revision 1.28 diff -u -p -u -r1.28 Makefile.bsd-wrapper --- Makefile.bsd-wrapper25 Apr 2022 19:26:17 - 1.28 +++ Makefile.bsd-wrapper26 Aug 2022 05:31:15 - @@ -14,6 +14,7 @@ SHARED_LIBS= X11 18.0 X11_xcb 2.0 CONFIGURE_ARGS= --enable-tcp-transport --enable-unix-transport --enable-ipv6 \ --disable-composecache \ + --disable-thread-safety-constructor \ --without-xmlto --without-fop --without-xsltproc .include -- Matthieu Herrb
xterm at 30bpp with TrueType fonts regression
RGB(name,shift) \
+ ((unsigned long)(name << xw->rgb_shifts[shift]) \
+& xw->visInfo->name ##_mask)
+MyPixel result = (MyPixel) (nRGB(red, 0) | nRGB(green, 1) | nRGB(blue, 2));
return (int) result;
}
static void
formatDirectColor(char *target, XtermWidget xw, unsigned value)
{
-Pixel result[3];
-
-#define getRGB(name, shift) \
-do { \
- result[shift] = value & xw->visInfo->name ## _mask; \
- result[shift] >>= xw->rgb_shifts[shift]; \
- if (xw->rgb_widths[shift] < 8) \
- result[shift] <<= (int) (8 - xw->rgb_widths[shift]); \
-} while(0)
-
-getRGB(red, 0);
-getRGB(green, 1);
-getRGB(blue, 2);
-
-#undef getRGB
-
-sprintf(target, "%lu:%lu:%lu", result[0], result[1], result[2]);
+#define fRGB(name, shift) \
+ (value & xw->visInfo->name ## _mask) >> xw->rgb_shifts[shift]
+sprintf(target, "%lu:%lu:%lu", fRGB(red, 0), fRGB(green, 1), fRGB(blue,
2));
}
#endif /* OPT_DIRECT_COLOR */
@@ -3600,6 +3697,7 @@
if (AllowColorOps(xw, ecGetColor)) {
XColor color;
+ Colormap cmap = xw->core.colormap;
char buffer[80];
/*
@@ -3611,7 +3709,7 @@
GetOldColors(xw);
color.pixel = xw->work.oldColors->colors[ndx];
- (void) QueryOneColor(xw, );
+ XQueryColor(TScreenOf(xw)->display, cmap, );
sprintf(buffer, "%d;rgb:%04x/%04x/%04x", i + 10,
color.red,
color.green,
@@ -3752,6 +3850,8 @@
(void) code;
TRACE(("ResetColorsRequest code=%d\n", code));
+
+#if OPT_COLOR_RES
if (GetOldColors(xw)) {
ScrnColors newColors;
const char *thisName;
@@ -3777,6 +3877,7 @@
}
result = True;
}
+#endif
return result;
}
@@ -6974,9 +7075,7 @@
XtPointer client_data GCC_UNUSED,
XtPointer call_data GCC_UNUSED)
{
-TRACE(("die_callback client=%p, call=%p\n",
- (void *) client_data,
- (void *) call_data));
+TRACE(("die_callback %p\n", die_callback));
TRACE_SM_PROPS();
NormalExit();
}
@@ -7186,7 +7285,7 @@
}
static int
-insertFontParams(XtermWidget xw, int *targetp, Bool first)
+insertFontParams(XtermWidget xw, int *targetp, Boolean first)
{
int changed = 0;
int n;
Index: ptyx.h
===
RCS file: /cvs/OpenBSD/xenocara/app/xterm/ptyx.h,v
retrieving revision 1.51
diff -u -r1.51 ptyx.h
--- ptyx.h 25 Apr 2022 19:20:37 - 1.51
+++ ptyx.h 2 Sep 2022 09:58:21 -
@@ -552,6 +552,10 @@
#define OPT_COLOR_CLASS 1 /* true if xterm uses separate color-resource
classes */
#endif
+#ifndef OPT_COLOR_RES
+#define OPT_COLOR_RES 1 /* true if xterm delays color-resource evaluation */
+#endif
+
#ifndef OPT_DABBREV
#define OPT_DABBREV 0 /* dynamic abbreviations */
#endif
Index: util.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xterm/util.c,v
retrieving revision 1.41
diff -u -r1.41 util.c
--- util.c 25 Apr 2022 19:20:38 - 1.41
+++ util.c 2 Sep 2022 09:58:21 -
@@ -2953,7 +2953,7 @@
if (!found) {
i = oldest;
color.pixel = pixel;
- (void) QueryOneColor(xw, );
+ XQueryColor(TScreenOf(xw)->display, xw->core.colormap, );
cache[i].color.color.red = color.red;
cache[i].color.color.green = color.green;
cache[i].color.color.blue = color.blue;
@@ -5075,10 +5075,10 @@
&& ((color >= 0)
|| (result != (Pixel) color))) {
XColor work;
- last_in = result;
work.pixel = result;
- if (QueryOneColor(xw, )) {
- DIM_IT(red);
+last_in = result;
+if (XQueryColor(TScreenOf(xw)->display, xw->core.colormap, ))
{
+ DIM_IT(red);
DIM_IT(green);
DIM_IT(blue);
if (allocateBestRGB(xw, )) {
Index: xterm.h
===
RCS file: /cvs/OpenBSD/xenocara/app/xterm/xterm.h,v
retrieving revision 1.50
diff -u -r1.50 xterm.h
--- xterm.h 25 Apr 2022 19:20:38 - 1.50
+++ xterm.h 2 Sep 2022 09:58:21 -
@@ -1180,7 +1180,7 @@
extern XtInputMask xtermAppPending (void);
extern XrmOptionDescRec * sortedOptDescs (XrmOptionDescRec *, Cardinal);
extern XtermWidget getXtermWidget (Widget /* w */);
-extern XVisualInfo *getVisualInfo (XtermWidget /* xw */);
+extern int getVisualInfo (XtermWidget /* xw */);
extern char *udk_lookup (XtermWidget /* xw */, int /* keycode */, int * /* len
*/);
extern char *xtermEnvEncoding (void);
extern char *xtermFindShell (char * /* leaf */, Bool /* warning */);
--
Matthieu Herrb
update: X server 21.1.4
ion 1.5
diff -u -p -u -r1.5 present_scmd.c
--- present/present_scmd.c 11 Nov 2021 09:03:14 - 1.5
+++ present/present_scmd.c 30 Aug 2022 17:15:39 -
@@ -158,6 +158,9 @@ present_scmd_get_crtc(present_screen_pri
if (!screen_priv->info)
return NULL;
+if (!screen_priv->info->get_crtc)
+return NULL;
+
return (*screen_priv->info->get_crtc)(window);
}
@@ -194,6 +197,9 @@ present_flush(WindowPtr window)
return;
if (!screen_priv->info)
+return;
+
+if (!screen_priv->info->flush)
return;
(*screen_priv->info->flush) (window);
Index: render/picture.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/render/picture.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 picture.c
--- render/picture.c11 Nov 2021 09:03:15 - 1.14
+++ render/picture.c30 Aug 2022 17:15:39 -
@@ -865,7 +865,7 @@ CreateSolidPicture(Picture pid, xRenderC
}
pPicture->id = pid;
-pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictSolidFill));
+pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(SourcePict));
if (!pPicture->pSourcePict) {
*error = BadAlloc;
free(pPicture);
@@ -896,7 +896,7 @@ CreateLinearGradientPicture(Picture pid,
}
pPicture->id = pid;
-pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictLinearGradient));
+pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(SourcePict));
if (!pPicture->pSourcePict) {
*error = BadAlloc;
free(pPicture);
@@ -936,7 +936,7 @@ CreateRadialGradientPicture(Picture pid,
}
pPicture->id = pid;
-pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictRadialGradient));
+pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(SourcePict));
if (!pPicture->pSourcePict) {
*error = BadAlloc;
free(pPicture);
@@ -979,7 +979,7 @@ CreateConicalGradientPicture(Picture pid
}
pPicture->id = pid;
-pPicture->pSourcePict = (SourcePictPtr)
malloc(sizeof(PictConicalGradient));
+pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(SourcePict));
if (!pPicture->pSourcePict) {
*error = BadAlloc;
free(pPicture);
--
Matthieu Herrb
Re: update fontconfig to version 2.14.0
On Mon, Aug 15, 2022 at 11:12:20AM +0200, Matthieu Herrb wrote: > Hi, > > the patch below updates fontconfig to version 2.14.0. > > It contains bug fixes but also a few changes in the default config > files. So the way you favourite application displays them may change > (again). > > There are no visible API/ABI changes. > > Also note that the cache format version was bumped. You may want to > prune old cache files (doas rm /var/cache/fontconfig/*.cache-7 as well > as rm ~/.cache/fontconfig/*.cache-7) at some point. > > Please test it (apply the patch to /usr/xenocara and rebuild xenocara > by following release(8). > > ok ? > ping ? -- Matthieu Herrb
Re: [matth...@openbsd.org: Re: xlock don't take my password anymore]
On Mon, Aug 29, 2022 at 09:08:26AM +0200, Greg Steuck wrote:
> Greg Steuck writes:
>
> Matthieu> + authok = priv_pw_check(user, style, pass);
>
> I suspect your original patch may have swapped the arguments. The
> password should go before style.
Oops you're right thanks.
>
> What do you thing about this patch (tested locally, but I don't have
> style):
Works for me. I also cannot check style easyly (otherwise I would
probably have caught the mistake, but I've check with
and without : in the password).
>
> diff --git a/app/xlockmore/xlock/passwd.c b/app/xlockmore/xlock/passwd.c
> index 914db414f..23ba9043e 100644
> --- a/app/xlockmore/xlock/passwd.c
> +++ b/app/xlockmore/xlock/passwd.c
> @@ -1278,17 +1278,15 @@ checkPasswd(char *buffer)
>
> #ifdef USE_PRIVSEP
> char*pass;
> - char*style;
>
> /* buffer can be in the form style:pass */
> if ((pass = strchr(buffer, ':')) != NULL) {
> - *pass++ = '\0';
> - style = buffer;
> - } else {
> - pass = buffer;
> - style = NULL;
> + *pass++ = '\0';
> + if (priv_pw_check(user, pass, buffer))
> + return True;
> + *--pass = ':';
> }
> - return priv_pw_check(user, pass, style);
> + return priv_pw_check(user, buffer, NULL);
> #elif defined(BSD_AUTH)
> char *pass;
> char *style;
> --
> 2.37.2
>
--
Matthieu Herrb
[matth...@openbsd.org: Re: xlock don't take my password anymore]
ok ?
(although I didn't get an answer from Jean-Michel yet, I'm quite sure
the issue is real and the fix correct).
- Forwarded message from Matthieu Herrb -
Date: Tue, 23 Aug 2022 11:08:28 +0200
From: Matthieu Herrb
To: BESSOT Jean-Michel
Cc: b...@openbsd.org
Subject: Re: xlock don't take my password anymore
On Sun, Aug 14, 2022 at 01:05:49PM +0200, BESSOT Jean-Michel wrote:
> Hello
>
> Xlock do not take my password since my last snapshot update (well there is
> time since the one before).
>
> I use a bépo keyboard so kdb is set with fr dvorak
>
Hi,
can you try the patch below (already tested by Denis, who provided a
hint on the issue) ?
(get the xenocara tree, apply in app/xlockmore using patch(1) and
rebuild xlockmore by running the following commands in
/usr/xenocara/app/xlockmore :
doas make -f Makefile.bsd-wrapper obj
doas make -f Makefile.bsd-wrapper build
Index: xlock/passwd.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xlockmore/xlock/passwd.c,v
retrieving revision 1.3
diff -u -r1.3 passwd.c
--- xlock/passwd.c 26 Jun 2022 14:09:51 - 1.3
+++ xlock/passwd.c 22 Aug 2022 21:35:49 -
@@ -1279,16 +1279,19 @@
#ifdef USE_PRIVSEP
char*pass;
char*style;
+ int authok;
/* buffer can be in the form style:pass */
if ((pass = strchr(buffer, ':')) != NULL) {
*pass++ = '\0';
style = buffer;
- } else {
- pass = buffer;
- style = NULL;
- }
- return priv_pw_check(user, pass, style);
+ authok = priv_pw_check(user, style, pass);
+ *--pass = ':';
+ } else
+ authok = 0;
+ pass = buffer;
+ style = NULL;
+ return (authok || priv_pw_check(user, pass, style));
#elif defined(BSD_AUTH)
char *pass;
char *style;
--
Matthieu Herrb
- End forwarded message -
--
Matthieu Herrb
Re: remove twm(1) from xenocara ?
On Sun, Jul 17, 2022 at 10:38:53AM +0200, Matthieu Herrb wrote: > Hi, > > twm(1) is the original X11R5 window manager. It has not been update to > support any of the extended window manager hints and still only knows > how to handle the legacy bitmapped fonts rendered by the X server. > > In ports we have x11/ctwm which, for people looking at legacy stuff, is > superior ihmo. > > I'm suggesting here to drop twm from xenocara (ie xbase). > > Anyone willing to keep it around is welcome to submit a port for it. Thanks for all the feedback. twm is going to stay. I'll update it soon. -- Matthieu Herrb
remove twm(1) from xenocara ?
Hi, twm(1) is the original X11R5 window manager. It has not been update to support any of the extended window manager hints and still only knows how to handle the legacy bitmapped fonts rendered by the X server. In ports we have x11/ctwm which, for people looking at legacy stuff, is superior ihmo. I'm suggesting here to drop twm from xenocara (ie xbase). Anyone willing to keep it around is welcome to submit a port for it. ok ? -- Matthieu Herrb
Re: patch: xlock: unveil issue: login.conf
On Wed, Jul 06, 2022 at 09:13:29AM +0200, Sebastien Marie wrote:
> Hi,
>
> I am currently debugging some unveil issues reported when process accounting
> in
> enabled (see acct(2)).
>
> xlock is currently doing some unveil(2) violation:
>
> $ lastcomm | grep U
> xlock-FU semarie __
> 0.00 secs Wed Jul 6 07:13 (1:21:00.00)
>
> I tracked them to be related to "login.conf" access (due to auth_userokay(3)
> usage).
>
> The diff belows adds all "login.conf" related files to readable files by the
> process:
>
> - /etc/login.conf
> - /etc/login.conf.db
> - /etc/login.conf.d/*
>
ok matthieu@ (confused not to have thought about this).
>
> diff 7f83513b277728e78b173796466b04c2373f0b55
> /home/semarie/repos/openbsd/xenocara
> blob - 7fdf4f11d18bdb1bab730f008ef7ea10e0e482ca
> file + app/xlockmore/xlock/privsep.c
> --- app/xlockmore/xlock/privsep.c
> +++ app/xlockmore/xlock/privsep.c
> @@ -255,8 +255,14 @@ priv_init(gid_t gid)
>
> imsg_init(_ibuf, socks[0]);
>
> + if (unveil(_PATH_LOGIN_CONF, "r") == -1)
> + err(1, "unveil %s", _PATH_LOGIN_CONF);
> + if (unveil(_PATH_LOGIN_CONF ".db", "r") == -1)
> + err(1, "unveil %s.db", _PATH_LOGIN_CONF);
> + if (unveil(_PATH_LOGIN_CONF_D, "r") == -1)
> + err(1, "unveil %s", _PATH_LOGIN_CONF_D);
> if (unveil(_PATH_AUTHPROGDIR, "rx") == -1)
> - err(1, "unveil");
> + err(1, "unveil %s", _PATH_AUTHPROGDIR);
> if (pledge("stdio rpath getpw proc exec", NULL) == -1)
> err(1, "pledge");
>
>
> With it, I don't have unveil(2) violation anymore when running xlock(1).
>
> Comments or OK ?
> --
> Sebastien Marie
>
--
Matthieu Herrb
Re: proposed xterm changes
On Wed, May 18, 2022 at 12:51:15PM -0600, Theo de Raadt wrote: > Based upon the discussion of xterm a couple of days ago, I have been > working on a couple changes to reduce the privs of xterm in general, > by reducing the scope of the utmp egid by opening utmp early, improving > the unveil calls to match, and then tightening the pledge. > > Additionally, some file-related functions not used by our xterm because > of feature disabling, are become hidden behind #ifdef, and I update the > manual page. > > It's a jumbo diff, for testing in snaps, to see if there is any fallout. > I tried to tighten a bunch of other really ugly things I found (nested > select and poll calls, oh boy, with short-cut exit paths to workaround > the introduced problems). But, for now, this is how far I think we can > go in first few steps. > > As I said, this is in snaps. Hi, Ok for the source changes. The balance between restricting functionalities and pushing users toward using even less secure applications from ports seems reasonable to me here. For the man page, I'd prefer if we add information on the disabled features in the 'OPENBSD SPECIFICS' section at the end for consistency with how other changes are documented, like below. Index: xterm.man === RCS file: /cvs/OpenBSD/xenocara/app/xterm/xterm.man,v retrieving revision 1.57 diff -u -p -u -r1.57 xterm.man --- xterm.man 25 Apr 2022 19:20:38 - 1.57 +++ xterm.man 22 May 2022 09:08:37 - @@ -8977,3 +8977,7 @@ entry for xterm defines the capability as \fB^?\fP. .PP The u\*n and koi8r\*n shell scripts are not provided by OpenBSD. +.PP +The following functions are disabled on OpenBSD: +\fBexec\-formatted()\fP, \fBexec\-selectable()\fP and +\fBspawn\-new\-terminal()\fP. -- Matthieu Herrb
Re: UPDATE: xterm 372
On Sun, Mar 27, 2022 at 10:54:43AM +0200, Matthieu Herrb wrote: > Hi, > > the patch below updates xterm to version 372. Please test, especially > if you use or depend on less common features, and report any issues. > Note that the new status line code is not enabled in Xenocara. > > to apply: > > cd /usr/xenocara/app/xterm > patch -p0 -E < this mail > doas make obj > doas make build > > Comments, ok ? > Ping -- Matthieu Herrb
building a -current kernel fails on 7.0
Hi, I'm not sure if upgrade by building the system from sources is supposed to be supported or not. Anyways, for some reason I tried to build à -current kernel on a 7.0 system, but, unless I've some other stuff set wrong it fails: error: unknown warning option '-Wno-unused-but-set-variablé; did you mean '-Wno-unused-const-variablé? [-Werror,-Wunknown-warning-option] *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:1955 'assym.h') -- Matthieu Herrb
dhcpd(8) man page correction : synchronisation
Hi, It looks to me that the -Y option is used to specify the destination to which to send synchronisation messages (not where to receive them, this is -y). Index: dhcpd.8 === RCS file: /cvs/OpenBSD/src/usr.sbin/dhcpd/dhcpd.8,v retrieving revision 1.29 diff -u -p -u -r1.29 dhcpd.8 --- dhcpd.8 29 Aug 2017 08:20:18 - 1.29 +++ dhcpd.8 22 Feb 2022 15:45:20 - @@ -252,7 +252,7 @@ the limited broadcast address (255.255.2 .It Fl Y Ar synctarget Add target .Ar synctarget -to receive synchronisation messages. +to send synchronisation messages. .Ar synctarget can be either an IPv4 address for unicast messages or a network interface name followed optionally by a colon and a numeric TTL -- Matthieu Herrb
Xserver 21.1 mode selection fixes
Hi,
steven@ reported that, using xf68-video-nv X server 21.1 is dumping
core on startup.
The following patch fixes it. While here I also fixed another bug on
drivers that don't intialize a private structure.
If you're using one older graphics card (ie not inteldrm or radeondrm
based), please test.
These are also:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/807
and https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/808
ok ?
Index: hw/xfree86/modes/xf86Crtc.h
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h,v
retrieving revision 1.15
diff -u -p -u -r1.15 xf86Crtc.h
--- hw/xfree86/modes/xf86Crtc.h 11 Nov 2021 09:10:04 - 1.15
+++ hw/xfree86/modes/xf86Crtc.h 4 Dec 2021 17:50:33 -
@@ -837,11 +837,11 @@ extern _X_EXPORT int xf86CrtcConfigPriva
static _X_INLINE xf86OutputPtr
xf86CompatOutput(ScrnInfoPtr pScrn)
{
-xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
+xf86CrtcConfigPtr config;
if (xf86CrtcConfigPrivateIndex == -1)
-return NULL;
-
+return NULL;
+config = XF86_CRTC_CONFIG_PTR(pScrn);
if (config->compat_output < 0)
return NULL;
return config->output[config->compat_output];
Index: hw/xfree86/modes/xf86Modes.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Modes.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 xf86Modes.c
--- hw/xfree86/modes/xf86Modes.c11 Nov 2021 09:03:08 - 1.12
+++ hw/xfree86/modes/xf86Modes.c5 Dec 2021 18:20:52 -
@@ -803,10 +803,14 @@ xf86CVTMode(int HDisplay, int VDisplay,
{
struct libxcvt_mode_info *libxcvt_mode_info;
DisplayModeRec *Mode = xnfcalloc(1, sizeof(DisplayModeRec));
+char *tmp;
libxcvt_mode_info =
libxcvt_gen_mode_info(HDisplay, VDisplay, VRefresh, Reduced,
Interlaced);
+XNFasprintf(, "%dx%d", HDisplay, VDisplay);
+Mode->name = tmp;
+
Mode->VDisplay = libxcvt_mode_info->vdisplay;
Mode->HDisplay = libxcvt_mode_info->hdisplay;
Mode->Clock = libxcvt_mode_info->dot_clock;
--
Matthieu Herrb
Re: fix for X crash with the radeon(4) driver
On Sun, Nov 14, 2021 at 05:25:32PM +0100, Matthieu Herrb wrote:
> Hi,
>
> after the upgrade to X server 21.1.1, some people reported crashes in
> the radeon driver when using xrandr(1) or a similar utility.
>
> If you are seeing these crashes, please test the patch below (copied
> for a similar "fix" in the amdgpu(4) driver)
>
> get the xenocara sources if you don't alreaady, apply the patch in the
> driver/xf86-video-ati directory and there run (as root)
>
> make -f Makefile.bsd-wrapper obj
> make -f Makefile.bsd-wrapper build
>
> Then restart xenodm and try the xrandr invocation again.
>
> Please report success or failure.
Ping. .
Anyone tried this patch ?
This is not the bug that happens semi-randomly on mouse button events,
but still, if you have a Radeon card and are using xrandr(1) to setup
multiple monitors, you're likely to hit that bug
>
> Index: src/radeon_kms.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/driver/xf86-video-ati/src/radeon_kms.c,v
> retrieving revision 1.21
> diff -u -p -u -r1.21 radeon_kms.c
> --- src/radeon_kms.c 11 Nov 2021 09:30:14 - 1.21
> +++ src/radeon_kms.c 14 Nov 2021 16:16:08 -
> @@ -931,6 +931,13 @@ radeon_dirty_update(ScrnInfoPtr scrn)
> }
> }
>
> +static void
> +radeonSourceValidate(DrawablePtr draw, int x, int y, int w, int h,
> + unsigned int subWindowMode)
> +{
> +}
> +
> +
>
> Bool
> radeon_scanout_do_update(xf86CrtcPtr xf86_crtc, int scanout_id,
> @@ -993,7 +1000,7 @@ radeon_scanout_do_update(xf86CrtcPtr xf8
> SetPicturePictFilter(src, xf86_crtc->filter, xf86_crtc->params,
>xf86_crtc->nparams);
>
> - pScreen->SourceValidate = NULL;
> + pScreen->SourceValidate = radeonSourceValidate;
> CompositePicture(PictOpSrc,
>src, NULL, dst,
>extents.x1, extents.y1, 0, 0, extents.x1,
>
>
> --
> Matthieu Herrb
--
Matthieu Herrb
Re: possible fix for Xorg 21.1.1 crashes
On Tue, Nov 16, 2021 at 11:26:40PM +0100, Matthieu Herrb wrote:
> Hi,
>
> I think I found the bug that causes crashes in X for some people.
>
> If X started crashing since you upgraded to the last snapshots, can
> you try the patch below ?
>
> get /usr/xenocara from CVS then
>
> cd /usr/xenocara/xserver
> patch -p0 -E < /this/patch
> doas make -f Makefile.bsd-wrapper obj
> doas make -f Makefile.bsd-wrapper build
>
> And restart the X server, for example :
> doas rcctl restart xenodm
>
Here's a more complete fix. Ust this one instead, sorry.
Index: Xi/exevents.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/Xi/exevents.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 exevents.c
--- Xi/exevents.c 11 Nov 2021 09:03:02 - 1.24
+++ Xi/exevents.c 16 Nov 2021 23:15:44 -
@@ -1901,7 +1901,7 @@ ProcessDeviceEvent(InternalEvent *ev, De
* nested) to clients. */
if (event->source_type == EVENT_SOURCE_FOCUS)
return;
-if (!grab && CheckDeviceGrabs(device, event, 0))
+if (!grab && CheckDeviceGrabs(device, ev, 0))
return;
break;
case ET_KeyRelease:
@@ -1914,7 +1914,7 @@ ProcessDeviceEvent(InternalEvent *ev, De
if (b->map[key] == 0) /* there's no button 0 */
return;
event->detail.button = b->map[key];
-if (!grab && CheckDeviceGrabs(device, event, 0)) {
+if (!grab && CheckDeviceGrabs(device, ev, 0)) {
/* if a passive grab was activated, the event has been sent
* already */
return;
Index: dix/events.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/dix/events.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 events.c
--- dix/events.c11 Nov 2021 09:03:03 - 1.22
+++ dix/events.c16 Nov 2021 23:15:44 -
@@ -1191,7 +1191,7 @@ EnqueueEvent(InternalEvent *ev, DeviceIn
}
}
-eventlen = event->length;
+eventlen = sizeof(InternalEvent);
qe = malloc(sizeof(QdEventRec) + eventlen);
if (!qe)
@@ -1319,7 +1319,7 @@ ComputeFreezes(void)
syncEvents.replayDev = (DeviceIntPtr) NULL;
-if (!CheckDeviceGrabs(replayDev, >device_event,
+if (!CheckDeviceGrabs(replayDev, event,
syncEvents.replayWin)) {
if (IsTouchEvent(event)) {
TouchPointInfoPtr ti =
@@ -3027,7 +3027,7 @@ BOOL
ActivateFocusInGrab(DeviceIntPtr dev, WindowPtr old, WindowPtr win)
{
BOOL rc = FALSE;
-DeviceEvent event;
+InternalEvent event;
if (dev->deviceGrab.grab) {
if (!dev->deviceGrab.fromPassiveGrab ||
@@ -3042,16 +3042,16 @@ ActivateFocusInGrab(DeviceIntPtr dev, Wi
if (win == NoneWin || win == PointerRootWin)
return FALSE;
-event = (DeviceEvent) {
-.header = ET_Internal,
-.type = ET_FocusIn,
-.length = sizeof(DeviceEvent),
-.time = GetTimeInMillis(),
-.deviceid = dev->id,
-.sourceid = dev->id,
-.detail.button = 0
+event = (InternalEvent) {
+.device_event.header = ET_Internal,
+.device_event.type = ET_FocusIn,
+.device_event.length = sizeof(DeviceEvent),
+.device_event.time = GetTimeInMillis(),
+.device_event.deviceid = dev->id,
+.device_event.sourceid = dev->id,
+.device_event.detail.button = 0
};
-rc = (CheckPassiveGrabsOnWindow(win, dev, (InternalEvent *) , FALSE,
+rc = (CheckPassiveGrabsOnWindow(win, dev, , FALSE,
TRUE) != NULL);
if (rc)
DoEnterLeaveEvents(dev, dev->id, old, win, XINotifyPassiveGrab);
@@ -3068,7 +3068,7 @@ static BOOL
ActivateEnterGrab(DeviceIntPtr dev, WindowPtr old, WindowPtr win)
{
BOOL rc = FALSE;
-DeviceEvent event;
+InternalEvent event;
if (dev->deviceGrab.grab) {
if (!dev->deviceGrab.fromPassiveGrab ||
@@ -3080,16 +3080,16 @@ ActivateEnterGrab(DeviceIntPtr dev, Wind
(*dev->deviceGrab.DeactivateGrab) (dev);
}
-event = (DeviceEvent) {
-.header = ET_Internal,
-.type = ET_Enter,
-.length = sizeof(DeviceEvent),
-.time = GetTimeInMillis(),
-.deviceid = dev->id,
-.sourceid = dev->id,
-.detail.button = 0
+event = (InternalEvent) {
+.device_event.header = ET_Internal,
+.device_event.type = ET_Enter,
+.device_event.length = sizeof(DeviceEvent),
+.device_event.time = GetTimeInMillis(),
+.device_event.deviceid = dev->id,
+.device_event.sourceid = dev->id,
+.device_event.detail.button = 0
};
-rc = (CheckPassiveGrabsOnWindow(win, dev, (
possible fix for Xorg 21.1.1 crashes
heckPassiveGrabsOnWindow(pWin, device, (InternalEvent *) event,
+if (CheckPassiveGrabsOnWindow(pWin, device, ievent,
sendCore, TRUE)) {
ret = TRUE;
goto out;
Index: include/dix.h
===
RCS file: /cvs/OpenBSD/xenocara/xserver/include/dix.h,v
retrieving revision 1.17
diff -u -p -u -r1.17 dix.h
--- include/dix.h 11 Nov 2021 09:03:13 - 1.17
+++ include/dix.h 16 Nov 2021 22:03:19 -
@@ -458,7 +458,7 @@ WindowHasNewCursor(WindowPtr /* pWin */
extern Bool
CheckDeviceGrabs(DeviceIntPtr /* device */ ,
- DeviceEvent * /* event */ ,
+ InternalEvent * /* event */ ,
WindowPtr /* ancestor */ );
extern void
--
Matthieu Herrb
fix for X crash with the radeon(4) driver
Hi,
after the upgrade to X server 21.1.1, some people reported crashes in
the radeon driver when using xrandr(1) or a similar utility.
If you are seeing these crashes, please test the patch below (copied
for a similar "fix" in the amdgpu(4) driver)
get the xenocara sources if you don't alreaady, apply the patch in the
driver/xf86-video-ati directory and there run (as root)
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper build
Then restart xenodm and try the xrandr invocation again.
Please report success or failure.
Index: src/radeon_kms.c
===
RCS file: /cvs/OpenBSD/xenocara/driver/xf86-video-ati/src/radeon_kms.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 radeon_kms.c
--- src/radeon_kms.c11 Nov 2021 09:30:14 - 1.21
+++ src/radeon_kms.c14 Nov 2021 16:16:08 -
@@ -931,6 +931,13 @@ radeon_dirty_update(ScrnInfoPtr scrn)
}
}
+static void
+radeonSourceValidate(DrawablePtr draw, int x, int y, int w, int h,
+unsigned int subWindowMode)
+{
+}
+
+
Bool
radeon_scanout_do_update(xf86CrtcPtr xf86_crtc, int scanout_id,
@@ -993,7 +1000,7 @@ radeon_scanout_do_update(xf86CrtcPtr xf8
SetPicturePictFilter(src, xf86_crtc->filter, xf86_crtc->params,
xf86_crtc->nparams);
- pScreen->SourceValidate = NULL;
+ pScreen->SourceValidate = radeonSourceValidate;
CompositePicture(PictOpSrc,
src, NULL, dst,
extents.x1, extents.y1, 0, 0, extents.x1,
--
Matthieu Herrb
X server updated to version 21.1.1
Hi, I've updated the X server in Xenocara to version 21.1.1, together with Freetype (2.11.0) and fontconfig 2.13.94. One of the visible change of this update is that some LCD panels now report their real physical dimensions to the X server, rather than just computing it based on a default resolution of 96dpi. This means that the actual DPI computed from these dimensions will change and impact the size of the displayed fonts. If your fonts have chanded sizes too much after the last snapshot update, you can add xrandr --dpi 96 in your ~/.xsession (or ~/.xinitrc) file to set the resolution manually to the previous default. You can also fiddle with the X resources (~/.Xresources ) to fix font sizes in invidual applications. Older X applications are more likely to mis-behave and need the global dpi fix. -- Matthieu Herrb
Re: xdpyinfo: can't load library 'libdmx.so.2.0'
On Wed, Sep 15, 2021 at 08:15:20AM +0200, Sebastien Marie wrote: > On Wed, Sep 15, 2021 at 05:11:12AM +, Renato Aguiar wrote: > > I noticed this after sysupgrading to latest snapshot: > > > > $ ldd /usr/X11R6/bin/xdpyinfo > > /usr/X11R6/bin/xdpyinfo: > > ld.so: xdpyinfo: can't load library 'libdmx.so.2.0' > > /usr/X11R6/bin/xdpyinfo: signal 9 > > > > It works fine after manually building and installing xdpyinfo from > > latest xenocara code. > > > > libdmx.so has been removed recently. From > xenocara/app/xdpyinfo/configure, dmx library could be detected as > build time. > > I suppose the host used to build the snapshots still has old dmx > library in path, and the build of xdpyinfo detected it and link to it, > whereas the library isn't in sets anymore. > I've just committed a fix to xdpyinfo build system to explicitely disable dmx support in that case. -- Matthieu Herrb
remove libdmx from Xenocara?
Hi, is anyone here using libdmx from Xenocara? Afaict, with the help of sqlports no port/package is using it, and it's also not used by anything built in xenocara. libdmx is the client part of the Xdmx system (distributed multi-screen X server, that make it possible to create a huge screen out of several X servers running on different machine). The server part has been disabled for years and is known to be broken even under Linux. -- Matthieu Herrb
Re: update xf86-video-amdgpu to latest git
On Thu, Jul 08, 2021 at 05:29:01PM +1000, Jonathan Gray wrote: > The latest xf86-video-amdgpu release was in 2019. > > xf86-video-amdgpu-19.1.0..origin/master Hi, Works so far here on my X395 (Vega Mobile 8) with -current. -- Matthieu Herrb
log reason when a packet causes pf to add an IP to a table ?
Hi I have rules like this one on the firewalls I manage: pass in on $in_if proto tcp from any to port ssh \ flags S/SA keep state \ (source-track rule, max-src-states 30, max-src-conn 20, \ max-src-conn-rate 15/30, overload flush global) block log from However some legitimate remote users get their addresses added to the ssh-bruteforce table from time to time. I'd like to be able to figure out the reason (ie which condtion triggers the overload). Is there a way to have it logged somewhere that I'm missing ? Thanks in avance, -- Matthieu Herrb
Re: update xterm to version 367
On Sat, Mar 27, 2021 at 10:22:15AM +0100, Matthieu Herrb wrote: > Patch #367 - 2021/03/26 > > ok ? comments ? Hi, I could use some actual test results. I'd like to commit the update. -- Matthieu Herrb
Re: xf86-input-ws: fix hotplugging usb mice on legacy-free machines
On Fri, Mar 26, 2021 at 03:41:41PM -0500, joshua stein wrote: > The X server's autoconfiguration probes each /dev/wsmouseN device > and if its WSMOUSEIO_GTYPE ioctl returns something like > WSMOUSE_TYPE_TOUCHPAD, xf86-input-ws attaches to that device > directly which causes the wsmouse device to detach from the mux. > This allows xinput to handle these special devices separately each > with their own configuration. > > The last part of the X server configuration loop is this: > > /* Add a default entry catching all other mux elements as "ws" */ > wscons_add_pointer(WSCONS_MOUSE_PREFIX, "ws", ATTR_POINTER); > > For any simple mice like a basic USB one, they will remain in the > mux and the wsmux ioctl handler will route WSMOUSEIO_GTYPE to the > first wsmouse device in the mux. xf86-input-ws will attach to > /dev/wsmouse and all USB mouse traffic will flow through that single > device properly, even if the mouse is unplugged and plugged back in > later. > > However, if X is started when there are no other mice attached to > the mux (because nothing is attached or because it already took the > non-simple devices out of the mux), WSMOUSEIO_GTYPE will fail and > xf86-input-ws will bail due to the bad ioctl response: > > [ 2459.571] (II) config/wscons: checking input device /dev/wsmouse > [ 2459.571] (II) Using input driver 'ws' for '/dev/wsmouse' > [ 2459.571] (**) /dev/wsmouse: always reports core events > [ 2459.571] (II) ws: /dev/wsmouse: debuglevel 0 > [ 2459.571] (**) Option "Device" "/dev/wsmouse" > [ 2459.571] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 > [ 2459.571] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 > [ 2459.571] (**) ws: /dev/wsmouse: associated screen: 0 > [ 2459.571] (EE) PreInit returned 2 for "/dev/wsmouse" > [ 2459.571] (II) UnloadModule: "ws" > > Later, if a USB mouse is attached while X is running, it sends its > data through the wsmouse mux but the X server isn't listening to it. > > To remedy this, make xf86-input-ws ignore a bad WSMOUSEIO_GTYPE > ioctl response if it's talking to the mux device, and just assume it > will be USB mouse traffic. This hasn't affected "legacy" laptops > because they often have a pms(4) port which remains the default > device in the wsmouse mux even if there isn't an actual mouse > attached to that port. > > (This doesn't solve the issue of a device like a umt(4) attached > after starting X not being treated as its own device because X > would need to open that device directly. That can't easily be > solved right now.) Hi, yes this makes sense and can help in some situations. I don't see any practical drawbacks. ok matthieu@ -- Matthieu Herrb
update xterm to version 367
Patch #367 - 2021/03/26 * add OSC 22 to allow programs to select different pointer cursor at runtime. * change configuration for no-return functions to use _Noreturn when it is available, because clang --analyze does not properly handle the gcc noreturn attribute. * add cursorTheme resource to provide a way to enable or disable the cursor theme feature. * modified CopyWait event retries to use shorter sleeps, to improve responsiveness (tmux #2556). * improve quoting/escaping in demo-scripts per shellcheck. * add resizeByPixel resource, to permit disabling window manager resizing-hints (patch by Tim Oehl). * corrected printOptsImmediate handling of alternate-screen (report by Abhijit Dasgupta). * update sample terminfo to more closely match ncurses. * add/improve limit-checks for Xlib calls (report by Roman Fiedler). * fix a typo in the help-message (report by Tomas Korbar). ok ? comments ? Index: MANIFEST === RCS file: /cvs/xenocara/app/xterm/MANIFEST,v retrieving revision 1.47 diff -u -p -u -r1.47 MANIFEST --- MANIFEST14 Feb 2021 09:14:06 - 1.47 +++ MANIFEST27 Mar 2021 09:21:21 - @@ -1,4 +1,4 @@ -MANIFEST for xterm-366, version xterm-366 +MANIFEST for xterm-367, version xterm-367 MANIFESTthis file 256colres.h resource-definitions for 256-color mode Index: NEWS === RCS file: /cvs/xenocara/app/xterm/NEWS,v retrieving revision 1.7 diff -u -p -u -r1.7 NEWS --- NEWS14 Feb 2021 09:14:06 - 1.7 +++ NEWS27 Mar 2021 09:21:21 - @@ -1,20 +1,23 @@ The NEWS file was generated from xterm.log.html, which serves as the changelog for xterm. -Patch #366 - 2021/02/10 +Patch #367 - 2021/03/26 - * correct a compiler-warning fix in patch #352 which allowed - sign-extension of coordinate values (report by "CismonX"). - * correct upper-limit for selection buffer, accounting for combining - characters (report/testcase by Tavis Ormandy). - * with alwaysHighlight true, xterm does not properly track focus. The - screen->select FOCUS flag remains always on, which prevents - bellIsUrgent from working, as the urgent WM_HINT flag is only set - in setXUrgency() when the window is not focused. Fix this by - updating screen->select in unselectwindow() regardless of the value - of always_highlight (patch by Jiri Bohac). - * improve fix for interaction between SRM and ENQ (report by Grant - Taylor). - * build-fix for --with-Xaw3dxft, needed when --with-toolbar is - omitted (report by Jimmy Olgeni, Emanuel Haupt). + * add OSC 22 to allow programs to select different pointer cursor at + runtime. + * change configuration for no-return functions to use _Noreturn when + it is available, because clang --analyze does not properly handle + the gcc noreturn attribute. + * add cursorTheme resource to provide a way to enable or disable the + cursor theme feature. + * modified CopyWait event retries to use shorter sleeps, to improve + responsiveness (tmux #2556). + * improve quoting/escaping in demo-scripts per shellcheck. + * add resizeByPixel resource, to permit disabling window manager + resizing-hints (patch by Tim Oehl). + * corrected printOptsImmediate handling of alternate-screen (report + by Abhijit Dasgupta). + * update sample terminfo to more closely match ncurses. + * add/improve limit-checks for Xlib calls (report by Roman Fiedler). + * fix a typo in the help-message (report by Tomas Korbar). Index: THANKS === RCS file: /cvs/xenocara/app/xterm/THANKS,v retrieving revision 1.15 diff -u -p -u -r1.15 THANKS --- THANKS 14 Feb 2021 09:14:06 - 1.15 +++ THANKS 27 Mar 2021 09:21:21 - @@ -1,4 +1,4 @@ --- $XTermId: THANKS,v 1.30 2021/02/09 01:32:10 tom Exp $ +-- $XTermId: THANKS,v 1.31 2021/03/01 22:00:49 tom Exp $ -- vile:txtmode fk=utf-8 There's no AUTHORS file in this distribution; it would be redundant since I (Thomas E. Dickey) have done more than 80% of the work on xterm since 1996. @@ -225,6 +225,7 @@ Thierry Reding Thomas Wolff Thorsten Glaser Tim Adye +Tim Oehl Tim Pope Tobias Stoeckmann Todd Eigenschink Index: Tekproc.c === RCS file: /cvs/xenocara/app/xterm/Tekproc.c,v retrieving revision 1.29
Re: allow xlock -dpms* values < 30 and > 0
On Thu, Mar 11, 2021 at 03:36:03PM +0100, Alex Raschi wrote:
> Ping
>
> There was an extra space after 'noff', below is the updated patch.
>
> On Tue, Feb 23, 2021 at 11:11:21AM +0100, Alex Raschi wrote:
> > Hi,
> >
> > I noticed that xlock does not allow values between 30 and 0 for options
> > -dpms{standby,suspend,off}, the man page suggests that all values >= 0
> > are accepted. I use the blank mode and i would like to set a lower
> > timeout so i made a patch to remove the limit.
> >
> > ok?
Hi,
sorry I didn't pay attention your mail initially. I've commited the
patch below. Thanks.
>
> Index: app/xlockmore/xlock/xlock.c
> ===
> RCS file: /cvs/xenocara/app/xlockmore/xlock/xlock.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 xlock.c
> --- app/xlockmore/xlock/xlock.c 26 Nov 2006 17:13:23 - 1.2
> +++ app/xlockmore/xlock/xlock.c 20 Feb 2021 15:37:47 -
> @@ -624,7 +624,6 @@ extern int XHPEnableReset(Display * dsp
>
> #endif
> #ifdef USE_DPMS
> -#define MIN_DPMS 30 /* 30 second minimum */
> #if 1
> #include
> #include
> @@ -1114,9 +1113,9 @@ SetDPMS(Display * display, int nstandby,
> DPMSSetTimeouts(display, standby, suspend, off);
> else
> DPMSSetTimeouts(display,
> - (nstandby <= 0 ? 0 : (nstandby >
> MIN_DPMS ? nstandby : MIN_DPMS)),
> - (nsuspend <= 0 ? 0 : (nsuspend >
> MIN_DPMS ? nsuspend : MIN_DPMS)),
> - (noff <= 0 ? 0 : (noff > MIN_DPMS ?
> noff : MIN_DPMS)));
> + (nstandby <= 0 ? 0 : nstandby),
> + (nsuspend <= 0 ? 0 : nsuspend),
> + (noff <= 0 ? 0 : noff));
> }
> }
--
Matthieu Herrb
xenodm : don't add authorizations for tcp connections by default
s ();
doWrite = 0;
for (i = 0; i < d->authNum; i++)
- writeLocalAuth (new, auths[i], d->name);
+ writeLocalAuth (new, auths[i], d->name, d->listenTcp);
doWrite = 1;
if (old) {
if (fstat (fileno (old), ) != -1)
Index: xenodm/resource.c
===
RCS file: /cvs/xenocara/app/xenodm/xenodm/resource.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 resource.c
--- xenodm/resource.c 8 Mar 2021 17:54:28 - 1.6
+++ xenodm/resource.c 8 Mar 2021 20:05:11 -
@@ -169,6 +169,8 @@ struct displayResource serverResources[]
"" },
{ "autoLogin", "AutoLogin",DM_STRING, boffset(autoLogin),
"" },
+{ "listenTcp", "ListenTcp", DM_BOOL,boffset(listenTcp),
+ "false" },
};
#define NUM_SERVER_RESOURCES (sizeof serverResources/\
Index: xenodm/server.c
===
RCS file: /cvs/xenocara/app/xenodm/xenodm/server.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 server.c
--- xenodm/server.c 11 Jul 2018 14:35:46 - 1.4
+++ xenodm/server.c 8 Mar 2021 20:05:11 -
@@ -86,6 +86,8 @@ StartServerOnce (struct display *d)
snprintf (arg, sizeof(arg), "-auth %s", d->authFile);
argv = parseArgs (argv, arg);
}
+ if (d->listenTcp)
+ argv = parseArgs(argv, "-listen tcp");
if (!argv) {
LogError ("StartServer: no arguments\n");
sleep ((unsigned) d->openDelay);
--
Matthieu Herrb
Re: Ignore /tmp/.Xauth* in daily
On Sat, Mar 06, 2021 at 09:52:58PM +0300, Vadim Zhukov wrote:
> сб, 6 мар. 2021 г. в 21:30, Theo de Raadt :
> >
> > Matthieu Herrb wrote:
> >
> > > Linux, systemd and XDG have inventend this /run/user/$uid tmpfs that
> > > is created automagically and they use that in place of /tmp for
> > > volatile things that don't beloing to $HOME, but this is not a can of
> > > worms I want to open now.
> >
> > Awesome, another directory to drop stuff and run a filesystem out of space
> > with unclear consequences...
> >
> > This does not fit with our direction either.
>
> So this code appeared in X11R4. There was no VCS repo, I suppose, so no
> history.
>
> There are basically four cases why xdm may fail to create ~/.Xauthority:
>
> a) home directory doesn't exist
> b) home directory is non-writeable due to permissions
> c) /home is full
> d) /home is on NFS and there are locking/network issues.
>
> I'm not sure if (a) is a valid case. (b) is a variant of my case, as I
> said, I can live without this feature. In the case of (c) users
> (non-admins) won't be able to do something anyway. Can't speak for NFS
> (I've quit the job where /home on NFS has been set up a few years ago)
> so no opinion on (d).
>
I think 4 his not an issue anymore.the locking mecanism used by xauth
is working with all current NFS implementations (including
OpenBSD's).
Here is a patch to remve the backup authorization file. Unfortunatly
there is no simple way to display an explicit error message. One will
need to check the xenodm.log file.
Xsession can be patched too to remove the fallback to /tmp/xes- log
file if ~/.xsession-errors cannot be writen. This will be a separate
diff.
Index: include/dm.h
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/include/dm.h,v
retrieving revision 1.15
diff -u -p -u -r1.15 dm.h
--- include/dm.h10 Jan 2021 09:18:30 - 1.15
+++ include/dm.h6 Mar 2021 17:53:44 -
@@ -122,7 +122,6 @@ struct display {
char**authNames;/* authorization protocol names */
unsigned short *authNameLens; /* authorization protocol name lens */
char*clientAuthFile;/* client specified auth file */
- char*userAuthDir; /* backup directory for tickets */
int authComplain; /* complain when no auth for XDMCP */
/* information potentially derived from resources */
Index: man/xenodm.man
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/man/xenodm.man,v
retrieving revision 1.11
diff -u -p -u -r1.11 xenodm.man
--- man/xenodm.man 15 Aug 2019 16:23:33 - 1.11
+++ man/xenodm.man 6 Mar 2021 17:53:44 -
@@ -582,18 +582,6 @@ to occur, during which time the new auth
The default is
.Cm false ,
which will work for all MIT servers.
-.It Ic DisplayManager. Ns Ar DISPLAY Ns Ic .userAuthDir
-When
-.Nm
-is unable to write to the usual user authorization file
-.Pq Pa $HOME/.Xauthority ,
-it creates a unique file name in this directory and points the environment
-variable
-.Ev XAUTHORITY
-at the created file.
-It uses
-.Pa /tmp
-by default.
.El
.Sh CONFIGURATION FILE
First, the
Index: xenodm/auth.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/xenodm/auth.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 auth.c
--- xenodm/auth.c 1 Jan 2021 18:09:07 - 1.15
+++ xenodm/auth.c 6 Mar 2021 17:53:44 -
@@ -752,7 +752,7 @@ void
SetUserAuthorization (struct display *d, struct verify_info *verify)
{
FILE *old = NULL, *new;
-char home_name[1024], backup_name[1024], new_name[1024];
+char home_name[1024], new_name[1024];
char *name = NULL;
char *home;
char *envname = NULL;
@@ -762,7 +762,6 @@ SetUserAuthorization (struct display *d,
struct statstatb;
inti;
intmagicCookie;
-intfd;
Debug ("SetUserAuthorization\n");
auths = d->authorizations;
@@ -793,45 +792,10 @@ SetUserAuthorization (struct display *d,
}
}
if (lockStatus != LOCK_SUCCESS) {
- snprintf (backup_name, sizeof(backup_name),
- "%s/.XauthXX", d->userAuthDir);
- fd = mkstemp (backup_name);
- if (fd >= 0) {
- old = fdopen (fd, "r");
- if (old == NULL)
- (void) close(fd);
- }
-
- if (old != NULL)
- {
- lockStatus = XauLockAuth (backup_name, 1, 2, 10);
- Debug ("backup lock is %d\n", lockStatus);
- if (lockStatus == L
Re: Ignore /tmp/.Xauth* in daily
On Sat, Mar 06, 2021 at 08:50:57PM +0300, Vadim Zhukov wrote: > > Well, I do... nothing? I can show my .xsession, there's nothing > special. I run cwm, FWIW, and do not start anything heavy from the > beginning, to have a working desktop ASAP. KDE and GNOME won't work > this way for sure. :-) ok, I was wrong. My testing account did have a .xsession from a previous test that caued the failure. With the real default Xsession it still starts. But I tend to agree with Theo that these backup strategies to write to /tmp when one cannot write to $HOME are wrong. Linux, systemd and XDG have inventend this /run/user/$uid tmpfs that is created automagically and they use that in place of /tmp for volatile things that don't beloing to $HOME, but this is not a can of worms I want to open now. -- Matthieu Herrb
Re: Ignore /tmp/.Xauth* in daily
On Sat, Mar 06, 2021 at 09:56:34AM -0700, Theo de Raadt wrote: > Matthieu Herrb wrote: > > > On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote: > > > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov : > > > > > > > > Hello all. > > > > > > > > Since xenodm has DEF_USER_AUTH_DIR set to "/tmp", we need to ignore > > > > /tmp/.Xauth* in daily cleanup, don't we? > > > > > > > > Found the hard way a few minutes ago on my X240. > > > > > > Thanks sthen@, I've realized this happens only when xenodm could not > > > create ~/.Xauthority. In my case this happens because my laptop starts > > > with /home mounted read-only, but there may be others. Mattieu, the > > > xenodm logic itself is correct, right? If yes, anyone brave enough to > > > okay the diff below then? :-) > > > > Hi, > > > > Yes I think the xenodm logic (inherithed from xdm) is correct. > > > > Althoug in my experience, when an X session cnnot write to $HOME it > > generally doesn't get very far (iirc not beeing able to write to > > .xsession-errors used to be fatal)... I tried to log in with a read-only /home and it failed as I remembered it. Vadim are your doing something special in you X session to make that work ? > > > > Anyways ok to skip that directory if it exists in daily. > > It is not a directory -- it is a file. > > I don't understand how this file is created. Well-known names in /tmp > are raceable -- therefore we and others increasingly use directories > containing > files as a safer pattern. Where is the code that creates this file? Is it > safe? I am suspicious. It's created by mkstemp(3) in /usr/xenocara/app/xenodm/xenodm/auth.c:798 > > I strongly disagree with the pattern ".Xauth*". It should be EXACT. If > someone else creates a file called .Xauthsadflkjdsaf, it should not be > deleted. > > As a final point, is this strategy of considering /tmp a safe place acceptable > at all? If $HOME doesn't work, why not just have X fail to work correctly > and consider this "fail over to /tmp" a junk idea from the past? The backup dir can be configured to something else, but it needs to be writeable by the user whois login in. It could be a subdir of /tmp (if the rc.d script takes care of creating it) or I can remove that feature from xenodm and fail the login if /home is not writeable. -- Matthieu Herrb
Re: Ignore /tmp/.Xauth* in daily
On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote:
> чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov :
> >
> > Hello all.
> >
> > Since xenodm has DEF_USER_AUTH_DIR set to "/tmp", we need to ignore
> > /tmp/.Xauth* in daily cleanup, don't we?
> >
> > Found the hard way a few minutes ago on my X240.
>
> Thanks sthen@, I've realized this happens only when xenodm could not
> create ~/.Xauthority. In my case this happens because my laptop starts
> with /home mounted read-only, but there may be others. Mattieu, the
> xenodm logic itself is correct, right? If yes, anyone brave enough to
> okay the diff below then? :-)
Hi,
Yes I think the xenodm logic (inherithed from xdm) is correct.
Althoug in my experience, when an X session cnnot write to $HOME it
generally doesn't get very far (iirc not beeing able to write to
.xsession-errors used to be fatal)...
Anyways ok to skip that directory if it exists in daily.
>
> > Index: daily
> > ===
> > RCS file: /cvs/src/etc/daily,v
> > retrieving revision 1.95
> > diff -u -p -r1.95 daily
> > --- daily 20 Oct 2020 22:42:29 - 1.95
> > +++ daily 3 Mar 2021 22:58:28 -
> > @@ -49,7 +49,7 @@ if [ -d /tmp -a ! -L /tmp ]; then
> > cd /tmp && {
> > find -x . \
> > \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
> > - -o -path './tmux-*' \) \
> > + -o -path './tmux-*' -o -path './.Xauth*' \) \
> > -prune -o -type f -atime +7 -delete 2>/dev/null
> > find -x . -type d -mtime +1 ! -path ./vi.recover ! -path
> > ./.X11-unix \
> > ! -path ./.ICE-unix ! -name . \
>
> --
> WBR,
> Vadim Zhukov
--
Matthieu Herrb
Re: use /dev/dri/ in xenocara
On Thu, Feb 18, 2021 at 09:18:51PM +1100, Jonathan Gray wrote:
Ok matthieu@.
> Index: lib/libdrm/xf86drm.h
> ===
> RCS file: /cvs/xenocara/lib/libdrm/xf86drm.h,v
> retrieving revision 1.21
> diff -u -p -r1.21 xf86drm.h
> --- lib/libdrm/xf86drm.h 11 Feb 2021 10:27:08 - 1.21
> +++ lib/libdrm/xf86drm.h 18 Feb 2021 10:02:03 -
> @@ -76,18 +76,11 @@ extern "C" {
> (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH)
> #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)
>
> -#ifdef __OpenBSD__
> -#define DRM_DIR_NAME "/dev"
> -#define DRM_PRIMARY_MINOR_NAME "drm"
> -#define DRM_CONTROL_MINOR_NAME "drmC"
> -#define DRM_RENDER_MINOR_NAME "drmR"
> -#else
> #define DRM_DIR_NAME "/dev/dri"
> #define DRM_PRIMARY_MINOR_NAME "card"
> #define DRM_CONTROL_MINOR_NAME "controlD"
> #define DRM_RENDER_MINOR_NAME "renderD"
> #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
> -#endif
>
> #define DRM_DEV_NAME "%s/" DRM_PRIMARY_MINOR_NAME "%d"
> #define DRM_CONTROL_DEV_NAME "%s/" DRM_CONTROL_MINOR_NAME "%d"
> Index: xserver/hw/xfree86/drivers/modesetting/driver.c
> ===
> RCS file: /cvs/xenocara/xserver/hw/xfree86/drivers/modesetting/driver.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 driver.c
> --- xserver/hw/xfree86/drivers/modesetting/driver.c 12 Dec 2020 09:30:54
> - 1.9
> +++ xserver/hw/xfree86/drivers/modesetting/driver.c 18 Feb 2021 10:02:03
> -
> @@ -226,7 +226,7 @@ open_hw(const char *dev)
> else {
> dev = getenv("KMSDEVICE");
> if ((NULL == dev) || ((fd = priv_open_device(dev)) == -1)) {
> -dev = "/dev/drm0";
> +dev = "/dev/dri/card0";
> fd = priv_open_device(dev);
> }
> }
--
Matthieu Herrb
some fvwmrc defautlts changes
ce TN TN off "telnet" +*SshChoice RL RL on "ssh" +*SshSelectionUserSel single +#*SshChoice Default Default on "same user" +#*SshChoice CustomCustomoff "user:" +*SshText "(Userid:" +*SshInputUserName 10 "" +*SshText ")" +*SshLine center +*SshText "FG:" +*SshInputFgColor 15 "" +*SshText "BG:" +*SshInputBgColor 15 "" +*SshLine expand +*SshButton quit "Login" ^M +*SshCommand Exec xterm $(FgColor?-fg $(FgColor)) $(BgColor?-bg $(BgColor)) -T xterm@$(HostName) -e $(RL?ssh) $(TN?telnet) $(HostName) $(UserName?-l $(UserName)) +*SshButton restart "Clear" +*SshCommand Beep +*SshButton quit "Cancel" +*SshCommand Nop # FvwmForm alias - query exit ala mwm *QuitVerifyGrabServer -- Matthieu Herrb
Re: behaviour of openssl s_server and certificate chains on 6.8
On Thu, Jan 14, 2021 at 02:20:38PM +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > Hi, > > > > I'm trying to debug strange beahaviour changes with certificates on a > > systemc after upgrading it from 6.7 to 6.8... > > > > On 6.7, If I run : > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > returns the full certificate chain mycert->CA > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > (my real application is sendmail...) > > In short: Yes, this is known. You can't get the chain in 6.8. > > This is the reason why ajacoutot switched sendmail to link against > eopenssl11 as a workaround in -stable. As your thread on ports shows, > this workaround doesn't work if you add something that links against > LibreSSL to the mix. > > There are several layers of unexpected things/bugs involved. The two > main points are: > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to >be able to avoid it. This was addressed post release when people >using OpenLDAP ran into it. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > 2. The new verifier doesn't behave as it should when auto chain is >enabled. As a workaround -current switches to the legacy verifier in >this situation for about a week now. The proper fix in the new >verifier is under discussion. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > I don't know whether/when there will be backports of some fixes to 6.8. > As sthen said in the thread on ports, right now the simplest fix is to > run -current. Ok, thanks. Not the easiest for me, but I wont try to build a frankenstein system. In the mean time it looks like switching to insecure ldap connections for sendmail works (the ldap server is on localhost so the risk is not very high) -- Matthieu Herrb
behaviour of openssl s_server and certificate chains on 6.8
Hi, I'm trying to debug strange beahaviour changes with certificates on a systemc after upgrading it from 6.7 to 6.8... On 6.7, If I run : openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem then openssl s_client -showcerts -connect localhost:4433 returns the full certificate chain mycert->CA With the same commands on 6.8, I don't get the CA certificate. Is this a known issue, and how can I get the chain with 6.8 ? (my real application is sendmail...) -- Matthieu Herrb
Re: Edit /etc/boot.conf
On Sun, Dec 06, 2020 at 04:21:10PM +0100, Mark Kettenis wrote:
> Both armv7 and powerpc64 support VTs, so let xenodem take the VT
> reserved for X in /etc/ttys.
>
> ok?
Sure. It will soon be time to invert the test and list machines that
don't support VTs
>
>
> Index: app/xenodm/Makefile.bsd-wrapper
> ===
> RCS file: /cvs/xenocara/app/xenodm/Makefile.bsd-wrapper,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile.bsd-wrapper
> --- app/xenodm/Makefile.bsd-wrapper 1 Apr 2020 19:58:02 - 1.5
> +++ app/xenodm/Makefile.bsd-wrapper 6 Dec 2020 14:59:40 -
> @@ -4,8 +4,8 @@
> XENODMCONFIGDIR=/etc/X11/xenodm
> PIXMAPDIR=$(XENODMCONFIGDIR)/pixmaps
>
> -.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == i386 \
> -|| ${MACHINE} == macppc
> +.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == armv7 \
> +|| ${MACHINE} == i386 || ${MACHINE} == macppc || ${MACHINE} == powerpc64
> DEFAULT_VT= --with-default-vt=vt05
> .endif
>
--
Matthieu Herrb
Re: add OpenType bitmap fonts to xenocara
On Sun, Oct 25, 2020 at 12:02:05PM +0100, Christopher Zimmermann wrote:
> Hi,
>
> this makes the xenocara bitmap fonts available for pango apps like gvim,
> too.
> Is it ok to call fonttosfnt directly in the Makefile or is there a reason to
> use a macro like done for $(BDFTOPCF) ? OK?
Hi,
I have some concerns too
- I would prefer if either it would be done upstreams first. Even if
the font pachages don't change very often, these change will make
future merges less easy.
As an alternative, this could be added as before- or afterinstall:
target to the respective Makefile.bsd-wrappers. without touching the
upstream files. (fonts/Makefile.inc can be used to factorize part of
the rules).
- there are a few fonts which produce an error/ warning when
generating the otb files:
Couldn't determine full name for micro.otb
Couldn't get family name for micro.otb
Couldn't determine full name for decsess.otb
Couldn't get family name for decsess.otb
Couldn't determine full name for deccurs.otb
Couldn't get family name for deccurs.otb
May be they can be left alone ?
- running make checkdist after make release also show
> ./usr/X11R6/lib/X11/fonts/misc/cursor.bdf
it looks like a typo in cursor-misc/Makefile.{am,in} (BDF_FILES
intead of OTB_FILES)
--
Matthieu Herrb
Re: fonttosfnt: merge changes to fix fonts for new pango
On Fri, Oct 09, 2020 at 09:39:37AM +0200, Christopher Zimmermann wrote: > > Hi Matthieu, > > you already gave an ok some time ago to merge changes to fonttosfnt. Now > that my changes have been tested and merged upstream I'd like to integrate > them into xenocara. May I ask for another ok? Sorry I should have reacted faster. I've asked Peter Hutterer to make a formal release of xfonttosfnt 1.1.1 with your commits upstreams. In the long run it makes things easier to follow if we can just upgrade to the upstream version. May I ask you for a few more days of waiting ? If nothing happens on the xorg side in the next 3 days, then ok to commit the changes locally. -- Matthieu Herrb
Re: Support astfb(4) in wsfb(4)
On Sat, Oct 03, 2020 at 04:50:28PM +0200, Mark Kettenis wrote:
> The astfb(4) is a little-endian framebuffer on a (for now) big-endian
> architecture. Therefore we need to tell X that the pixels have their
> color components laid out in a non-standard way.
>
> Note that support for this pixel layout in X is weak. Normal stuff
> works but the software rendering in Mesa doesn't seem to work
> properly. So while this is good enough to get a bunch of xterms on
> the screen, glxgears will have the wrong colors.
>
> ok?
yes, ok.
>
> P.S. I don't think basing on the wsdisplay type is the right thing to
> do, but it is what we have done in the past. Maybe we should
> extend wsdisplay_fbinfo with some fields that communicate the
> pixel format and use that?
>
>
> Index: driver/xf86-video-wsfb/src/wsfb_driver.c
> ===
> RCS file: /cvs/xenocara/driver/xf86-video-wsfb/src/wsfb_driver.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 wsfb_driver.c
> --- driver/xf86-video-wsfb/src/wsfb_driver.c 27 Jul 2019 07:48:19 -
> 1.38
> +++ driver/xf86-video-wsfb/src/wsfb_driver.c 3 Oct 2020 14:39:18 -
> @@ -632,6 +632,17 @@ WsfbPreInit(ScrnInfoPtr pScrn, int flags
> masks.blue = 0x1f;
> }
> break;
> + case WSDISPLAY_TYPE_ASTFB:
> + if (pScrn->depth > 16) {
> + masks.red = 0xff00;
> + masks.green = 0x00ff;
> + masks.blue = 0xff00;
> + } else {
> + masks.red = 0x1f;
> + masks.green = 0x3f << 5;
> + masks.blue = 0x1f << 11;
> + }
> + break;
> default:
> masks.red = 0;
> masks.green = 0;
--
Matthieu Herrb
hostname.if '!' commands and rdomains
Hi,
When I'm configuring an interface with a spécific rdomain, I'd assume
that '!' commands (especially /sbin/route commands) are executed in
the rdomain for this interface.
I know that parsing this file is complex and somehow fragile but still
I tried to write a patch.
What do you think ?
Of course I'm ok with any enhancements / fixes to my shell foo.
--- netstart.orig Wed Jul 29 11:19:53 2020
+++ netstartWed Jul 29 11:52:39 2020
@@ -67,8 +67,16 @@
_cmds[${#_cmds[*]}]="ifconfig $_if ${_c[@]} up;dhclient $_if"
V4_DHCPCONF=true
;;
+ rdomain) ((${#_c[*]} == 2)) || return
+ _cmds[${#_cmds[*]}]="ifconfig $_if rdomain ${_c[_name]}"
+ _rdomain=${_c[_name]}
+ ;;
'!'*) _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
- _cmds[${#_cmds[*]}]="${_cmd#!}"
+ if [[ $_rdomain -ne 0 ]]; then
+ _cmds[${#_cmds[*]}]="/sbin/route -T$_rdomain exec
${_cmd#!}"
+ else
+ _cmds[${#_cmds[*]}]="${_cmd#!}"
+ fi
;;
*) _cmds[${#_cmds[*]}]="ifconfig $_if ${_c[@]}"
;;
--
Matthieu Herrb
Re: Add ability to set control values with video(1)
On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote: > Marcus Glocker wrote: > > > Instead of introducing the CLI parameter controls in video(1), we could > > introduce videoctl(1) in base, same as we have with audioctl(1). This > > also gives us the possibility to only display the current video > > parameters. > > I must have missed something. Why does it need to be a seperate comment. > Won't this produce confusion? Why can video do this? > > Is it really correct for the video hardware to have persistant settings? > Would it not be better if the required mode was always commanded when > a video is being recorded? I've not followed UVC hardware too closely; it seems that some of the cameras are always fully automatically adjusting their parameters, while others allow for manual setting that remains between device open(). And some of the controls are not available when video(4) is used from a browser (for conferencing). On a 2nd thought having that integrated with video(1) allows to control the values with visual feedback so it makes sense to keep only one program. But ihmo it would be more user friendly if the command line syntax was more regular with audio or wscons control programs. -- Matthieu Herrb
Re: typo in www/faq/current.html - libxkbui...
On Sat, Jul 11, 2020 at 03:19:46PM +0100, Larry Hynes wrote: > Hi > > # rm /usr/X11R6/include/extenstions/XKBui.h > > does not look right to me. > > 1. The spelling of extensions is incorrect > 2. I think /usr/X11R6/include/X11/extensions/XKBui.h >is the correct path Fixed. Thanks for the report. > > Index: faq/current.html > === > RCS file: /cvs/www/faq/current.html,v > retrieving revision 1.1047 > diff -u -p -r1.1047 current.html > --- faq/current.html 10 Jul 2020 06:04:41 - 1.1047 > +++ faq/current.html 11 Jul 2020 14:17:46 - > @@ -106,7 +106,7 @@ It should be manually removed. > > # rm /usr/X11R6/lib/libxkbui.* > # rm /usr/X11R6/lib/pkgconfig/xkbui.pc > -# rm /usr/X11R6/include/extenstions/XKBui.h > +# rm /usr/X11R6/include/X11/extensions/XKBui.h > > -- Matthieu Herrb
Re: WireGuard patchset for OpenBSD, rev. 3
On Fri, Jun 19, 2020 at 06:46:00PM +1000, Matt Dunwoodie wrote: > Hi all, > > After the previous submission of WireGuard, we've again been through a > number of improvements. Thank you everyone for your feedback. Hi, I was wondering if there is a way to specify a routing domain/table for wgendpoint in ifconfig(8). In a VPN client setup (roadwarrior style) I'd like to keep wg0 in rdomain 0 and put the actual physical interface in rdomain 1. So that all daemons (smtpd, unwind, ...) use the VPN by default and only the strict minimum to setup the VPN runs in rdomain 1. Everything works if I set wg0 in rdomain1 and keep my re0 interface in rdomain 0, but as soon as I set rdomain 1 for re0 and rdomain 0 for wg0, the VPN cannot come up (and I see the UDP packets to port 51820 trying to go out through wg0). Thanks for your work on wireguard ! -- Matthieu Herrb
Re: WireGuard patchset for OpenBSD, rev. 3
On Fri, Jun 19, 2020 at 06:46:00PM +1000, Matt Dunwoodie wrote: > Hi all, > > After the previous submission of WireGuard, we've again been through a > number of improvements. Thank you everyone for your feedback. Hi, While giving wireguard a try, I found that this patch is needed to fix ifconfig(8) documentation : diff --git sbin/ifconfig/ifconfig.8 sbin/ifconfig/ifconfig.8 index 29edeb60793..93429b4c103 100644 --- sbin/ifconfig/ifconfig.8 +++ sbin/ifconfig/ifconfig.8 @@ -2056,7 +2056,7 @@ Packets on a VLAN interface without a tag set will use a value of .Op Cm wgpsk Ar presharedkey .Op Fl wgpsk .Op Cm wgpka Ar persistent-keepalive -.Op Cm wgpip Ar ip port +.Op Cm wgendpoint Ar ip port .Op Cm wgaip Ar allowed-ip/prefix .Oc .Op Fl wgpeerall @@ -2137,7 +2137,7 @@ By default this functionality is disabled, equivalent to a value of 0. This is often used to ensure a peer will be accessible when protected by a firewall, as is when behind a NAT address. A value of 25 is commonly used. -.It Cm wgpip Ar ip port +.It Cm wgendpoint Ar ip port Set the IP address and port to send the encapsulated packets to. If the peer changes address, the local interface will update the address after receiving a correctly authenticated packet. -- Matthieu Herrb
Re: Xwindows keymap weirdness
On Mon, Jun 01, 2020 at 03:28:52PM +0200, Stéphane Aulery wrote: > Hello, > > Le 01/06/2020 14:55, Matthieu Herrb a écrit : > > > > > > > > (I have just tried with a test user with nothing configured besides > > > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper > > > characters) > > > > I'm using a real US keyboard with AltGr or the Menu Key (depending on > > the actual keyboard) set as Compose and typing full compose sequences > > to get diacritics. ieand so on. > > I use a Bépo keyboard but this but > > Your experience interests me. I use a Bépo keyboard but I plan to switch to > a QWERTY + compose keyboard like you do. I hope this will give better > compatibility between systems and less software config remapping. > > I do not see how to configure this in console. I'm only using this under X. the OpenBSD console is plain ASCII and has no support for for UTF8 characters, so no need to enter them. To setup the right alt key as compose, you can either: - run 'setxkbmap -option compose:ralt' somewhere in your session startup script - create /etc/X11/xorg.conf.d/90-keyboard.conf containing --- Cut --- Section "InputClass" Identifier "Kbd" MatchDriver "kbd" Option "XkbOptions" "compose:ralt" EndSection --- Cut --- > > What are the pitfalls? I don't know. I've a number of things in mind, but I'm not sure they're relevant. The existing Compose rules allow me to enter all important UTF-8 characters I need outside of ASCII: French diacritics, non-breaking spaces, median point, Euro sign, etc. Oh yes: one issue: I almost never test non default keyboard layouts in Xenocara because of this (no /etc/kbdtype file on my OpenBSD machines) :) -- Matthieu Herrb
Re: Xwindows keymap weirdness
On Mon, Jun 01, 2020 at 02:16:16PM +0200, Marc Espie wrote: > I occasionnally use setxkbmap 'us(intl)' in order to have diacritics > as dead keys. > > I have LC_CTYPE=en_US.UTF-8 > > If I type 'c > > I get a ç in programs like firefox or chrome, BUT I get > ć in xterm ? > > why are things different ? Because firefox or chrome probably don't use /usr/X11R6/share/X11/locale/en_US.UTF-8/Compose (the rules used by Xlib) but their own Compose rules. I don't know if there is some other "standard" toolkit (gtk+3?) providing alternative rules or if they just hard-code their own rules somewhere. > which program is right ? There may be an international standard (ISO, XDG, ... ?) that controls those rules and what X.Org is shipping in /usr/X11R6/share/X11/locale/en_US.UTF-8/Compose But I can't find a reference. So I would say that xterm is right: the compose sequence for ç is ,c. And as you got it there is a ć character in some alphabets reachable with 'c or ' c You have a key in the default us(intl) XKB layout (it's on the the 4th group for the '5' key) but I don't remember how to reach that group :) > > (I have just tried with a test user with nothing configured besides > LC_CTYPE=en_US.UTF-8, without which xterm/vim doesn't show proper characters) I'm using a real US keyboard with AltGr or the Menu Key (depending on the actual keyboard) set as Compose and typing full compose sequences to get diacritics. ieand so on. -- Matthieu Herrb
Re: Removing old video drivers
On Mon, May 11, 2020 at 09:40:30AM -0700, Dirk Praet wrote: > Hi Matthieu, > > It would seem I'm a bit (too) late to this party. In short: I'm running a > high security environment leveraging the combined power of contemporary > OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all > kinds of modern BIOS/EFI/processor "management" technology. My recent > upgrade to 6.6 has crippled several machines using the Trident video > chipset, which I then found out was removed from both the 6.6 binary > distribution and the Xenocara tree. Which begs the following questions: > > - Is it possible to bring the Trident-module back ? No. At least not in the OpenBSD supported tree. You can still try to get the sources out of CVS's Attic and build it for yourself but I'm not sure if it will compile against X server 1.20.8. > - If not, is there any (documented) way to still get X to work on the > affected (laptop) machines using a framebuffer or other module, blacklisting > in some way the Trident module which Xorg detects as the chipset in use but > then bails out on because it is no longer there ? You can try to use the xf86-video-vesa driver, but it's main limitation is that it only supports graphics modes that are hard-coded in the machine's video BIOS. And laptops from that ERA often didn't even bother to provide a video mode that matches the native resolution of their panel. > - Is the removal of additional graphics modules in the future not > effectively rendering the i386 port useless for anything else than pure CLI, > router or headless systems, and, shouldn't , in that case, an explicit > warning be added to release notes/installer/sysupgrade ? Too late unfortunatly. 6.6 was release 6 month ago. -- Matthieu Herrb
Re: [UPDATE] xcb-proto and libxcb 1.14
On Sun, Mar 22, 2020 at 08:13:11PM +0100, Matthieu Herrb wrote: > Hi, > > the patch below updates XCB (xcb-proto and libxcb) to version 1.14.0. > > I've been running this on amd64 for a while. Comments ? ok ? > > Note that it goes together with an update to the x11/py-xcbgen port > that I'm sending to ports@ at the same time. Ping -- Matthieu Herrb
UPDATE: xserver 1.20.8
Hi,
The patch below updates the X server to version 1.20.8.
Apply the patch in ${XSRCDIR}/xserver with patch -p0 -E and then
rebuild Xenocara according to release(8).
Comments, ok ?
Index: ChangeLog
===
RCS file: /cvs/OpenBSD/xenocara/xserver/ChangeLog,v
retrieving revision 1.35
diff -u -p -u -r1.35 ChangeLog
--- ChangeLog 26 Jan 2020 13:48:54 - 1.35
+++ ChangeLog 2 Apr 2020 17:59:06 -
@@ -1,3 +1,414 @@
+commit f84ad082557f9cde6b8faa373eca6a0a89ba7d56
+Author: Matt Turner
+Date: Sun Mar 29 13:02:03 2020 -0700
+
+xserver 1.20.8
+
+Signed-off-by: Matt Turner
+
+commit 8837279869309317c110afb6f2f3c24484c77657
+Author: Jon Turney
+Date: Wed Apr 17 11:37:11 2019 +0100
+
+Fix old-style definition warning for xf86OSInputThreadInit()
+
+../hw/xfree86/os-support/stub/stub_init.c: In function
‘xf86OSInputThreadInit’:
+../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style
function definition [-Wold-style-definition]
+
+(cherry picked from commit 7c266cafed14b38c039091651069ae9888c3a8ae)
+
+commit 0c012f968b4e02a2bc892ce71f7bea9bd3f7fb22
+Author: Jon Turney
+Date: Wed Mar 13 14:57:14 2019 +
+
+Add xf86OSInputThreadInit to stub os-support as well
+
+stub os support also needs to provide xf86OSInputThreadInit, omitted in
+ea1527a8
+
+(cherry picked from commit c020769dbfb965740c8441d8242b738ef572a7c9)
+
+commit b259485975078087fe6bde2b9e1eccf4ae14120c
+Author: Michel Dänzer
+Date: Tue Mar 17 11:45:22 2020 +0100
+
+xwayland: Delete all frame_callback_list nodes in xwl_unrealize_window
+
+We were only calling xwl_present_unrealize_window for the toplevel
+window, but the list can contain entries from child windows as well,
+in which case we were leaving dangling pointers to freed memory.
+
+Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/1000
+Fixes: c5067feaeea1 "xwayland: Use single frame callback for Present
+ flips and normal updates"
+Reviewed-by: Olivier Fourdan
+Tested-by: Olivier Fourdan
+(cherry picked from commit 5e91587302e85fd6f0e8d5ffbe30182e18c6913f)
+
+commit a033571644d277dc49a489f7ae32c4ad92856543
+Author: Jonas Ådahl
+Date: Fri Sep 13 17:11:27 2019 +0200
+
+xwayland/glamor-gbm: Handle DRM_FORMAT_MOD_INVALID gracefully
+
+The compositor may send DRM_FORMAT_MOD_INVALID instead of a list of
+modifiers for various reasons. Handle this gracefully by ignoring it.
+
+Without this, if a compositor would send DRM_FORMAT_MOD_INVALID, it'd
+result in empty windows provided by Xwayland.
+
+Signed-off-by: Jonas Ådahl
+Reviewed-by: Olivier Fourdan
+Reviewed-by: Michel Dänzer
+(cherry picked from commit edf964434eac10ffbe27cc883e3ab95505669aee)
+
+commit 3c48bd50ad33f2a533ac76afa38d6e3906ebc28a
+Author: Arthur Williams
+Date: Sun Oct 6 18:55:35 2019 +
+
+dix: Check for NULL spriteInfo in GetPairedDevice
+
+There is a race when reseting the XServer that causes spriteInfo to be
+NULL in GetPairedDevice resulting a segfault and subsequent crash. The
+problem was noticed when opening a connection, creating master devices,
+destroying master devices and closing the connection during testing.
+
+Signed-off-by: Arthur Williams
+
+
+(cherry picked from commit e693c9657f98c334e9921ca2f8ebf710497c0c6a)
+
+commit 1610ef1d6b5ba99da9d1a639f3b65b2e61514a7d
+Author: David Seifert
+Date: Fri Jan 24 12:49:44 2020 +0100
+
+Fix building with `-fno-common`
+
+* GCC 10 will switch the default to `-fno-common`.
+ https://gcc.gnu.org/PR85678
+
+Bug: https://bugs.gentoo.org/705880
+Signed-off-by: Matt Turner
+
+commit 2a185dd22ddb5b0d7d2ef5948591028766bb9530
+Author: Michel Dänzer
+Date: Mon Mar 2 18:09:31 2020 +0100
+
+xwayland: Use frame callbacks for Present vblank events
+
+Instead of only the fallback timer.
+
+Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/854
+
+v2:
+* Drop unused frame_callback member of struct xwl_present_window
+ (Olivier Fourdan)
+
+Reviewed-by: Olivier Fourdan
+(cherry picked from commit 9b31358c52e951883bf7c01c953a9da080542244)
+
+commit 99a6d6b15e0757a4652a569a1b2070c76a00b567
+Author: Michel Dänzer
+Date: Wed Nov 27 18:04:06 2019 +0100
+
+xwayland: Use single frame callback for Present flips and normal updates
+
+Using a list of Present windows that need to be called back.
+
+This prepares for the following change, there should be no change in
+observed behaviour.
+
+v2:
+* Use xwl_window_create_frame_callback instead of making the
+ frame_listener struct non-static (Olivier Fourdan)
+
+Reviewed-by: Olivier Fourdan
+(cherry picked from commit c5067feaeea115761f0a72f37407c6e5e943d1a1)
+
+commit
Re: xorg packaging issue
On Tue, Mar 24, 2020 at 01:26:36PM +0100, Marc Espie wrote: > There's some inconsistency: > lists/xserv/mi:./usr/X11R6/share/aclocal/xorg-macros.m4 > lists/xshare/mi:./usr/X11R6/lib/pkgconfig/xorg-macros.pc > > both should be in xshare It was moved to xserv by fries@ some years ago for I don't know what reason. Fixed now. Thanks. > > This does explain the failures of tightvnc on some bulk machines. > By default, proot does NOT copy xserv in the chroot, and I believe > it's correct. -- Matthieu Herrb
[UPDATE] xcb-proto and libxcb 1.14
st of the XML
def register(self):
Index: proto/xcb-proto/xcbgen/xtypes.py
===
RCS file: /cvs/OpenBSD/xenocara/proto/xcb-proto/xcbgen/xtypes.py,v
retrieving revision 1.7
diff -u -p -u -r1.7 xtypes.py
--- proto/xcb-proto/xcbgen/xtypes.py11 Sep 2018 19:31:11 - 1.7
+++ proto/xcb-proto/xcbgen/xtypes.py8 Mar 2020 17:55:27 -
@@ -192,12 +192,12 @@ class SimpleType(PrimitiveType):
Any type which is typedef'ed to cardinal will be one of these.
Public fields added:
-none
+xml_type is the original string describing the type in the XML
'''
-def __init__(self, name, size):
+def __init__(self, name, size, xml_type=None):
PrimitiveType.__init__(self, name, size)
self.is_simple = True
-
+self.xml_type = xml_type
def resolve(self, module):
self.resolved = True
@@ -206,24 +206,27 @@ class SimpleType(PrimitiveType):
# Cardinal datatype globals. See module __init__ method.
-tcard8 = SimpleType(('uint8_t',), 1)
-tcard16 = SimpleType(('uint16_t',), 2)
-tcard32 = SimpleType(('uint32_t',), 4)
-tcard64 = SimpleType(('uint64_t',), 8)
-tint8 = SimpleType(('int8_t',), 1)
-tint16 = SimpleType(('int16_t',), 2)
-tint32 = SimpleType(('int32_t',), 4)
-tint64 = SimpleType(('int64_t',), 8)
-tchar = SimpleType(('char',), 1)
-tfloat = SimpleType(('float',), 4)
-tdouble = SimpleType(('double',), 8)
+tcard8 = SimpleType(('uint8_t',), 1, 'CARD8')
+tcard16 = SimpleType(('uint16_t',), 2, 'CARD16')
+tcard32 = SimpleType(('uint32_t',), 4, 'CARD32')
+tcard64 = SimpleType(('uint64_t',), 8, 'CARD64')
+tint8 = SimpleType(('int8_t',), 1, 'INT8')
+tint16 = SimpleType(('int16_t',), 2, 'INT16')
+tint32 = SimpleType(('int32_t',), 4, 'INT32')
+tint64 = SimpleType(('int64_t',), 8, 'INT64')
+tchar = SimpleType(('char',), 1, 'char')
+tfloat = SimpleType(('float',), 4, 'float')
+tdouble = SimpleType(('double',), 8, 'double')
+tbyte = SimpleType(('uint8_t',), 1, 'BYTE')
+tbool = SimpleType(('uint8_t',), 1, 'BOOL')
+tvoid = SimpleType(('uint8_t',), 1, 'void')
class FileDescriptor(SimpleType):
'''
Derived class which represents a file descriptor.
'''
def __init__(self):
-SimpleType.__init__(self, ('int'), 4)
+SimpleType.__init__(self, ('int'), 4, 'fd')
self.is_fd = True
def fixed_size(self):
@@ -240,7 +243,7 @@ class Enum(SimpleType):
bits contains a list of (name, bitnum) tuples. items only appear if
specified as a bit. bitnum is a number.
'''
def __init__(self, name, elt):
-SimpleType.__init__(self, name, 4)
+SimpleType.__init__(self, name, 4, 'enum')
self.values = []
self.bits = []
self.doc = None
@@ -333,6 +336,9 @@ class ListType(Type):
self.member.resolve(module)
self.expr.resolve(module, self.parents)
+# resolve() could have changed the size (ComplexType starts with size
0)
+self.size = self.member.size if self.member.fixed_size() else None
+
self.required_start_align = self.member.required_start_align
# Find my length field again. We need the actual Field object in the
expr.
@@ -506,7 +512,6 @@ class ComplexType(Type):
self.nmemb = 1
self.size = 0
self.lenfield_parent = [self]
-self.fds = []
# get required_start_alignment
required_start_align_element = elt.find("required_start_align")
Index: distrib/sets/lists/xbase/mi
===
RCS file: /cvs/OpenBSD/xenocara/distrib/sets/lists/xbase/mi,v
retrieving revision 1.125
diff -u -p -u -r1.125 mi
--- distrib/sets/lists/xbase/mi 4 Jan 2020 18:04:05 - 1.125
+++ distrib/sets/lists/xbase/mi 22 Mar 2020 19:05:03 -
@@ -358,7 +358,7 @@
./usr/X11R6/lib/libxcb-res.a
./usr/X11R6/lib/libxcb-res.so.1.1
./usr/X11R6/lib/libxcb-screensaver.a
-./usr/X11R6/lib/libxcb-screensaver.so.1.1
+./usr/X11R6/lib/libxcb-screensaver.so.2.0
./usr/X11R6/lib/libxcb-shape.a
./usr/X11R6/lib/libxcb-shape.so.1.1
./usr/X11R6/lib/libxcb-shm.a
@@ -388,7 +388,7 @@
./usr/X11R6/lib/libxcb-xvmc.a
./usr/X11R6/lib/libxcb-xvmc.so.1.0
./usr/X11R6/lib/libxcb.a
-./usr/X11R6/lib/libxcb.so.4.0
+./usr/X11R6/lib/libxcb.so.4.1
./usr/X11R6/lib/libxkbfile.a
./usr/X11R6/lib/libxkbfile.la
./usr/X11R6/lib/libxkbfile.so.6.0
--
Matthieu Herrb
Re: piixpm(4) on ATI SBx00
00
> @@ -60,6 +60,7 @@ struct piixpm_softc {
> int sc_poll;
> int sc_is_sb800;
> int sc_is_fch;
> + int sc_sb800_selen;
>
> struct piixpm_smbus sc_busses[4];
> struct i2c_controller sc_i2c_tag[4];
> @@ -181,6 +182,12 @@ piixpm_attach(struct device *parent, str
> val |= (bus_space_read_1(sc->sc_iot, ioh, 1) << 8);
> smb0en = val & SB800_SMB0EN_EN;
> base = val & SB800_SMB0EN_BASE_MASK;
> +
> + bus_space_write_1(sc->sc_iot, ioh, 0,
> + SB800_PMREG_SMB0SELEN);
> + val = bus_space_read_1(sc->sc_iot, ioh, 1);
> + if (val & SB800_SMB0SELEN_EN)
> + sc->sc_sb800_selen = 1;
> }
>
> if (smb0en == 0) {
> @@ -296,11 +303,20 @@ piixpm_i2c_acquire_bus(void *cookie, int
> AMDFCH41_PM_PORT_INDEX);
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1,
> smbus->sb_bus << 3);
> - } else if (sc->sc_is_sb800) {
> + } else if (sc->sc_is_sb800 && sc->sc_sb800_selen) {
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 0,
> SB800_PMREG_SMB0SEL);
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1,
> smbus->sb_bus << 1);
> + } else if (sc->sc_is_sb800) {
> + uint8_t val;
> +
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 0,
> + SB800_PMREG_SMB0EN);
> + val = bus_space_read_1(sc->sc_iot, sc->sc_sb800_ioh, 1) &
> + ~SB800_SMB0EN_PORT_MASK;
> + val |= smbus->sb_bus << 1;
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1, val);
> }
>
> return (0);
> @@ -317,11 +333,20 @@ piixpm_i2c_release_bus(void *cookie, int
> AMDFCH41_PM_PORT_INDEX);
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1,
> 0);
> - } else if (sc->sc_is_sb800) {
> + } else if (sc->sc_is_sb800 && sc->sc_sb800_selen) {
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 0,
> SB800_PMREG_SMB0SEL);
> bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1,
> 0);
> + } else if (sc->sc_is_sb800) {
> + uint8_t val;
> +
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 0,
> + SB800_PMREG_SMB0EN);
> + val = bus_space_read_1(sc->sc_iot, sc->sc_sb800_ioh, 1) &
> + ~SB800_SMB0EN_PORT_MASK;
> + val |= 0;
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1, val);
> }
>
> if (cold || sc->sc_poll || (flags & I2C_F_POLL))
> Index: piixreg.h
> ===
> RCS file: /cvs/src/sys/dev/pci/piixreg.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 piixreg.h
> --- piixreg.h 16 Dec 2019 21:39:40 - 1.5
> +++ piixreg.h 7 Jan 2020 11:12:29 -
> @@ -70,8 +70,11 @@
> #define SB800_PMREG_SIZE 2 /* index/data pair */
> #define SB800_PMREG_SMB0EN 0x2c/* 16-bit register */
> #define SB800_PMREG_SMB0SEL 0x2e/* bus selection */
> +#define SB800_PMREG_SMB0SELEN0x2f/* bus selection enable */
> #define SB800_SMB0EN_EN 0x0001
> #define SB800_SMB0EN_BASE_MASK 0xffe0
> +#define SB800_SMB0EN_PORT_MASK 0x06
> +#define SB800_SMB0SELEN_EN 0x01
>
> #define SB800_SMB_HOSTC 0x10/* I2C bus configuration */
> #define SB800_SMB_HOSTC_SMI (1 << 0)/* SMI */
--
Matthieu Herrb
[UPDATE] xhost 1.0.8
Hi again, the patch below update xhost to version 1.0.8. testing and oks welcome. Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/app/xhost/ChangeLog,v retrieving revision 1.6 diff -u -p -u -r1.6 ChangeLog --- ChangeLog 10 May 2015 10:12:42 - 1.6 +++ ChangeLog 15 Aug 2019 17:34:35 - @@ -1,3 +1,96 @@ +commit 997135c6e37faa50f8b42a5f95c0cc8461ed6be9 +Author: Alan Coopersmith +Date: Tue Feb 19 14:50:20 2019 -0800 + +xhost 1.0.8 + +Signed-off-by: Alan Coopersmith + +commit 0ef87307f77e7e3df04b227046904cecbe6dd3f6 +Author: Alan Coopersmith +Date: Wed Nov 21 17:06:21 2018 -0800 + +Update configure.ac bug URL for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 136e3be46cbd93a490483126b837f67c391129a1 +Author: Alan Coopersmith +Date: Fri Nov 16 22:15:54 2018 -0800 + +Update README for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 317312bd23cf5c524932c6f12319ed3eed68d981 +Author: Alan Coopersmith +Date: Mon Nov 12 14:05:52 2018 -0800 + +Drop ancient workarounds for Cray that are no longer needed + +Signed-off-by: Alan Coopersmith + +commit 62bfa9d421138ec538682eb0323fa9f438d6b2c7 +Author: Alan Coopersmith +Date: Mon Nov 12 13:27:55 2018 -0800 + +Prefer inet_aton, if available, over inet_addr + +Signed-off-by: Alan Coopersmith + +commit 0c3627bc7dac395c6af8bd1fb747ef3556e95fb4 +Author: Tobias Stoeckmann +Date: Wed Jul 4 16:20:06 2018 +0200 + +Prevent OOB access on illegal server response. + +While parsing Xorg responses it is possible to trigger an out of +boundary read if the response does not contain enough bytes. + +In case of IPv4, the padding normally prevents this, but IPv6 +addresses can trigger an out of boundary read. + +It takes a hostile xorg-server to reproduce this issue. If +os/access.c is adjusted to always use a length of 1, it is possible +to reproduce it and make it visible with an ASAN-compiled xhost. + +Reading past the memory boundary could reveal sensitive information +to external DNS servers, because a lookup will be performed. + +Signed-off-by: Tobias Stoeckmann +Reviewed-by: Matthieu Herrb + +commit 28015d91e284ee4b797a6e99ec16d53147c0ddb6 +Author: Mihail Konev +Date: Thu Jan 26 14:00:21 2017 +1000 + +autogen: add default patch prefix + +Signed-off-by: Mihail Konev + +commit 3ee80cd398579c0f182ff7131ebfe7b65efed72b +Author: Emil Velikov +Date: Mon Mar 9 12:00:52 2015 + + +autogen.sh: use quoted string variables + +Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent +fall-outs, when they contain space. + +Signed-off-by: Emil Velikov +Reviewed-by: Peter Hutterer +Signed-off-by: Peter Hutterer + +commit 991e4a8a26e9c03faa291b522067443a8d05af7a +Author: Jon TURNEY +Date: Sun Sep 14 18:13:28 2014 +0100 + +Move sethostent()/gethostent() stubs used in Windows builds to avoid implicit-function-declaration warnings + +Signed-off-by: Jon TURNEY +Reviewed-by: Alan Coopersmith +Reviewed-by: David Macek + commit 06d71376aa43f9177ec1e37ed1e4d0faca655cff Author: Alan Coopersmith Date: Thu Apr 16 23:28:02 2015 -0700 Index: Makefile.am === RCS file: /cvs/OpenBSD/xenocara/app/xhost/Makefile.am,v retrieving revision 1.4 diff -u -p -u -r1.4 Makefile.am --- Makefile.am 7 Apr 2012 15:52:30 - 1.4 +++ Makefile.am 15 Aug 2019 17:34:35 - @@ -18,4 +18,4 @@ ChangeLog: dist-hook: ChangeLog INSTALL - +EXTRA_DIST = README.md Index: Makefile.in === RCS file: /cvs/OpenBSD/xenocara/app/xhost/Makefile.in,v retrieving revision 1.9 diff -u -p -u -r1.9 Makefile.in --- Makefile.in 11 Oct 2016 22:14:40 - 1.9 +++ Makefile.in 15 Aug 2019 17:34:57 - @@ -52,7 +52,7 @@ build_triplet = @build@ host_triplet = @host@ bin_PROGRAMS = xhost$(EXEEXT) subdir = . -DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \ +DIST_COMMON = $(am__configure_deps) $(srcdir)/Makefile.am \ $(srcdir)/Makefile.in $(srcdir)/config.h.in \ $(top_srcdir)/configure AUTHORS COPYING ChangeLog INSTALL \ compile config.guess config.sub depcomp install-sh missing @@ -293,6 +293,7 @@ xhost_SOURCES = xhost.c AM_CFLAGS = $(CWARNFLAGS) $(XHOST_CFLAGS) $(XAU_CFLAGS) xhost_LDADD = $(XHOST_LIBS) MAINTAINERCLEANFILES = ChangeLog INSTALL +EXTRA_DIST = README.md all: config.h $(MAKE) $(AM_MAKEFLAGS) all-recursive Index: README === RCS file: README diff -N README --- README 24 Oct 2009 14:14:08 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,26 +0,0 @@ -xhost is used to manage the list of host names or user names
[UPDATE] xauth 1.1.0
ster Xauth *a, regist
return 1;
}
-/* return non-zero iff display and authorization type are the same */
-
-static int
-match_auth(register Xauth *a, register Xauth *b)
-{
-return ((match_auth_dpy(a, b)
-&& a->name_length == b->name_length
-&& memcmp(a->name, b->name, a->name_length) == 0) ? 1 : 0);
-}
-
-
static int
merge_entries(AuthList **firstp, AuthList *second, int *nnewp, int *nreplp)
{
@@ -1144,7 +1131,7 @@ merge_entries(AuthList **firstp, AuthLis
a = first;
for (;;) {
- if (match_auth (a->auth, b->auth)) { /* found a duplicate */
+ if (eq_auth_dpy_and_name (a->auth, b->auth)) { /* found a
duplicate */
AuthList tmp; /* swap it in for old one */
tmp = *a;
*a = *b;
@@ -1175,6 +1162,45 @@ merge_entries(AuthList **firstp, AuthLis
}
+static void
+sort_entries(AuthList **firstp)
+{
+/* Insert sort, in each pass it removes auth records of certain */
+/* cathegory from the given list and inserts them into the sorted list. */
+
+AuthList *sorted = NULL, *sorted_tail = NULL;
+AuthList *prev, *iter, *next;
+
+#define SORT_OUT(EXPRESSION) { \
+ prev = NULL; \
+ for (iter = *firstp; iter; iter = next) { \
+ next = iter->next; \
+ if (EXPRESSION) { \
+ if (prev) \
+ prev->next = next; \
+ else \
+ *firstp = next; \
+ if (sorted_tail == NULL) { \
+ sorted = sorted_tail = iter; \
+ } else { \
+ sorted_tail->next = iter; \
+ sorted_tail = iter; \
+ } \
+ iter->next = NULL; \
+ } else { \
+ prev = iter; \
+ } \
+ } \
+}
+
+SORT_OUT(iter->auth->family != FamilyWild && iter->auth->number_length !=
0);
+SORT_OUT(iter->auth->family != FamilyWild && iter->auth->number_length ==
0);
+SORT_OUT(iter->auth->family == FamilyWild && iter->auth->number_length !=
0);
+SORT_OUT(iter->auth->family == FamilyWild && iter->auth->number_length ==
0);
+
+*firstp = sorted;
+}
+
static Xauth *
copyAuth(Xauth *auth)
{
@@ -1513,6 +1539,7 @@ do_merge(const char *inputfilename, int
printf ("%d entries read in: %d new, %d replacement%s\n",
nentries, nnew, nrepl, nrepl != 1 ? "s" : "");
if (nentries > 0) xauth_modified = True;
+ sort_entries(_head);
}
return 0;
@@ -1661,6 +1688,7 @@ do_add(const char *inputfilename, int li
fprintf (stderr, "unable to merge in added record\n");
return 1;
}
+sort_entries(_head);
xauth_modified = True;
return 0;
Index: test-driver
===
RCS file: /cvs/OpenBSD/xenocara/app/xauth/test-driver,v
retrieving revision 1.2
diff -u -p -u -r1.2 test-driver
--- test-driver 19 Feb 2017 17:30:58 - 1.2
+++ test-driver 15 Aug 2019 17:06:03 -
@@ -1,9 +1,9 @@
#! /bin/sh
# test-driver - basic testsuite driver script.
-scriptversion=2013-07-13.22; # UTC
+scriptversion=2018-03-07.03; # UTC
-# Copyright (C) 2011-2014 Free Software Foundation, Inc.
+# Copyright (C) 2011-2018 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -16,7 +16,7 @@ scriptversion=2013-07-13.22; # UTC
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
@@ -140,9 +140,9 @@ echo ":copy-in-global-log: $gcopy" >> $t
# Local Variables:
# mode: shell-script
# sh-indentation: 2
-# eval: (add-hook 'write-file-hooks 'time-stamp)
+# eval: (add-hook 'before-save-hook 'time-stamp)
# time-stamp-start: "scriptversion="
# time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
# time-stamp-end: "; # UTC"
# End:
--
Matthieu Herrb
[UPDATE] libXpm 3.5.13
Hi, The diff below updates libXpm to version 3.5.13. Tests and oks welcome. Apply in $XSRCDIR/lib/libXpm and then rebuild xenocara following release(8). Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libXpm/ChangeLog,v retrieving revision 1.6 diff -u -p -u -r1.6 ChangeLog --- ChangeLog 16 Dec 2016 07:28:34 - 1.6 +++ ChangeLog 15 Dec 2019 18:27:04 - @@ -1,3 +1,131 @@ +commit b0fc485495a694816d76a43978e2cfd5575c554d +Author: Peter Hutterer +Date: Fri Dec 13 14:25:06 2019 +1000 + +libXpm 3.5.13 + +Signed-off-by: Peter Hutterer + +commit 5817fd4ac5308fe7c23301c652f174997009b7d5 +Author: Benjamin Tissoires +Date: Wed Dec 4 11:17:21 2019 +0100 + +parse: simplify error paths in xpmParseColors() + +We introduced a new label to handle the errors, we should use it +for the rest of the function. + +Signed-off-by: Benjamin Tissoires + +commit e1d8f704d52f70680869b7aae1da0ad2382db363 +Author: Peter Hutterer +Date: Thu Dec 5 06:17:00 2019 +1000 + +parse: avoid memleak on error with STRLCAT/STRLCPY + +The original macro might exit the function without freeing `colorTable`. + +Move the macros into a slightly less awful helper function and use goto +to clean up in case of error. + +Signed-off-by: Peter Hutterer + +commit 7af7c5e275b69daedee3696bee1e880586f30373 +Author: Fabrice Fontaine +Date: Fri May 3 07:59:09 2019 +0200 + +Allow usage when fork() is not available + +When fork() is not available, we need to define NO_ZPIPE so that +libXpm doesn't try to fork/exec to use a pipe to uncompress compressed +.xpm files. There is obviously a loss of functionality, but loading +uncompressed .xpm files should continue to work. + +Signed-off-by: Thomas Petazzoni +[Retrieved from: + https://git.buildroot.net/buildroot/tree/package/x11r7/xlib_libXpm/0001-fork-check.patch] +Signed-off-by: Fabrice Fontaine + +commit 0be2c6712728cea1fa1bcc640e564c45c2c82e37 +Author: Alan Coopersmith +Date: Fri Dec 7 19:47:06 2018 -0800 + +Update configure.ac bug URL for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit c9f8faf1c05fb92abc6c5b1db5e45eb1a7942875 +Author: Alan Coopersmith +Date: Mon Nov 19 22:30:30 2018 -0800 + +Update README for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 73a1e769dcf2a603fc63f5c36626c1c6db815f46 +Author: Alan Coopersmith +Date: Sun Sep 30 15:09:29 2018 -0700 + +After fdopen(), use fclose() instead of close() in error path + +Found by Oracle's Parfait 2.2 static analyzer: + +Error: File Leak + File Leak [file-ptr-leak]: + Leaked File fp +at line 94 of lib/libXpm/src/RdFToBuf.c in function 'XpmReadFileToBuffer +'. + fp initialized at line 86 with fdopen + fp leaks when len < 0 at line 92. + +Introduced-by: commit 8b3024e6871ce50b34bf2dff924774bd654703bc + +Signed-off-by: Alan Coopersmith +Reviewed-by: Peter Hutterer + +commit bc1b4962f048cfa33b76be46493e10cfb256fe98 +Author: Dave Bodenstab +Date: Wed Feb 22 12:04:54 2012 + + +Windows build fixes + +https://bugs.freedesktop.org/show_bug.cgi?id=46475 +https://bugs.freedesktop.org/attachment.cgi?id=57479 + +Signed-off-by: Alan Coopersmith + +commit e42ca7b484418b169fd19a4c68e23ad2a6ec7a11 +Author: Mihail Konev +Date: Thu Jan 26 13:52:49 2017 +1000 + +autogen: add default patch prefix + +Signed-off-by: Mihail Konev + +commit ed8f9c2e8b635eb63497c48b24a056f9e6f50609 +Author: Emil Velikov +Date: Mon Mar 9 12:00:52 2015 + + +autogen.sh: use quoted string variables + +Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent +fall-outs, when they contain space. + +Signed-off-by: Emil Velikov +Reviewed-by: Peter Hutterer +Signed-off-by: Peter Hutterer + +commit 644d7c595ba29fb368666fb497e1e14a92a65a77 +Author: Peter Hutterer +Date: Tue Jan 24 10:32:07 2017 +1000 + +autogen.sh: use exec instead of waiting for configure to finish + +Syncs the invocation of configure with the one from the server. + +Signed-off-by: Peter Hutterer +Reviewed-by: Emil Velikov + commit 1fab5e81fd761f628fb68d22934615536dbd0220 Author: Matthieu Herrb Date: Mon Dec 12 23:09:52 2016 +0100 Index: Makefile.am === RCS file: /cvs/OpenBSD/xenocara/lib/libXpm/Makefile.am,v retrieving revision 1.4 diff -u -p -u -r1.4 Makefile.am --- Makefile.am 10 Mar 2012 14:30:32 - 1.4 +++ Makefile.am 15 Dec 2019 18:27:04 - @@ -8,7 +8,7 @@ ACLOCAL_AMFLAGS = -I m4 pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = xpm.pc -EXTRA_DIST = COPYRIGHT NEWS.old +EXTRA_DIST = COPYRIGHT NEWS.old README.md MAINTAINERCLEANFILES = Change
Re: [Patch]: Integrate VA-API into xenocara
On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote: > This is a rather large patch that moves my previously submitted > VA-API ports into xenocara. For your convenience, I've inlined > a diff that shows you all of the changes I made to existing files > that you can easily read in your MUA. The attached patch also > contains these changes and should be the only xenocara patch > you need to apply. > > Summary of Changes: > - libva added to xenocara/lib/libva > - vainfo added to xenocara/app/vainfo > - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver > - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag > - 3RDPARTY file updated to include libva, libva-utils, and intel-vaapi-driver > - BSD.x11.dist updated to include /usr/X11R6/include/va/ (separate patch) > > Architectures Tested: amd64 > > Testing Instructions: > 1. save xenocara-vaapi.patch.gz to /tmp > 2. cd /tmp; gunzip xenocara-vaapi.patch.gz > 3. cd /usr/xenocara > 4. patch -p0 < /tmp/xenocara-vaapi.patch > 5. Follow normal build instructions in README within the root of xenocara > 6. Run vainfo. It should report available profiles and entrypoints for > VA-API. >Example of successful execution: Hi, I won't be able to look at this before the 28th, being busy for work and then away for vacation. Thaks for this work. -- Matthieu Herrb
update: X server to version 1.20.6
Hi,
The diff below update the X server to version 1.20.6.
See ChangeLog for changes.
Testing and oks are welcome.
Index: ChangeLog
===
RCS file: /cvs/OpenBSD/xenocara/xserver/ChangeLog,v
retrieving revision 1.33
diff -u -p -u -r1.33 ChangeLog
--- ChangeLog 27 Jul 2019 07:57:06 - 1.33
+++ ChangeLog 23 Nov 2019 11:51:22 -
@@ -1,3 +1,929 @@
+commit 6b3fafa9bfa94b9b04a1a44dc52afb7c4bc250ce
+Author: Matt Turner
+Date: Fri Nov 22 17:52:04 2019 -0500
+
+xserver 1.20.6
+
+Signed-off-by: Matt Turner
+
+commit 88f12aa74bf4fea25d5b8d8002b3088432feb405
+Author: Matt Turner
+Date: Thu Nov 21 11:23:18 2019 -0500
+
+xfree86: Test presence of isastream()
+
+isastream() was never more than a stub in glibc, and was removed in
+glibc-2.30 by commit a0a0dc83173c ("Remove obsolete, never-implemented
+XSI STREAMS declarations").
+
+Bug: https://bugs.gentoo.org/700838
+Reviewed-by: Julien Cristau
+Signed-off-by: Matt Turner
+(cherry picked from commit e6ab7f9f342f463092c45226f3294074351fdd5e)
+
+commit 0e60139064b84b856c59e5a456e26c60710b1b69
+Author: Olivier Fourdan
+Date: Mon Nov 18 17:28:45 2019 +0100
+
+present/wnmd: Relax assertion on CRTC on abort_vblank()
+
+Currently, the function `present_wnmd_abort_vblank()` would fail if the
+given `crtc` is NULL.
+
+However, `xwl_present_get_crtc()` can return `NULL` under some
+circumstances, which would cause an unexpected termination of Xwayland
+in such a case, caused by the assertion failure being triggered.
+
+Remove the assertion, considering that the `crtc` isn't actually used in
+neither `present_wnmd_abort_vblank()` nor `xwl_present_abort_vblank()`.
+
+Signed-off-by: Olivier Fourdan
+Reviewed-by: Michel Dänzer
+Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/937
+(cherry picked from commit 4f984fc06bd57cabfa38f6191f10714878dc8969)
+
+commit 2edadf26f1f8deddbe171115fa502337ac62df02
+Author: Aaron Plattner
+Date: Tue Nov 19 10:08:51 2019 -0800
+
+os: Don't crash in AttendClient if the client is gone
+
+If a client is in the process of being closed down, then its
client->osPrivate
+pointer will be set to NULL by CloseDownConnection. This can cause a crash
if
+freeing the client's resources results in a call to AttendClient. For
example,
+if the client has a pending sync fence:
+
+ Thread 1 "X" received signal SIGSEGV, Segmentation fault.
+ AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
+ (gdb) bt
+ #0 AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
+ #1 0x5571c3dbb865 in SyncAwaitTriggerFired (pTrigger=) at ../Xext/sync.c:694
+ #2 0x5571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at
../miext/sync/misync.c:120
+ #3 0x5571c3dbbc69 in FreeFence (obj=, id=) at ../Xext/sync.c:1909
+ #4 0x5571c3d7a01d in doFreeResource (res=0x5571c506e3d0,
skip=skip@entry=0) at ../dix/resource.c:880
+ #5 0x5571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at
../dix/resource.c:1146
+ #6 FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1109
+ #7 0x5571c3d5525f in CloseDownClient (client=0x5571c4aed9a0) at
../dix/dispatch.c:3473
+ #8 0x5571c3d55eeb in Dispatch () at ../dix/dispatch.c:492
+ #9 0x5571c3d59e96 in dix_main (argc=3, argv=0x7ffe7854bc28,
envp=) at ../dix/main.c:276
+ #10 0x7fea4837cb6b in __libc_start_main (main=0x5571c3d1d060 ,
argc=3, argv=0x7ffe7854bc28, init=, fini=,
rtld_fini=, stack_end=0x7ffe7854bc18) at ../csu/libc-start.c:308
+ #11 0x5571c3d1d09a in _start () at ../Xext/sync.c:2378
+ (gdb) print client->osPrivate
+ $1 = (void *) 0x0
+
+Since the client is about to be freed, its ignore count doesn't matter and
+AttendClient can simply be a no-op. Check for client->clientGone in
AttendClient
+and remove similar checks from two callers that had them.
+
+Signed-off-by: Aaron Plattner
+(cherry picked from commit 4308f5d3d1fbd0f5dce81e22c0c3f08c65a7c9d8)
+
+commit 68cfee97bc59580724d594c82f5ee55a980dadf0
+Author: Adam Jackson
+Date: Wed Oct 9 11:57:18 2019 -0400
+
+dix: Call SourceValidate before GetImage
+
+This ensures that any prep work for the drawable we're about to read
+from is already done before we call down to GetImage. This should be no
+functional change as most of the callers with a non-trivial
+SourceValidate are already wrapping GetImage and doing the equivalent
+thing, but we'll be simplifying that shortly.
+
+More importantly this ensures that if any of that prep work would
+generate events - like automatic compositing flushing rendering to a
+parent pixmap which then triggers damage - then it happens entirely
+before we start writing the GetImage
[UPDATE] xf86-video-amdgpu and xf86-video-ati to versions 19.1.0
rtc);
}
@@ -2695,18 +2704,20 @@ void RADEONLeaveVT_KMS(ScrnInfoPtr pScrn
(!clients[i] || clients[i]->clientState != ClientStateRunning))
continue;
- FindClientResourcesByType(clients[i], RT_PIXMAP, pixmap_unref_fb,
- pRADEONEnt);
+ FindClientResourcesByType(clients[i], RT_PIXMAP,
+ client_pixmap_unref_fb, pScreen);
}
- pixmap_unref_fb(pScreen->GetScreenPixmap(pScreen), None, pRADEONEnt);
+ pixmap_unref_fb(pScreen->GetScreenPixmap(pScreen));
} else {
memset(info->front_buffer->bo.radeon->ptr, 0,
pScrn->displayWidth * info->pixel_bytes * pScrn->virtualY);
}
-TimerSet(NULL, 0, 1000, cleanup_black_fb, pScreen);
+if (pScreen->GCperDepth[0])
+ TimerSet(NULL, 0, 1000, cleanup_black_fb, pScreen);
+ hide_cursors:
xf86_hide_cursors (pScrn);
radeon_drop_drm_master(pScrn);
Index: driver/xf86-video-ati/src/radeon_present.c
===
RCS file: /cvs/OpenBSD/xenocara/driver/xf86-video-ati/src/radeon_present.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 radeon_present.c
--- driver/xf86-video-ati/src/radeon_present.c 8 Mar 2019 21:59:57 -
1.6
+++ driver/xf86-video-ati/src/radeon_present.c 19 Oct 2019 16:23:21 -
@@ -254,6 +254,7 @@ radeon_present_check_flip(RRCrtcPtr crtc
xf86CrtcPtr xf86_crtc = crtc->devPrivate;
ScreenPtr screen = window->drawable.pScreen;
ScrnInfoPtr scrn = xf86_crtc->scrn;
+struct radeon_pixmap *priv = radeon_get_pixmap_private(pixmap);
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
RADEONInfoPtr info = RADEONPTR(scrn);
PixmapPtr screen_pixmap = screen->GetScreenPixmap(screen);
@@ -276,6 +277,23 @@ radeon_present_check_flip(RRCrtcPtr crtc
if (pixmap->devKind != screen_pixmap->devKind)
return FALSE;
#endif
+
+if (priv && priv->fb_failed)
+ return FALSE;
+
+if (!radeon_pixmap_get_fb(pixmap)) {
+ if (!priv)
+ priv = radeon_get_pixmap_private(pixmap);
+
+ if (priv && !priv->fb_failed) {
+ xf86DrvMsg(scrn->scrnIndex, X_WARNING,
+ "Cannot get FB for Present flip (may be "
+ "normal if using PRIME render offloading)\n");
+ priv->fb_failed = TRUE;
+ }
+
+ return FALSE;
+}
/* The kernel driver doesn't handle flipping between BOs with different
* tiling parameters correctly yet
--
Matthieu Herrb
Re: rcctl issues when running in non-default rdomain
On Thu, Sep 05, 2019 at 11:00:06PM +0200, Matthieu Herrb wrote:
> Hi,
>
> on my redundant firealls I have an " admin" interface in rdomain 1
> with a sshd listening, used to be able to access the slave machine and
> let it access the internet to be able to run syspatch or pkg_add.
>
> This works well, but but if I use rcctl in this non default rdomain to
> control services normally running in the default rdomain, things don't
> behave too well. In particular, 'rcctl start' or 'restart' starts the
> service with rtable 1.
>
> Alternatives would be to run the admin interface in the default rdomain
> and all other interfaces in a separate one, but it feels more painful
> to setup.
>
> It seems to me that the patch below helps, but may be it has other
> unforseen and unwanted effects ?
>
> Thoughts ?
I've been told privately that this was already handled. Indeed this
was a pair of firewalls still runnuing 6.4.
So issue closed. Thanks.
>
> Index: rc.subr
> ===
> RCS file: /cvs/OpenBSD/src/etc/rc.d/rc.subr,v
> retrieving revision 1.131
> diff -u -r1.131 rc.subr
> --- rc.subr 21 Mar 2019 15:10:27 - 1.131
> +++ rc.subr 5 Sep 2019 20:56:38 -
> @@ -320,5 +320,4 @@
> # make sure pexp matches the process (i.e. doesn't include the quotes)
> pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
> rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> -[ "${daemon_rtable}" -eq "$(id -R)" ] ||
> - rcexec="route -T ${daemon_rtable} exec ${rcexec}"
> +rcexec="route -T ${daemon_rtable} exec ${rcexec}"
>
>
> --
> Matthieu Herrb
--
Matthieu Herrb
rcctl issues when running in non-default rdomain
Hi,
on my redundant firealls I have an " admin" interface in rdomain 1
with a sshd listening, used to be able to access the slave machine and
let it access the internet to be able to run syspatch or pkg_add.
This works well, but but if I use rcctl in this non default rdomain to
control services normally running in the default rdomain, things don't
behave too well. In particular, 'rcctl start' or 'restart' starts the
service with rtable 1.
Alternatives would be to run the admin interface in the default rdomain
and all other interfaces in a separate one, but it feels more painful
to setup.
It seems to me that the patch below helps, but may be it has other
unforseen and unwanted effects ?
Thoughts ?
Index: rc.subr
===
RCS file: /cvs/OpenBSD/src/etc/rc.d/rc.subr,v
retrieving revision 1.131
diff -u -r1.131 rc.subr
--- rc.subr 21 Mar 2019 15:10:27 - 1.131
+++ rc.subr 5 Sep 2019 20:56:38 -
@@ -320,5 +320,4 @@
# make sure pexp matches the process (i.e. doesn't include the quotes)
pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
-[ "${daemon_rtable}" -eq "$(id -R)" ] ||
- rcexec="route -T ${daemon_rtable} exec ${rcexec}"
+rcexec="route -T ${daemon_rtable} exec ${rcexec}"
--
Matthieu Herrb
rad(8) and carp interfaces
Hi, I've a pair of redundant routers, which need to run rad(8) on the internal interfaces. But using carp, on the inactive router, rad complains every time it tries to send a RA: rad[65590]: sendmsg on carp2: Can't assign requested address Which I can understand since it currently doesnt "own" the shared IPv6 address of the carp interface. Is there a way to configure rad to avoid these errors? How do other people handle the situation? Thanks in advance, -- Matthieu Herrb
[UPDATE] freetype 2.10.1
Hi, The diff at https://herrb.eu/freetype-2.10.1-full.diff updates freetype to version 2.10.1. To test it, apply the patch to $XSRCDIR and rebuild Xenocara according the release(8) man page. Some things about about this update: - it is a major library bump. I took the opportunity to make the shared library build more in-line with what would be produced by the upstream build system: adding symbol visibility and a version map. The result is a lot less public symbols. Directly dependent X libraries (Xft, fontconfig and Xfont2) have been bumped too. - the new reference documentation includes a lot of huge binary or packed one-liner javascript files that break diff/patch. I've removed that part from the diff. I'm undecided wether to remove freetype-doc completely from $XSRCDIR and maybe add it as a port, or adding back all those binaries manually. Unfortunatly, I don't think that the documenation system that is used can easyly be converted to mandoc for inclusion as man pages instead (which would be ideal). Ingo ? - The new color emoji support is disabled, since there is no libpng or libharfbuzz in the base system. - The diff is too large to be sent inline. Sorry. This is the checksum of the file : SHA256 (freetype-2.10.1-full.diff) = 884e1b38691d15e582934f077b2b2b45fa7e79fe353130b4f9cf825e82bb97e6 ok, comments ? -- Matthieu Herrb
Re: arm64 glass console
On Sat, Aug 10, 2019 at 12:16:14AM +0200, Mark Kettenis wrote: > The diff below makes it possible to switch over to the framebuffer > console in the bootloader. Currently, we'll use whatever device is > designated in the device tree (or the ACPI SPCR table) as the console. > With this diff you can use: > > boot> set tty fb0 > > to override that default. > > ok? Hi, This works great on my PineBook 11" HD -- Matthieu Herrb
Re: [update] libxtrans 1.4.0
On Sun, Jul 14, 2019 at 06:31:13PM +0200, Matthieu Herrb wrote: > Hi, > > the patch below updates libxtrans to version 1.4.0. Since there is one > removed in a generated file used by other libs, there are also libX11 > and libICE major bumps. Ping. In particular, how is the schedule wrt major bumps ? I'd like to commit this (and the other libs updates) tomorrow (CET) if possible. > > comments, oks ? > > Index: lib/libICE/Makefile.bsd-wrapper > === > RCS file: /cvs/OpenBSD/xenocara/lib/libICE/Makefile.bsd-wrapper,v > retrieving revision 1.3 > diff -u -p -u -r1.3 Makefile.bsd-wrapper > --- lib/libICE/Makefile.bsd-wrapper 13 Aug 2013 07:07:12 - 1.3 > +++ lib/libICE/Makefile.bsd-wrapper 14 Jul 2019 15:36:48 - > @@ -1,5 +1,5 @@ > # $OpenBSD: Makefile.bsd-wrapper,v 1.3 2013/08/13 07:07:12 guenther Exp $ > > -SHARED_LIBS= ICE 10.0 > +SHARED_LIBS= ICE 11.0 > > .include > Index: lib/libX11/Makefile.bsd-wrapper > === > RCS file: /cvs/OpenBSD/xenocara/lib/libX11/Makefile.bsd-wrapper,v > retrieving revision 1.24 > diff -u -p -u -r1.24 Makefile.bsd-wrapper > --- lib/libX11/Makefile.bsd-wrapper 11 Mar 2016 13:09:42 - 1.24 > +++ lib/libX11/Makefile.bsd-wrapper 14 Jul 2019 15:36:49 - > @@ -1,7 +1,7 @@ > # $OpenBSD: Makefile.bsd-wrapper,v 1.24 2016/03/11 13:09:42 okan Exp $ > .include > > -SHARED_LIBS= X11 16.1 X11_xcb 2.0 > +SHARED_LIBS= X11 17.0 X11_xcb 2.0 > > CONFIGURE_ARGS= --enable-tcp-transport --enable-unix-transport --enable-ipv6 > \ > --disable-composecache \ > Index: lib/libxtrans/ChangeLog > === > RCS file: /cvs/OpenBSD/xenocara/lib/libxtrans/ChangeLog,v > retrieving revision 1.8 > diff -u -p -u -r1.8 ChangeLog > --- lib/libxtrans/ChangeLog 28 Sep 2014 16:56:06 - 1.8 > +++ lib/libxtrans/ChangeLog 14 Jul 2019 15:37:04 - > @@ -1,3 +1,213 @@ > +commit c4262efc9688e495261d8b23a12f956ab38e006f > +Author: Alan Coopersmith > +Date: Sat Mar 16 14:25:35 2019 -0700 > + > +xtrans 1.4.0 > + > +Signed-off-by: Alan Coopersmith > + > +commit faa42207a0653535ab80825b0acb50b417702ec4 > +Author: Alan Coopersmith > +Date: Fri Dec 7 19:52:43 2018 -0800 > + > +Update configure.ac bug URL for gitlab migration > + > +Signed-off-by: Alan Coopersmith > + > +commit cd22de616c77328da3410b1eaab541c2d331ffdb > +Author: Alan Coopersmith > +Date: Mon Nov 19 23:12:07 2018 -0800 > + > +Update README for gitlab migration > + > +Signed-off-by: Alan Coopersmith > + > +commit 06cfa80fb3d03ca03fd92f9687a77958338e012c > +Author: Alan Coopersmith > +Date: Sun Sep 30 17:04:51 2018 -0700 > + > +Use fchmod() instead of chmod() when creating named pipes > + > +Signed-off-by: Alan Coopersmith > + > +commit 7bd504f7ab7799ab77ad50eb39f6afdbaf2f9e50 > +Author: Alan Coopersmith > +Date: Sat Aug 25 11:18:52 2018 -0700 > + > +Use strcasecmp if it's available, instead of lowercasing strings > + > +Signed-off-by: Alan Coopersmith > + > +commit 941cfa50bc2d45f20943fd21bab98e2eceeeb259 > +Author: Alan Coopersmith > +Date: Sat Aug 25 10:45:04 2018 -0700 > + > +Set freeXLOCAL to NULL after freeing it to prevent double frees > + > +We shouldn't be calling the LocalEndTransports routine twice, but > +just make sure if we do, we don't call free twice on the same pointer. > + > +Signed-off-by: Alan Coopersmith > + > +commit a97e5fc6e4f294294d75500068892aea11952773 > +Author: Rin Okuyama > +Date: Tue Feb 21 06:18:37 2017 + > + > +avoid -Wformat errors from clang > + > +https://bugs.freedesktop.org/show_bug.cgi?id=99882 > + > +Reviewed-by: Alan Coopersmith > +Signed-off-by: Alan Coopersmith > + > +commit 28366676effaa512e43bfd2276a317389a992511 > +Author: Emil Velikov > +Date: Mon Mar 9 12:00:52 2015 + > + > +autogen.sh: use quoted string variables > + > +Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent > +fall-outs, when they contain space. > + > +Signed-off-by: Emil Velikov > +Reviewed-by: Peter Hutterer > +Signed-off-by: Peter Hutterer > + > +commit 8554cf05262ab6ad6e8da5f11022e5dc2a452e38 > +Author: Peter Hutterer > +Date: Tue Jan 24 10:32:07 2017 +1000 > + > +autogen.sh: use exec instead of waiting for configure to finish > + > +Syncs the invocation of configure with the one from the
Re: ldomctl.8: split config into new ldom.conf.5
On Sat, Jul 27, 2019 at 03:30:53AM +0200, Klemens Nanni wrote: > Index: usr.sbin/ldomd/Makefile > === > RCS file: /cvs/src/usr.sbin/ldomd/Makefile,v > retrieving revision 1.3 > diff -u -p -r1.3 Makefile > --- usr.sbin/ldomd/Makefile 27 Oct 2012 20:03:24 - 1.3 > +++ usr.sbin/ldomd/Makefile 27 Jul 2019 01:25:36 - > @@ -16,7 +16,7 @@ NOPROG= yes > > .endif > > -MAN= ldomd.8 > +MAN= ldomd.8 ldom.conf.5 > MANSUBDIR=sparc64 > > .include Here on amd64 this breaks the build: install -c -o root -g bin -m 444 /share/OpenBSD/src/usr.sbin/ldomd/ldomd.8 /usr/share/man/man8/sparc64/ldomd.8 install -c -o root -g bin -m 444 /share/OpenBSD/src/usr.sbin/ldomd/ldom.conf.5 /usr/share/man/man5/sparc64/ldom.conf.5 install: /usr/share/man/man5/sparc64/INS@uuYbA85wgn: No such file or directory *** Error 1 in /share/OpenBSD/src/usr.sbin/ldomd (:35 '/usr/share/man/man5/sparc64/ldom.conf.5') -- Matthieu Herrb
[update] libXdmcp 1.1.3
2... " >&6; }
+if ${ac_cv_lib_ws2_32_main+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ ac_check_lib_save_LIBS=$LIBS
+LIBS="-lws2_32 $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+
+int
+main ()
+{
+return main ();
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+ ac_cv_lib_ws2_32_main=yes
+else
+ ac_cv_lib_ws2_32_main=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ws2_32_main" >&5
+$as_echo "$ac_cv_lib_ws2_32_main" >&6; }
+if test "x$ac_cv_lib_ws2_32_main" = xyes; then :
+ cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBWS2_32 1
+_ACEOF
+
+ LIBS="-lws2_32 $LIBS"
+
+fi
+
+;;
+ *)
+;;
+esac
+
# Checks for library functions.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for arc4random_buf in -lbsd"
>&5
$as_echo_n "checking for arc4random_buf in -lbsd... " >&6; }
@@ -18703,7 +18794,7 @@
fi
-for ac_func in srand48 lrand48 arc4random_buf
+for ac_func in srand48 lrand48 arc4random_buf getentropy
do :
as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
@@ -19633,7 +19724,7 @@
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by libXdmcp $as_me 1.1.2, which was
+This file was extended by libXdmcp $as_me 1.1.3, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -19699,7 +19790,7 @@
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //;
s/[\\""\`\$]/&/g'`"
ac_cs_version="\\
-libXdmcp config.status 1.1.2
+libXdmcp config.status 1.1.3
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
Index: configure.ac
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdmcp/configure.ac,v
retrieving revision 1.6
diff -u -r1.6 configure.ac
--- configure.ac6 Apr 2015 13:43:53 - 1.6
+++ configure.ac14 Jul 2019 21:09:27 -
@@ -22,7 +22,7 @@
# Initialize Autoconf
AC_PREREQ([2.60])
-AC_INIT([libXdmcp], [1.1.2],
+AC_INIT([libXdmcp], [1.1.3],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXdmcp])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
@@ -55,9 +55,17 @@
# Checks for libraries.
AC_SEARCH_LIBS([recvfrom],[socket])
+case $host_os in
+ *mingw*)
+AC_CHECK_LIB([ws2_32],[main])
+;;
+ *)
+;;
+esac
+
# Checks for library functions.
AC_CHECK_LIB([bsd], [arc4random_buf])
-AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf])
+AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf getentropy])
# Obtain compiler/linker options for depedencies
PKG_CHECK_MODULES(XDMCP, xproto)
Index: doc/xdmcp.xml
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdmcp/doc/xdmcp.xml,v
retrieving revision 1.2
diff -u -r1.2 xdmcp.xml
--- doc/xdmcp.xml 10 Mar 2012 13:58:12 - 1.2
+++ doc/xdmcp.xml 14 Jul 2019 21:09:27 -
@@ -23,7 +23,7 @@
X Display Manager Control Protocol
X.Org Standard
- X Version 11, Release
+ X Version 11
Version 1.1
--
Matthieu Herrb
[update] libICE 1.0.10
-off-by: Benjamin Tissoires +Reviewed-by: Mark Kettenis +Reviewed-by: Alan Coopersmith +Signed-off-by: Peter Hutterer + +commit 1746abbb1ae1c41ba29c14895c5bd3f1334faef5 +Author: Mihail Konev +Date: Thu Jan 26 13:52:49 2017 +1000 + +autogen: add default patch prefix + +Signed-off-by: Mihail Konev + +commit 3aa14db63fefb7634b1bd4370e33ba14c4ea90ae +Author: Emil Velikov +Date: Mon Mar 9 12:00:52 2015 + + +autogen.sh: use quoted string variables + +Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent +fall-outs, when they contain space. + +Signed-off-by: Emil Velikov +Reviewed-by: Peter Hutterer +Signed-off-by: Peter Hutterer + +commit d41c57eaa0c1474acf0a6fb271f22106e3070016 +Author: Peter Hutterer +Date: Tue Jan 24 10:32:07 2017 +1000 + +autogen.sh: use exec instead of waiting for configure to finish + +Syncs the invocation of configure with the one from the server. + +Signed-off-by: Peter Hutterer +Reviewed-by: Emil Velikov + +commit ac4bb20e74e064b219de70e9b54516a921fdb7c3 +Author: Tobias Stoeckmann +Date: Tue Nov 22 20:13:29 2016 +0100 + +Fix use after free on subsequent calls + +The function IceAuthFileName is vulnerable to a use after free. The +flaw can be triggered by calling the function three times: + +- First call succeeds and stores the path in buf, a dynamically + allocated buffer with size bsize. +- Second call fails due to out of memory. It frees buf, but keeps + the old size in bsize. +- Third call only checks if bsize is large enough. Then it uses + buf without allocating it again -- the use after free happens. + +In order to exploit this, an attacker must change environment variables +between each call, namely ICEAUTHORITY or HOME. It also takes subsequent +calls. Due to these limitations, I don't consider this to be of high +priority. + +Reviewed-by: Matthieu Herrb + +commit b1720edc9b9f3e7a05caa3fcd81761e5818ea255 +Author: Remko van der Vossen +Date: Sun Jul 19 08:34:11 2015 -0700 + +Bug 90616 - libICE build fails on array bounds check + +https://bugs.freedesktop.org/show_bug.cgi?id=90616 + +Recent versions of gcc have array bounds checking turned on by default, +this leads to build failures of libICE. As the _IceVersionCount variable +in ICElibint.h is not declared const the compiler cannot assume that the +nested for loop in ProcessConnectionSetup stays within bounds. + +The simple fix is of course to change the declarations of _IceVersionCount, +_IceVersions, and the local variable myVersionCount to const declarations. + +Reviewed-by: Alan Coopersmith +Signed-off-by: Alan Coopersmith + +commit 8a511dad53774693ed818d54d7896e1663942b18 +Author: Jon TURNEY +Date: Sat Sep 13 17:13:44 2014 +0100 + +Include unistd.h for getpid() + +Signed-off-by: Jon TURNEY +Reviewed-by: David Macek + +commit fd22b62ae6380ddb00fa4c750f5ce175d2a6e76f +Author: Alan Coopersmith +Date: Sun Sep 14 13:08:17 2014 -0700 + +spec: Convert troff \*Q..\*U to DocBook ... + +Reported-by: Jasper St. Pierre +Signed-off-by: Alan Coopersmith +Reviewed-by: Jasper St. Pierre + commit 0dfab4253e26d5c6e5f058126eb5e9f7a7732ae8 Author: Alan Coopersmith Date: Fri Jun 6 18:28:28 2014 -0700 Index: Makefile.am === RCS file: /cvs/OpenBSD/xenocara/lib/libICE/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- Makefile.am 4 Mar 2012 18:57:08 - 1.4 +++ Makefile.am 14 Jul 2019 20:12:15 - @@ -19,3 +19,5 @@ lint: (cd src && $(MAKE) $(MFLAGS) lint) endif LINT + +EXTRA_DIST = README.md Index: Makefile.bsd-wrapper === RCS file: /cvs/OpenBSD/xenocara/lib/libICE/Makefile.bsd-wrapper,v retrieving revision 1.3 diff -u -r1.3 Makefile.bsd-wrapper --- Makefile.bsd-wrapper13 Aug 2013 07:07:12 - 1.3 +++ Makefile.bsd-wrapper14 Jul 2019 20:12:15 - @@ -1,5 +1,5 @@ # $OpenBSD: Makefile.bsd-wrapper,v 1.3 2013/08/13 07:07:12 guenther Exp $ -SHARED_LIBS= ICE 10.0 +SHARED_LIBS= ICE 11.0 .include Index: Makefile.in === RCS file: /cvs/OpenBSD/xenocara/lib/libICE/Makefile.in,v retrieving revision 1.11 diff -u -r1.11 Makefile.in --- Makefile.in 11 Oct 2016 22:15:18 - 1.11 +++ Makefile.in 14 Jul 2019 20:12:15 - @@ -51,7 +51,7 @@ build_triplet = @build@ host_triplet = @host@ subdir = . -DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \ +DIST_COMMON = $(am__configure_deps) $(srcdir)/Makefile.am \ $(srcdir)/Makefile.in $(srcdir)/config.h.in \ $(srcdir)/ice.pc.in $(top_srcdir)/configure AUTHORS COPYING \ ChangeLog INSTALL compile config.gues
[update] libXft 2.3.3
mat->depth);
- pa.repeat = True;
- info->colors[i].pict = XRenderCreatePicture (draw->dpy,
-pix,
-info->solidFormat,
-CPRepeat, );
- XFreePixmap (dpy, pix);
+if (info->hasSolid) {
+ /*
+* Free any existing entry
+*/
+ if (info->colors[i].pict)
+ XRenderFreePicture (dpy, info->colors[i].pict);
+ /*
+* Create picture
+*/
+ info->colors[i].pict = XRenderCreateSolidFill (draw->dpy,
>color);
+} else {
+ if (info->colors[i].screen != draw->screen && info->colors[i].pict)
+ {
+ XRenderFreePicture (dpy, info->colors[i].pict);
+ info->colors[i].pict = 0;
+ }
+ /*
+* Create picture if necessary
+*/
+ if (!info->colors[i].pict)
+ {
+ Pixmap pix;
+ XRenderPictureAttributespa;
+
+ pix = XCreatePixmap (dpy, RootWindow (dpy, draw->screen), 1, 1,
+info->solidFormat->depth);
+ pa.repeat = True;
+ info->colors[i].pict = XRenderCreatePicture (draw->dpy,
+pix,
+info->solidFormat,
+CPRepeat, );
+ XFreePixmap (dpy, pix);
+ }
+ /*
+* Set to the new color
+*/
+ info->colors[i].color = color->color;
+ info->colors[i].screen = draw->screen;
+ XRenderFillRectangle (dpy, PictOpSrc,
+ info->colors[i].pict,
+ >color, 0, 0, 1, 1);
}
-/*
- * Set to the new color
- */
info->colors[i].color = color->color;
info->colors[i].screen = draw->screen;
-XRenderFillRectangle (dpy, PictOpSrc,
- info->colors[i].pict,
- >color, 0, 0, 1, 1);
+
return info->colors[i].pict;
}
Index: src/xftint.h
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXft/src/xftint.h,v
retrieving revision 1.4
diff -u -p -u -r1.4 xftint.h
--- src/xftint.h11 Jun 2012 19:23:03 - 1.4
+++ src/xftint.h10 Jun 2019 16:52:02 -
@@ -245,6 +245,7 @@ typedef struct _XftDisplayInfo {
XExtCodes *codes;
FcPattern *defaults;
FcBool hasRender;
+FcBool hasSolid;
XftFont*fonts;
XRenderPictFormat *solidFormat;
unsigned long glyph_memory;
--
Matthieu Herrb
[update] libxtrans 1.4.0
Hi, the patch below updates libxtrans to version 1.4.0. Since there is one removed in a generated file used by other libs, there are also libX11 and libICE major bumps. comments, oks ? Index: lib/libICE/Makefile.bsd-wrapper === RCS file: /cvs/OpenBSD/xenocara/lib/libICE/Makefile.bsd-wrapper,v retrieving revision 1.3 diff -u -p -u -r1.3 Makefile.bsd-wrapper --- lib/libICE/Makefile.bsd-wrapper 13 Aug 2013 07:07:12 - 1.3 +++ lib/libICE/Makefile.bsd-wrapper 14 Jul 2019 15:36:48 - @@ -1,5 +1,5 @@ # $OpenBSD: Makefile.bsd-wrapper,v 1.3 2013/08/13 07:07:12 guenther Exp $ -SHARED_LIBS= ICE 10.0 +SHARED_LIBS= ICE 11.0 .include Index: lib/libX11/Makefile.bsd-wrapper === RCS file: /cvs/OpenBSD/xenocara/lib/libX11/Makefile.bsd-wrapper,v retrieving revision 1.24 diff -u -p -u -r1.24 Makefile.bsd-wrapper --- lib/libX11/Makefile.bsd-wrapper 11 Mar 2016 13:09:42 - 1.24 +++ lib/libX11/Makefile.bsd-wrapper 14 Jul 2019 15:36:49 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile.bsd-wrapper,v 1.24 2016/03/11 13:09:42 okan Exp $ .include -SHARED_LIBS= X11 16.1 X11_xcb 2.0 +SHARED_LIBS= X11 17.0 X11_xcb 2.0 CONFIGURE_ARGS= --enable-tcp-transport --enable-unix-transport --enable-ipv6 \ --disable-composecache \ Index: lib/libxtrans/ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libxtrans/ChangeLog,v retrieving revision 1.8 diff -u -p -u -r1.8 ChangeLog --- lib/libxtrans/ChangeLog 28 Sep 2014 16:56:06 - 1.8 +++ lib/libxtrans/ChangeLog 14 Jul 2019 15:37:04 - @@ -1,3 +1,213 @@ +commit c4262efc9688e495261d8b23a12f956ab38e006f +Author: Alan Coopersmith +Date: Sat Mar 16 14:25:35 2019 -0700 + +xtrans 1.4.0 + +Signed-off-by: Alan Coopersmith + +commit faa42207a0653535ab80825b0acb50b417702ec4 +Author: Alan Coopersmith +Date: Fri Dec 7 19:52:43 2018 -0800 + +Update configure.ac bug URL for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit cd22de616c77328da3410b1eaab541c2d331ffdb +Author: Alan Coopersmith +Date: Mon Nov 19 23:12:07 2018 -0800 + +Update README for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 06cfa80fb3d03ca03fd92f9687a77958338e012c +Author: Alan Coopersmith +Date: Sun Sep 30 17:04:51 2018 -0700 + +Use fchmod() instead of chmod() when creating named pipes + +Signed-off-by: Alan Coopersmith + +commit 7bd504f7ab7799ab77ad50eb39f6afdbaf2f9e50 +Author: Alan Coopersmith +Date: Sat Aug 25 11:18:52 2018 -0700 + +Use strcasecmp if it's available, instead of lowercasing strings + +Signed-off-by: Alan Coopersmith + +commit 941cfa50bc2d45f20943fd21bab98e2eceeeb259 +Author: Alan Coopersmith +Date: Sat Aug 25 10:45:04 2018 -0700 + +Set freeXLOCAL to NULL after freeing it to prevent double frees + +We shouldn't be calling the LocalEndTransports routine twice, but +just make sure if we do, we don't call free twice on the same pointer. + +Signed-off-by: Alan Coopersmith + +commit a97e5fc6e4f294294d75500068892aea11952773 +Author: Rin Okuyama +Date: Tue Feb 21 06:18:37 2017 + + +avoid -Wformat errors from clang + +https://bugs.freedesktop.org/show_bug.cgi?id=99882 + +Reviewed-by: Alan Coopersmith +Signed-off-by: Alan Coopersmith + +commit 28366676effaa512e43bfd2276a317389a992511 +Author: Emil Velikov +Date: Mon Mar 9 12:00:52 2015 + + +autogen.sh: use quoted string variables + +Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent +fall-outs, when they contain space. + +Signed-off-by: Emil Velikov +Reviewed-by: Peter Hutterer +Signed-off-by: Peter Hutterer + +commit 8554cf05262ab6ad6e8da5f11022e5dc2a452e38 +Author: Peter Hutterer +Date: Tue Jan 24 10:32:07 2017 +1000 + +autogen.sh: use exec instead of waiting for configure to finish + +Syncs the invocation of configure with the one from the server. + +Signed-off-by: Peter Hutterer +Reviewed-by: Emil Velikov + +commit 560d7550e23e9b14056b4a9b2569c2f256015f8a +Author: Jeremy Huddleston Sequoia +Date: Sat Sep 10 22:09:51 2016 -0700 + +Update strlcpy macro check to also check HAVE_STRLCPY + +xorg-server moved from HAS_STRLCPY to HAVE_STRLCPY in 2011 + +cf-xserver: d829a7c5cb42c979b58f3547136df5b05d906423 + +Signed-off-by: Jeremy Huddleston Sequoia + +commit 2e4c338eda8ec6996b7bacc1d0c7dfe7de925864 +Author: Adam Jackson +Date: Thu Sep 1 09:28:58 2016 -0400 + +Revert "Make FreeConnInfo static" + + ajax: 75419e6b6d985ea8796f05d1acb5e154b065c9b9 of xtrans also + seems to have broken xtest. + +And indeed it does, xts5 knows a fair amount about xlib internals for +some reason. Whether that's cromulent or
Re: ssh-askpass(1): fix indicator size with multiple screens
On Sun, Jun 16, 2019 at 09:55:24PM +1000, Damien Miller wrote: > > > On Sun, 16 Jun 2019, Matthieu Herrb wrote: > > > On Sun, Jun 09, 2019 at 04:47:53PM +0200, Matthieu Herrb wrote: > > > Hi, > > > > > > ssh-askpass(1) is trying to be clever and computes the size of its > > > indicator relatively to the screen resolution. > > > > > > Unfortunatly, when multiple screens are present, this gets ugly. The > > > support for Xinerama correctly computes the dimensions of the window > > > to be created, relatively to the screen on which it will appear, but > > > the computation of the indicator size is based on the size of the > > > whole display, resulting in too small indicators (and too many of them > > > if the screens hare layed out horizontally). > > > > > > The patch below fixes that by computing the resolution of the whole > > > display before taking xinerama into account. > > > > > > A better fix would be to make this application really aware of XRandR > > > and use the actual screen resolution from XRandR; this is an > > > interesting project, if anyone wants to give it a try. > > > > > > ok? > > > > ping > > ok djm. Thanks, > Is there an upstream for ssh-askpass? The old one I have > http://www.jmknoble.net/software/x11-ssh-askpass/ doesn't resolve any more. I have the same (dead) reference in /usr/xenocara/3RDPARTY and google can't find any newer home, except https://github.com/sigmavirus24/x11-ssh-askpass but it's just a mirror of the original code, without anything new. -- Matthieu Herrb
