Simon Ser

> "At least as standard" how? There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation. > A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on. But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations. On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction. It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar". > And there seem to be more visibly independent implementations of…

(2020). simon's been doing an amazing job. he also keeps a really really good monthly blog with what he's been up to, which is one of the most informative, interesting, useful resources on the planet for understanding what's happening with the planet's leading edge open source display technologies: https://emersion.fr/blog/ 101% worth a follow. last month he was working on a new display-damage scene graph to optimize screen updates with, did some work on borrowing DRM devices for XR/VR displays, worked on gamescope gpu profiling/performance tooling, updated/refactored some embedded chips to make PinePhone run better. and he has a stream of small projects which are always fascinating: "The new project of the month is blackbox. It’s a small utility which silently records debug logs of a program, and dumps the recorded logs on-demand." (reminds me of JACK Time Machine but for programs not audio). Simon iconifies what open source ought to be: not just source, not just free-as-in-, but an accessible, cooperative, multiplayer exploration of the world. Simon's blogging unfolds his (vast) sections of the map & shows us all what he's found. It's amazing, especially since Simon is up to such good stuff.

Related: https://emersion.fr/blog/2020/saying-no-to-unethical-tasks/

Some time ago I've written an article about a particular aspect of shells, job control: https://emersion.fr/blog/2019/job-control/

They are: https://indico.freedesktop.org/event/4/ https://emersion.fr/blog/2023/hdr-hackfest-wrap-up/ https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meeti… ...

Most Wayland compositors track damage obsessively. If you turn on the paint debug overlay in Weston or something wlroots-based and start typing in e.g. gnome-terminal (with blinking cursor turned off), you'll see that only a single character is painted at a time. Here's a good post: https://emersion.fr/blog/2019/intro-to-damage-tracking/ To do this with EGL, you need to eglSwapBuffersWithDamage(KHR|EXT) instead of just eglSwapBuffers: https://gitlab.freedesktop.org/wayland/weston/blob/23d01c67a320ab1920e… (isn't it nice to have a GL API that's not terrible? :D) I think I know how to do it, going to try soon. Bugzilled: https://bugzilla.mozilla.org/show_bug.cgi?id=1590586

This comment is mostly correct (as a daily Wayland user), with a few exceptions. > Wayland does almost nothing besides render buffer handling. Input? Applications job. Applications don't do more work to handle input on Wayland as opposed to e.g. X11. It's still event-based, and the compositor feeds input events to applications that can process them as normal. Keyboard, mouse and touch input are part of the core Wayland protocol, and tablet input is part of an extension that all major compositors fully support. > Window decorations? Compositors job. Kind of, it's the job of the application (client-side decorations) or compositor (server-side decorations). The compositor can choose which to use. CSDs give more custom look-and-feels to applications that have them (think Firefox or Chrome); SSDs provide consistent looks across all apps. GNOME only supports CSDs, but is an exception in that regard. > Clipboard? Maybe compositor or toolkit. Both: https://emersion.fr/blog/2020/wayland-clipboard-drag-and-drop/ Clipboards are (implementation-complexity-wise) scary in X11 as well.