FYI: new X server in -current, among other X things
On Friday 15 Jul 2022, at 15:12, matthew green wrote: > i've updated most of xsrc to their latest versions. > > there are probably a few build issues left to find > across all ports, and perhaps some run-time ones too > but basic testing looks fine for me. > > please send-pr or email here if you find problems. Hi, A bit late ... but I just updated and found a wskbd/xorg.conf rather small issue but also rather painful, so I report here in case something can be improved (including my own limited knowledge on this topic :) Before, I used to have a InputDevice keyboard section in my xorg.conf, so that I could pass some xkb options (required to all the extra sun keys working): Option "XkbModel""sun_type6_usb" Option "XkbLayout" "us" Option "XkbOptions" "compose:menu" Option "XkbRules""base" After the update, I noticed this stopped working, because: (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. So, I tried to disable "hotplugging" (Option "AutoAddDevices" "false") and kept the InputDevice section with: Driver "kbd" Option "Device" "/dev/wskbd" This failed because "/dev/wskbd" was said to be already open (by whom?). Using "/dev/wskbd0" instead mostly worked, except that switching to VT0 was leaving the keyboard in a weird state, sending escape codes instead of normal keys and preventing to type anything useful. (but a few times it was also kind of self-reparing and was working ...) So basically the issue is that manually adding a keyboard does not work anymore? (also, I don't fully understand the difference between /dev/wskbd and /dev/wskb0: man 4 wskbd, kbd, wscons, wsmux don't talk about it, maybe I missed some other documentation). I finally switched back to hotplugging, and added a InputClass section instead of a InputDevice, with MatchDriver "kbd" and my custom xkb options. (I failed to use a "MachUSBID" setting, which would have been more correct, but probably wscons does not report the USB id to Xorg). So all-in-all I'm fine with this setting, but it took me quite some time to figure out what to do and I'm still not sure I did it the right way :) Best, Anthony
Re: FYI: new X server in -current, among other X things
On Thu, 28 Jul 2022 at 12:38:10 -0500 (CDT), John D. Baker wrote: > I updated my -current install to shortly after the GCC 10.4 update, > doing a non-update build on everything. I then rebuilt all my extra > packages. > > Logging via xdm using the failsafe mode, the in-tree 'ctwm' works > fine. > Using my prefered fvwm2 (wm/fvwm), however, hangs as soon as it tries > to decorate any windows (my '.xsession' script starts 'urxvt' among > other things before exec-ing the window manager). > > The root window is mostly vacant, the undecorated icon region for > 'xconsole' is the only thing visible and the mouse cursor is the > "wristwatch" glyph. > > Switching to a text console and running 'ps' or 'top' shows the > 'fvwm2' > process is "parked". So far the only way to stop it is 'kill -9'. > > I know pkgsrc-HEAD is preferred on -current, but I'm using an up-to- > date pkgsrc-2022Q2. I've tested fvwm on 9.99.99 builds from July 22nd and July 29th (fvwm rebuilt both times from pkgsrc HEAD), as initiated via startx, and had no issues. I also tried rxvt-unicode and didn't have any issue there, either. Perhaps there's some combination of your full setup that's tripping a regression. (I don't use xdm at all.) I've tested the following WMs and DEs and haven't found any issues (other than the one already known and addressed with Xfce): blackbox ctwm (from X base) enlightenment16 fluxbox fvwm fvwm3 icewm14 (1.4.2) jwm lxde lxqt mate openbox sawfish xfce4 Regards, Dave
Re: FYI: new X server in -current, among other X things
mrg@ wrote: > > > (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h [snip] > this looks simple enough to just do. > > > (2) "-flipPixels" option removal [snip] > go for it. Both committed. Thanks! https://mail-index.netbsd.org/source-changes/2022/07/30/msg140050.html https://mail-index.netbsd.org/source-changes/2022/07/30/msg140049.html > we have a few things reverted, we maybe should > talk to upstream to have them either revert there or at least > provide the removed features elsewhere. I filed issues and mentioned if these mono support could be reverted, but no positive comments. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057 Maybe we should prepare gitlab merge request, but I'm not sure if non-member can do it.. --- Izumi Tsutsui
re: FYI: new X server in -current, among other X things
> > (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h > > > > OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix > > was neceesary for non-XFree86 driver based dumb server (on luna88k etc.): > > https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b > > https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153 > > > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16 > > I turns out that at least luna68k Xorg server (happens to?) works > without this change, but anyway upstream 1.22.x branch already > has this fix: > > https://gitlab.freedesktop.org/xorg/xserver/-/commit/75d70612888f18339703315549db781a22c0cb23 > > I wonder if we should pull this fix or not for our (1.)21.1.4 tree.. this looks simple enough to just do. > > (2) "-flipPixels" option removal > > > > "-flipPixels" option (that inverts black and white on 1bpp server) > > has been removed since 1.21. > > > > https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f > > > > As noted in the log the upstream authors claim > > "No supported driver supports 1bpp anymore, nor has in a very long time." > > > > Howeverwe we still have several working servers (xf86-video-wsfb based > > servers on mac68k and luna68k, monolithic servers for sun3 and x68) > > and at least there was a report that this option was mandatory on SE/30. > > So I would like to revert this change. > > It also turns out that the above changes also remove a menber from > ScrnInfoRec structure in hw/xfree86/common/xf86str.h and it breaks > ABIs of xf86-video-* drivers. > > However fortunately the removed member "Bool flipPixels" in the > SrcnInfoRec has not been used for -flipPixels options so we can > safely pull back -flipPixels support by reverting the changes > except xf86str.h. > > If there is no particular comments I would like to commit the > attached (reverting -flipPixels removal) patch. go for it. we have a few things reverted, we maybe should talk to upstream to have them either revert there or at least provide the removed features elsewhere. thanks. .mrg.
Re: FYI: new X server in -current, among other X things
I wrote:
> mrg@ wrote:
>
> > i've updated most of xsrc to their latest versions.
> > fontconfig and Mesa are remaining. i've tested the
> > new code on amd64 and arm64, and built several ports
> > to confirm they still build. the biggest change is
> > the new xorg-server.
>
> On 1.21.x, I'm afraid there are two known issue for ancient Tier-II ports.
>
>
> (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h
>
> OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix
> was neceesary for non-XFree86 driver based dumb server (on luna88k etc.):
> https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b
> https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16
I turns out that at least luna68k Xorg server (happens to?) works
without this change, but anyway upstream 1.22.x branch already
has this fix:
https://gitlab.freedesktop.org/xorg/xserver/-/commit/75d70612888f18339703315549db781a22c0cb23
I wonder if we should pull this fix or not for our (1.)21.1.4 tree..
> (2) "-flipPixels" option removal
>
> "-flipPixels" option (that inverts black and white on 1bpp server)
> has been removed since 1.21.
>
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f
>
> As noted in the log the upstream authors claim
> "No supported driver supports 1bpp anymore, nor has in a very long time."
>
> Howeverwe we still have several working servers (xf86-video-wsfb based
> servers on mac68k and luna68k, monolithic servers for sun3 and x68)
> and at least there was a report that this option was mandatory on SE/30.
> So I would like to revert this change.
It also turns out that the above changes also remove a menber from
ScrnInfoRec structure in hw/xfree86/common/xf86str.h and it breaks
ABIs of xf86-video-* drivers.
However fortunately the removed member "Bool flipPixels" in the
SrcnInfoRec has not been used for -flipPixels options so we can
safely pull back -flipPixels support by reverting the changes
except xf86str.h.
If there is no particular comments I would like to commit the
attached (reverting -flipPixels removal) patch.
---
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86.h
===
RCS file: /cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86.h,v
retrieving revision 1.5
diff -u -p -d -r1.5 xf86.h
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86.h 15 Jul 2022
02:18:59 - 1.5
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86.h 24 Jul 2022
14:58:35 -
@@ -79,6 +79,14 @@ extern _X_EXPORT Bool xf86DRI2Enabled(vo
#define XF86SCRNINFO(p) xf86ScreenToScrn(p)
+#define XF86FLIP_PIXELS() \
+ do { \
+ if (xf86GetFlipPixels()) { \
+ pScreen->whitePixel = (pScreen->whitePixel) ? 0 : 1; \
+ pScreen->blackPixel = (pScreen->blackPixel) ? 0 : 1; \
+ } \
+ while (0)
+
#define BOOLTOSTRING(b) ((b) ? "TRUE" : "FALSE")
/* Compatibility functions for pre-input-thread drivers */
@@ -278,6 +286,8 @@ xf86GetWeight(void);
extern _X_EXPORT Gamma
xf86GetGamma(void);
extern _X_EXPORT Bool
+xf86GetFlipPixels(void);
+extern _X_EXPORT Bool
xf86ServerIsExiting(void);
extern _X_EXPORT Bool
xf86ServerIsResetting(void);
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c
===
RCS file:
/cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c,v
retrieving revision 1.1.1.7
diff -u -p -d -r1.1.1.7 xf86Globals.c
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c 15 Jul
2022 02:12:51 - 1.1.1.7
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c 24 Jul
2022 14:58:35 -
@@ -188,6 +188,7 @@ int xf86FbBpp = -1;
int xf86Depth = -1;
rgb xf86Weight = { 0, 0, 0 };
+Bool xf86FlipPixels = FALSE;
Gamma xf86Gamma = { 0.0, 0.0, 0.0 };
Bool xf86AllowMouseOpenFail = FALSE;
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c
===
RCS file:
/cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c,v
retrieving revision 1.6
diff -u -p -d -r1.6 xf86Helper.c
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c15 Jul
2022 02:18:59 - 1.6
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c24 Jul
2022 14:58:36 -
@@ -952,8 +952,14 @@ xf86SetDpi(ScrnInfoPtr pScrn, int x, int
void
xf86SetBlackWhitePixels(ScreenPtr pScreen)
{
-pScreen->whitePixel = 1;
-pScreen->blackPixel = 0;
+if (xf86FlipPixels) {
+pScreen->whitePixel = 0;
+pScreen->blackPixel = 1;
+}
+else {
+pScreen->whitePixel = 1;
+pScreen->blackPixel = 0;
+}
}
/*
@@
Re: FYI: new X server in -current, among other X things
On Mon, 2022-07-18 at 21:23 -0400, David H. Gutteridge wrote: > On Mon, 2022-07-18 at 07:17 +1000, matthew green wrote: > > > can you post the whole Xorg.0.log somewhere? most of > > > my i915 systems have become non-functional the last few > > > years, but i have one system to test. > > > > unfortunately, my system (kaby lake, GT 630) seems to work > > fine with xorg-server 21.1.4 for me. > > This seems isolated to the modesetting driver. If I use intel instead, > then there are no issues. I've opened PR xsrc/56934 to track this. With mrg@'s commit to fix this[1], I can now start an X session without issue with the modesetting driver, and things generally work. I do see what seems like a separate, much more minor regression where rendering is incomplete (this doesn't occur with the intel driver, only modesetting), e.g., the mouse pointer gets garbled when I move it between windows. No idea where the trouble would be here. Anyway, thanks to rjs@ and mrg@ for fixing this! Regards, Dave 1. http://mail-index.netbsd.org/source-changes/2022/07/21/msg139935.html
Re: FYI: new X server in -current, among other X things
On Sun, 2022-07-17 at 00:28 -0400, David H. Gutteridge wrote: > Separately, libX11 added a feature called "thread safety constructor" > which we have enabled. It can cause hangs with X11 clients that aren't > coded safely. This did include xfce4-settings from Xfce until the > version I pushed to pkgsrc a couple of days ago (4.16.3). I believe > LXDE is also affected, but haven't had time to deal with it yet. Not > sure about any other DEs or X clients. (I'm not able to test at the > moment, of course.) LXDE has a basically identical code block (copied from Xfce, even the "xfce" function names are retained) to the one that was causing deadlocks when Xfce starts, though it's used for other purposes. I was not able to reproduce any hangs with that LXDE component, though. I'm not aware of anything else adversely affected by the libX11 change, but I guess we'll see. Regards, Dave
re: FYI: new X server in -current, among other X things
Robert Swindells writes: > > I wrote: > > It looks like not all the functions are getting setup in the glamor > > struct by load_glamor(), I'm guessing because those functions are > > not exported by libglamoregl.so. > > > > Do we need to add more source files to this: > > > > src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile > > Adding all of the glamor modules to libglamoregl.so makes it stop > crashing for me. can you send a patch? i'll look at it soon. .mrg.
Re: FYI: new X server in -current, among other X things
Martin Husemann wrote: > > Does anyone happen to have firefox-102.0.1nb1 installed and not yet > updated the X server and Xlib? Have rebuilt firefox-102.0.1, works fine with the old X stack.
Re: FYI: new X server in -current, among other X things
I wrote: > It looks like not all the functions are getting setup in the glamor > struct by load_glamor(), I'm guessing because those functions are > not exported by libglamoregl.so. > > Do we need to add more source files to this: > > src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile Adding all of the glamor modules to libglamoregl.so makes it stop crashing for me.
Re: FYI: new X server in -current, among other X things
matthew green wrote:
>
> with a normal build, you should at least be able to get
> a stack trace with function names, if not line numbers.
The last function name that I get is drmmode_init().
Comparing the updated source with the working version shows this:
{
#ifdef GLAMOR_HAS_GBM
ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
+modesettingPtr ms = modesettingPTR(pScrn);
if (drmmode->glamor) {
-if (!glamor_init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
+if (!ms->glamor.init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
return FALSE;
}
#ifdef GBM_BO_WITH_MODIFIERS
-glamor_set_drawable_modifiers_func(pScreen, get_drawable_modifiers);
+ms->glamor.set_drawable_modifiers_func(pScreen,
get_drawable_modifiers);
#endif
}
#endif
It looks like not all the functions are getting setup in the glamor
struct by load_glamor(), I'm guessing because those functions are
not exported by libglamoregl.so.
Do we need to add more source files to this:
src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile
Re: FYI: new X server in -current, among other X things
I have a minor (but strange) issue with the new X setup. My Radeon amdgpu does not fully work yet (strange colours, some drawing artifacts, otherwise mostly ok), so I am using vesfb and wsfb_drv (but the same effect happens with the amdgpu driver). I hadn't updated firefox before the X server update, so I'm not sure this issue is due to the X update or due to the firefox update: When I start firefox and select Help|About firefox from the menu I get a transparent "about mozilla firefox" window. It only starts drawing its content when I either move it, or click elsewhere (so it loses focus and the wm causes a frame redraw). Does anyone happen to have firefox-102.0.1nb1 installed and not yet updated the X server and Xlib? Martin
re: FYI: new X server in -current, among other X things
Robert Swindells writes: > > I wrote: > > > >>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] > >>> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] > >>> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) > >>> [0x75b46379c930] > >>> [ 378.034] (EE) > >>> [ 378.034] (EE) Segmentation fault at address 0x0 > >>> > >>> This happens with ctwm as part of the base installation, as well as with > >>> other pre-existing window managers and such from pkgsrc built against > >>> 9.99.97. > >> > >>can you configure X to generate a core dump or run it > >>under GDB and get the real stack trace? i thought we'd > >>fixed this problem in libexecinfo, but it's still not > >>tracing through the SEGV above, so finding what is > >>crashing where is what we need next. > > > >FWIW, I get the same on my Pinebook with a lima kernel, this may not be > >i915 specific. > > > >Doing a full debug build now. > > Building with MKDEBUG=yes stops it crashing, but it also stops glamor > from working. > > I guess it is back to printf(). with a normal build, you should at least be able to get a stack trace with function names, if not line numbers. you'll have to disable the xorg SEGV catcher... oh they seem to have removed that entirely: commit c7414f4d07b69a4b2f0d0af06f032393cf5fe6aa Author: Adam Jackson Date: Wed Aug 22 14:57:05 2018 -0400 xfree86: Remove NoTrapSignals This was dangerous on UMS and largely pointless on KMS. have you tried running the (non-debug) one from inside gdb as well, that should also give you something. .mrg.
Re: FYI: new X server in -current, among other X things
I wrote: > >>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] >>> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] >>> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) >>> [0x75b46379c930] >>> [ 378.034] (EE) >>> [ 378.034] (EE) Segmentation fault at address 0x0 >>> >>> This happens with ctwm as part of the base installation, as well as with >>> other pre-existing window managers and such from pkgsrc built against >>> 9.99.97. >> >>can you configure X to generate a core dump or run it >>under GDB and get the real stack trace? i thought we'd >>fixed this problem in libexecinfo, but it's still not >>tracing through the SEGV above, so finding what is >>crashing where is what we need next. > >FWIW, I get the same on my Pinebook with a lima kernel, this may not be >i915 specific. > >Doing a full debug build now. Building with MKDEBUG=yes stops it crashing, but it also stops glamor from working. I guess it is back to printf().
re: FYI: new X server in -current, among other X things
> can you post the whole Xorg.0.log somewhere? most of > my i915 systems have become non-functional the last few > years, but i have one system to test. unfortunately, my system (kaby lake, GT 630) seems to work fine with xorg-server 21.1.4 for me.
Re: FYI: new X server in -current, among other X things
>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] >> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] >> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) >> [0x75b46379c930] >> [ 378.034] (EE) >> [ 378.034] (EE) Segmentation fault at address 0x0 >> >> This happens with ctwm as part of the base installation, as well as with >> other pre-existing window managers and such from pkgsrc built against >> 9.99.97. > >can you configure X to generate a core dump or run it >under GDB and get the real stack trace? i thought we'd >fixed this problem in libexecinfo, but it's still not >tracing through the SEGV above, so finding what is >crashing where is what we need next. FWIW, I get the same on my Pinebook with a lima kernel, this may not be i915 specific. Doing a full debug build now.
re: FYI: new X server in -current, among other X things
> TL;DR: after upgrading via the sets available from releng builds from > July 16th (http://releng.netbsd.org/builds/HEAD/202207160630Z) I'm not > able to start X on amd64 with i915 graphics. Separately, there may be > issues with libX11 1.8.1 where clients will hang due to recursive locks > occurring. the libX11 thing is pretty terrible. upstream says that _not_ enabling it means other things are broken. i don't know anything better than fixing the clients i guess, which is pretty terrible for backwards compat code/binaries. > [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] > [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] > [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) > [0x75b46379c930] > [ 378.034] (EE) > [ 378.034] (EE) Segmentation fault at address 0x0 > > This happens with ctwm as part of the base installation, as well as with > other pre-existing window managers and such from pkgsrc built against > 9.99.97. can you configure X to generate a core dump or run it under GDB and get the real stack trace? i thought we'd fixed this problem in libexecinfo, but it's still not tracing through the SEGV above, so finding what is crashing where is what we need next. does it happen when X starts up? maybe it crashes with plain running "X" without any arguments (ie, not using some frontend that will also fire up clients etc.) can you post the whole Xorg.0.log somewhere? most of my i915 systems have become non-functional the last few years, but i have one system to test. .mrg.
Re: FYI: new X server in -current, among other X things
On Fri, 15 Jul 2022 at 15:12:07 +1000, matthew green wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. > > there are probably a few build issues left to find > across all ports, and perhaps some run-time ones too > but basic testing looks fine for me. > > please send-pr or email here if you find problems. TL;DR: after upgrading via the sets available from releng builds from July 16th (http://releng.netbsd.org/builds/HEAD/202207160630Z) I'm not able to start X on amd64 with i915 graphics. Separately, there may be issues with libX11 1.8.1 where clients will hang due to recursive locks occurring. I haven't had time to look into this in any detail, but after upgrading kernel and userland to the July 16th sets (and running etcupgrade), I'm now unable to start any window manager. I get the following: [ 378.027] (EE) [ 378.027] (EE) Backtrace: [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) [0x75b46379c930] [ 378.034] (EE) [ 378.034] (EE) Segmentation fault at address 0x0 [ 378.034] (EE) Fatal server error: [ 378.034] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 378.034] (EE) [ 378.034] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 378.034] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 378.034] (EE) [ 378.053] (EE) Server terminated with error (1). Closing log file. This happens with ctwm as part of the base installation, as well as with other pre-existing window managers and such from pkgsrc built against 9.99.97. Separately, libX11 added a feature called "thread safety constructor" which we have enabled. It can cause hangs with X11 clients that aren't coded safely. This did include xfce4-settings from Xfce until the version I pushed to pkgsrc a couple of days ago (4.16.3). I believe LXDE is also affected, but haven't had time to deal with it yet. Not sure about any other DEs or X clients. (I'm not able to test at the moment, of course.) Regards, Dave
Re: FYI: new X server in -current, among other X things
Hello, On Fri, 15 Jul 2022 15:12:07 +1000 matthew green wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. > > there are probably a few build issues left to find > across all ports, and perhaps some run-time ones too > but basic testing looks fine for me. Alright, I'll check all my weirdo drivers! have fun Michael
Re: FYI: new X server in -current, among other X things
Thanks for your work. mrg@ wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. On 1.21.x, I'm afraid there are two known issue for ancient Tier-II ports. (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix was neceesary for non-XFree86 driver based dumb server (on luna88k etc.): https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153 https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16 (2) "-flipPixels" option removal "-flipPixels" option (that inverts black and white on 1bpp server) has been removed since 1.21. https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f As noted in the log the upstream authors claim "No supported driver supports 1bpp anymore, nor has in a very long time." Howeverwe we still have several working servers (xf86-video-wsfb based servers on mac68k and luna68k, monolithic servers for sun3 and x68) and at least there was a report that this option was mandatory on SE/30. So I would like to revert this change. I've filed several issue reports about the 1bpp server including this, but it looks the upstream has ~no interest to keep it. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057 https://gitlab.freedesktop.org/xorg/xserver/-/issues/1056 Thanks, --- Izumi Tsustui
FYI: new X server in -current, among other X things
hi folks. i've updated most of xsrc to their latest versions. fontconfig and Mesa are remaining. i've tested the new code on amd64 and arm64, and built several ports to confirm they still build. the biggest change is the new xorg-server. there are probably a few build issues left to find across all ports, and perhaps some run-time ones too but basic testing looks fine for me. please send-pr or email here if you find problems. thanks! .mrg.
