> I wrote my own I see the growing trend of words losing all meaning is still going strong in 2026. I wonder what human communication will look like in the near future?
[deleted]
Frame – Linux X server in Assembly
71–80 of 115 posts
Re: Frame – Linux X server in Assembly
#72I would like to see a similar project that fixes Wayland. Like, can someone vibe-code window positioning, add SSD to GNOME (damage was already done, but still), and add the ability to send events so you can automate and drive the app offscreen for testing.
One of the issues with Wayland is that it forces every compositor to reimplement the X server, badly. So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
It's also an 80% solution, the same thing so many rust "rewrites" are notorious for. Sure it finally mostly works at this point. Mostly. But it took a decade of kicking and screaming to get here and there are still edge cases that don't work, many clearly viewed as wontfix simply because there isn't enough popular support to force the hand of the purists. Hopefully llms make a community bootleg wayland protocol effort viable.
Re: Frame – Linux X server in Assembly
#73This is the very definition of "scratching your own itch" lol.
Very inspiring and I applaud your efforts.
I haven't written assembler in years but this inspires me to do a small project for the fun of it.
Re: Frame – Linux X server in Assembly
#74I would like to see a similar project that fixes Wayland. Like, can someone vibe-code window positioning, add SSD to GNOME (damage was already done, but still), and add the ability to send events so you can automate and drive the app offscreen for testing.
OMG, yes, please, get rid of all those composers, all that mess that people are doing. X11 is 40 years of battle testing. Wayland in 22 years (it already has 18) will be 100x worse than X11. A Dockbar I am working on https://github.com/edumucelli/docking/ is a pain to build on Wayland. It already supports a lot of composers and even mutter/gnome with that Gnome shell extension, but at what cost ...
Daniel Stone from linux.conf.au 2013, The Real Story Behind Wayland and X https://www.youtube.com/watch?v=RIctzAQOe44
You can always use XWayland if you feel that way.
Re: Frame – Linux X server in Assembly
#75With the crazy lack of supply for hardware and ridiculous prices, seems we are going to have to start squeezing more juice out of our existing hardware. What I would love to see is how well this runs on an ancient system. Will this for instance run on an old PI and make it snappy?
Re: Frame – Linux X server in Assembly
#76> I wrote my own I see the growing trend of words losing all meaning is still going strong in 2026. I wonder what human communication will look like in the near future?
I wrote my own comment on hackernews. This is the prompt I used...
Re: Frame – Linux X server in Assembly
#77Earlier quoted context omitted.
Try running `tile` as a wm. I imagine it's not fully compliant to support dwm.
Huh. So it's not the window manager. It's individual applications that are working or not. Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass Not: alacritty, st So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??
There are 3-4 typical different approaches to rendering text on X. If it's not yet (or not correctly) implementing one or two of them, that'd explain it.
EDIT: Testing with xtruss shows st uses RenderCompositeGlyphs8(), part of the RENDER extension. I don't have Alacritty installed, but I think Alacritty uses the GPU, at least by default? Looking at the source for Glass it seems to use PolyText16 - the "old school" old server-side font rendering API. A lot of older X11 apps would work fine with PolyText16, and a lot of newer X11 apps does all the text rendering client side into a shared memory buffer without requiring GPU support, so it's not hard to end up with a set of applications where none of them would run into either gap.
EDIT2: I've looked at the Frame source, and it does seem to have support for the RenderCompositeGlyph calls and other supporting request, so not sure what the issue with st is. It's not doing anything unconventional.
I'd try rxvt (PolyText8/16) or xterm (ImageText8/16). If either/both works it's likely an issue with the RenderCompositeGlyphs support.
Re: Frame – Linux X server in Assembly
#78At first I was so interested into this guy, writing his own everything, thinking this has got to be something to aspire to, to be as good a programmer as this guy. Then I realised LLMs wrote this, and I was so very disappointed. It was naive and stupid of me to think otherwise, but here I am.
Re: Frame – Linux X server in Assembly
#79Earlier quoted context omitted.
One of the issues with Wayland is that it forces every compositor to reimplement the X server, badly. So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
It's also an 80% solution, the same thing so many rust "rewrites" are notorious for. Sure it finally mostly works at this point. Mostly. But it took a decade of kicking and screaming to get here and there are still edge cases that don't work, many clearly viewed as wontfix simply because there isn't enough popular support to force the hand of the purists. Hopefully llms make a community bootleg wayland protocol effor…
That's a bit dishonest since you're forgetting about all those features that now work, aren't you?
Re: Frame – Linux X server in Assembly
#80It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.
There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.
This has got to be the craziest AI-shill sentence I have heard in a long time.
How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code. With people pedantically adding every optimization imaginable and unimaginable to produce the most efficient code possible. And you have the audacity to say LLMs, which write garbage non-trivial amount of time, are capable of producing better assembly.
This has got to be either a masterful ragebait, or a person with very low knowledge of modern compilers, because even an LLM would not write something so stupid as this.