X.Org Server Development Hit A Decade High For The Number Of Commits In 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • anda_skoa
    Senior Member
    • Nov 2013
    • 1194

    Originally posted by Quackdoc View Post
    I dunno, I feel like exposing a feature they already have isn't that hard.
    It is probably more like a consolidation.

    They had an implementation that worked on X11 and one that worked on Wayland.
    Which they consolidated into an implementation that works on both.

    Comment

    • anda_skoa
      Senior Member
      • Nov 2013
      • 1194

      Originally posted by oiaohm View Post
      Yes you are right varlink itself does not need a broker. A varlink based dbus broker would way to support the older applications that have not been updated to varlink.
      This would just add overhead for no gain.

      Either D-Bus over varlink gets rid of the D-Bus broker or you can just use it directly and not have the protocol tunneling.

      Originally posted by oiaohm View Post
      You have missed it. AF_UNIX in the Linux kernel is a broker.
      AF_UNIX is a socket family name.
      A flag that you pass to the socket() call to get a Unix socket.

      If you bind() and listen() it that is a server socket.
      If you connect() it that is a client socket.
      Calling accept() on the server socket will return a new socket bidirectionally connected to the client socket

      There is no broker.

      Originally posted by oiaohm View Post
      This is why Linux kernel developers were against kdbus and bus1 because these are duplicating the already existing broker in the Linux kernel.
      Unix sockets have no routing. They are direct connections.

      A bus is something totally different. It has capability to send messages to several recipients, even broadcast to all.
      This is what the D-Bus daemon implements in user space and what kdbus/bus1 tried in kernel space.

      If Unix sockets could do that already D-Bus would already use it.
      Havoc Pennington didn't add a D-Bus daemon because he thought it would be fun, he did that because it was necessary.

      Originally posted by oiaohm View Post
      You are on Linux you can open AF_UNIX sockets not connect to file system.
      Yes

      Originally posted by oiaohm View Post
      This is because there is a broker there.
      No.
      That is because the "path" is just an identifier, a name.
      Using a file system path was the easiest to ensure a unique name with standard OS facilities (and makes it easily discoverable which is also nice).
      The "virtual name" still looks like a path when printed, it just doesn't correspond to anything you would see with "ls" or a file manager.


      Originally posted by oiaohm View Post
      Dbus was not designed to take advantage of the AF_UNIX broker.
      It was designed to take full advantage of the Unix socket functionality.
      Passing file descriptors, socket peer credentials, etc.

      Comment

      • oiaohm
        Senior Member
        • Mar 2017
        • 8417

        Originally posted by anda_skoa View Post
        AF_UNIX is a socket family name.
        A flag that you pass to the socket() call to get a Unix socket.

        If you bind() and listen() it that is a server socket.
        If you connect() it that is a client socket.
        Calling accept() on the server socket will return a new socket bidirectionally connected to the client socket

        There is no broker.

        Unix sockets have no routing. They are direct connections.
        This is not in fact true on Linux.

        This network filtering can connect to a AF_UNIX socket under Linux because there is a broker in the Linux kernel in the middle of the connection. Did you not notice that you can put a firewall between a server socket and the client socket under LInux..

        Linux BPF network filtering can be connected to your AF_UNIX socket. Yes it is possible to route AF_UNIX socket to AF_UNIX socket under LInux. Same way you route between different interfaces. Yes it also possible to duplicate message coming on one socket and send it back out on many using BPF network filtering applied to AF_UNIX sockets under LInux .

        Originally posted by anda_skoa View Post
        A bus is something totally different. It has capability to send messages to several recipients, even broadcast to all.
        This is what the D-Bus daemon implements in user space and what kdbus/bus1 tried in kernel space.
        What you can in fact implement using the broker/firewall on the AF_UNIX sockets in the Linux kernel. There was a demo in the lkml when bus1 was being debated doing exactly this using BPF network filtering on AF_UNIX sockets.

        Also majority of your dbus communication is 1 to 1. Last time I looked all the xdg desktop portal is 1 to 1.

        anda_skoa Linux is a odd one where the AF_UNIX does in fact have a broker/firewall. Most implementations of AF_UNIX you don't have a broker so you cannot apply firewall rules to a AF_UNIX socket.

        This is where kdbus and bus1 runs into trouble. For the way Linux is designed dbus support in kernel should have been implementing extend to the AF_UNIX broker/firewall. Instead kdbus and bus1 end up making a duplicate of lots of what the AF_UNIX broker/firewall in Linux is doing.

        This is the problem there is a broker on AF_UNIX in Linux this how you can connect firewalling to AF_UNIX sockets. From memory freebsd and openbsd you cannot connect your firewalling to the AF_UNIX because there is no broker so this cannot be done.

        Yes under Linux you can be selectively blocking messages between client and server using a AF_UNIX socket because you have applied a firewall to it.


        ​

        Comment

        • Quackdoc
          Senior Member
          • Oct 2020
          • 5061

          Originally posted by anda_skoa View Post
          It is probably more like a consolidation.

          They had an implementation that worked on X11 and one that worked on Wayland.
          Which they consolidated into an implementation that works on both.
          and by exposing pipewire directly, they can now support libcamera and v4l2 sharing, they can support applications which can provide a pipewire source such as gstreamer which can replace v4l2loopback in a lot of cases and more. meanwhile all they need to do is expose that.

          Comment

          • anda_skoa
            Senior Member
            • Nov 2013
            • 1194

            Originally posted by Quackdoc View Post
            and by exposing pipewire directly, they can now support libcamera and v4l2 sharing, they can support applications which can provide a pipewire source such as gstreamer which can replace v4l2loopback in a lot of cases and more.
            Exactly. The capture portal is just another pipewire source for them.

            So even if the original motivation was to consolidate capture into a single solution, they've got some "bonus" simplifications as well.


            Comment

            • Weasel
              Senior Member
              • Feb 2017
              • 4500

              Originally posted by anda_skoa View Post
              Unfortunately implementations are never equal and if you need to switch to a different one convenience/productivity enhancement like scripts are your least concern.

              But if you are on your preferred implementation, why go into much more effort in creating a solution around third party tools just because you theoretically might need to change many years into the future?

              Generic solutions come at a cost. Usually more complexity, fewer features and the perpetual need to evaluate every change against several targets to verify the change to be still generic enough.

              How many of the AutoHotKey users you've referred to in the other comment have decided that they need to find a solution with using the Windows Cmd Shell because AHKs might die at some point?
              Oh don't get me wrong I'm not saying you should be using generic solution, I'm just saying you should be asking for a generic solution.

              Because if (not when) your compositor/custom solution dies at some point, at that point it's too late already, it should've happened before, you get what I mean?

              I'm not using Wayland, precisely for these reasons. I still continue to bash it and want these things from it, just so I can have a generic solution if I ever have to switch to this crap (assuming Arcan and X11 dies).

              Comment

              • Weasel
                Senior Member
                • Feb 2017
                • 4500

                Originally posted by oiaohm View Post

                Weasel I come from KDE community who are use to using kwin scripting. So yes having full blown scripting language.

                Does not change the fact that AHK is a hack. Weasel Windows and X11 and Wayland all have not had full blown automation interfaces.

                Please note AHK under windows is not using the interfaces of the windows compositor. Yes the way AHK is doing that the at-spi interfaces. AT-SPI2 over dbus on Linux.

                Weasel this has been my problem you are asking something to be in Wayland protocol then mention AHK and that says by it design this should be in the at-spi interfaces that are not Wayland. Are you asking for these features to be in the wrong part completely and are asking for it to be in the wrong part because you have been using X11 debugging interfaces.
                No, AHK uses standard Windows APIs, not automation APIs. It's far from a hack and a totally normal use of the Windows API. On Windows, you don't have to use the compositor APIs to access the screen, you can use the old APIs.

                They may map to the compositor (DWM) APIs but who cares, that's on Microsoft. Querying Windows positions is done with user32 APIs lol.

                Comment

                • oiaohm
                  Senior Member
                  • Mar 2017
                  • 8417

                  Originally posted by Weasel View Post
                  No, AHK uses standard Windows APIs, not automation APIs. It's far from a hack and a totally normal use of the Windows API. On Windows, you don't have to use the compositor APIs to access the screen, you can use the old APIs.

                  They may map to the compositor (DWM) APIs but who cares, that's on Microsoft. Querying Windows positions is done with user32 APIs lol.
                  Going to normal user32 API is going to the Microsoft graphical toolkit. That is a interface before DWM API exists on Windows. Yes the syscalls for that information are not DWM syscalls.

                  Weasel this does not match what you have been doing with X11. X11 you have been using debugging APIs these are not meant to be generally used and have some serous design flaws.

                  user32 API include some API for assistive technologies. Yes Microsoft precursor to MSAA.

                  Remember I said windows does not have proper automation APIs. It has hack attempts and not just one attempt Weasel.

                  Weasel so you don't ask for Microsoft to put user32 functionality in the DWM API right. Wayland Protocol is equal to the DWM API.

                  Also think about something else Weasel. You are so focused on controlling applications who is output on Wayland what are you going todo if the application you want to control happens to DRM lease or go direct KMS.

                  Weasel remember on Windows vista how you could run with DWM disabled and the user32 window position things still worked. User32 is not going by the rendering channel to get the window position information.

                  Yes the who cares how Windows does it attempt misses that you are not using the direct interfaces by using user32 instead using a toolkit and saying I don't care how it hooked up.

                  It is very important how it hooked up. Yes saying may map to DWM API means you never looked where it mapped before you started demanding Wayland has this feature. The user32 does not map to DWM API for windows positions.

                  User32 connects up to the Windows NT kernel design part the GDI executive. Yes the DWM for what it should be rendering collects this information from the GDI executive. There is a fun bug that can happen with windows where the location where user32 tells you the window is on screen and the location where DWM has in fact rendered on screen don't in fact line up its only a few pixels out.

                  Here a good question Weasel is Wayland protocol the equal to Windows NT GDI executive the answer is no it not. The closest thing would Direct Rendering Manager (DRM) is subsystem but its missing the useful metadata that the WIndows NT GDI executive has. Its not that the buffer objects of the Direct Rendering Manager (DRM) is subsystem don't have metadata storage its that it simply not used for useful things like the Window name of this buffer and the location the buffer was rendered out and so on as the GDI executive buffers are.

                  Weasel this is where it gets really bad. If we had not had the eglstreams push from Nvidia and had just gone all in on DRI/ Direct Rendering Manager (DRM) it would have been possible that all information was being passed to the compositor as single file handle because all the meta data that in the wayland protocol would have instead been in the buffer metadata. So having a more window like experience.

                  Weasel Wayland causing problems normally points to other issues that are not directly wayland.

                  You can go straight to the kernel to fake input. So why can you not go straight to the kernel with permissions to find out where an applications output is in fact displayed.

                  Weasel just think if you could take application process information look at the graphical buffers it has find out if they are currently are displayed then automate based off this information totally not caring if the application was X11, Wayland, or direct KMS that is a possibility of putting the information useful for automation in the Direct Rendering Manager (DRM) buffer metadata.

                  Weasel Like it or not I don't see the problem is in fact with the Wayland protocol itself. Its either above it with AT-SPI2 or under it with the Direct Rendering Manager (DRM) subsystem and fixing at both of these locations is attempting to fix the problem generic way that not dependent on Wayland or X11 or whatever future replacement protocol appears.

                  Windows user32 says the problem is kernel Direct Rendering Manager (DRM) subsystem because of it usage of windows NT GDI executive . Windows automation interfaces says the problem in toolkit as in AT-SPI2.

                  Yes weasel this also say the way you were doing automation under X11 is wrong because you were doing it in the wrong place.

                  Comment

                  • mangeek
                    Senior Member
                    • Dec 2012
                    • 404

                    Originally posted by Weasel View Post
                    Also you're basically in the wrong crowd if you never heard of it before. Echo chamber and all that.
                    Hmm. I must be in the 'wrong crowd'. Turns out that 25 years into a career of automating stuff and I have been doing it all wrong the whole time! I should have been relying on GUI output and simulated inputs instead of actual sources and APIs the whole time.

                    But jokes aside, if someone came to me with a use case like yours, I would probably suggest (without knowing the specifics) using something like a librosa Python macro in Audacity. That would let you break out of an interactive GUI process into something repeatable that operates directly on the data instead of trying to interpret a GUI output out at the 'edge of the stack'.
                    Last edited by mangeek; 08 January 2025, 10:00 PM.

                    Comment

                    • Weasel
                      Senior Member
                      • Feb 2017
                      • 4500

                      Originally posted by mangeek View Post
                      Hmm. I must be in the 'wrong crowd'. Turns out that 25 years into a career of automating stuff and I have been doing it all wrong the whole time! I should have been relying on GUI output and simulated inputs instead of actual sources and APIs the whole time.
                      Yes you have been. That is why this shit is super popular on Windows for personal use. Not fringe use cases.

                      Originally posted by mangeek View Post
                      But jokes aside, if someone came to me with a use case like yours, I would probably suggest (without knowing the specifics) using something like a librosa Python macro in Audacity. That would let you break out of an interactive GUI process into something repeatable that operates directly on the data instead of trying to interpret a GUI output out at the 'edge of the stack'.
                      First of all it's a proprietary app. Secondly, you're missing the freaking point. The point is convenience in the end not something for "production".

                      Writing the script and automating with a macro should be done as fast as possible (including "not thinking" much about it before-hand, like overall design and whatever crap). It's not something you release to the public as production ready automation. It's for you to simplify your life so it should be done as fast as possible and as simple as possible. After all it's all about saving your time and ONLY your time. Otherwise you lose more time writing that shit than the time you save.

                      You can obviously do anything by yourself given unlimited time and expertise. But that's not how it works. We're talking power users here, who just want to get it done for themselves, not admins whose job revolves around it.

                      Comment

                      Working...
                      X