I was referring to Marcan/Hector being behind the vtuber. The Linux port itself is obviously a much larger team.
Does that not sound odd to you? A protocol that could handle vastly more complex keyboards (i.e the Sun Type 5 keyboard) can't handle a fairly basic consumer keyboard. The same one used perfectly fine for the Intel mac models. The guy is absolutely blagging it to push his agenda.
I'm referring to the vtuber being part of that team. Lina does GPU stuff. Hector doesn't seem to touch that. Don't really see any evidence that Lina is Hector's sockpuppet.
No, 8 bits for keys from the dawn of X11 doesn't sound odd at all.
Hmm, I have come across these in the past. It still isn't convincing; for example this part of it:
Wayland "sent"
Because that would break backwards compatibility of a small part of Xorg.
Conversely, Xorg's refusal to create X12 or whatever's necessary to natively support larger scancodes is probably an example as to why momentum coalesced around something completely different.Because that would break backwards compatibility of a small part of Xorg.
... instead they want to break not only backwards compatibility with the whole display system, but the entire software ecosystem.
Other NetBSD developed drivers include:
A lot of people say that, in both Linux and BSD camps. Who's got the skill and motivation to make it a reality, though? My thinking goes, it will start with a 'proof of concept' - someone will set up 3 machines (or VMs), a FreeBSD, a NetBSD, and an OpenBSD - and set up a CI infrastructure to develop and test that fork, and maintain it... If you think it through, this fantasy of a project is a LOT of work to set up, let alone get right.
It's kind of the point, that they are split from Linux. Upstream is so different than what suits BSD. It's the effort to upstream improvements, which suit more purposes including for Linux, which one BSD operating system does and another doesn't. Let them be in maintenance or slow mode for Linux to use like that. Then have a BSD independent fork, where each BSD can differ from that.
It really is a lot. It would take collaboration between the foundations to different extents. At minimum, they would have to agree on a fork, which can simply be what Xorg used to be. Alternatively, a fork could be independently run opting not to install the traditional Xorg. OpenBSD and NetBSD are already collaborating on some parts. Then, each one would have to be tested on the machines, and there's a lot of ports. So both Xorg versions would have to be available side by side on FreeBSD, until one is depreciated. The newer Python still hasn't replaced the older one, and the newest xaw3dxft hasn't replaced the older xaw programs for example,A lot of people say that, in both Linux and BSD camps. Who's got the skill and motivation to make it a reality, though? My thinking goes, it will start with a 'proof of concept' - someone will set up 3 machines (or VMs), a FreeBSD, a NetBSD, and an OpenBSD - and set up a CI infrastructure to develop and test that fork, and maintain it... If you think it through, this fantasy of a project is a LOT of work to set up, let alone get right.
I don't think it has anything to do with Linux. So far, the forks of xorg in NetBSD and OpenBSD that I've noted are more to do with integrating them to the buildsystem ecosystem. There's few, impactful deviations to standard x.org
I couldnt figure out how to use wayland instead of xorg. Any suggestions?I will do nothing, since I am using Wayland under FreeBSD for quite some time and it works just well for me.
That's the hard part, it needs to be automatic and reliable, to the same extent as what Xorg provides.
Has anyone written a Wayland script? I'm sure this isn't an unreasonable expectation that could easily be accomplished with a script. I am by the way not interested in writing the script.
