Announcement

Collapse
No announcement yet.

NetBSD On The State & Future Of X.Org/X11

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

  • Originally posted by oiaohm View Post
    This is also not true.


    Even the forks of Xfree86 you had software that only run on them. Like the Quake2-GLX here that is customized for Utah-glx.



    It absolutely cannot be JWM because only comes into existence in 2003 so it from the wrong time frame and need newer X11 protocol features than what a 90s X11 server is going to provide even Xfree86 one. IceWM is from the right time frame being 1997 but it absolutely falls on face with Accelerated-X and all the other closed source X11 servers of the 90s because all of them are based of x386(predecessor to Xfree86) that branches off before ICCCM that becomes Extended Window Manager Hints​.

    Accelerated-X only got ICCCM and Extended Window Manager extensions to the X11 protocol in 2002 even that ICCCM had been in the X11 standard as of 1994. So you could not use IceWM until 2002 under Accelerated-X and that was in fact first out of all the commercials X11 servers to get that feature..

    The branch point for the commercial X11 servers being sold in 90s is somewhere in 1987-1988 in the predecessor to Xfree86 being X386 by the X11 protocol features they supported.

    ICCCM is a 1994 added feature to the X11 protocol. Yes IceWM of 1997 does not work without ICCCM.

    Avis the commercial X11 servers of the 90s are bad they are not the current versions of the X11 protocol. They have their own custom extensions.

    These commercial and open source X11 servers of the 90s very much look like the mess we have with Wayland now. Avis not every X11 protocol extension would be implemented on the commercial or open source X11 servers. Are you aware that Xfree86 and x.org X11 xserver never implemented everything written in the X11 protocol standard? Yes this is where it gets really fun the commercial X11 servers added their own extensions to the X11 protocol that Xfree86/x.org X11 server never implemented. This starts reading like Wayland today right Avis.

    Avis the old commercial and open source X11 servers of the 90s basically have the same problems Wayland Compositors today have of not having matched up implemented extensions so not implementing the exact same protocol resulting in software being server/compositor picky. Avis like it or not history does repeat.

    avis the hard reality the commercial and open source X11 servers of the 90s don't have the same X11 feature set. Feature set alignment appears around 2003.

    Avis because you had never used the commercial X11 servers you have incorrectly presumed all they provided was just acceleration. The commercials X11 servers even between them did not implement all the same parts of the X11 protocol.

    Due to missing X11 extensions issues in the 90s the following was true.
    1) software that worked on Xfree86 would not work on commercial X11 server
    2) software that would work on a commercial X11 server that would not work on Xfree86 .
    3) software that worked on one commercial X11 server that would not work on a different commercial X11 server.
    Great stack of frustration to say the least at times. Kicker every one of these implementations was valid and correct X11 protocol implementations.

    Please note before BSD I was using Unix as well so Avis I was around X11 software for the full 90s and using it in business.
    I think the fragmentation you describe wasn't really such a big problem, at least not in the way you describe it.

    In the 1990, I developed X11 applications and "ported" them to SGI, SUN, AIX, Apollo workstations and on Intel PC, Consensys Unix System V release 4. Later I switched to UnixWare and finally in 1997 to Linux. I used the same source with some #defines, as I still do today when I target only MacOS and Linux.

    I develop desktop applications, so my needs are maybe more narrow with respect to window managers.

    ICCCM is much older than what you describe, it was initially developed in 1988 and version 1.0 became part of X11R4, version 1.1 was released with X11R5, and version 2.0 with X11R6. It was necessary since forever, otherwise you could not set window title, program icon, tell window manager which buttons to display in title bar (close, iconize, maximize....), recall a window from an iconized state.

    I actively used only one extension, that is MIT-SHM for fast refreshes of bitmaps between client and server. Code path for the extension is always double, do XQueryExtension() to check if MIT-SHM is available, and if not, use the core X11 protocol to copy from XImage to Pixmap or window. A simple code block handled al the "fragmentation":
    if (haveMITSHM)
    XPutImage(...)
    else
    XSmhPutImage(...)
    So the same program worked either locally or across the network to a different X11 on a different computer (and/or CPU architecture).

    If some software blindly used extension without checking for it first, it is simply buggy software, not conforming to X11 protocol.

    If you want to talk about fragmentation, I had problems in different areas not in extensions or core X11 protocol. Namely, commercial Unix vendors were very slow in upgrading to new versions of X11R3,4,5. Upgrades were controlled by the system administrators, so you had to work with whatever was there. You had to write software that supported both X11R3, R4 and R5, using #defines. Differences between different Unix versions and compiler dialects were also notable. Some systems did not support shared libraries, and that created problems if you used some LGPL code. Motif was not open source, so we had to buy a run-time license. Those were the real problems of the time, not X11 itself with its extensions.

    Some notable Wayland proponents claim that X11 is no longer network transparent, and that nobody uses core X11 protocol for drawing. That is simply not true. If you don't know or use such software, it does not mean it does not exist, and that other people are not using it.
    Note that I am not anti-Wayland, I have switched many platforms, will use anything that works. Wayland in its Microsoft WSLg implementation allows me to run my Linux X11 binaries on Windows. But I am against software that breaks standards and requires complete rewrites, life is too short for that.

    Comment


    • Originally posted by dpeterc View Post
      Namely, commercial Unix vendors were very slow in upgrading to new versions of X11R3,4,5. Upgrades were controlled by the system administrators, so you had to work with whatever was there. You had to write software that supported both X11R3, R4 and R5,
      This was not just commerical Unix vendors. In the 90s you had x386 based commercial X11 servers on Linux the ones with accelerations being X11R4-5. Do note I mentioned that the Commercial X11 servers on Linux appeared to branch off sometime in 1987-1988 this is before X11R4 most commonly and these were not the x386 based ones.

      So you had all the commercial X11 vendor problems of not upgrading their X11 servers when on Linux and using Commercial X11 servers.

      Acclerated-X to be correct was at best up to X11R5 in the 90s. You only get X11R6 in 2003 with Accelerated-X..

      ICCCM is much older than what you describe, it was initially developed in 1988 and version 1.0 became part of X11R4, version 1.1 was released with X11R5, and version 2.0 with X11R6.​
      I should have been more clear here ICCCM v2.0​ is required for IceWM to work. Sorry I opped there and failed to type the 2.0 bit. There was problems with software on Linux written post 1994 working anything that was not X11R6.

      There was a lot of Linux and BSD written X11 applications that did not bother including legacy X11 support so it was either the current X11 protocol at the time of the software release and newer or no run. So you would put in Accelerated-X or one of the commercial X11 servers in the 90s so you had accelerated opengl and now a stack of X11 programs on a Linux or BSD system no longer work.

      Originally posted by dpeterc View Post
      Some notable Wayland proponents claim that X11 is no longer network transparent, and that nobody uses core X11 protocol for drawing.
      Devil in the details. X11 network transparency was design for LAN not WAN and also was optimized for lower CPU with less ram and resources(so no operation bundling or compression). X11protocol network transparency does not have latency compensation or correct management of lost packets that you need for WAN or operation bundling or compression.

      This was attempted to add something to cope with WAN but it never took off. XPRA comes about for the same reasons.


      Lets take xpra your core X11 protocol drawing is performed locally turned into 2d image that can be massively compressed and sent over the network.

      dpeterc the problem is network latency. Does it make sense if you want to do performant network transparency to send a stack of individual drawing commands as their own individual packets with individual acknowledgements packets come back for each one with the fact that over Wan any of these packets could magically disappear on you. You get away with this on a LAN but you really don't get away with this with WAN.

      The reality is core X11 drawing protocol parts really don't make sense to send over network on modern day systems. Modern day CPU are more than able to perform these drawing operations locally so avoid the application having network latency on all the drawing commands and send the compressed result over wire. If not drawing locally means of bundling up operations to avoid stacking all the network latency is required. This is the same reason why font servers for X11 has mostly disappeared as well.

      From the features X11 should have to be a modern network transparent protocol these are all missing and are important for operating over Internet/Wan. X11 is not modern network transparent protocol so has issues being used in modern Internet/Wan networks and most likely should not be used in these use cases. Yes might as well consider for modern Internet/Wan that X11 is no longer network transparent because using X11 network transparency over modern internet/Wan is just going to cause yourself trouble that you should have just avoid suffering..

      Comment


      • Originally posted by deusexmachina View Post

        Are you claiming to be an engineer? We definitely need to increase the honor in our industry again. This is shameless! If you think about what a modern car does compared to last gen car, then you might be intelligent enough to understand what I'm talking about. You're in the class of people infected with an ideology to destroy and effectively outlaw the old cars - and you've been fairly transparent about that in your speech patterns. You refuse to answer basic questions about why you're trying to make all cars lose features for no perceivable benefit. You're trying to take an engineers tools away; to make it harder to obtain a system that they can easily build on without tampering with monoliths - especially which refuse their contribution. If you cannot see this, then you are a "useful idiot" of another's agenda.

        Why do people who want to be able to more easily work on their own cars - which are serving them better than the new ones - deserve to be detested and mocked by you? What is this bright future you're imagining will occur once people adopt your vision for this part of the Linux/BSD desktop stack? systemD + Wayland + XDG + whatever else being able to enforce digital rights management across the majority of the open source world? You're working for free as an ideologue due to the massive marketing budget the industry has?
        Maybe because your old car doesn't meet the 2024 safety requirements?
        The brakes don't stop well enough, there are no seat belts etc. You can always use it for displaying antique cars! You can always repair it, but don't get upset if the mechanic doesn't want to get involved.
        While as far as Xorg is concerned, no one will stop you from using it, but if no one maintains it that code will be increasingly vulnerable.
        You want to force the devs. to work on something they no longer want?​

        Comment


        • Originally posted by mrg666 View Post
          You have been saying Wayland is not working. And you are lying, you don't know what you are talking about.
          Oh really? Prove it.

          You can start with the very post you quoted:

          I said this: WAYLAND IS STILL BROKEN AND WON'T ALLOW TO POSITION WINDOWS VIA SCRIPTS

          So, you claim this is a lie and I don't know what I'm talking about.

          OK. Prove me wrong. Show me how you do it on Wayland with a script, then.

          If not then SHUT THE FUCK UP because YOU have no idea what you're talking about, neither do you know what "lie" means, you delusional shill.

          Comment


          • Originally posted by deusexmachina View Post

            So... It is "serverless"? Trips from where to where? Is this seriously a performance strategy of the Wayland team?
            X requires a separate process that sits between the clients and the window manager, known as the server, which means it has to act as an intermediary to communicate between them. Wayland does not. That's why compositors are not optional under Wayland like they are under X. Without the compositor, there is no server, so you have no way to draw anything.

            Comment


            • Originally posted by Weasel View Post
              Oh really? Prove it.

              You can start with the very post you quoted:

              I said this: WAYLAND IS STILL BROKEN AND WON'T ALLOW TO POSITION WINDOWS VIA SCRIPTS

              So, you claim this is a lie and I don't know what I'm talking about.

              OK. Prove me wrong. Show me how you do it on Wayland with a script, then.

              If not then SHUT THE FUCK UP because YOU have no idea what you're talking about, neither do you know what "lie" means, you delusional shill.
              Aw someone is so angry and still does not know what he is talking about. You are the one making claims, I only state about what I use and see. You need proof? Install Fedora 40 KDE Spin and see. I have no idea about your stupid passion about software you don't use and know. I have no idea who (or what) you are. All I see is a sick POS showing anger around with foolish claims. You are nothing but just a clown and annoying pest.

              Window positions, scripts, horse crap, and all that ... yuck.

              Comment


              • Originally posted by woddy View Post

                Maybe because your old car doesn't meet the 2024 safety requirements?
                The brakes don't stop well enough, there are no seat belts etc. You can always use it for displaying antique cars! You can always repair it, but don't get upset if the mechanic doesn't want to get involved.
                While as far as Xorg is concerned, no one will stop you from using it, but if no one maintains it that code will be increasingly vulnerable.
                You want to force the devs. to work on something they no longer want?​
                have you ever worked on cars? upgrading breaks or adding a break booster can be done on 50 year old cars if you wanted to. Much cheaper than buying a new car that needs special tools to bleed the breaks.

                Comment


                • Originally posted by cj.wijtmans View Post

                  have you ever worked on cars? upgrading breaks or adding a break booster can be done on 50 year old cars if you wanted to. Much cheaper than buying a new car that needs special tools to bleed the breaks.
                  Right, he doesn't see the many facets of this analogy. Now you have to buy a car which doesn't let you do x, y or z. And now some modern cars make you pay subscription services to make use of hardware you already own: https://www.youtube.com/watch?v=-CprKqnfsqU
                  Wayland zealots are acting like the analogy is just the crumple zone of very old vs new cars - "it'll kill you vs you'll be saved." Meanwhile there isn't really such a parallel in our example here. It is more like "easier vs harder to fix the way you want it yourself" - considering contributor issues on the freedesktop repositories. They could decide to have a very permissive develop branch to see what people come up with and let it diverge from stable - or something. It has been a while; let someone else have a crack at it... Unless it really is about who gets to control the major components across most FOSS OSs.

                  X requires a separate process that sits between the clients and the window manager, known as the server
                  I realize that, but describing this as a latency reducer is just not honest. DE devs having to reimplement more themselves could also be considered a performance reducer, right? Having to communicate with another process that is always on the same system is not really "an extra server" with "extra latency" in practice. It would be easy for the Wayland experts to add benchmarks to their website - so why don't they? There were some on Phoronix that did not correspond to much of a difference in practice as people seem to describe in theory.
                  Last edited by deusexmachina; 08 May 2024, 04:00 PM.

                  Comment


                  • Originally posted by Weasel View Post
                    I said this: WAYLAND IS STILL BROKEN AND WON'T ALLOW TO POSITION WINDOWS VIA SCRIPTS
                    No need to bold it but you have not asked question if Wayland ever allows you to-do this will it be helpful? Or at-least not answered the question correctly.

                    Weasel you have mostly focused on macro control of applications.
                    Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...

                    This merge request really makes positioning window for Macro control pointless.

                    Why the position the window appears in is relative to the zone origin after this merge. Directly emulated input devices are not bound to the zone origin. So location 0.0 from input device and 0.0 inside zone don't align.

                    Lets just say for argument sake they have the same origin for the input and zone. Are you good the answer is no you not. Why you could be using a HDR screen so now the application window is up-scaled. Ok i will use a simple number but it does not have to be simple the simple number being 2 times scaled. Macro not aware you are currently using a HDR screen so moved the mouse point to 4,4 but due to the 2 times scale should have moved the mouse pointer to 8,8 so now your macro clicks completely in the wrong place.

                    You want to avoid being behind too many layers of abstraction to control and application you will use a Wayland proxy like wldbg.

                    Zones solution effectively turns multi independent applications into effectively a singe multiple-document interface (MDI) application. This is the old virtual desktops on overdrive. Wayland relative nature this also does not mean all the windows inside a zone are using the same graphical scaling.

                    Weasel the reality here is Wayland relative design is a very different ball game to what people are use to. Its relative position and relative scale is Wayland. This is a totally different beast to attempt to macro control.

                    Yes using wldbg proxy between Wayland compositor and Wayland application you don't have output scaling mess with you and you don't need to know where the window is on screen to send instructions and you are in the location to get the value that the window is currently scaled by and can force no scaling if required.

                    Another way around the proxy is the application toolkit you want to control support at-spi2.

                    Weasel the day Wayland allows positioning by scripts will come after 264 or something like 264 has merged so positioning by scripts not going to be that helpful because the positioning is still going to be relative to "who knows what" with the window output scaled by "who knows what". Yes the only party that can answer the "who knows what" is the Wayland compositor and by design it not going to be telling you because Wayland is a relative world not absolute one. Wayland equals getting use to not knowing these "who knows what" and getting stuff done anyhow.

                    Yes Wayland world you application can be told it currently 2x scaled when Wayland compositor is really showing to user 1.5 scaled. This is the relative world nature for you the information Wayland compositor is tell your application about the world does not have to relate to real reality.

                    Yes one of the comments I have done about wayland is that Wayland operates on a military style need to know base and it design for a lot of things it believes you don't need to know and will feed you lie answers so you provide what Wayland compositor wants in the same way military will tell lower people lies about why X items are required to protect operational secrecy..

                    Wayland will require macro control of applications done by new/old methods that are not linked to absolute positioning because the reality of Wayland you are not getting absolute positioning as a option in any near term. Yes proxy control of application was something that was done before X11 protocol had the Xtest extension. Yes the Xtest extension did not always exist in the X11 protocol. So putting a proxy between the server and the application to control the application is in fact a very old method that comes from early X11.

                    Comment


                    • Originally posted by Weasel View Post
                      Oh really? Prove it.

                      You can start with the very post you quoted:

                      I said this: WAYLAND IS STILL BROKEN AND WON'T ALLOW TO POSITION WINDOWS VIA SCRIPTS

                      So, you claim this is a lie and I don't know what I'm talking about.

                      OK. Prove me wrong. Show me how you do it on Wayland with a script, then.

                      If not then SHUT THE FUCK UP because YOU have no idea what you're talking about, neither do you know what "lie" means, you delusional shill.
                      wayland sucks cant even script window pos just like u cant get ur facts straight try that on X11 even my grandma could do it wayland devs too busy breakin stuff than fixin gnome fanboys always defendin broken tech prolly too young to remember when things just werked old tech is gold tech rust is crap javascript is king objects are overrated just like ur arguments lol cant even argue without trippin on ur own ignorance

                      Comment

                      Working...
                      X