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: 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
some fvwmrc defautlts changes
+*SshChoice 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: 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
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: 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 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: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);
xenodm : don't add authorizations for tcp connections by default
tAddrs ();
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), &statb) != -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: 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
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 dif
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
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
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: 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
[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: [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
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
update: X server 21.1.4
n 1.28
diff -u -p -u -r1.28 utils.c
--- os/utils.c 20 Feb 2022 17:41:35 - 1.28
+++ os/utils.c 30 Aug 2022 17:15:39 -
@@ -693,7 +693,6 @@ ProcessCommandLine(int argc, char *argv[
ErrorF("Failed to disable listen for %s transport",
defaultNoListenList[i]);
}
-SeatId = getenv("XDG_SEAT");
for (i = 1; i < argc; i++) {
/* call ddx first, so it can peek/override if it wants */
Index: present/present_scmd.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/present/present_scmd.c,v
retrieving revision 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
xterm at 30bpp with TrueType fonts regression
getRGB(red, 0);
-getRGB(green, 1);
-getRGB(blue, 2);
-
-#undef getRGB
-
+#define nRGB(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, &color);
+ XQueryColor(TScreenOf(xw)->display, cmap, &color);
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, &color);
+ XQueryColor(TScreenOf(xw)->display, xw->core.colormap, &color);
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, &work)) {
- DIM_IT(red);
+last_in = result;
+if (XQueryColor(TScreenOf(xw)->display, xw->core.colormap, &work))
{
+ DIM_IT(red);
DIM_IT(green);
DIM_IT(blue);
if (allocateBestRGB(xw, &work)) {
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
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
Re: [please test] pvclock(4): fix several bugs
Qemu 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 patch for X*IfEvent() API issues
1:35 -
@@ -50,6 +50,7 @@ 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
Update to xterm 375
s 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
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: Sat
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
libX11 patch for X*IfEvent() API issues, take #2
rieving 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: 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&m=166332904632232&w=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
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&m=166332904632232&w=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
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: 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 = X
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: Diff for evaluation (WACOM tablet driver)
+ printf("0x%x\n", usbd_req_stat);
>
> uhidev_get_report_desc(uha->parent, &desc, &size);
> 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,
> - &reportbuf, 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, &report_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->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, &ms->sc_loc_x);
> y = hid_get_data(data, len, &ms->sc_loc_y);
> + pressure = hid_get_data(data, len, &ms->sc_loc_z);
> + distance = hid_get_data(data, len, &ms->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, &ms->sc_loc_btn[i]))
> - buttons |= (1 << i);
> -
> - if (sc->sc_flags & UWACOM_USE_PRESSURE) {
> - pressure = hid_get_data(data, len, &sc->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, &ms->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, &ms->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: Diff for evaluation (WACOM tablet driver)
(HUP_WACOM | HUP_DIGITIZERS, HUD_TABLET_FKEYS),
> + HCOLL_PHYSICAL))) {
> + DPRINTF("found tablet keys collection\n");
> + pad_buttons_hid_parser(ms, tablet_keys_col, &flags);
> + }
> + 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, &ms->sc_loc_x, &flags))
> 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: 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, &now);
> 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
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/l
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: 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: 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.
@@
Re: Term::Cap full revamp
}
> -else
> -{
> +} else {
> $state = 0;# we're already finished
> }
> }
>
> -# This is eval'ed inside the while loop for each file
> -$search = q{
> - while () {
> - 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
[UPDATE] xcb-proto and libxcb 1.14
6)
self.add_type('INT32', '', ('int32_t',), tint32)
self.add_type('INT64', '', ('int64_t',), tint64)
-self.add_type('BYTE', '', ('uint8_t',), tcard8)
-self.add_type('BOOL', '', ('uint8_t',), tcard8)
+self.add_type('BYTE', '', ('uint8_t',), tbyte)
+self.add_type('BOOL', '', ('uint8_t',), tbool)
self.add_type('char', '', ('char',), tchar)
self.add_type('float', '', ('float',), tfloat)
self.add_type('double', '', ('double',), tdouble)
-self.add_type('void', '', ('void',), tcard8)
+self.add_type('void', '', ('void',), tvoid)
# This goes out and parses the rest 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: 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: 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 915cc10776
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
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: 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: 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: 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: 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
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 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
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: [bugfix] xterm(1) needs "cpath" pledge(2)
On Sun, Jul 29, 2018 at 07:28:19AM +0200, Sebastien Marie wrote:
> Hi,
>
> First, thanks to (trying) to search for solve the problem you encountered.
>
> On Sat, Jul 28, 2018 at 10:08:04PM +0300, Leonid Bobrov wrote:
> > Hi!
> >
> > Like I said yesterday, I don't know how to reproduce this bug, it just
> > happened to me and I got this dmesg(1):
> > xterm[90461]: pledge "cpath", syscall 5
> >
> > Right now I quickly grep(1)'ed xterm(1)'s source code:
> > mazocomp$ egrep "mkdir\(|unlink\(|rmdir\(" -R . -n
> > ./misc.c:760: && mkdir(filename, 0700) == 0) {
> > ./misc.c:804: unlink(xterm_cursor_theme);
> > ./misc.c:805: rmdir(my_path);
> >
>
> your search isn't accurate regarding the error message you got.
>
> the pledge error in dmesg could be read as:
> xterm (pid 90461) has been killed due to pledge violation.
> the program tried to use syscall 5 using "cpath" promise, but it
> didn't pledged for it.
>
> what is the syscall 5 ?
>
> $ grep '5$' /usr/include/sys/syscall.h
> #define SYS_open5
>
> So it is an open(2) call which need "cpath".
>
> if it needs "cpath", the flags argument of open(2) should contains
> O_CREAT:
>
> kern/vfs_syscalls.c
> 1018 if (oflags & O_CREAT)
> 1019 ni_pledge |= PLEDGE_CPATH;
>
>
> so at some point after calling pledge(2), xterm called open(?, ?|O_CREAT).
>
> it could be a direct call to open(2), or an indirect call (like calling
> fopen(3) with "w").
>
> if you search in xterm code source, you should find several occurrences
> of such calls. But like deraadt@ told you, you should also ensure this
> call is effectively *after* the pledge call.
>
> as hint, you know it seems to be triggerable from some keyboard
> combinaison. enumerating what xterm does by default for such things
> could help too to track the problem.
>
> there is a open(2) call somewhere: the pledge violation is proof of
> that. but the solution isn't necessary to allow this file creation (by
> bindly extending the pledge promises). it could be to disallow the file
> creation.
>
> but to decide, we should know *what* triggered this behaviour.
Hi,
After digging a bit, there is at least the 'Print All Immediatly'
function from button 1 menu that will trigger the creation of a file
and violate the pledge.
see xtermPrintImmediately() in print.c:789. The fopen() itself appears
in charToPrinter() on line 498 of the same file.
Should this feature be disabled in xterm ?
--
Matthieu Herrb
update libxcb to 1.13.1
output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext
2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"'
+ output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext
2>&1 | $GREP -v "^Configured with:" | $GREP " \-L"'
else
# FIXME: insert proper C++ library support
@@ -7286,7 +7301,7 @@ if test yes != "$_lt_caught_CXX_error";
# Commands to make compiler produce verbose output that lists
# what "hidden" libraries, object files and flags are used when
# linking a shared library.
- output_verbose_link_cmd='$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"'
+ output_verbose_link_cmd='$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP " \-L"'
else
# g++ 2.7 appears to require '-G' NOT '-shared' on this
# platform.
@@ -7297,7 +7312,7 @@ if test yes != "$_lt_caught_CXX_error";
# Commands to make compiler produce verbose output that lists
# what "hidden" libraries, object files and flags are used when
# linking a shared library.
- output_verbose_link_cmd='$CC -G $CFLAGS -v conftest.$objext
2>&1 | $GREP -v "^Configured with:" | $GREP "\-L"'
+ output_verbose_link_cmd='$CC -G $CFLAGS -v conftest.$objext
2>&1 | $GREP -v "^Configured with:" | $GREP " \-L"'
fi
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-R $wl$libdir'
Index: dist/libxcb/src/xcb_in.c
===
RCS file: /cvs/OpenBSD/xenocara/dist/libxcb/src/xcb_in.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 xcb_in.c
--- dist/libxcb/src/xcb_in.c11 Sep 2018 19:34:56 - 1.12
+++ dist/libxcb/src/xcb_in.c27 Sep 2018 19:16:38 -
@@ -958,8 +958,20 @@ void _xcb_in_replies_done(xcb_connection
pend = container_of(c->in.pending_replies_tail, struct pending_reply,
next);
if(pend->workaround == WORKAROUND_EXTERNAL_SOCKET_OWNER)
{
-pend->last_request = c->out.request;
-pend->workaround = WORKAROUND_NONE;
+if (XCB_SEQUENCE_COMPARE(pend->first_request, <=, c->out.request))
{
+pend->last_request = c->out.request;
+pend->workaround = WORKAROUND_NONE;
+} else {
+/* The socket was taken, but no requests were actually sent
+ * so just discard the pending_reply that was created.
+ */
+struct pending_reply **prev_next = &c->in.pending_replies;
+while (*prev_next != pend)
+prev_next = &(*prev_next)->next;
+*prev_next = NULL;
+c->in.pending_replies_tail = prev_next;
+free(pend);
+}
}
}
}
Index: dist/libxcb/src/xcb_out.c
===
RCS file: /cvs/OpenBSD/xenocara/dist/libxcb/src/xcb_out.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 xcb_out.c
--- dist/libxcb/src/xcb_out.c 2 Sep 2016 10:09:43 - 1.10
+++ dist/libxcb/src/xcb_out.c 27 Sep 2018 19:16:38 -
@@ -387,8 +387,14 @@ int xcb_take_socket(xcb_connection_t *c,
{
c->out.return_socket = return_socket;
c->out.socket_closure = closure;
-if(flags)
-_xcb_in_expect_reply(c, c->out.request,
WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
+if(flags) {
+/* c->out.request + 1 will be the first request sent by the
external
+ * socket owner. If the socket is returned before this request is
sent
+ * it will be detected in _xcb_in_replies_done and this
pending_reply
+ * will be discarded.
+ */
+_xcb_in_expect_reply(c, c->out.request + 1,
WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
+}
assert(c->out.request == c->out.request_written);
*sent = c->out.request;
}
Index: lib/libxcb/src/Makefile
===
RCS file: /cvs/OpenBSD/xenocara/lib/libxcb/src/Makefile,v
retrieving revision 1.10
diff -u -p -u -r1.10 Makefile
--- lib/libxcb/src/Makefile 11 Sep 2018 19:34:57 - 1.10
+++ lib/libxcb/src/Makefile 27 Sep 2018 19:17:51 -
@@ -6,7 +6,7 @@
DATADIR= ${X11BASE}/share
PYTHON= python${PYTHON_VERSION}
-MANOPTIONS=-c 'libxcb 1.13' -l 'X Version 11' -s 3
+MANOPTIONS=-c 'libxcb 1.13.1' -l 'X Version 11' -s 3
SRCS= \
bigreq.c \
Index: lib/libxcb/src/config.h
===
RCS file: /cvs/OpenBSD/xenocara/lib/libxcb/src/config.h,v
retrieving revision 1.6
diff -u -p -u -r1.6 config.h
--- lib/libxcb/src/config.h 11 Sep 2018 19:34:57 - 1.6
+++ lib/libxcb/src/config.h 27 Sep 2018 19:18:59 -
@@ -77,7 +77,7 @@
#define PACKAGE_NAME "libxcb"
/* Define to the full name and version of this package. */
-#define PACKAGE_STRING "libxcb 1.13"
+#define PACKAGE_STRING "libxcb 1.13.1"
/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "libxcb"
@@ -86,7 +86,7 @@
#define PACKAGE_URL ""
/* Define to the version of this package. */
-#define PACKAGE_VERSION "1.13"
+#define PACKAGE_VERSION "1.13.1"
/* Major version of this package */
#define PACKAGE_VERSION_MAJOR 1
@@ -95,7 +95,7 @@
#define PACKAGE_VERSION_MINOR 13
/* Patch version of this package */
-#define PACKAGE_VERSION_PATCHLEVEL 0
+#define PACKAGE_VERSION_PATCHLEVEL 1
/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1
--
Matthieu Herrb
Re: unveil xserver's priv proc
On Wed, Oct 24, 2018 at 10:36:58AM +0100, Ricardo Mestre wrote:
> Hello,
>
> semarie@ already gave positive feedback for unveiling xserver, did
> anyone tested it yet and comment on it or OK?
Sorry I almost forgot I was running with this patch for some days
now.
ok matthieu@
>
> Index: privsep.c
> ===
> RCS file: /cvs/xenocara/xserver/os/privsep.c,v
> retrieving revision 1.29
> diff -u -p -u -r1.29 privsep.c
> --- privsep.c 6 Aug 2018 20:11:34 - 1.29
> +++ privsep.c 24 Oct 2018 09:35:01 -
> @@ -274,6 +274,10 @@ priv_init(uid_t uid, gid_t gid)
> setproctitle("[priv]");
> close(socks[1]);
>
> + for (dev = allowed_devices; dev->name != NULL; dev++) {
> + if (unveil(dev->name, "rw") == -1)
> + err(1, "unveil");
> + }
> if (pledge("stdio rpath wpath sendfd proc", NULL) == -1)
> err(1, "pledge");
>
--
Matthieu Herrb
Re: unveil bdftopcf
On Wed, Oct 24, 2018 at 11:24:59AM +0100, Ricardo Mestre wrote:
> Hi,
>
> If input_name is provided we can unveil it with read permissions, if
> output_name is provided we need to unveil this one with rwc. Additionally
> depending on the different combinations of if these files are passed via args
> or from stdin/to stdout we can also pledge accordingly to the code path. This
> has been tested succefully with bdf fonts we have bundled in
> xenocara.
This one looks ok, but it lacks autoconf support to allow the
application to build on other systems.
>
> Since I have several other X apps unveiled and/or pledged could you please
> comment not only with the unveil/pledge part, but also err vs fprintf/exit,
> the
> placement of the #includes and also tabs vs spaces?
Generally, I'm not too found of pledging/unveiling random X client
programs. There are a lot of "hidden" features in X libraries that
will probably break with too strict pledges and/or unveils.
Also since this is OpenBSD-specific, it will be difficult to get it
upstreams, especially if you don't provide the autoconf goo to make
the code still build/work on Linux. And when not upstreaming it
creates more burden to merge new versions of the applications.
>
> Index: bdftopcf.c
> ===
> RCS file: /cvs/xenocara/app/bdftopcf/bdftopcf.c,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 bdftopcf.c
> --- bdftopcf.c29 Mar 2018 20:34:30 - 1.5
> +++ bdftopcf.c24 Oct 2018 10:15:41 -
> @@ -38,7 +38,9 @@ from The Open Group.
> #include "fntfil.h"
> #include "bdfint.h"
> #include "pcf.h"
> +#include
> #include
> +#include
> #include
>
> int
> @@ -158,6 +160,26 @@ main(int argc, char *argv[])
> }
> argv++;
> }
> +
> + if (input_name) {
> + if (unveil(input_name, "r") == -1)
> + err(1, "unveil");
> + }
> + if (output_name) {
> + if (unveil(output_name, "rwc") == -1)
> + err(1, "unveil");
> + if (pledge("stdio rpath wpath cpath", NULL) == -1)
> + err(1, "pledge");
> + }
> + if (input_name && !output_name) {
> + if (pledge("stdio rpath", NULL) == -1)
> + err(1, "pledge");
> + }
> + if (!input_name && !output_name) {
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> + }
> +
> if (input_name) {
> input = FontFileOpen(input_name);
> if (!input) {
--
Matthieu Herrb
signature.asc
Description: PGP signature
Xenocara: disable xdm-authorization-1 cleanly
Hi,
The XDM-AUTHORIZATION-1 protocol is currenly disabled in xenocara.
It makes sense: this auth protocol doesn't work with IPv6, is relying
on weak DES encryption and only useful with XDMP which isn't supported
by xenodm.
But it's currently only disabled as a side-effect of a buggy check in
xenodm. (If written correctly the test whould enable it...).
This buggy check is a left-over from xdm, and is useless for xenodm.
So let's remove it, and explicitely disable xdm-auth-1 in xserver.
ok ?
Index: app/xenodm/configure.ac
===
RCS file: /cvs/xenocara/app/xenodm/configure.ac,v
retrieving revision 1.9
diff -u -r1.9 configure.ac
--- app/xenodm/configure.ac 15 Jul 2018 09:05:11 - 1.9
+++ app/xenodm/configure.ac 1 Nov 2018 11:49:32 -
@@ -198,8 +198,6 @@
XENODM_CFLAGS="$XENODM_CFLAGS $DMCP_CFLAGS $XLIB_CFLAGS $AUTH_CFLAGS
$STATIC_GREETER_CFLAGS"
XENODM_LIBS="$XENODM_LIBS $DMCP_LIBS"
-AC_CHECK_LIB(Xdmcp, XdmcpWrap, [xdmauth="yes"], [xdmauth="no"], [$DMCP_LIBS])
-
AC_SUBST(XENODM_CFLAGS)
AC_SUBST(XENODM_LIBS)
Index: xserver/Makefile.bsd-wrapper
===
RCS file: /cvs/xenocara/xserver/Makefile.bsd-wrapper,v
retrieving revision 1.67
diff -u -r1.67 Makefile.bsd-wrapper
--- xserver/Makefile.bsd-wrapper25 Oct 2018 21:55:18 - 1.67
+++ xserver/Makefile.bsd-wrapper1 Nov 2018 11:49:32 -
@@ -35,7 +35,7 @@
--with-module-dir=${LIBDIR}/modules ${GLX_OPTION} \
--disable-install-setuid --enable-privsep \
${KDRIVE_OPTION} \
- --enable-xcsecurity \
+ --enable-xcsecurity --disable-xdm-auth-1 \
--without-fop --without-xmlto --without-xsltproc \
--disable-dmx ${NO_XORG_OPTION} \
--disable-unit-tests \
--
Matthieu Herrb
Re: pledge xenodm
On Fri, Nov 02, 2018 at 07:03:11PM +, Ricardo Mestre wrote:
> Hi,
>
> Looking at pledging xenodm a little bit more I was able to run it with
> the diff below across X restarts, with stock configuration.
>
> Please test it, if you have special configs better since most likely
> this will break it but we need to know where and why and with that maybe
> trim xenodm's bloat.
Hi,
xenodm crashes if one logs out from the first session that was
created. the pldege() call in StartDisplay is too strict.
I've not had time to fully figure out if this can be fixed. Iirc I
tried when I did the initial work on adding pledge to xenodm and it's
not possible because of the code that creates the auth cookie and
chown()s it to _x11.
I didn't have time yet to do a more serious testing of the session
pledge.
>
> DisplayManager:
> rpath: open(2) /etc/X11/xenodm/xenodm-config
> cpath: unlink(2) d->authFile
> proc: kill(2)
>
> Session:
> rpath: open(2) /etc/fbtab
> wpath/cpath: open(2) d->authFile
> fattr: chmod(2) d->authFile
> dns: sysctl(2) for name resolution
> proc: kill(2)
> exec: execve(2) /etc/X11/xenodm/TakeConsole
> id: setuid(2)
>
> Index: dm.c
> ===
> RCS file: /cvs/xenocara/app/xenodm/xenodm/dm.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 dm.c
> --- dm.c 11 Jul 2018 16:57:04 - 1.6
> +++ dm.c 31 Oct 2018 15:15:49 -
> @@ -604,6 +604,10 @@ StartDisplay (struct display *d)
> Debug ("pid: %d\n", pid);
> d->pid = pid;
> d->status = running;
> +
> + if (pledge("stdio rpath cpath proc", NULL) == -1)
> + exit(OPENFAILED_DISPLAY);
> +
> break;
> }
> }
> Index: session.c
> ===
> RCS file: /cvs/xenocara/app/xenodm/xenodm/session.c,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 session.c
> --- session.c 11 Jul 2018 20:28:41 - 1.12
> +++ session.c 31 Oct 2018 15:15:49 -
> @@ -378,6 +378,10 @@ StartClient (
> default:
> Debug ("StartSession, fork succeeded %d\n", pid);
> *pidp = pid;
> +
> + if (pledge("stdio rpath wpath cpath fattr dns proc exec id", NULL) ==
> -1)
> + exit(25);
> +
> return 1;
> }
> }
>
> - End forwarded message -
--
Matthieu Herrb
xenodm: remove unused 'keyFile' resource
Hi,
The 'keyfile' resource is not used anymore in xenodm (it was used to
specify the secret keys for the XDM-AUTHORIZATION-1 authentication
protocol in xdm with xdmcp).
ok?
Index: config/xenodm-config.in
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/config/xenodm-config.in,v
retrieving revision 1.4
diff -u -p -u -r1.4 xenodm-config.in
--- config/xenodm-config.in 5 Sep 2017 17:48:07 - 1.4
+++ config/xenodm-config.in 3 Nov 2018 16:37:43 -
@@ -2,7 +2,6 @@
!
DisplayManager.authDir:@XENODMXAUTHDIR@
DisplayManager.errorLogFile: @XENODMLOGDIR@/xenodm.log
-DisplayManager.keyFile:@XENODMCONFIGDIR@/xenodm-keys
DisplayManager.servers:@XENODMCONFIGDIR@/Xservers
DisplayManager*resources: @XENODMCONFIGDIR@/Xresources
! All displays should use authorization, but we cannot be sure
Index: include/dm.h
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/include/dm.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 dm.h
--- include/dm.h10 Jul 2018 14:20:42 - 1.13
+++ include/dm.h3 Nov 2018 16:35:48 -
@@ -182,7 +182,6 @@ extern int daemonMode;
extern char*authDir;
extern int autoRescan;
extern int removeDomainname;
-extern char*keyFile;
extern char**exportList;
extern struct display *FindDisplayByName (char *name),
Index: xenodm/resource.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/xenodm/resource.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 resource.c
--- xenodm/resource.c 10 Jul 2018 15:32:27 - 1.4
+++ xenodm/resource.c 3 Nov 2018 16:36:16 -
@@ -50,7 +50,6 @@ int sourceAddress;
char *authDir;
intautoRescan;
intremoveDomainname;
-char *keyFile;
char **exportList;
#define DM_STRING 0
@@ -95,9 +94,6 @@ char **exportList;
#ifndef DEF_USER_AUTH_DIR
# define DEF_USER_AUTH_DIR "/tmp"
#endif
-#ifndef DEF_KEY_FILE
-# define DEF_KEY_FILE ""
-#endif
#ifndef DEF_ACCESS_FILE
# define DEF_ACCESS_FILE ""
#endif
@@ -122,8 +118,6 @@ struct dmResources {
"true"} ,
{ "removeDomainname","RemoveDomainname",DM_BOOL,(char **) &removeDomainname,
"true"} ,
-{ "keyFile", "KeyFile", DM_STRING, &keyFile,
- DEF_KEY_FILE} ,
{ "exportList","ExportList", DM_ARGV,(char **) &exportList,
""} ,
{ "sourceAddress","SourceAddress",DM_BOOL, (char **) &sourceAddress,
--
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
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
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
possible fix for Xorg 21.1.1 crashes
ice->spriteInfo->sprite->spriteTrace[i];
-if (CheckPassiveGrabsOnWindow(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
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, &event->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 *) &event, FALSE,
+rc = (CheckPassiveGrabsOnWindow(win, dev, &event, 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 = (CheckPassiveG
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
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(&tmp, "%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: 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: 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
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: 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
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: 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: 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
ssh-askpass(1): fix indicator size with multiple screens
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?
Index: x11-ssh-askpass.c
===
RCS file: /cvs/OpenBSD/xenocara/app/ssh-askpass/x11-ssh-askpass.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 x11-ssh-askpass.c
--- x11-ssh-askpass.c 24 Apr 2015 02:19:41 - 1.6
+++ x11-ssh-askpass.c 9 Jun 2019 14:32:59 -
@@ -1507,6 +1507,12 @@ int main(int argc, char **argv)
app.screen_height = HeightOfScreen(app.screen);
app.screen_xoffset = 0;
app.screen_yoffset = 0;
+
+ app.xResolution =
+ app.screen_width * 1000 / WidthMMOfScreen(app.screen);
+ app.yResolution =
+ app.screen_height * 1000 / HeightMMOfScreen(app.screen);
+
if (XineramaIsActive(app.dpy) &&
(screens = XineramaQueryScreens(app.dpy, &nscreens)) != NULL &&
nscreens) {
@@ -1516,11 +1522,6 @@ int main(int argc, char **argv)
app.screen_yoffset = screens[0].y_org;
XFree(screens);
}
-
- app.xResolution =
- app.screen_width * 1000 / WidthMMOfScreen(app.screen);
- app.yResolution =
- app.screen_height * 1000 / HeightMMOfScreen(app.screen);
createDialog(&app);
createGCs(&app);
--
Matthieu Herrb
libXfont2: disable font server code
Hi, We disabled almost all X font server support code already. The patch below removes support for connecting to a font server from libXfont2. It means that you X server will no longer be able to use fonts from a remote font server. But did you even know this was possible ? ok? comments? Index: Makefile.bsd-wrapper === RCS file: /cvs/OpenBSD/xenocara/lib/libXfont2/Makefile.bsd-wrapper,v retrieving revision 1.2 diff -u -r1.2 Makefile.bsd-wrapper --- Makefile.bsd-wrapper26 May 2018 07:51:00 - 1.2 +++ Makefile.bsd-wrapper9 Jun 2019 17:15:38 - @@ -3,6 +3,6 @@ SHARED_LIBS= Xfont2 1.0 -CONFIGURE_ARGS+= --with-xmlto=no --disable-devel-docs +CONFIGURE_ARGS+= --disable-fc --with-xmlto=no --disable-devel-docs .include -- Matthieu Herrb
update: libXdmcp 1.1.3
DMIN_MAN_DIR = x; then
@@ -18262,6 +18294,11 @@ esac
fi
# Test for the ability of xmlto to generate a text target
+#
+# NOTE: xmlto 0.0.27 or higher return a non-zero return code in the
+# following test for empty XML docbook files.
+# For compatibility reasons use the following empty XML docbook file and if
+# it fails try it again with a non-empty XML file.
have_xmlto_text=no
cat > conftest.xml << "EOF"
EOF
@@ -18269,10 +18306,18 @@ if test "$have_xmlto" = yes; then :
if $XMLTO --skip-validation txt conftest.xml >/dev/null 2>&1; then :
have_xmlto_text=yes
else
+ # Try it again with a non-empty XML file.
+ cat > conftest.xml << "EOF"
+
+EOF
+ if $XMLTO --skip-validation txt conftest.xml >/dev/null 2>&1;
then :
+ have_xmlto_text=yes
+else
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: xmlto cannot generate text
format, this format skipped" >&5
$as_echo "$as_me: WARNING: xmlto cannot generate text format, this format
skipped" >&2;}
fi
fi
+fi
rm -f conftest.xml
if test $have_xmlto_text = yes; then
HAVE_XMLTO_TEXT_TRUE=
@@ -18657,6 +18702,52 @@ if test "$ac_res" != no; then :
fi
+case $host_os in
+ *mingw*)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in
-lws2_32" >&5
+$as_echo_n "checking for main in -lws2_32... " >&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 @@ _ACEOF
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 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
# 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 @@ _ACEOF
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 -p -u -r1.6 configure.ac
--- configure.ac6 Apr 2015 13:43:53 - 1.6
+++ configure.ac17 Mar 2019 10:21:28 -
@@ -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 @@ AC_PROG_LN_S
# 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 -p -u -r1.2 xdmcp.xml
--- doc/xdmcp.xml 10 Mar 2012 13:58:12 - 1.2
+++ doc/xdmcp.xml 17 Mar 2019 10:21:28 -
@@ -23,7 +23,7 @@
X Display Manager Control Protocol
X.Org Standard
- X Version 11, Release &fullrelvers;
+ X Version 11
Version 1.1
--
Matthieu Herrb
update: libXcomposite 0.45
ok files.
+# For compatibility reasons use the following empty XML docbook file and if
+# it fails try it again with a non-empty XML file.
have_xmlto_text=no
cat > conftest.xml << "EOF"
EOF
@@ -17779,10 +17793,18 @@ if test "$have_xmlto" = yes; then :
if $XMLTO --skip-validation txt conftest.xml >/dev/null 2>&1; then :
have_xmlto_text=yes
else
+ # Try it again with a non-empty XML file.
+ cat > conftest.xml << "EOF"
+
+EOF
+ if $XMLTO --skip-validation txt conftest.xml >/dev/null 2>&1;
then :
+ have_xmlto_text=yes
+else
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: xmlto cannot generate text
format, this format skipped" >&5
$as_echo "$as_me: WARNING: xmlto cannot generate text format, this format
skipped" >&2;}
fi
fi
+fi
rm -f conftest.xml
if test $have_xmlto_text = yes; then
HAVE_XMLTO_TEXT_TRUE=
@@ -18132,10 +18154,6 @@ else
am__EXEEXT_FALSE=
fi
-if test -z "${MAINTAINER_MODE_TRUE}" && test -z "${MAINTAINER_MODE_FALSE}";
then
- as_fn_error $? "conditional \"MAINTAINER_MODE\" was never defined.
-Usually this means the macro was only invoked conditionally." "$LINENO" 5
-fi
if test -z "${AMDEP_TRUE}" && test -z "${AMDEP_FALSE}"; then
as_fn_error $? "conditional \"AMDEP\" was never defined.
Usually this means the macro was only invoked conditionally." "$LINENO" 5
@@ -18557,7 +18575,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by libXcomposite $as_me 0.4.4, which was
+This file was extended by libXcomposite $as_me 0.4.5, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -18617,13 +18635,13 @@ $config_headers
Configuration commands:
$config_commands
-Report bugs to <https://bugs.freedesktop.org/enter_bug.cgi?product=xorg>."
+Report bugs to <https://gitlab.freedesktop.org/xorg/lib/libXcomposite/issues>."
_ACEOF
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //;
s/[\\""\`\$]/&/g'`"
ac_cs_version="\\
-libXcomposite config.status 0.4.4
+libXcomposite config.status 0.4.5
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
Index: configure.ac
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXcomposite/configure.ac,v
retrieving revision 1.6
diff -u -p -u -r1.6 configure.ac
--- configure.ac5 Jan 2013 14:59:39 - 1.6
+++ configure.ac17 Mar 2019 10:10:24 -
@@ -31,14 +31,13 @@ AC_PREREQ([2.60])
# that 'revision' number appears in Xcomposite.h and has to be manually
# synchronized.
#
-AC_INIT(libXcomposite, [0.4.4],
- [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
[libXcomposite])
+AC_INIT(libXcomposite, [0.4.5],
+ [https://gitlab.freedesktop.org/xorg/lib/libXcomposite/issues],
[libXcomposite])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
-AM_MAINTAINER_MODE
# Initialize libtool
AC_PROG_LIBTOOL
Index: man/Xcomposite.man
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXcomposite/man/Xcomposite.man,v
retrieving revision 1.3
diff -u -p -u -r1.3 Xcomposite.man
--- man/Xcomposite.man 5 Jan 2013 14:59:39 - 1.3
+++ man/Xcomposite.man 17 Mar 2019 10:10:24 -
@@ -1,7 +1,7 @@
'\" t
.\" Title: Xcomposite
.\"Author: Keith Packard
-.\" Generator: DocBook XSL Stylesheets vsnapshot_9276 <http://docbook.sf.net/>
+.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
.\" Date: 23 April 2007
.\"Manual: X Composite Extension Library
.\"Source: __vendorversion__
@@ -9,15 +9,6 @@
.\"
.TH "XCOMPOSITE" "__libmansuffix__" "23 April 2007"
"__vendorversion__" "X Composite Extension Library"
.\" -
-.\" * Define some portability stuff
-.\" -
-.\" ~
-.\" http://bugs.debian.org/507673
-.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
-.\" ~
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\" -
.\" * set default formatting
.\" -
.\" disable hyphenation
@@ -252,7 +243,7 @@ The X server must support at least versi
\fBXCompositeReleaseOverlayWindow\fR
.RS 4
This request specifies that the client is no longer using the Composite
Overlay Window on the screen specified by the argument
-\fIwindow\fR\&. A screen\*(Aqs Composite Overlay Window is unmapped when there
are no longer any clients using it\&.
+\fIwindow\fR\&. A screen\'s Composite Overlay Window is unmapped when there
are no longer any clients using it\&.
.sp
The X server must support at least version 0\&.3 of the Composite Extension for
\fBXCompositeReleaseOverlayWindow\fR\&.
Index: src/Xcomposite.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXcomposite/src/Xcomposite.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 Xcomposite.c
--- src/Xcomposite.c5 Jan 2013 14:59:39 - 1.4
+++ src/Xcomposite.c17 Mar 2019 10:10:24 -
@@ -147,7 +147,7 @@ XCompositeExtAddDisplay (XCompositeExtIn
*/
XExtCodes *codes = XAddExtension(dpy);
if (!codes) {
- XFree(info);
+ Xfree(info);
return NULL;
}
XESetCloseDisplay (dpy, codes->extension, XCompositeCloseDisplay);
--
Matthieu Herrb
update libXdamage 1.1.5
ally this means the macro was only invoked conditionally." "$LINENO" 5
-fi
if test -z "${AMDEP_TRUE}" && test -z "${AMDEP_FALSE}"; then
as_fn_error $? "conditional \"AMDEP\" was never defined.
Usually this means the macro was only invoked conditionally." "$LINENO" 5
@@ -18186,7 +18191,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by libXdamage $as_me 1.1.4, which was
+This file was extended by libXdamage $as_me 1.1.5, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -18252,7 +18257,7 @@ _ACEOF
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //;
s/[\\""\`\$]/&/g'`"
ac_cs_version="\\
-libXdamage config.status 1.1.4
+libXdamage config.status 1.1.5
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
Index: configure.ac
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdamage/configure.ac,v
retrieving revision 1.4
diff -u -p -u -r1.4 configure.ac
--- configure.ac5 Jan 2013 15:02:20 - 1.4
+++ configure.ac17 Mar 2019 10:18:21 -
@@ -29,14 +29,13 @@ AC_PREREQ([2.60])
# digit in the version number to track changes which don't affect the
# protocol, so Xdamage version l.n.m corresponds to protocol version l.n
#
-AC_INIT(libXdamage, [1.1.4],
+AC_INIT(libXdamage, [1.1.5],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXdamage])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([config.h])
# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
-AM_MAINTAINER_MODE
# Initialize libtool
AC_PROG_LIBTOOL
Index: src/Makefile.am
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdamage/src/Makefile.am,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.am
--- src/Makefile.am 5 Jan 2013 15:02:20 - 1.3
+++ src/Makefile.am 17 Mar 2019 10:18:21 -
@@ -5,11 +5,10 @@ libXdamage_la_SOURCES = \
Xdamage.c
libXdamage_la_LIBADD = $(XDAMAGE_LIBS)
-AM_CFLAGS = $(CWARNFLAGS) $(XDAMAGE_CFLAGS)
-
-INCLUDES = -I$(top_srcdir)/include/X11/extensions
-
libXdamage_la_LDFLAGS = -version-number 1:1:0 -no-undefined
+
+AM_CFLAGS = $(CWARNFLAGS) $(XDAMAGE_CFLAGS)
+AM_CPPFLAGS = -I$(top_srcdir)/include/X11/extensions
libXdamageincludedir = $(includedir)/X11/extensions
libXdamageinclude_HEADERS = $(top_srcdir)/include/X11/extensions/Xdamage.h
Index: src/Makefile.in
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdamage/src/Makefile.in,v
retrieving revision 1.8
diff -u -p -u -r1.8 Makefile.in
--- src/Makefile.in 11 Oct 2016 22:15:26 - 1.8
+++ src/Makefile.in 17 Mar 2019 10:18:52 -
@@ -294,9 +294,9 @@ libXdamage_la_SOURCES = \
Xdamage.c
libXdamage_la_LIBADD = $(XDAMAGE_LIBS)
-AM_CFLAGS = $(CWARNFLAGS) $(XDAMAGE_CFLAGS)
-INCLUDES = -I$(top_srcdir)/include/X11/extensions
libXdamage_la_LDFLAGS = -version-number 1:1:0 -no-undefined
+AM_CFLAGS = $(CWARNFLAGS) $(XDAMAGE_CFLAGS)
+AM_CPPFLAGS = -I$(top_srcdir)/include/X11/extensions
libXdamageincludedir = $(includedir)/X11/extensions
libXdamageinclude_HEADERS = $(top_srcdir)/include/X11/extensions/Xdamage.h
all: all-am
Index: src/Xdamage.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXdamage/src/Xdamage.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 Xdamage.c
--- src/Xdamage.c 5 Jan 2013 15:02:20 - 1.4
+++ src/Xdamage.c 17 Mar 2019 10:18:21 -
@@ -101,7 +101,7 @@ XDamageExtAddDisplay (XDamageExtInfo*ex
*/
XExtCodes *codes = XAddExtension(dpy);
if (!codes) {
- XFree(info);
+ Xfree(info);
return NULL;
}
XESetCloseDisplay (dpy, codes->extension, XDamageCloseDisplay);
--
Matthieu Herrb
update: libXcursor 1.2.0
Hi, another update : libXcursor 1.2.0 ok ? Index: ChangeLog === RCS file: /cvs/OpenBSD/xenocara/lib/libXcursor/ChangeLog,v retrieving revision 1.7 diff -u -p -u -r1.7 ChangeLog --- ChangeLog 28 Nov 2017 15:46:58 - 1.7 +++ ChangeLog 17 Mar 2019 10:14:20 - @@ -1,3 +1,52 @@ +commit b84b5d100f193fda0630c4d6fa889cd3e05ca033 +Author: Alan Coopersmith +Date: Sun Mar 10 17:36:26 2019 -0700 + +libXcursor 1.2.0 + +Signed-off-by: Alan Coopersmith + +commit 8ff9605921a6ea3e05b5c72aa1b2a7f78b624699 +Author: Alan Coopersmith +Date: Fri Dec 7 19:41:07 2018 -0800 + +Update configure.ac bug URL for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 534456082ed051d6427a77e4bda19473ea8b621c +Author: Alan Coopersmith +Date: Mon Nov 19 21:47:26 2018 -0800 + +Update README for gitlab migration + +Signed-off-by: Alan Coopersmith + +commit 2263c196cb0dcb8547b378df7b35f83b8b99c01e +Author: Cosimo Cecchi +Date: Fri Nov 9 20:06:41 2018 -0800 + +Support XDG user data dir location + +Nowadays ~/.icons is not used anymore as the preferred location for +custom user icon themes; XDG_DATA_HOME/icons (aka ~/.local/share/icons) +is what toolkits like GTK prefer. + +Prepend that location to the default xcursor path, so that cursor +themes installed there can be used by apps and toolkits that use +libXcursor. + +commit f64a8cc1a65dcad4294e2988b402a34175019663 +Author: Philipp Ludwig +Date: Sun Jan 22 14:21:54 2017 +0100 + +Fix crash when encountering cursor themes with circular dependencies. + +https://bugs.freedesktop.org/show_bug.cgi?id=3603 + +Signed-off-by: Philipp Ludwig +Signed-off-by: Alan Coopersmith + commit 4828abe494df8fb4aa00dcaa22a03446ba418d01 Author: Matthieu Herrb Date: Sat Nov 25 11:59:31 2017 +0100 Index: Makefile.am === RCS file: /cvs/OpenBSD/xenocara/lib/libXcursor/Makefile.am,v retrieving revision 1.5 diff -u -p -u -r1.5 Makefile.am --- Makefile.am 10 Mar 2012 13:53:27 - 1.5 +++ Makefile.am 17 Mar 2019 10:14:20 - @@ -43,3 +43,5 @@ ChangeLog: $(CHANGELOG_CMD) dist-hook: ChangeLog INSTALL + +EXTRA_DIST = README.md Index: Makefile.in === RCS file: /cvs/OpenBSD/xenocara/lib/libXcursor/Makefile.in,v retrieving revision 1.12 diff -u -p -u -r1.12 Makefile.in --- Makefile.in 28 Nov 2017 15:46:58 - 1.12 +++ Makefile.in 17 Mar 2019 10:15:21 - @@ -72,7 +72,7 @@ POST_UNINSTALL = : 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)/xcursor.pc.in $(top_srcdir)/configure \ $(top_srcdir)/include/X11/Xcursor/Xcursor.h.in AUTHORS COPYING \ @@ -342,6 +342,7 @@ AM_CFLAGS = $(XRENDER_CFLAGS) $(XFIXES_C pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = xcursor.pc MAINTAINERCLEANFILES = ChangeLog INSTALL +EXTRA_DIST = README.md all: config.h $(MAKE) $(AM_MAKEFLAGS) all-recursive Index: README === RCS file: README diff -N README --- README 31 Oct 2009 17:47:06 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,25 +0,0 @@ -libXcursor - X Window System Cursor management library - -All questions regarding this software should be directed at the -Xorg mailing list: - -http://lists.freedesktop.org/mailman/listinfo/xorg - -Please submit bug reports to the Xorg bugzilla: - -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg - -The master development code repository can be found at: - -git://anongit.freedesktop.org/git/xorg/lib/libXcursor - -http://cgit.freedesktop.org/xorg/lib/libXcursor - -For patch submission instructions, see: - - http://www.x.org/wiki/Development/Documentation/SubmittingPatches - -For more information on the git code manager, see: - -http://wiki.x.org/wiki/GitPage - Index: README.md === RCS file: README.md diff -N README.md --- /dev/null 1 Jan 1970 00:00:00 - +++ README.md 17 Mar 2019 10:14:20 - @@ -0,0 +1,18 @@ +libXcursor - X Window System Cursor management library +-- + +All questions regarding this software should be directed at the +Xorg mailing list: + + https://lists.x.org/mailman/listinfo/xorg + +The master development code repository can be found at: + + https://gitlab.freedesktop.org/xorg/lib/libXcursor + +Please submit bug reports and requests to merge patches there. + +For patch submission instructions, see: + + https://www.x.org/wiki/Development
Re: ssh-askpass(1): fix indicator size with multiple screens
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
>
> Index: x11-ssh-askpass.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/app/ssh-askpass/x11-ssh-askpass.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 x11-ssh-askpass.c
> --- x11-ssh-askpass.c 24 Apr 2015 02:19:41 - 1.6
> +++ x11-ssh-askpass.c 9 Jun 2019 14:32:59 -
> @@ -1507,6 +1507,12 @@ int main(int argc, char **argv)
> app.screen_height = HeightOfScreen(app.screen);
> app.screen_xoffset = 0;
> app.screen_yoffset = 0;
> +
> + app.xResolution =
> + app.screen_width * 1000 / WidthMMOfScreen(app.screen);
> + app.yResolution =
> + app.screen_height * 1000 / HeightMMOfScreen(app.screen);
> +
> if (XineramaIsActive(app.dpy) &&
>(screens = XineramaQueryScreens(app.dpy, &nscreens)) != NULL &&
>nscreens) {
> @@ -1516,11 +1522,6 @@ int main(int argc, char **argv)
>app.screen_yoffset = screens[0].y_org;
>XFree(screens);
> }
> -
> - app.xResolution =
> - app.screen_width * 1000 / WidthMMOfScreen(app.screen);
> - app.yResolution =
> - app.screen_height * 1000 / HeightMMOfScreen(app.screen);
>
> createDialog(&app);
> createGCs(&app);
>
> --
> Matthieu Herrb
--
Matthieu Herrb
Re: libXfont2: disable font server code
On Sun, Jun 09, 2019 at 07:22:26PM +0200, Matthieu Herrb wrote: > Hi, > > We disabled almost all X font server support code already. The patch > below removes support for connecting to a font server from libXfont2. > > It means that you X server will no longer be able to use fonts from a > remote font server. But did you even know this was possible ? > > ok? comments? ping > > Index: Makefile.bsd-wrapper > === > RCS file: /cvs/OpenBSD/xenocara/lib/libXfont2/Makefile.bsd-wrapper,v > retrieving revision 1.2 > diff -u -r1.2 Makefile.bsd-wrapper > --- Makefile.bsd-wrapper 26 May 2018 07:51:00 - 1.2 > +++ Makefile.bsd-wrapper 9 Jun 2019 17:15:38 - > @@ -3,6 +3,6 @@ > > SHARED_LIBS= Xfont2 1.0 > > -CONFIGURE_ARGS+= --with-xmlto=no --disable-devel-docs > +CONFIGURE_ARGS+= --disable-fc --with-xmlto=no --disable-devel-docs > > .include > > -- > Matthieu Herrb -- Matthieu Herrb
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
[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 n
[update] libXft 2.3.3
>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, &pa);
- 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->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, &pa);
+ 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->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->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] libICE 1.0.10
fall back to the current (partly vulnerable) code. + +Signed-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_s
[update] libXdmcp 1.1.3
if test $have_xmlto_text = yes; then
HAVE_XMLTO_TEXT_TRUE=
@@ -18657,6 +18702,52 @@
fi
+case $host_os in
+ *mingw*)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in
-lws2_32" >&5
+$as_echo_n "checking for main in -lws2_32... " >&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 &fullrelvers;
+ X Version 11
Version 1.1
--
Matthieu Herrb
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
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 wi
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
[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
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
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
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
[UPDATE] xf86-video-amdgpu and xf86-video-ati to versions 19.1.0
None, pRADEONEnt);
+
pixmap_unref_fb(drmmode_crtc->scanout[0].pixmap);
if (drmmode_crtc->scanout[1].pixmap)
- pixmap_unref_fb(drmmode_crtc->scanout[1].pixmap,
- None, pRADEONEnt);
+
pixmap_unref_fb(drmmode_crtc->scanout[1].pixmap);
} else {
drmmode_crtc_scanout_free(crtc);
}
@@ -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
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
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
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
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: 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(&child_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
pf half-open tcp in state table
Hi,
I've recently setup a new pair of OpenBSD 6.2 pf firewalls (with carp)
in my lab, and that's not performing very well.
tcp-based NFS v3 and v4 traffic (between Linux clients and a NetApp
server) through it is struggling, and some SSH or HTTPS transfers are
stalling, with their states disapearing from the state table.
I'm trying to figure out what's going on to fix the issue.
The main anomaly I see is the huge number (and it keeps growing) of
half-open tcp states, after 24h of uptime. See pfctl -vsi output
below.
Any clues on how to diagnose this and hopefully fix my firewalls ?
Below here are the limits and timeouts form my pf.conf, plus pfctl -vsi and
pfctl -st output
Thanks in advance,
set limit states 8
set timeout { adaptive.start 0, adaptive.end 0 }
set timeout {tcp.closing 1800, tcp.finwait 90, tcp.closed 180 }
Status: Enabled for 0 days 00:18:58 Debug: err
Hostid: 0xbe01b86e
Checksum: 0x489fc22aa9e7d141eb93cb12375c7c55
Interface Stats for vlan4 IPv4 IPv6
Bytes In 5766746796 3274270260
Bytes Out 3158075114 4781634462
Packets In
Passed18928091 11038798
Blocked2378976 124784
Packets Out
Passed 2911529 3575695
Blocked108 29
State Table Total Rate
current entries58485
half-open tcp 4294375902
searches 715176441 628450.3/s
inserts 4274979237565.7/s
removals4269130737514.3/s
Source Tracking Table
current entries0
searches 00.0/s
inserts00.0/s
removals 00.0/s
Counters
match6889153 6053.7/s
bad-offset 00.0/s
fragment43383.8/s
short 00.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 62975.5/s
ip-option 258621 227.3/s
proto-cksum00.0/s
state-mismatch 1900.2/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
translate 00.0/s
no-route 00.0/s
Limit Counters
max states per rule00.0/s
max-src-states 00.0/s
max-src-nodes 00.0/s
max-src-conn 00.0/s
max-src-conn-rate 00.0/s
overload table insertion 00.0/s
overload flush states 00.0/s
tcp.first 120s
tcp.opening 30s
tcp.established 86400s
tcp.closing1800s
tcp.finwait 90s
tcp.closed 180s
tcp.tsdiff 30s
udp.first60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 60s
interval 10s
adaptive.start0 states
adaptive.end 0 states
src.track 0s
--
Matthieu Herrb
