[HN Gopher] Xorg-Server 21.1.0
___________________________________________________________________
Xorg-Server 21.1.0
Author : Liskni_si
Score : 132 points
Date : 2021-10-27 17:29 UTC (5 hours ago)
(HTM) web link (lists.x.org)
(TXT) w3m dump (lists.x.org)
| jancsika wrote:
| I found a neat tool recently called x2x. It lets me forward
| keyboard/mouse movement from my laptop to my rpi-connected tv
| over ssh. So my laptop ends up doubling as a very fancy remote
| control. :)
|
| E.g., I just mouse over to the right on my screen so I can move
| the mouse on my tv and then type in a search string to bring up a
| video to watch in the browser on the tv.
|
| 1. Can this be done with Wayland currently? (Currently = works in
| some lts version of a popular distro like Debian or Ubuntu).
|
| 2. Glad to see people still working on fixing bugs and making
| improvements in Xorg-Server!
| Liskni_si wrote:
| Coincidentally, xmonad 0.17.0 was released today as well:
| https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html :-)
| nextos wrote:
| Yes, I've been using XMonad (and StumpWM) for many years and
| they are tightly coupled to Xorg.
|
| Moving to Wayland implies a complete rewrite of both is
| necessary.
| dyingkneepad wrote:
| It's so nice to see this!
|
| As someone who is still not using Wayland by default (I tried,
| but it regresses my setup), I am thankful there are still people
| involved on this. Good job, guys, you are appreciated. It's not
| just because Wayland looks sexier [0] that your work on the thing
| most people actually use is appreciated.
|
| [0]: considering Wayland is more than a decade old by now and is
| still a huge mess, I guess I'll keep trusting old lady Xorg's
| experience to handle my workflow.
| woodruffw wrote:
| > The meson support is now fully mature. While autotools support
| will still be kept for this release series, it will be dropped
| afterwards.
|
| autotools delenda est.
| sprash wrote:
| Rather bad news. Meson introduces a rat-tail of build
| dependencies.
| doppioandante wrote:
| You may be interested in muon:
| https://git.sr.ht/~lattis/muon/
| cozzyd wrote:
| Terrible name. A muon is a lepton, not a meson.
|
| If it were a lighter replacement of electron, muon would be
| an appropriate (if counterintuitive) name.
|
| There are so many mesons (pion, kaon, \eta, \rho, J/\psi,
| D, B, \omega,\upsilon), why not pick one of those?
| woodruffw wrote:
| > Meson introduces a rat-tail of build dependencies.
|
| From the Ubuntu repos, it looks like the top-level
| dependencies are Ninja and Python 3[1]. That doesn't seem
| particularly bad to me?
|
| [1]: https://packages.ubuntu.com/focal/meson
| eddieh wrote:
| Had to deal with this recently, Homebrew on macOS though.
| Meson build failed. Had to manually install Mako with pip,
| which also installed MarkupSafe. Then bitched that Homebrew
| (or Linuxbrew) will break in the future for some reason. So
| next time I build X, I can look forward to that. :/
| wott wrote:
| Each time something requires Meson, you can also bet it
| requires a different version than the one you have
| installed... :-/
| woodruffw wrote:
| My understanding (which could be very wrong) is that
| Meson on its own has no external dependencies like Mako,
| but that (by virtue of being Python) anybody can write a
| terrible build that introduces additional dependencies.
| Is that correct?
|
| If so, that's unfortunate, but it isn't _that_ different
| from what happens in autotools land -- I 've had plenty
| of builds fail because the configure step fails to check
| for `$tool` and then expects it to be present at build-
| time.
| eddieh wrote:
| I believe that's correct.
| bonzini wrote:
| Two: Python and ninja/samurai (samurai doesn't have any
| dependency other than a C compiler). Almost any program the
| size of Xorg will likely already depend on Python anyway.
| wott wrote:
| > Almost any program the size of Xorg will likely already
| depend on Python anyway.
|
| Last time I built X by hand, there was one... one single X
| element the building of which depended on Python amongst
| the many, many components of X: XCB. So I had to install
| Python just for that one module; let me tell you I wasn't
| happy at all with such choice. Icing on the cake, the
| Python scripts were not compatible with Python 3, and also
| mixed spaces and tabs for indentation, so I had to write
| patches to get the stuff to compile.
| pantalaimon wrote:
| Won't that annoy most distributions as they now have to update
| their package build script for X.org?
| woodruffw wrote:
| The life of a package distributor is one of constant build
| changes. Among them, the switch from autotools to meson is
| probably not an especially disruptive one. For the ecosystems
| I've helped maintain, it certainly wouldn't be.
| wahern wrote:
| Packaging frameworks like Debian and RPM coevolved with
| autotools, especially when it comes to things like cross-
| compilation, standard build flags, etc. Anything that moves
| _away_ from autotools is, AFAIU, generally considered a
| PITA for maintainers of the big distributions. Modern build
| tools optimize for the problems of massive corporate
| centralized repositories and build pipelines, which often
| bundle dependencies and otherwise approach most problems
| from an entirely different angle. Nuances related to
| portability, cross-compilation, filesystem hierarchies,
| dynamic library versioning, etc, are typically
| afterthoughts if they 're considered at all.
|
| OTOH, while it's a PITA it's certainly one to which package
| maintainers are accustomed. autotools began to lose
| mindshare among younger programmers and with younger
| projects many years ago.
| sjcoles wrote:
| Modern rpm spec has built in macros for meson making it
| less of an issue.
| wahern wrote:
| IME as someone who has done _alot_ of portability work,
| both for my own projects and others, and including
| writing more than my fair share of Debian and RPM builds
| (but not as an official package maintainer for a distro),
| boilerplate stuff is rarely the issue. It 's all the
| random, niche problems that invariably crop up at least
| once or twice with every project, even smaller ones.
| Every build is broken somehow. Given that basic reality,
| what matters is how often you can route around brokenness
| without patching the upstream build, and when you must
| patch how easy it will be to implement and maintain those
| patches.
| eddieh wrote:
| Building X was already complex and annoying. While I hate
| autotools, I didn't find Meson to be particularly better. If
| anything this is a lateral change. Instead of m4, shell, and
| makefiles, Meson has python, some python packages (managed
| with pip), and ninja. I guess Meson is faster, but I'm not
| convinced that justifies changing the build system especially
| since the speed up isn't too significant.
| p12tic wrote:
| My own experience working on X server, clean ccache-based
| rebuild is a couple minutes faster on meson compared to
| autotools. These minutes add up quickly, switching my
| workflow to meson paid for itself the same day.
| bonzini wrote:
| Meson doesn't depend on anything other than the Python
| standard library.
| eddieh wrote:
| Okay, but builds can require additional python modules.
| Mesa requires Mako and won't build without it.
| chousuke wrote:
| If you're packaging RPMs, what you need is approximately to
| change a few %configure macros to the corresponding %meson
| macros. Though X.org is large enough that there will probably
| be some weirdness.
|
| If your software is distributed as a source tarball, the
| build system follows established conventions like honouring
| $DESTDIR and doesn't do anything weird like download extra
| stuff from the internet, creating packages is super easy, at
| least with RPM.
|
| Most of the time you just write out a bit of metadata, list
| your dependencies, use standard macros for your build system
| to do the actual building and then list the files that you
| want to use from the build (potentially putting them in
| subpackages), and that's it. RPM even supports specifying
| dependencies like pkgconfig(library) or perl(Thing) so that
| the actual package name that provides it does not matter.
|
| I haven't done Debian packaging in ages so I don't know how
| it compares.
| p12tic wrote:
| On Debian it's the same. I use Debian packages as the means
| to ship code to test devices and the most time consuming
| thing when converting X server from autotools to meson was
| the default configure flags (meson and autotools use
| different formats).
| bradfitz wrote:
| While researching what Meson was after reading this, I was
| amused at this FAQ entry on their site:
|
| https://mesonbuild.com/howtox.html --- "How do I do X in
| Meson?"
|
| :)
| p12tic wrote:
| Hi, I'm the release manager responsible for this X release seeing
| the light.
|
| This release would not have happened if an effort to improve
| touchpad support in Linux was not funded for the past year and
| half. X server 21.1 makes touchpad gesture functionality support
| universal so it's much easier to offer consistent user experience
| for everyone and downstream developers are less reluctant to
| accept contributions.
|
| Thanks a lot to all the sponsors:
| https://github.com/sponsors/gitclear
|
| By the way, I wonder if there is demand for long-term maintenance
| of X server specifically. If you think you could contribute,
| maybe write here and if there's enough interest maybe it's
| possible to crowd fund something.
| eddieh wrote:
| Hi, I was recently trying to make some improvements to the
| build for XQuartz, which in turn was so I could make some
| changes to XQuartz and fix some issues with recent macOS
| changes too.
|
| While I made some progress, it took much longer than I
| anticipated. I wonder if there's demand enough for X server on
| macOS to justify this work? Additionally, I'd have to find some
| funds to support my work as well, if I were to continue.
| ace2358 wrote:
| Yes there is! XQuartz is so important to keep going as there
| are a few beautiful tools that run on it that would be sad to
| see go.
| znpy wrote:
| > By the way, I wonder if there is demand for long-term
| maintenance of X server specifically.
|
| Hello and thank you for your work!
|
| I'd love to see Xorg maintained at least.
|
| It seems to me there still is dust to settle around wayland and
| xorg os getting little to no development.
|
| Honestly, I'd just like xorg to keep working until the rest of
| the ecosystem has native wayland support.
|
| Taking myself as an example: i just like xfce. Xfce is not on
| wayland yet. I don't care how buggy xorg is or how better
| wayland is, I won't switch if I can't run xfce.
| GekkePrutser wrote:
| Thanks for your efforts!
|
| In my view there's absolutely space for Xorg in the future. Not
| every OS can run Wayland well and Wayland lacks some X features
| like network transparency.
|
| I kinda hope it'll be backed by an organisation that's really
| keen on taking it forward. Augmenting the security model for
| example. And going back to some client rendering enabling
| features like anti-aliasing. I really think there's a lack of a
| viable remote display tool in Linux, where Windows has RDP.
| Block pushers are just too slow. VDI usecases are picking up
| again heavily, as do other security based techniques which
| could benefit, like remote browser isolation. Filling up my
| desktop with Windows running on a bunch of other computers is
| just so powerful.
|
| So in other words I'd love to see an X12 that really moves
| towards the future. As I understand it, it's currently with
| RedHat which only sees future in Wayland and X is just on life
| support. I regret that because I see a lot of concepts in it
| that are still very valid and that have been lost in current
| alternatives.
| Klasiaster wrote:
| For Wayland there is waypipe for single-window forwarding
| over SSH, and there is wayvnc for wlroots-based compositors
| (Phosh, sway) which can run in headless mode with llvmpipe
| rendering, and weston has an RDP backend (but I recommend
| wlroots with wayvnc over weston).
| yjftsjthsd-h wrote:
| > I really think there's a lack of a viable remote display
| tool in Linux, where Windows has RDP. Block pushers are just
| too slow. VDI usecases are picking up again heavily, as do
| other security based techniques which could benefit, like
| remote browser isolation. Filling up my desktop with Windows
| running on a bunch of other computers is just so powerful.
|
| I think it's just a tooling problem; Apache Guacamole or Xpra
| can trivially stick windows in a browser window, VNC is...
| okay, not amazing, but passable, and even RDP can be made to
| work well on Linux, it's just that setting up any of those is
| a horrible pain on Linux (in my experience at least).
| diegocg wrote:
| X is a dead end. If you want an evolution of X with network
| transparency, Arcan seem to be the most likely alternative
| https://arcan-fe.com/2020/10/28/a12-advancing-network-
| transp...
| emidln wrote:
| I successfully use X11 and its network and OS transparency
| daily. Macbooks don't have 2TB of RAM or schedule 256
| threads at the same time.
| markstos wrote:
| Which OSes can't run Wayland well?
| ch_123 wrote:
| The last I checked, the BSDs and most other Unix-likes (and
| genuine Unix(tm) variants) don't support Wayland. In fact,
| Wayland is pretty much Linux-only in practice.
| amarshall wrote:
| Wayland is viable on FreeBSD, at least. It is very much
| not "Linux-only".
| ch_123 wrote:
| From the FreeBSD wiki:
|
| https://wiki.freebsd.org/Graphics/Wayland
|
| > While Wayland isn't ready for general use.
|
| I can't readily find anything to indicate that this claim
| is out of date. I am aware that Wayland has been ported,
| but I have not heard of it being widely used, or being
| "production ready" as per se.
| amarshall wrote:
| FreeBSD wiki is a bit notorious for being out-of-date,
| and that particular page is marked "CategoryStale".
| Anyway, first result on DuckDuckGo is someone using
| Wayland on FreeBSD successfully [1].
|
| [1]: https://euroquis.nl/freebsd/2021/03/16/wayland.html
| rbanffy wrote:
| > Wayland lacks some X features like network transparency.
|
| This, IMHO, is the most tragic loss in functionality desktop
| systems suffered.
|
| It's hard to justify being unable to do something we've done
| since the mid 90's. The fact I could sit in front of a
| computer while running GUI software from different machines
| with different OSs as if they were local and that, now, the
| best I can hope for is what VNC gave me in the early 2000's
| is nothing short of depressing.
| guenthert wrote:
| I can relate as I'm one of the few people I personally know
| who has used that feature in the last twenty years. In the
| last ten years or so however, I used some variation of NX
| in any case, whenever I needed a remote X application, as
| then I typically need to preserve the session as well. I
| think the last time I used plain X11 protocol across the
| network was when I still had Sun Rays (between the Sun Ray
| server and the application's host).
| mrweasel wrote:
| So if the touchpad funding had failed there would have been no
| more Xorg release?
| p12tic wrote:
| At least I would not have been driving this release.
|
| Maybe someone else would have stepped up, it's hard to say.
| However there was no release manager for the last several
| years, so the likelihood of this outcome would have been
| small.
| mrweasel wrote:
| That seems to be very much in line with previous statements
| from Redhat and others that X is almost abandoned.
| wott wrote:
| The statements that _they_ took the keys and then
| abandoned it.
| dralley wrote:
| You would be hard pressed to find _any_ current-or-former
| Xorg developer who actually _wants_ to work on Xorg
| anymore, regardless of their employer. The intersection
| between long-time core Xorg maintainers and people-who-
| started-the-Wayland project is nearly 100%.
|
| The fact that Red Hat doesn't see much future in Xorg
| reflects this, rather than the other way around.
|
| The other historically important corporate sponsor of
| Xorg development is Intel, and they seem to have reached
| the same conclusion.
|
| (I work for Red Hat, but not on anything graphics
| related)
| yjftsjthsd-h wrote:
| > By the way, I wonder if there is demand for long-term
| maintenance of X server specifically. If you think you could
| contribute, maybe write here and if there's enough interest
| maybe it's possible to crowd fund something.
|
| Are we talking money, time, tooling, etc.? I'm rather attached
| to Xorg and would like it to keep going; what would be the most
| helpful?
| zbuf wrote:
| > By the way, I wonder if there is demand for long-term
| maintenance of X server specifically.
|
| Certainly interested in that, though you're not clear whether
| it's time, money or community you're asking for.
|
| Whatever happens, at some point momentum would have to gather
| outside of RedHat.
|
| Still very happy with X here, and mainly running X applications
| across network rather than Qt/GTK toolkits and desktop
| environments.
| p12tic wrote:
| > though you're not clear whether it's time, money or
| community you're asking for
|
| All of these, but perhaps the most important would be money
| as it's the only thing that clearly indicates the level of
| community support. Once there's funding it's much easier to
| prioritize the work.
| jmclnx wrote:
| As a BSD user, glad to see the release, but I am concerned about
| the future of X since Wayland has plenty of Linuxisms in it,
| making it very hard to port.
|
| https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-...
|
| https://undeadly.org/cgi?action=article;sid=20210124113220
| jbverschoor wrote:
| Can we get an html implementation of X, in such a way that it
| doesn't require framebuffers, but just uses the the windowing and
| text primitives?
| cpach wrote:
| Not sure but maybe this is similar to what you're
| describing...? https://guacamole.apache.org/
| yjftsjthsd-h wrote:
| You'd have to pair with xvnc or
| https://en.wikipedia.org/wiki/Xvfb + x11vnc or so, but yeah
| pantalaimon wrote:
| After a quick search I found
|
| https://github.com/Xpra-org/xpra-html5
|
| and
|
| https://github.com/GothAck/javascript-x-server
| marcodiego wrote:
| Xorg/Xfree86 served us very well for decades. Will still continue
| to do so as XWayland. It feels like saying goodbye to a good
| employer that is retiring but will be replaced by someone more
| adequate for the job.
|
| Thank you all, devs!
| sprash wrote:
| So far there is no viable replacement around that is "more
| adequate for the job" (Wayland is fundamentally flawed at the
| concept level). So Xorg will stick around much longer probably
| decades.
| pengaru wrote:
| > (Wayland is fundamentally flawed at the concept level)
|
| That's a mighty big hand you're waving.
| hsbauauvhabzb wrote:
| As a consumer/power user with a fairly bespoke window manager
| I'm worried that the minimalist approach to wayland will
| fragment functionality depending on compostor / DE.
|
| Wanna use Firefox? gotta use gnome compostor for that!
| Chromium only works on KDE compostor, etc.
|
| Is this a misguided fear, or do you anticipate it moving that
| way?
| wing-_-nuts wrote:
| >Wayland is fundamentally flawed at the concept level
|
| Expand?
| sprash wrote:
| The biggest problem of Wayland is that it has the wrong
| philosophy ("Every frame is perfect") and the wrong
| abstractions ("Everything in the universe is an array with
| RGBA values"). If your foundations are flawed like that you
| are doomed from the start. What remains is a very expensive
| and cumbersome way of blitting bitmaps.
| bitwize wrote:
| People with decades of experience, each, in the Linux and
| Unix graphics stack, have determined that the most
| efficient thing to provide, from a display server
| perspective, is a way of blitting bitmaps (specifically,
| of compositing bitmaps representing viewports into a
| final screen image) and that, if there is rendering to be
| done, it should be done client side. This is the
| consensus of those with domain knowledge, and it is what
| is supported by the broader community (toolkits, DEs,
| etc.). It's also how the major toolkits have been doing
| things anyway, irrespective of how X11 actually works:
| draw everything client side and send it to the X server
| for display. So, your X server is really effectively
| nothing more than a shitty Wayland compositor.
|
| And people wonder why Linux lags behind Windows and macOS
| in terms of desktop smoothness and quality.
|
| When all is said and done, you may as well remove the
| legacy cruft (drawing and filling primitives, the fucking
| X font architecture, etc.), delegate remote display to a
| protocol that is better designed to support it such as
| RDP or PipeWire that only gets loaded when necessary
| (which it's not for 90% of users in 90% of use cases),
| and streamline the display server itself to just that
| which modern clients actually need, and that's Wayland.
| Wayland just brings Linux, barely, up to the state of the
| art set by Windows, macOS, iOS, and Android -- which have
| prioritized perfect frames and smooth compositing and
| presentation since forever ago.
| alerighi wrote:
| Sure, it has better performance if there is not a
| networking protocol in the middle.
|
| What I like about X, that is missing in Wayland, is that
| you no longer can run the X server on a machine and
| connect to clients (application) on another.
|
| And if you think about it... this day with the cloud it
| could have been the killer feature! Nowadays is normal to
| have programs that run in VM in the cloud with a sort of
| remote desktop client. X11 would have been more
| performant even with not so fast network connection,
| because you have the rendering done in your local PC and
| only commands that pass on the network.
|
| And if you think about it for a moment, isn't how web
| browsers work? Where you have the server that sends some
| HTML to the browser (nowadays JS and other stuff) and the
| browser doing the job of rendering? If you compare the X
| server to a web browser and the X client to a web site,
| isn't very similar? And this is the model that is winning
| nowadays.
|
| Meanwhile we think about a new graphical server that
| cannot be used on a network, in a period where we are
| returning in the era of mainframes, when X was created
| (granted, nowadays is not a big PC in a room but a
| multitude of VM in the cloud).
|
| The problem is not X, the problem is that X was never
| used at is full potential because we are so used to the
| (to me not optimal) model that Microsoft/Apple proposed
| to us.
|
| You could have had monitors with an integrated X server,
| like in the past you had serial terminals, without fans,
| cables, and stuff on your desk, just a small ARM
| processor with a GPU to render things on screen. And a
| single network cable going to a computer that you had
| anywhere else in the house/company, or in the cloud.
|
| No need for HDMI or other display interfaces, just run a
| network cable to each monitor, plug keyboard and mouse on
| the monitor, you are done. The GPU is in the monitor,
| doesn't it make more sense? How much money that could
| have saved to a company? It would have been more
| efficient than thin clients that connect to an RDP
| Windows machine that has to have a GPU just to render the
| remote session? Large installations like displays used
| for public information? Why use a full screen web
| browser, it's overkill, when you could have simply
| launched a X server on the particular display, then
| launched an application on a server and connected to the
| IP of that particular monitor to display everything you
| wanted?
|
| The architecture of X was modern 40 years ago when it was
| invented. It in some ways predicted the future, and now
| that we are discarding it for something that tries to
| imitate Windows/macOS (badly, because these operating
| systems just works well, Wayland doesn't). Is it worthed?
| bitwize wrote:
| The people who write and maintain X decided that life is
| too short to write or maintain X. Wayland is their way
| forward.
|
| Web browsers (and Electron) are replacements for NeWS,
| not X really. That's part of the reason why Electron
| won't go away, the architecture advantages are too great:
| have the server push running code to the local display to
| take advantage of local acceleration. NeWS was awesome in
| its day, and it kind of lives on in the form of browsers
| and Electron.
| rbanffy wrote:
| And none of the original NeWS developers miss writing
| apps in PostScript.
| rbanffy wrote:
| > this day with the cloud it could have been the killer
| feature!
|
| My impression is that latencies kill X performance.
| Having a server under my desk is one thing, but running
| even something like xedit halfway across a world is
| painful. It may be possible to update these tools to be
| less synchronous, but I'm not sure this is a great use
| case, certainly not for new applications.
|
| > No need for HDMI or other display interfaces, just run
| a network cable to each monitor, plug keyboard and mouse
| on the monitor, you are done.
|
| This would be great. Every monitor has at least a frame
| buffer and there is no need to push every pixel to the
| monitor 60 times a second. Worst case scenario is you
| have a sporting event where you need to push every pixel
| to the screen 60 or more times per second, but, most of
| the time, there's no such need.
| margalabargala wrote:
| Presumably the designers of Wayland do not think that
| this philosophy and those abstractions are so
| fundamentally flawed.
|
| Could you explain why these concepts are so flawed, for
| those of us to whom it is not immediately obvious?
| sprash wrote:
| For some applications you want "every frame is recent"
| and can tolerate some glitches as trade off for not
| having perfect frames. Also displays have different pitch
| values, subpixel arrangements, color spaces, etc. A line
| from A to B might look completely different on different
| monitors. By offering only RGB arrays as abstraction
| Wayland pushes the the need for care of those differences
| down to clients which is a mistake.
|
| Additionally a Desktop system in general is much more
| than a bunch of bitmaps blittet together. Applications
| need to interact and such functionality has to be tightly
| integrated into the compositor with standardized
| protocols otherwise it will be impossible to have such
| functionality. Taking screenshots, drawing to the root
| window or knowing about coordinates of windows from other
| programs are some examples.
| kaba0 wrote:
| > For some applications you want "every frame is recent"
| and can tolerate some glitches as trade off for not
| having perfect frames
|
| Oh and what gives, wayland just has an extension for this
| use case!
|
| HDR is work in progress, there is nothing unchangeable in
| Wayland that would disallow different buffer types.
| im3w1l wrote:
| It tried to come up with issues (out of gamut colors?
| other optical properties than opacity - turn a portion of
| the screen into a mirror? not correctly modelling color
| filter arrays?). Best I could come up with was that it's
| not VR-ready. Which might be an issue in 15+ years.
| kaba0 wrote:
| How would Wayland be fundamentally flawed?
| sprash wrote:
| Wayland makes the wrong abstractions and does not offer
| vital functionality usually needed on a Desktop system. As
| a result every Toolkit/Compositor has to implement that
| additional functionality itself and most of the time it is
| incompatible to the competitor for no apparent reason.
|
| As an exercise I recommend to write a native universal
| applicable Wayland application that takes screenshots.
| xxpor wrote:
| Why are objections like this not solved with things like
| wlroots?
| folmar wrote:
| wlroots are not used by the two main desktops, so to get
| basic features like screenshots you need to support 3
| different ways already.
| boudin wrote:
| You're mistaken, that's not the role of wayland. If
| you're looking into an universal way to takr screenshots,
| screesncast, etc..., you're looking for xdg-desktop-
| portal. There'is implementations for wlroots, gnome, qt,
| and others.
| wing-_-nuts wrote:
| >You're mistaken, that's not the role of wayland.
|
| A side note, but I _really_ hate this ideology of 'x
| does one thing' outside of command line tools. This is a
| display server we're talking about. It should be able to
| enable normal desktop usage. Maybe not everything but
| core features like brightness control, screen sharing,
| screenshots, etc. Otherwise every wm that comes along is
| going to have to reinvent the wheel. There are tons of
| really great window managers out there, where the authors
| have looked at all the work it will take to get running
| on wayland, and have simply thrown their hands up in
| frustration.
|
| It seems to me the only people that really benefit from
| the switch to wayland are the wayland devs themselves.
| kaba0 wrote:
| Wlroots is an implementation of wayland protocols -- if
| gnome and plasma implement the same protocol according to
| specification, you only have to write code to that
| protocol, once.
| yjftsjthsd-h wrote:
| Right, but that protocol isn't in wayland proper and
| isn't standardized, so GNOME and KDE and wlroots all have
| different takes.
| dralley wrote:
| Right, but the point is that the protocol doesn't _need_
| to be in Wayland proper, so long as it 's standardized
| _somewhere_. And it is.
|
| https://flatpak.github.io/xdg-desktop-portal/portal-
| docs.htm...
| craftinator wrote:
| > As an exercise I recommend to write a native universal
| applicable Wayland application that takes screenshots.
|
| As someone who tried to do this... Ouch. Things like this
| are why X will still be around in 15 years.
| markstos wrote:
| Wayland as a `screencopy` protocol and the `wlroots`
| library packages it for other compositors to use.
|
| Is the issue that compositors don't implement the
| `screencopy` protocol themselves or use the
| implementation provided by wlroots?
|
| Ref: https://wayland.app/protocols/wlr-screencopy-
| unstable-v1
| folmar wrote:
| Not really - to quote the page you reference:
|
| > "Warning! The protocol described in this file is
| experimental and backward incompatible changes may be
| made.
|
| and the compositors were there way before 2018, so it's a
| bit too much to expect them to jump on the protocol.
| tosihakkeri wrote:
| Based on what you just wrote, it sounds to me that you
| might be assuming the wrong abstraction yourself.
| kaba0 wrote:
| Wayland as a display protocol (correctly) started out
| with a tiny core, which can display the content of a
| window, and manage available extensions by version.
|
| This has grown out to be a really great abstraction,
| where later multiple implementations can decide on new
| protocols/extensions to support. And they have already
| done plenty of such extensions, and they are compatible
| with each other. Remember, these are protocols. There is
| no need to implement them yourself, they can be made into
| a library, like wlroots, and you can build your
| compositor on that base, without any repetition. Also,
| multiple implementations only mean that there won't be
| implementation-specific quirks.
|
| As for screenshots specifically, while the base use case
| is trivial enough, recording screens are most definitely
| not (it needs proper synchronization). Pipewire is the
| project that can solve the issue perfectly, and it is
| indeed working correctly for like a year already, with
| screen share even in proprietary apps like teams.
| enriquto wrote:
| > As for screenshots specifically, while the base use
| case is trivial enough, recording screens are most
| definitely not (it needs proper synchronization).
| Pipewire is the project that can solve the issue
|
| If I understand the OP correctly, this sort of philosophy
| is deeply troubling to some people. For simplicity-
| oriented folks, trivial things should be trivial, as a
| matter of principle. If some trivial thing becomes
| slightly less convenient so that complex stuff may be
| possible, this is an unacceptable compromise; or at least
| a very worrying one. When taking static screenshots
| requires an entire "project" that is "just ready this
| year" , the threshold of unacceptability is long
| surpassed.
|
| I get that wayland folks do not share this worldview and
| they want to do the right thing, even at the expense of
| sacrifying things that were previously easy. But, to
| other people, this rubs them in a _very_ wrong way.
| kaba0 wrote:
| wlroots does implement a very simple screenshot protocol,
| the reason I didn't mention it was that it is not cross-
| wayland-implementation. But there is nothing inherent in
| wayland that would prevent this functionality -- they
| just try to find a good abstraction they all can stick to
| (as these APIs will likely be used for a long time), and
| gnome and plasma people have a different view on that.
|
| (Also, if we have a complex program that does all the
| things we need and a simple program+the complex one, we
| will have more complexity in the latter case so the
| previous one may be preferred)
| bitwize wrote:
| I'm sure the architects of Xorg have a much better idea
| of which abstraction to use and why it's superior to
| Wayland.
|
| Oh wait, the architects of Xorg _designed_ Wayland!
|
| X11 is a dead end. Its authors have deprecated it and
| offered an upgrade path: Wayland. Time to make like Elsa
| and let it go.
| bitwize wrote:
| > As a result every Toolkit/Compositor has to implement
| that additional functionality itself and most of the time
| it is incompatible to the competitor for no apparent
| reason.
|
| Or, compositors can use these wonderful things we have
| called dynamic libraries, and simply link against
| implementations of that desktop functionality, such as
| wlroots -- which implementations, by the way, will be far
| less crufty and ad hoc than the equivalent X11 solution!
|
| Much of the reason why X is the way it is is because back
| in the day, Unix lacked dynamic libraries in general, so
| in order to share an implementation of, say, graphics
| primitives, the best way was to write a server that
| implemented them and have clients communicate with that
| server. Now that we have dynamic libraries, we can share
| a single implementation of graphics rendering across
| multiple programs, _and_ still have all the speed
| advantages of doing all the rendering client side!
| pantalaimon wrote:
| I think it will take several years before smaller desktop
| projects like Mate will move to Wayland, until then I'm happy
| to use X.org
|
| There is nothing Wayland puts on the table that makes me
| compelled to go out of my way to use it.
| jgb1984 wrote:
| Wayland solves problems that I don't have, while introducing
| new ones (my Nvidia GPU isn't well supported, remote X doesn't
| exist and none of the wm's I love support it, like openbox). So
| I'll stay on Xorg for as long as I can.
| hsbauauvhabzb wrote:
| Are you able to elaborate on the GPU issues you've had? Im in
| the same position w/ an nvidia flu but I've never tried
| wayland
| jatone wrote:
| lack of support for nvidia is entire nvidia's own fault.
| basically they decided to go there own way on buffer
| management for userspace and the development community
| rejected them at large.
|
| it'll be fixed in about 1 year, nvidia finally got on board
| and built the APIs they needed to build. iirc KDE forced
| one of the nvidia devs to implement and then fix all the
| problems with nvidia on KDE wayland. basically the dev went
| back to nvidia and was like 'just implement the GDM apis'
___________________________________________________________________
(page generated 2021-10-27 23:01 UTC)