[dev] tinyx port to libXfont2

[stefan11111]

Hi dev@ list readers.

I just ported tinyx to libXfont2.
Maybe some of the readers here are interested in this,
as tinyx is made in the suckless spirit of minimalism.

https://github.com/tinycorelinux/tinyx/pull/8

For those of you who use gentoo, I also have an ebuild
for this patched tinyx in my overlay:
https://github.com/stefan11111/stefan_overlay/blob/main/x11-base/tinyx/tinyx-1.1.ebuild

So far, every X11 app I tested works, with the exception of st.
Xterm works however.

Even palemoon works.

St fails like so:

> $ st
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 78 (X_CreateColormap)
> Serial number of failed request: 393
> Current serial number in output stream: 394

Probably because tinyx doesn't implement an X11 extension that st needs.

--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -fno-stack-check -fno-ident
-fno-stack-protector -ftree-vectorize -ffast-math -funswitch-loops
-fuse-linker-plugin -flto -fdevirtualize-at-ltrans -fno-plt
-fno-semantic-interposition -falign-functions=64 -fgraphite-identity
-floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ipv6 ssl lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man custom-cflags"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d /var/lib/dbus /lib/udev"

How to fix gcc 14:

diff --git a/gcc/c-family/c-opts.cc.bak b/gcc/c-family/c-opts.cc
index f4dced8..0e12ac0 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -861,8 +861,6 @@ c_common_post_options (const char **pfilename)
reject certain GNU extensions also present the defaults for later
language modes. */
if (!c_dialect_cxx ()
- && !flag_isoc99
- && !global_dc->m_pedantic_errors
&& !OPTION_SET_P (flag_permissive))
{
flag_permissive = 1;

[stefan11111]

On 2024-11-03 23:57, stefan11111 wrote:
> For those of you who use gentoo, I also have an ebuild
> for this patched tinyx in my overlay:
> https://github.com/stefan11111/stefan_overlay/blob/main/x11-base/tinyx/tinyx-1.1.ebuild

This link is now broken, as someone pointed out a better way to manage
the 2 different tinyx versions.
The new link is
https://github.com/stefan11111/stefan_overlay/blob/main/x11-base/tinyx/tinyx-1.0.ebuild

[Hiltjo Posthuma]

Hi,

Many years ago I tested tinyx. It was quite nice and small.

If there are (small) changes required for st, dmenu and dmenu to work (again).
Feel free to send them.

--
Kind regards,
Hiltjo

[Storkman]

On Sun, Nov 03, 2024 at 11:57:18PM +0000, stefan11111 wrote:

> Hi dev@ list readers.
>
> I just ported tinyx to libXfont2.
> Maybe some of the readers here are interested in this,
> as tinyx is made in the suckless spirit of minimalism.
>
> https://github.com/tinycorelinux/tinyx/pull/8
>
> For those of you who use gentoo, I also have an ebuild
> for this patched tinyx in my overlay:
> https://github.com/stefan11111/stefan_overlay/blob/main/x11-base/tinyx/tinyx-1.1.ebuild
>
> So far, every X11 app I tested works, with the exception of st.
> Xterm works however.
>
> Even palemoon works.
>
> St fails like so:
>
> > $ st
> > X Error of failed request: BadMatch (invalid parameter attributes)
> > Major opcode of failed request: 78 (X_CreateColormap)
> > Serial number of failed request: 393
> > Current serial number in output stream: 394
>
> Probably because tinyx doesn't implement an X11 extension that st needs.

Have you tried the current git master of st? The way it handles color maps
has significantly changed in literally the last commit (August 8), making
it a lot more tolerant of funny display hardware.

--
Storkman

[stefan11111]

On 2024-11-05 00:03, Hiltjo Posthuma wrote:
>
> Hi,
>
> Many years ago I tested tinyx. It was quite nice and small.
>
> If there are (small) changes required for st, dmenu and dmenu to work
> (again).
> Feel free to send them.

Looks like git st works.
dmenu and dwm also work.

[Andrey Dobrovolsky]

Hi *.dev!

вт, 5 лист. 2024 р. о 03:33 Storkman <stor...@storkman.nl> пише:

I've packaged st 0.8.4 for TinyCore Linux and want to mention that it
works fine under TinyX with libXfont 1.4
. TinyX used in Xfbdev incarnation.

Regards!

[stefan11111]

On 2024-11-05 10:37, stefan11111 wrote:
>
> Looks like git st works.

Looked into it a bit more, and it turns out that the reason it failed
like that
is not because of code from st, but because of the alpha patch for st.

XftColorAllocName() fails(likely not implemented in tinyx), which kills
st.

Is there a way to get st to ignore/handle that error and not have it
kill the app?

[Storkman]

On Thu, Nov 07, 2024 at 11:18:03AM +0000, stefan11111 wrote:
> On 2024-11-05 10:37, stefan11111 wrote:
> >
> > Looks like git st works.
>
> Looked into it a bit more, and it turns out that the reason it failed
> like that
> is not because of code from st, but because of the alpha patch for st.
>
> XftColorAllocName() fails(likely not implemented in tinyx), which kills
> st.
>
> Is there a way to get st to ignore/handle that error and not have it
> kill the app?

The alpha patch actually reverts the upstream fix. This part:

> @@ -1118,11 +1127,23 @@ xinit(int cols, int rows)
> Window parent;
> pid_t thispid = getpid();
> XColor xmousefg, xmousebg;
> + XWindowAttributes attr;
> + XVisualInfo vis;
>
> if (!(xw.dpy = XOpenDisplay(NULL)))
> die("can't open display\n");
> xw.scr = XDefaultScreen(xw.dpy);
> - xw.vis = XDefaultVisual(xw.dpy, xw.scr);
> +
> + if (!(opt_embed && (parent = strtol(opt_embed, NULL, 0)))) {
> + parent = XRootWindow(xw.dpy, xw.scr);
> + xw.depth = 32;
> + } else {
> + XGetWindowAttributes(xw.dpy, parent, &attr);
> + xw.depth = attr.depth;
> + }
> +
> + XMatchVisualInfo(xw.dpy, xw.scr, xw.depth, TrueColor, &vis);
> + xw.vis = vis.visual;
>
> /* font */
> if (!FcInit())
> @@ -1132,7 +1153,7 @@ xinit(int cols, int rows)
> xloadfonts(usedfont, 0);
>
> /* colors */
> - xw.cmap = XDefaultColormap(xw.dpy, xw.scr);
> + xw.cmap = XCreateColormap(xw.dpy, parent, xw.vis, None);
> xloadcols();

The depth is hard-coded to 32, which might not be supported,
and the return value from XMatchVisualInfo() is not checked.
If I run this on Xephyr with display depth set to 8-bit, st actually segfaults.

You can see what display depth/class combinations are supported in the output
of xdpyinfo.

--
Storkman

[Hiltjo Posthuma]

Maybe some workaround using XSetErrorHandler() (like dwm does) could work.

I haven't tested st on older systems or <24-bit displays recently, but upstream
patches to support them are welcome.

Thanks,

--
Kind regards,
Hiltjo

[Storkman]

On Thu, Nov 07, 2024 at 11:18:03AM +0000, stefan11111 wrote:

> On 2024-11-05 10:37, stefan11111 wrote:
> >
> > Looks like git st works.
>
> Looked into it a bit more, and it turns out that the reason it failed
> like that
> is not because of code from st, but because of the alpha patch for st.
>
> XftColorAllocName() fails(likely not implemented in tinyx), which kills
> st.
>
> Is there a way to get st to ignore/handle that error and not have it
> kill the app?

Turns out I was looking at the wrong diff somehow. The alpha patch indeed
just introduced an entirely new bug, since the mainline st never needed
a 32-bit color mode.

I've made an updated version, if you'd like to check it out.

--
Storkman

[stefan11111]

Thank you for this patch.
I can confirm it works.
I get proper alpha in Xorg and I can use st in Xfbdev.

The patch didn't apply as-is to git st.
I applied the patch by hand, and I'll add the output of git diff as an attachment.

Maybe this patch should be added to the list of alpha patches on the page for st on the suckless wiki?

[stefan11111]

I also ported the patch to Luke Smith's st fork, the terminal I use.
Here's the patch that I ended up with after adapting your patch:
https://github.com/stefan11111/st/commit/d0fa309395ef2f9477e30e2134feac07cc504de0

I can confirm that, with this patch, Luke Smith's terminal also works.
Maybe someone else finds this useful too.

[stefan11111]

Not really related to what was discussed earlier,
but I thought I might find someone who can help me with this here.

I have this script for starting Xfbdev and running my .xinitrc:

```
#!/bin/sh

export DISPLAY=${DISPLAY:-:0}
trap "$HOME/.xinitrc" USR1

(
trap '' USR1

exec /usr/bin/Xfbdev -screen 1920x1080 :0 vt1
) &

wait
```

This script works fine, except when I kill dwm with alt + q.
Instead of killing the X server along with dwm, the X server freezes and
I have to telnet in
from another device to kill it, by running pkill Xfbdev.

Does anyone know how to improve the above script to get it to kill X
after I kill dwm?

[stefan11111]

On 2024-11-12 21:35, Eric Pruitt wrote:

> On Tue, Nov 12, 2024 at 08:07:45PM +0000, stefan11111 wrote:
>> Does anyone know how to improve the above script to get it to kill X
>> after I
>> kill dwm?
>

> Is vt1 a script that launches dwm? When you press Alt+Q to kill dwm,
> does this also kill any other running graphical applications? I believe
> you can use "-reset -terminate" to get the behavior you want if, when
> dwm is closed, there aren't any other clients.
>
> Eric
>
> PS: I've been having delivery issues with suckless.org, so I've BCC'd
> your personal address instead of respecting the Reply-To header.

vt1 is a option I pass to the X server.
It means, 'use virtual terminal 1', i.e. /dev/tty1.

I tried to add -reset -terminate to the options I pass to X in that
script.
Sadly, nothing changed.

[Storkman]

On Tue, Nov 12, 2024 at 08:07:45PM +0000, stefan11111 wrote:

> Not really related to what was discussed earlier,
> but I thought I might find someone who can help me with this here.
>
> I have this script for starting Xfbdev and running my .xinitrc:
>
> ```
> #!/bin/sh
>
> export DISPLAY=${DISPLAY:-:0}
> trap "$HOME/.xinitrc" USR1
>
> (
> trap '' USR1
>
> exec /usr/bin/Xfbdev -screen 1920x1080 :0 vt1
> ) &
>
> wait
> ```
>
> This script works fine, except when I kill dwm with alt + q.
> Instead of killing the X server along with dwm, the X server freezes and
> I have to telnet in
> from another device to kill it, by running pkill Xfbdev.
>
> Does anyone know how to improve the above script to get it to kill X
> after I kill dwm?

Well, that's what xinit is for, isn't it?

--
Storkman

[stefan11111]

Yes, but I want to have 2 scripts that launch X on my system.
xinit launches /usr/bin/X, which is symlinked to /usr/bin/Xorg.
The other script launches /usr/bin/Xfbdev.

Do you have another idea how to get 2 scripts or programs for launching
these different X servers?

[Storkman]

Check out the man page for xinit. You can specify the server and options
to it on the command line.

--
Storkman

[stefan11111]

On 2024-11-13 06:55, Storkman wrote:
>
> Check out the man page for xinit. You can specify the server and
> options
> to it on the command line.

I tried doing 'xinit -- /usr/bin/Xfbdev :0 vt1'
Sadly, when I do this, keyboard input doesn't work, and I can't even
switch to another tty.

Doing 'xinit -- /usr/bin/Xfbdev :0' works, and fixes the problem of
freezing when dwm dies,
but spawns X to the default vt7.

This is not a big problem, but I'd like it to work with vt1.
Explicitly passing vt7 also works.

Xfbdev is suid root, and should have permissions to every tty, including
tty1.
Even without suid root, it should have permissions to tty1, because it's
owned my the user I logged in as.

This wasn't a problem with the old script.

Do you have an idea how to fix this?

[Andrey Dobrovolsky]

вт, 12 лист. 2024 р. о 22:09 stefan11111 <stefa...@shitposting.expert> пише:

Hi stefan11111,

I've tested dwm-6.2 under Xfbdev in TinyCore Linux 13.1 and it doesn't
hang the X, I was able to quit dwm with Alt-Q and then exit X with
Ctrl-Alt-Backspace. In TCL X is started with .xsession and it doesn't
set any traps.

Regards,
-- jazzbiker

[Eric Pruitt]

On Tue, Nov 12, 2024 at 08:07:45PM +0000, stefan11111 wrote:

> Does anyone know how to improve the above script to get it to kill X after I
> kill dwm?