Announcement

Collapse
No announcement yet.

XWayland "Rootfull" Changes Merged For Running A Complete Desktop Environment

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

  • #51
    Originally posted by arQon View Post
    I'll dumb it down for you: write me the two lines of code a screen reader or keylogger would need if Wayland had been designed competently. Then, and only then, feel free to either (1) write the handful of lines of code the server half would need; or (2) try to justify why Wayland failed to. gl.
    https://wayland.freedesktop.org/libi...ibinput-replay

    Do note the libinput keylogger the record option keylogger. This works be you running wayland, X11 or text based TTY.

    https://gitlab.freedesktop.org/libinput/libei
    Yes there is input emulation as well done with libinput outside X11 or wayland protocol. Keyloggers on Linux and BSD that did not need to depend on X11 or Wayland or TTY have been around longer than Wayland existed. Thing most people don't notice is wayland compositors and X11 servers don't exclusive grab input devices.

    arQon you really need to explain to me when you can make a keylogger without using X11 protocol that works with X11 why do you need a keylogger in X11 protocol. Remember the X11 part of the protocol that was designed for a keylogger was designed for the same reason libinput record was. Historic X11 was trying to have all drivers in X11 this is why you had user mode setting drivers for graphics.

    Does it make sense really for every wayland compositor to support keylogging(that what you are asking for if that was in the wayland protocol)? No right. Does it make sense for every wayland compositor to have a permission system tracking what applications should and should not be key logging? No right.

    The reality you are presuming that the Wayland design is wrong arQon because you said "if Wayland had been designed competently". The reality is there is no need for keylogging in what Wayland compositor should be doing.

    Screen capture does it make sense to be built into the wayland protocol again most likely no. Think about it formats people want screen capture in will change over time. Hardware for encoding in those formats will change over time. One of the reason why pipewire screencapture at times performs way better than the X11 designed in screencapture is being able to use hardware encoding in a single trip setup.

    arQon like it or not D-bus has a permission system. D-bus name comes from "Desktop Bus" arQon Wayland and X11 and D-Bus are all IPC solutions.

    https://wayland.freedesktop.org/faq....ading_toc_j_10 Thing is Wayland IPC is specialist and always was. Wayland IPC was not designed to replace D-Bus IPC this come clear with the functionality that was intentionally left out. X11 IPC tried to be a all rounder leading to people attempting to implement print servers and other stupid things in it.

    arQon X11 IPC turns out to be horrible this came clear when people attempted add xace into it.

    Like it or arQon saying wayland protocol/wayland compistors should do everything is asking for all shoes to be made only in the average shoe size then wondering why shoes no longer fit most of the population.

    Global hotkeys, input capture, screen capture and lot of other things make more sense behind dbus than Wayland protocol. Remember Wayland protocol is only for systems running Wayland compositor. dbus can be on a system running X11, Wayland, TTY or some output system not invented yet. dbus is the generic everywhere IPC protocol on the Linux desktop computer.

    Something else to remember the party design Wayland protocol in the first place had studied what dbus could and could not do and only made wayland protocol because dbus was not ideal for graphical output. If dbus had been suitable for graphical output the reality is the replacement to X11 would not be Wayland protocol would be just a stack of dbus services.

    arQon get it yet dbus services was always intended by the designer of the wayland protocol to be part of the final solution. This is why particular suggestions get killed by him as it attempting to re-implement what should be dbus service inside Wayland protocol.


    Comment


    • #52
      I think I'll exit this conversation, as I not only seem unable to get through to you, but also can't even parse whether you're arguing that "keylogging" should or should not be the compositor's responsibility.

      To summarize: pretending that global hotkeys or screen-sharing are not genuine use-cases, as Wayland does, is wilful security theater. This is not in any way an either/or situation: there is a trivial way to have both a "secure" desktop *and* those capabilities. Wayland's continued refusal to even engage on the topic, and continued cop-out of pushing large amounts of behavior that it should be providing itself onto *other people* to implement via "the compositor" etc, despite repeatedly citing such concerns as why the world "needs" Wayland to replace X, is a significant part of why the project is still failing to gain acceptance after 15 years.

      Simply regurgitating an excuse does not magically validate it. The issue is purely about the Wayland project failing to deliver a complete working system. Attempting to pass the blame around onto someone else *does not change that*, even if you're willing to pretend that "someone else" should take the fall for that failure.

      Comment


      • #53
        Originally posted by arQon View Post
        To summarize: pretending that global hotkeys or screen-sharing are not genuine use-cases, as Wayland does, is wilful security theater. This is not in any way an either/or situation: there is a trivial way to have both a "secure" desktop *and* those capabilities. Wayland's continued refusal to even engage on the topic, and continued cop-out of pushing large amounts of behavior that it should be providing itself onto *other people* to implement via "the compositor" etc, despite repeatedly citing such concerns as why the world "needs" Wayland to replace X, is a significant part of why the project is still failing to gain acceptance after 15 years..
        What you written there is like saying systemtray should be part of Wayland protocol. Remember systemtray was done over X11 protocol before being moved to dbus. Yes there are particular advantages to the dbus solution.

        xdg-desktop-portal API that does screen-sharing these days.

        arQon lets look at KDE global hotkeys. KGlobalAccel5 This works over dbus. Turns out if you have sandboxed X11 application you need global hotkeys not by X11. You sandbox wayland you need global hotkeys not by Wayland protocol as well. The issue of turtles all the way down exist because you need to remember X11 and Wayland are both stack-abl Xnest and equal under X11 and items like gamescope under wayland as well.

        Like it or not global hotkeys problem is generic issue of sandbox applications and Wayland and to improve X11 performance. The advantage of dbus solution is it possible that application that want global hotkeys can share the keylogger under X11 turns out reduce the load your X11 server when running multiples of those applications. Even better results in scheduler being able to allocate CPU time effectively.

        arQon reality here you need to stop pretending that global hotkeys does make sense to be in the Wayland protocol. The existing KDE test case says otherwise that it makes more sense done in dbus with closest to hardware compositor. Why once dbus interface of a service is claimed nothing else can claim it. Dbus does not by design allow turtles all the way down. You don't end having to proxy messages as much in the dbus solution.

        Did you also forget weston can run on top of weston on top of weston on top of weston. Yes the reference wayland compositor truly will do turtles all the way down in theory. Now think if each of those instances of weston have implemented global hotkeys on the input processing route. The deepest stack application will have the most lag on the hotkey press because it will have to pass wayland compositor to wayland compositor before the application gets it. Vs the dbus solution where all the applications have the same amount of global hotkey lag.

        The reality some of these things don't make sense to be in the Wayland protocol. arQon yes you have been ignoring the KDE prototype of a dbus solution for global hotkeys and what advantages that provides.

        Comment


        • #54
          Why all this fuss? They just want to avoid maintaining xorg drivers by putting Wayland between the server and the driver. Rootless Is good for single apps while it is useless for running an X window manager. For running icewm, kde3 and alikes, you need a rootful xorg as a Fullscreen Wayland app.
          ​​​​

          Comment

          Working...
          X