Announcement

Collapse
No announcement yet.

Red Hat Developing New xwayland-run & wlheadless-run Utilities

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

  • avis
    replied
    Originally posted by spicfoo View Post

    Let's see what an engineer actually told you.



    You have repeatedly claimed that no other distro is doing certification and this is false. Also now you admit it is "relatively stable" implying it still requires maintenance.
    Yeah, I read what he told and I perfectly understood it. Maybe there's some magic I failed to comprehend? I don't need no freaking link and words like "let's see". What exactly are you referring to? Don't be obtuse and don't try to look smart. Use arguments.

    Which distro other than RHEL does xorg certification?

    Please give me the appropriate links to the official websites. Suse, Ubuntu, Oracle, Debian, Mandriva, Arch, what have you.

    For fuck's sake please start using solid facts and drop "you're lying". That's not how argumentation works.

    I'm waiting.
    Last edited by avis; 03 December 2023, 06:50 AM.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by fitzie View Post
    yes, his point wasn't that x11 was designed properly, but that there was a way. in wayland, it's designed properly but there is no way
    Yet.

    It should be pretty easy to take any of the compositors, spawn a process on screen lock and hand over the surface handles via pipie or socket.

    Very likely far less code and far more trivial than any of the hacks currently needed on X11.

    Originally posted by fitzie View Post
    there is no mechanism for a screensaver to be triggered on user idleness
    I would be surprised if many of the desktop compositors did not have idle detection for their locking.

    Originally posted by fitzie View Post
    and for the display manager to provide an unlock screen
    If a compositor has support for locking, surely they will also already have support for unlocking?

    Both locking and unlocking would no longer be a burden for the screensaver developer to solve.

    Originally posted by fitzie View Post
    theres no way to do it the right way and theres no way to do it the wrong way.
    Sounds like the perfect opportunity to propose a solution that is the least burden for all involved developers and likely even aligned with what other platforms do.

    Usually much better than to wait for someone with less domain expertise to do it and then work within the limitations of that solution.

    Originally posted by fitzie View Post
    this is why his screensaver, which has existed for 30 years and is available on every platform on earth, isn't available for wayland.
    That sounds like a rather strange argument.
    It is highly unlikely that the same code works on all the supported platforms without the need for any platform specific bits, but running on Wayland should do without?

    It sounded as if the X11 implementation needed a lot of work outside of the primary domain due to lack in infrastructure.

    Cheers,
    _

    Leave a comment:


  • spicfoo
    replied
    Originally posted by fitzie View Post
    this is why his screensaver, which has existed for 30 years and is available on every platform on earth, isn't available for wayland.
    You are incorrect about quite a few details there. XScreenSaver certainly does not work on Windows. Windows and Mac do not allow an arbitrary application to be a screensaver either. What XScreenSaver does on Mac is just leverage the built-in screensaver and Mac requires that functionality to be built-in for the compositor. Besides you must not be aware of https://wayland.app/protocols/ext-session-lock-v1 which allows for "secure session locking with arbitrary graphics" aka a screensaver.

    Leave a comment:


  • fitzie
    replied
    Originally posted by anda_skoa View Post

    No, the exact opposite!

    I was pointing out that if one doesn't read the article carefully it will give that impression.
    This misinterpretation might even have been the intent, but this is just my personal speculation.

    If one pays attention it clearly spells out how limited the X11 approach was and how much more sensible and inline with other platform this can be handled with Wayland.

    The author mentions the difficulty on X11 of holding a grab on all inputs, to ensure that unlocked content is no longer show and the pain of implementing the unlocking in the screensaver which should not be involved with that at all.

    With Wayland input blocking and output blanking, locking and unlocking is no longer the concern of the screensaver which can full concentrate on its main purpose.
    The article mentions macOS as another system handling it that way and I think one of the comments says that Windows also handles these tasks in the system rather than burdening every screensaver with it.

    The author is way to knowledgeable to have written an ignorant "screensavers won't work on Wayland" rant that many seem to interpret it to be.

    It is rather an acknowledgment of how Wayland enables a separation of concerns that weren't possible with X11.

    Letting the system handle the locking/unlocking and letting the screensaver handle the dynamic content while the lock is active.
    Letting the screensaver developer handle the artistic and fun bits without even having to think about the gnarly bits as they have been taken care of by the system developers.

    Cheers,
    _
    yes, his point wasn't that x11 was designed properly, but that there was a way. in wayland, it's designed properly but there is no way. there is no mechanism for a screensaver to be triggered on user idleness and have control of the display and for the display manager to provide an unlock screen. theres no way to do it the right way and theres no way to do it the wrong way.

    this is why his screensaver, which has existed for 30 years and is available on every platform on earth, isn't available for wayland.

    Leave a comment:


  • spicfoo
    replied
    Originally posted by ssokolow View Post

    Fair point. Unfortunately, I can't continue this conversation right now because I woke up with a "now that you got enough sleep, here is how much sleep debt you still need to pay back" headache and my brain is giving me timeouts when I try to figure out whether I have a URL to give you.
    I appreciate your effort on a good faith conversation and I hope you feel better soon. No rush on the URL. If you find it, feel free to drop a link. If not, it's no big deal. It's nothing more than a mild curiosity at this point.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by spicfoo View Post

    Sure. Like I said I support their decision to use abstraction layers. Later Qt depending on Gstreamer wasn't KDE's decision. If you want to convince me that KDE seriously considered Mutter or even Wlroots, show me the direct evidence.
    Fair point. Unfortunately, I can't continue this conversation right now because I woke up with a "now that you got enough sleep, here is how much sleep debt you still need to pay back" headache and my brain is giving me timeouts when I try to figure out whether I have a URL to give you.

    Leave a comment:


  • spicfoo
    replied
    Originally posted by avis View Post

    A redhat engineer explained exactly what maintenance entails.

    No other distro has ever done that yet people have worked with relatively stable and bug free xorg.
    Let's see what an engineer actually told you.

    Originally posted by hughsie View Post

    I'm sorry, but this is just nonsense. Even if the design of graphics hardware never changed, the number of Xorg CVEs the graphics team handles is huge, and each is usually high severity and requires a massive amount of validation and testing. The reality is that the X protocol is obsolete and designed for hardware that doesn't exist any more, it does not "work beautifully" by a long shot.


    You have repeatedly claimed that no other distro is doing certification and this is false. Also now you admit it is "relatively stable" implying it still requires maintenance.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by spicfoo View Post
    No other graphics system is going to allow an arbitrary application to paint over another application or read from it. Everything else requires a high privileged application in the root of the hierarchy (aka the compositor) to be in control of this level of access.
    Exactly!

    The screensaver would render onto the surfaces the compositor has created for that specific process.
    Just like on macOS as jwz's article points out.

    Somebody earlier in the thread misinterpreted thar article and thought Wayland would make screensavers more diifficult or "impossible", when it makes them much easier.
    All the gnarly bits of idle detection, blanking, locking, activity detection and unlocking, will have already been taken care of by the system.
    The screensaver developer is free to concentrate on their fancy content.

    Cheers,
    _

    Leave a comment:


  • avis
    replied
    Originally posted by spicfoo View Post

    Your false explanation was it all about certification and no other Linux is doing it. Every single enterprise linux distribution does certifications. No need to get emotional over getting this wrong. Just google it. You can readily confirm this within seconds.



    I appreciate your confirmation. You may continue to insist that Xorg is maintenance free and everyone else is lying. All the best
    A redhat engineer explained exactly what maintenance entails.

    No other distro has ever done that yet people have worked with relatively stable and bug free xorg.

    I'm repeating very strong arguments I've already voiced earlier. You continue to show that reasoning and argumentation are not your forte.

    My condolences. You could really stop embarrassing yourself further.

    Leave a comment:


  • spicfoo
    replied
    Originally posted by anda_skoa View Post

    With Wayland input blocking and output blanking, locking and unlocking is no longer the concern of the screensaver which can full concentrate on its main purpose.
    The article mentions macOS as another system handling it that way and I think one of the comments says that Windows also handles these tasks in the system rather than burdening every screensaver with it.
    _
    No other graphics system is going to allow an arbitrary application to paint over another application or read from it. Everything else requires a high privileged application in the root of the hierarchy (aka the compositor) to be in control of this level of access. X11 allows it because it was designed for a very different area where having clear boundaries between applications within a single user was unheard of. On the flip side, this kind of wide open access has enabled some very interesting applications (screensaver isn't the best example of this because this is largely legacy but say adhoc automation of interactive actions is much more useful) and fitting that sort of thing into a system with a clear separation of concerns requires some work. If you want to do that in Wayland outside of the compositor via a third party application, you would need to design a system that allows you to selectively mediate that . One answer for that is XDG portals which are D-Bus interfaces that are dedicated for a specific task. There are already interfaces for screenshots and screencasting for example.

    Leave a comment:

Working...
X