[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 31 March 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Lyude Paul, on behalf of the X.Org elections committee
Re: Wayland compatibility layer
Hi, I saw this and had a couple questions. When you say "wayland compatibility layer" I assumed at first this was for some reason a duplicate of nested compositors but I think I may have misunderstood. Is this basically the opposite of Xwayland, e.g. allowing X to act as a wayland compositor with twelveto11 as the translation layer? On Thu, 2022-10-20 at 13:08 +0800, Po Lu wrote: > Over the past several months, I and some other individuals wrote a > Wayland compositor that runs on common X setups. The code can be found > here: > > https://sourceforge.net/projects/twelveto11/ > Also JFYI - seeing as this is a freedesktop/x.org adjacent project you're more then welcome to use our gitlab instance if you'd like something a bit more accessible to host your code on. > It should be a more or less complete implementation of the important > parts of the Wayland protocol. Buffer transforms are currently missing, > but that's because I can't wrap my head around how they work. If DRI3 > is extended to allow creating Xv video, it would allow implementing YUV > image formats without a dependency on GL. > > The only major inefficiency I can think of is that buffer contents get > copied at least once, to the offscreen storage of the toplevel window, > which is then composited by the X compositing manager. Buffer-flipping > does not yet work well for fullscreen opaque surfaces, as that requires > some additions to the Composite extension here to work well: > > https://lists.x.org/pipermail/xorg-devel/2022-October/058918.html > > Please try it out and report any crashes or bugs that you may come > across. Thanks in advance. Patches are also welcome, and the code > should be well commented and structured, but please keep in mind the > coding standards (which happen to overlap greatly with the GNU ones): > https://www.gnu.org/prep/standards. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: Why does libinput randomly calls my touchpad "SynPS/2 Synaptics" or "Synaptics TM2722-001"?
Just so folks know: I happen to have experience with this part of the linux kernel (it's not a libinput bug) so I handled this offlist and redirected Ottavio to the right place to ask for support ♥ On Tue, 2024-04-23 at 15:12 +0100, Ottavio Caruso wrote: > Hi, > > $ sudo X -version > > X.Org X Server 1.21.1.7 > X Protocol Version 11, Revision 0 > Current Operating System: Linux t440 6.1.0-20-amd64 #1 SMP > PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-20-amd64 > root=UUID=42a17f43-89bb-4523-952f-b8d97bcb4a30 ro quiet > xorg-server 2:21.1.7-3+deb12u7 (https://www.debian.org/support) > Current version of pixman: 0.42.2 > > $ xinput --version > xinput version 1.6.3 > XI version on server: 2.4 > > > > On my old-ish Thinkpad T440, libinput alternatively calls my touchpad > "SynPS/2 Synaptics" or "Synaptics TM2722-001". > > $ grep Synaptics /var/log/messages > Nov 26 09:12:38 t440 kernel: [18070.908478] psmouse serio1: > synaptics: > serio: Synaptics pass-through port at isa0060/serio1/input0 > Nov 26 09:12:38 t440 kernel: [18070.947812] input: SynPS/2 Synaptics > TouchPad as /devices/platform/i8042/serio1/input/input35 > Nov 26 20:33:19 t440 kernel: [27221.274488] rmi4_f01 rmi4-00.fn01: > found > RMI device, manufacturer: Synaptics, product: TM2722-001, fw id: 0 > Nov 26 20:33:19 t440 kernel: [27221.314747] input: Synaptics TM2722- > 001 > as /devices/pci:00/:00:1f.3/i2c-0/0-002c/rmi4- > 00/input/input39 > Nov 27 19:28:05 t440 kernel: [ 6.327297] psmouse serio1: > synaptics: > serio: Synaptics pass-through port at isa0060/serio1/input0 > Nov 27 19:28:05 t440 kernel: [ 6.366655] input: SynPS/2 Synaptics > TouchPad as /devices/platform/i8042/serio1/input/input2 > > This without even rebooting or suspending the laptop. > > I have some scripts that disable or enable the touchpad (especially > when > I use the mouse) and I have to use tricks to accommodate this. > > Why does this happen in the first place? How can I troubleshoot it? > > Thanks. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: Question about the future of Xorg
Most of the people working on Wayland also worked on X11, a lot of lessons from X11's development specifically influenced Wayland's design. I think it's very much worth noting this because people talk about X vs. Wayland as if a separate project popped up next to X11 out of nowhere, but the reality is a lot of us see Wayland as the natural progression to X11 because it allowed us to be free of some of the constraints that come from how the X server is designed, like heavy round trips in its protocol, the fact that most modern compositing on X is just extension on extension on top of the actual X11 server which no longer does half of the things it's supposed to handle. You know X server used to draw its own widgets? It also has font rendering, a HAL for video drivers and input drivers, and more. And almost all of this stuff was out of use well before Wayland came onto the scene. Client toolkits do their own rendering (easier, faster, much more flexible), and font rendering. Save for nvidia's video drivers, we had pretty much stopped using the HAL for new input and video drivers as well (xf86-video-modesetting and xf86-input-libinput work for p much all hardware. There's a huge amount of stuff like this baked into the server, but very little of it makes sense on modern operating systems and much of it is really constraining. X wasn't "badly designed" per-say, for what it was I'll absolutely say it was a wonderful piece of software and it did its job well. But it's also designed for an era of computing that is much different than how most modern desktops work, so for a lot of the functionality we wanted to see in Wayland the only way to have implemented it in X would have required breaking people's setups. So, technically speaking splitting the development off was kind of a given in some sense anyway. Even if we didn't move work to Wayland it's more likely work would have been on an X server that didn't really resemble X11 and wasn't 1:1 compatible. On Mon, Jun 9, 2025, 09:51 Vasily wrote: > > > > > that's not a wayland thing. wayland is just a protocol plus associated > > tooling and libraries to speak that protocol. panning is a compositor > thing. > > > > if you wanted a compositor to support this then add it to that > compositor. as > > there is no single compositor in the wayland universe, you'd have to > make a > > choice. you could also build your own compositor. > > > > And that is the main issue with wayland. > "Very intelligent" people created a protocol plus associated tooling and > libraries and expected that community will build a new great compositor. > But if X11 was developed for ages and polished for decades by people who > loved it, no one want to spend his time and design a new compositor for > every > existing GPU > Because in this case it will be just another X11. > > If you take a look on Linux there are few servers in it already - like > systemd or dbus, pulse/pipewire, named ... > For my understanding there is nothing wrong with a server/client approach > and right now there is not any evidence that there is a wayland compositor > that works like X11 > Second problem that desktop must adopt such compositor. > > My personal opinion is that there are some issues need to be solved before > wayland compositor can substitute X11. > So I think X11 will work for us another 5 -10 years. > > > > > >
