Announcement

Collapse
No announcement yet.

The Process For Eventually Releasing X.Org Server 1.21

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

  • The Process For Eventually Releasing X.Org Server 1.21

    Phoronix: The Process For Eventually Releasing X.Org Server 1.21

    While formally the X.Org Server aimed to put out a new feature update every six months, in recent years they have been well off that trajectory with not much feature activity going on especially now that GLAMOR / XWayland / xf86-video-modesetting have stabilized and many Linux distributions eyeing Wayland by default. But there is now at least some little bit of interest in what's going into X.Org Server 1.21...

    http://www.phoronix.com/scan.php?pag...-Release-Means

  • DoMiNeLa10
    replied
    Originally posted by NateHubbard View Post

    That's a ridiculous statement. At best Microsoft only ignored it, just like everyone else did. It died entirely on its own.
    Let me rephrase what happened: Be wanted to sell boxes with a dual booting setup, but MS stepped in and didn't want to allow for that, claiming it would breach deals for licensing Windows. Looking at how Haiku is shaping up, I'd say it would've been an amazing OS for multimedia workstations.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by tildearrow View Post
    Sometimes I really need to know when is VBlank occurring because Mesa has a bugged VSync behavior. Time to put up my demonstration GIF again:
    The horrible part is with Vsync is you mostly find out after then have to attempt to calculate how long to next vsync. If you have your maths wrong bad things happen of course dynamic clock rates really don't help.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by nanonyme View Post
    Now I'm really curious. I don't want to GLX to go away either but why would you not want to have buffer swapping with sync to VBlank?
    Sometimes I really need to know when is VBlank occurring because Mesa has a bugged VSync behavior. Time to put up my demonstration GIF again:

    ​​​​​​

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    Nope it would be a total bullshit move but not surprising coming from you.

    Let's see, to add more effort, drop it and then have users chroot instead of... having it just work because it's not dropped. I wonder which option is more attractive.
    Current xlib today is implemented on top of xcb any how.
    https://xcb.pdx.freedesktop.narkive....d-applications

    Pure direct xlib has not existed for quite some time. Its no different to how Microsoft ships stuff with windows and turns it into a optional run-time package that you have to install.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    X11 protocol defines backwards compadiblity. Dropping xlib out of systems by default could be a good thing.
    We have flatpak and snap and chroot so old applications needing Xlib could be bundled up with a runtime.

    Someways kicking xlib out and leaving xcb in by default would be a very good thing.
    Nope it would be a total bullshit move but not surprising coming from you.

    Let's see, to add more effort, drop it and then have users chroot instead of... having it just work because it's not dropped. I wonder which option is more attractive.

    Leave a comment:


  • Weasel
    replied
    Originally posted by Vistaus View Post
    and macOS is a success too.
    You forgot the sarcasm.

    Leave a comment:


  • oiaohm
    replied
    Pardon major rework. Prior Answers are after >
    Drop DRI1 and DRI2?
    > What about old hardware?
    Lets get real here. UMS(usermode setting drivers) Most distributions are not building these any more that is your DRI 1 drivers. That hardware is not powerful enough to turn over firefox or chrome.
    DRI2 there are pure DRI2 drivers left. All DRI2 drivers have in fact migrated to DRI3.
    The problem with dropping DRI1/DRI2 is not old hardware. Its the NVIDIA closed source driver. It will break the NVIDIA closed source driver because they are using deprecated calls. Really its over due for this.

    Drop all drivers except xf86-video-modesetting?
    > What about old hardware?
    Basically the same as first. Drop all drivers except modesetting effects Nvidia a lot but AMD/Intel custom hardware tweaks are hit has well.
    Old hardware since the disappear of UMS drivers is support by modesetting how.

    Create a GLAMOR built a top of Vulkan instead of OpenGL?
    > Vulkamor
    I do expect this one at some point.

    Revise DRI3 to v3.3? (with what?)
    >OK...?
    Really should with freesync stuff. So there should be a new version of DRI.

    Drop Xlib in favor of XCB (never going to happen)
    >Please don't. I know you like breaking compatibility, but this is exactly why Windows has been a success (in many cases it is backwards compatible).
    X11 protocol defines backwards compadiblity. Dropping xlib out of systems by default could be a good thing.
    We have flatpak and snap and chroot so old applications needing Xlib could be bundled up with a runtime.

    Someways kicking xlib out and leaving xcb in by default would be a very good thing.

    AR/VR stuff? A new XRandR version?
    > Probably. What would that new RandR version bring though?
    This would fairly be because you have updates the DRI level.

    Drop any acceleration architectures? Is EXA, SNA, UXA, KAA, XAA all really needed? We now have GLAMOR!
    >I repeat: What about old hardware?!
    All those 2D accelerators horrible overlap with each other.
    https://www.x.org/wiki/ExaStatus/

    Like work should be put in to finish off the merge of KAA and XAA into EXA. That would kill off 2.
    SNA by intel is on by default. UXA is intel old superseded. SNA is meant to support all hardware that UXA did if it does not its a bug.

    So out of the list really only 3 should exist. EXA, SNA, GLAMOR. Using the others is really work around to a bug in EXA or SNA.

    A build flag to build a reduced, minimal X build only suitable for usage through XWayland?
    Is Panoramix/Xinerama, COMPOSITE, DamageExt, GLX, DBE, and framebuffer still needed?
    Is Xinput and xkbd still needed with libinput?

    A build flag to build a reduced, minimal X build only suitable for usage through XWayland?
    >Would be cool, but somebody should re-engineer the whole XWayland architecture anyway.
    This explains another area the next one.

    Is Panoramix/Xinerama, COMPOSITE, DamageExt, GLX, DBE, and framebuffer still needed?
    >Yes, many of these still needed! Are you crazy?!:
    Not exactly 100 percent Crazy.
    >Composite is necessary to have a compositor.
    >Damage is necessary for battery/power savings as it allows telling a compositor only to render a small portion of the screen
    If all composite solutions are going to be way-land compositors in future the Composte and Damage extentions from X11 protocol can absolutely go by by.

    GLX? Look. Why would you want to remove something 95% of applications still use?! (furthermore, please tell me how can I wait for VBlank without swapping buffers in EGL)
    This one I agree with. I have answered the vblank one the reality is in cpu you cannot really wait for vblank. If you are you are using a timing running in the cpu that has adjusted based on present time. So GPU limitations are an ass.

    Is Xinput and xkbd still needed with libinput?
    >Are you serious once again? libinput is a backend to XInput/XKB. Furthermore, once again, what about old hardware?
    We are getting close that there are no other Xinput/XKB drivers other than libinput for x.org server.
    Almost all the old drivers hardware support has been moved into libinput.

    The effected hardware list is insanely small if you remove the GLX one out that list and ingnore the Nvidia closed source driver death.

    If Intel graphics card turns out to be high end then doing this level of extreme will be more possible.






    Leave a comment:


  • boxie
    replied
    Originally posted by smitty3268 View Post

    Getting rid of X entirely would do a better job of that if that's what distros are interested in.
    Why not both? The cut down XWayland could be the carrot - and smitty with a massive stick could come and whack people with the NO MOAR X stick :P

    Leave a comment:


  • smitty3268
    replied
    Originally posted by nanonyme View Post
    Uhm, the entire protocol was just redesigned from scratch as HTTP2 a short while ago. Bad analogy.
    http/2 was published 4 years ago. That's older than multiple wayland releases.

    In fact, you can track it's history back through SPDY which was initially announced right around the same time that Wayland was. You could very roughly compare http1 and x11 dates too, if you wanted to extend things even further.

    All of which is ignoring the fact that my post was obviously sarcastic and not meant to be thought too deeply about.
    Last edited by smitty3268; 05-16-2019, 03:16 AM.

    Leave a comment:

Working...
X