cycloptic

9 ms·

31.
by cycloptic 6y ago
I don't know of any significant applications that are Wayland only. If that ever happened, someone could just make a really simple Wayland server that does the reverse of XWayland.
32.
by cycloptic 6y ago
It's not clear what that would solve, XWayland mostly fulfills that role already. It can't run window managers, but you wouldn't really get that everywhere from adding another Wayland extension either -- doing that would requ
33.
by cycloptic 6y ago
Or perhaps by then we will have moved onto another protocol that's even simpler.
34.
by cycloptic 6y ago
Look, you're a smart and accomplished person and you have some developed ideas of how thing should be done, please don't hate on other open source developers or accuse them of being "idiots" or "CADT" when you
35.
by cycloptic 6y ago
Sure but that's not any different if your application depended on some other GNOME or KDE specific API. If KDE decides an API is KDE only and GNOME doesn't want to make their own implementation then there's not much that you
36.
by cycloptic 6y ago
You asked if other X servers are used, there are other X servers that are widely used outside Linux (Xquartz, Xwin, etc) which would break if the clients required DRI3. Libwayland is a small library carrying the implementation of the wire p
37.
by cycloptic 6y ago
That's not really a reasonable comparison here, because option 2 has already mostly been done, for other reasons.
38.
by cycloptic 6y ago
That's only if you're using functionality specific to the DE, which is handled mostly the same as it is under X. GNOME and KDE for example tend to provide their functionality as dbus services. If you just have a simple app that ne
39.
by cycloptic 6y ago
AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. In Wayland those tasks have been split out into libraries. The details of the protocol IPC is handled by libwayland, the input is handled by libinput. Scre
40.
by cycloptic 6y ago
What you're saying is mostly what has happened already except the work has just been done outside the X server. The features in X that people don't use are already considered deprecated, and factoring the legacy parts off into a s
41.
by cycloptic 6y ago
The basic idea of Wayland is that it is a simplification and streamlining of a display server protocol. The work of designing that core protocol is already done and doesn't need to be done again, the original developer likely did it be
42.
by cycloptic 6y ago
Not really, it's the same amount of work either way considering this doesn't exist yet.
43.
by cycloptic 6y ago
Is that any different from normal? In my experience, if you're shipping a product on a Linux-based desktop, usually you target a specific set of distributions, i.e. the default configuration of the last few LTS versions of RHEL or Ubun
44.
by cycloptic 6y ago
That's one of the things Wayland was designed to do, of course implementations can build other things around it that allow privileged clients to break client isolation. The effort could have been put into X11 but it seems the people in
45.
by cycloptic 6y ago
I don't understand what you mean. You can still continue using X if that's what you want, people deciding to spend their time developing Wayland doesn't somehow break X or make it worse. Also just FYI, it seems x.org has merg
46.
by cycloptic 6y ago
There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the co
47.
by cycloptic 6y ago
You could do that but such an X server would not really be any practically different from Wayland. You would still complain that it broke your old clients, and newer clients would still have to maintain two code paths for the newer server a
48.
by cycloptic 6y ago
You really should consider watching the youtube talk that was linked in some sibling comments, it explains it in more detail than I could in just one post. For me personally, the real bad issues are things like the core protocol being synch
49.
by cycloptic 6y ago
No, the hard part is building a good API and user interface that works for everybody. IMO that's mostly why there are a lot of half-finished and inconsistent things like that X11.
50.
by cycloptic 6y ago
Someone could build a combined Wayland/X server in the same process like that, but why? The only reason you would need to do that would be to run Wayland clients natively on your X server. IMO if you want to use Wayland it is much easi
51.
by cycloptic 6y ago
Wayland doesn't have the equivalent of XGetImage for various reasons, but screen capture applications can use the ScreenCast flatpak portal to select window sources: https://flatpak.github.io/xdg-desktop-portal/por
52.
by cycloptic 6y ago
That's mostly a misconception, Wayland implementations don't need to start from scratch. Weston and wlroots are minimal from-scratch implementations, but GNOME and KDE for example do their implementations by re-using most of the c
53.
by cycloptic 6y ago
There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.
54.
by cycloptic 6y ago
I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific
55.
by cycloptic 6y ago
The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. I could go more into detail, but if you depend o
56.
by cycloptic 6y ago
There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don&#x2
57.
by cycloptic 6y ago
Can you be more specific about what are you comparing this to? An X client with similar functionality would likely be longer and require several X extensions.
58.
by cycloptic 6y ago
I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for vario
59.
by cycloptic 6y ago
There is a wayland protocol called presentation-time that's supposed to provide precise timing information to clients, GNOME just merged support for it two days ago: https://gitlab.gnome.org/GNOME/mutter/-&#x2
60.
by cycloptic 6y ago
There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn&#

More ›