Announcement

Collapse
No announcement yet.

New X.Org Server Release While Maintaining Separate XWayland Being Discussed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Depending on the point of view it is either tragic or funny.
    Whoever says something like '12 years and less than 10% market share' does not have the first clue how market adoption works.
    It is a done deal once you get to about 10% with a near exponential trend (that is about to go linear).

    Comment


    • #72
      Originally posted by mppix View Post
      Depending on the point of view it is either tragic or funny.
      Whoever says something like '12 years and less than 10% market share' does not have the first clue how market adoption works.
      Well in that case it is decreasing. It was 11% the month before

      https://linux-hardware.org/?view=os_...rver&period=89

      Comment


      • #73
        Originally posted by kpedersen View Post

        Well in that case it is decreasing. It was 11% the month before

        https://linux-hardware.org/?view=os_...rver&period=89
        You can show almost everything using a random window size on a data set with uncertainty. The general trends remain

        Comment


        • #74
          <Insert "lies, damn lies, and statistics" quote here>

          Comment


          • #75
            Originally posted by kpedersen View Post
            Well kind of, it distributed emulators running DOS. I would be very much more impressed if it still maintained Windows 95-98 era games (which even today are a real weak spot to emulate. Too resource intensive for full emulation, too hardware specific for virtualization). Neverwinter Nights and some of the older Loki games are going to prove challenging for stores like Steam to maintain. Though I think I am dragging this off topic here.
            There are some windows 3.11 and Windows 95-98 games in steam that run by wine/proton that valve does maintain that support. Yes these are games that don't run on current Windows.

            Comment


            • #76
              Originally posted by mdedetrich View Post
              The only reason right that Wayland is "tied" (very loosely speaking) to Linux now is that since Wayland is only a protocol, all of the DE were forced to re-implement everything from scratch and so unsurprisingly they decided to use Linux specific technologies (such as GBM) since it was easier which kinda forced the hand for the various BSD's.
              The reality is before Wayland all of the BSD based distributions were using different forms of ports of Linux technologies in the graphic stack. Wayland appears in 2008. GBM appears on Freebsd in 2004 and most other BSD by 2005 this is well before Wayland. So explain how is GBM and other parts like it a problem for the BSD when those parts have been on BSDs before Wayland existed.

              USES macros make it easy to declare requirements and settings for a FreeBSD Port


              GBM is not a Linux specific technology. I could go on an pull all the BSD. All the open source BSDs and Solaris based operating systems have the mesa libgbm interface library and the low level kernel GBM support. This existed before 2008 before the first line of text was written in the wayland protocol.

              mdedetrich the reality here is GBM is cross platform technology. Just GBM has been cross platform technology restricted to open source graphics drivers. Yes nvidia getting patch into libgbm recently to allow calling out to closed third party library is to allow closed source driver to interface in as most applications that use gbm expect the mesa libgbm to be on the system and as the way of interfacing. Please note I said most there is minigbm used in andorid and chromeos that is the other library for interfacing with kernel level GBM interfaces.

              In graphical work there are very few Linux specific technologies. Big one is systemd and cgroup stuff this is with systemd replacing gnome and kde session management and systemd logind replacing other parts.

              GBM you could say has been Mesa3D specific technology every platform using mesa3d as their source of open source accelerated graphics drivers has libgbm that works because the mesa3d open source accelerated graphics drivers don't work without it.

              Wayland developers did consider cross platform support in the reference implementation. We have had a long term feet dragger with Nvidia in this department. As in Nvidia not wanting provide the same interfaces the open source graphics drivers do.

              Comment


              • #77
                oiaohm

                The reality is before Wayland all of the BSD based distributions were using different forms of ports of Linux technologies in the graphic stack. Wayland appears in 2008. GBM appears on Freebsd in 2004 and most other BSD by 2005 this is well before Wayland. So explain how is GBM and other parts like it a problem for the BSD when those parts have been on BSDs before Wayland existed.
                Well played sir, well played. 😊.
                It helps when one actually knows what one talks about. And as I've mentioned earlier, now for the third time, Wayland IS available for at least FreeBSD, even if it's early days:



                So all BSDs should in theory be able to port Wayland eventually. Regarding proprietary Unix: I could not care less.
                Last edited by tomas; 13 July 2021, 01:16 AM.

                Comment


                • #78
                  Originally posted by tomas View Post
                  So all BSDs should in theory be able to port Wayland eventually. Regarding proprietary Unix: I could not care less.
                  Partially based on an earlier porting attempt by Johannes Lundberg from https://github.com/FreeBSDDesktop/freebsd-ports-graphics (specifically, the vt switching code)


                  Its not theory this here was a person who ported weston to freebsd. Yes the reference compositor. GBM is not problem. Yes there are parts that are Linux particular or FreeBSD particular but we are talking less than 1000 lines of code total. Not a single bit of it has anything todo with feature provided by Mesa3d.

                  Yes there are others that have made weston work on many of the BSD operating systems. The difference have basically been like there. The OS clock system name is different the TTY naming is different... All really minor surface level thing still annoying and time consuming to fix but not Linux only tech. This is a case the BSD and Linux have the same tech just named it differently.

                  Of course your more complex windows managers like KDE the wayland section uses systemd parts more. So problem child here is not items like KMS/GBM/DMA BUF..... the bits developed by Mesa3d group working with Intel and amd this is confirmed by the ports that have been done. The problems are having enough developer time to do the ports and the systemd problem. Of course that KMS/GBM/DMA-BUF..... of mesa3d is cross platform does not really suite the Nvidia story that we need EGLSTREAMS because it cross platform. The reality is both solutions were cross platform. Yes EGLSTREAMS really does not change about the 1000 lines of code different per platform supported either.

                  Comment


                  • #79
                    Originally posted by oiaohm View Post

                    The reality is before Wayland all of the BSD based distributions were using different forms of ports of Linux technologies in the graphic stack. Wayland appears in 2008. GBM appears on Freebsd in 2004 and most other BSD by 2005 this is well before Wayland. So explain how is GBM and other parts like it a problem for the BSD when those parts have been on BSDs before Wayland existed.

                    https://docs.freebsd.org/en/books/po.../uses/#uses-gl

                    GBM is not a Linux specific technology. I could go on an pull all the BSD. All the open source BSDs and Solaris based operating systems have the mesa libgbm interface library and the low level kernel GBM support. This existed before 2008 before the first line of text was written in the wayland protocol.

                    mdedetrich the reality here is GBM is cross platform technology. Just GBM has been cross platform technology restricted to open source graphics drivers. Yes nvidia getting patch into libgbm recently to allow calling out to closed third party library is to allow closed source driver to interface in as most applications that use gbm expect the mesa libgbm to be on the system and as the way of interfacing. Please note I said most there is minigbm used in andorid and chromeos that is the other library for interfacing with kernel level GBM interfaces.

                    In graphical work there are very few Linux specific technologies. Big one is systemd and cgroup stuff this is with systemd replacing gnome and kde session management and systemd logind replacing other parts.

                    GBM you could say has been Mesa3D specific technology every platform using mesa3d as their source of open source accelerated graphics drivers has libgbm that works because the mesa3d open source accelerated graphics drivers don't work without it.

                    Wayland developers did consider cross platform support in the reference implementation. We have had a long term feet dragger with Nvidia in this department. As in Nvidia not wanting provide the same interfaces the open source graphics drivers do.
                    GBM was created for Linux developers. by Linux developers. When the BSD's saw the writing on the wall with what was happening to graphics stack they manually ported GBM to their own platform because they had no choice. Proof of this case?

                    1. No one that develops GBM (or more accurately Mesa and related stack) tests BSD as part of the software development of the project. All testing/CI is pretty much done on Linux and the BSD's are pretty much forced to do the rest themselves (this is in stark contrast to X11/Xorg which was deliberately created as an OS neutral project and hence for all of its history up until recently was tested on all platforms, not just linux). This is also why the BSD's are behind on Linux with their graphics stack.
                    2. GBM was never created to be cross platform in the first place. BSD's actually didn't even have a need for GBM initially because unlike Linux, they don't really care about requiring GPL2 drivers in their tree (in fact they are actively trying to push GPL2 code out of their core distribution packages, if possible).

                    Actually up until recently it can be argued that GBM was "anti" cross platform because it only worked with open source drivers and no other majorly used OS (BSD's, Windows, MacOS) used open source drivers as the main driver for graphically demanding workloads. Open source drivers were used, but only for starting up the initial video output or for cases where no one cares about high fidelity graphics (i.e. server boxes need only basic VGA output). If you wanted good graphics (for w/e reason) on the BSD's, you were always running the NVidia blob.

                    Ironically then Linux's hand was forced, and MESA (and the rest of the stack) had to be adjusted to work with closed source drivers because unsurprisingly none of the Linux developers wanted to use anything that wasn't GBM if they had to rewrite things from scratch (which they had to with Wayland).

                    So yeah I stand by my statement, GBM was never designed to be cross platform and its "sorta" cross platform now (if you can call it that) but its by accident. It would be the exact same case if for some reason systemd was ported over to BSD and ended up being established (systemd was never designed for non Linux systems)

                    Comment


                    • #80
                      mdedetrich

                      Ironically then Linux's hand was forced, and MESA (and the rest of the stack) had to be adjusted to work with closed source drivers
                      Wait, what?!
                      What are you talking about?
                      In what way was "MESA (and the rest of the stack)" adjusted to work with closed source drivers? I suspect that you are mixing things up. Or are you referring to the recent change to Mesa to re-enable having pluggable GBM-backends in order for Nvidia (and others) to supply alternative GBM implementations? In that case, it's not a new feature or even adjustment, it was always there from the beginning. And it is in fact the other way around. It's Nvidia that's finally getting in line (or if you prefer: caving in) and adjusting its proprietary driver to work with the established open source driver mechanism like GBM and DMA-buf. It is Nvidia that will abandon EGL streams for Linux and finally fix their driver to work with Wayland and Xwayland. Kudos to the Linux- and Mesa community for sticking to their guns and not caving in to Nvidias so called "standard" EGL-streams that only they implemented.
                      Last edited by tomas; 13 July 2021, 04:42 AM.

                      Comment

                      Working...
                      X