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

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

  • oiaohm
    replied
    Originally posted by Weasel View Post
    Questionable how?

    Works completely flawless for me. Zero glitches (sync or whatever), zero skipped frames, etc.
    This is not understanding the problem.



    The issue you run into with Nvidia is not skipped frames or glitches either xcomposite does not work at all so you cannot to a proper window record or lower FPS less frames generated.

    XSHM yes no glitches no skipped frames but this is hidden by lower FPS.

    Not as completely flawless as you are making out just the flaw is not as in face but it there.

    Weasel if you want the best screen recording performance you system can do you have to bypass X11 xserver and bypass wayland compositors. When you have to bypass to get the best performance why make it to record you have to interface with Wayland compositor at all.

    This is why from my point of view the information should be on the DMABUF metadata. Lets just go all in on bypass. Full bypass route removed need to deal with Wayland composers and X11 Servers would allow screen record programs on Linux to be fully generic as in not care if you are using X11/Wayland/something else. only care that the metadata is set.. Yes lets make it that the default is the best no some half done middle man solution.

    Using X11 XSHM to screen record costs you FPS. Using xcomposite costs you FPS. Yes also costs normally more power consumed as well. So lower FPS more power consumed nothing good is happening here it is being able to look like it functioning correctly when it really not..

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    XSHM capture you might as just do ffmpeg straight from KMS capture the result is basically the same. When capturing window under X11 you are depending on xcomposite and this can be questionable with Nvidia.
    Questionable how?

    Works completely flawless for me. Zero glitches (sync or whatever), zero skipped frames, etc.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    II mean it even fucking says in the github:And I have Nvidia so I don't give a flying fuck about dmabuf.

    XSHM simply works.
    Weasel XSHM only does full screen capture not windows.

    OBS 28.1.2, installed via PPA Ubuntu Studio 22.04.1 LTS Window Capture (Xcomposite) appears to try - it has a correct list of all the window titles - but it still doesn't actually show anything for any of them. See screenshot. Window Capture (PipeWire) doesn't even have that. Its Properties...


    Screen Capture (XSHM) works completely. But I want a window that is usually behind others.
    XSHM capture you might as just do ffmpeg straight from KMS capture the result is basically the same. When capturing window under X11 you are depending on xcomposite and this can be questionable with Nvidia.

    Weasel its how old of Nvidia. Newer open source Nvidia kernel drivers have DMABUF support.

    will not work on Nvidia cards. Their drivers are special snowflakes that don't provide libdrm/dmabuf APIs.
    That not all Nvidia cards and driver combinations. Yes that note is 4 years old Weasel Nvidia drivers have changed since then. Nvidia use to be special snowflake. Now that Nvidia is ceasing to be a special snowflake we are not need the level of abstraction any more.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    OBS automatically does something you don't see under X11. Early OBS on X11 use to have overlapped windows missing bits and opengl/vulkan off screen not rendering.. There are work around required.





    These are non pipewire ways of screen capturing under Wayland. Note the top one does not care if you are running X11 or Wayland.
    I'm not using any plugin. So, nope, you wrote all that text for nothing. I'm NOT using DMABUF and it's not my magic wand.

    I mean it even fucking says in the github:
    • will not work on Nvidia cards. Their drivers are special snowflakes that don't provide libdrm/dmabuf APIs.
    And I have Nvidia so I don't give a flying fuck about dmabuf.

    XSHM simply works.
    Last edited by Weasel; 09 February 2025, 12:39 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    idk what you're talking about, works completely fine for me with OBS on X11..
    OBS automatically does something you don't see under X11. Early OBS on X11 use to have overlapped windows missing bits and opengl/vulkan off screen not rendering.. There are work around required.

    Originally posted by Weasel View Post
    I fire a opengl/vulkan game. Windowed. Change "desktop" which basically moves it offscreen (e.g. if I change to desktop on the right, the window gets moved to the left by screen size). Record and preview in OBS must work 100% correct as if it was on the current desktop even if it's out of focus and not visible at all and off screen.


    These are non pipewire ways of screen capturing under Wayland. Note the top one does not care if you are running X11 or Wayland.

    DMABUF being passed around appear as fd under the process. Yes looking at /proc/[pid]/fd directory

    You will notice in that directory files of /dev/dri/renderD.....with wayland applications these are DMABUF and one of them will be the application output window. You can get the size of the window.

    You can also do that against wayland compositor to see what DMABUF it using. Issue is that DMABUF do not have meta data on them to say hey this is main application window.

    Originally posted by Weasel
    Do it with a non-opengl/vulkan app as well. It must also work.
    Wayland there is no difference these days. While eglstreams was in the mix there was the DRI vs elgstreams buffers. Today there is only DMABUF/DRI with Wayland going forwards..

    Weasel if the metadata was on DMABUF there would be no need to talk to Wayland compositor to record application window. You would only need to know the PID of the application you need to record and watch the /proc/[pid]/fd directory if CSD applications and for SSD applications watch the compositor for the buffer of the application with the SSD added or have the recording software add the SSD....

    This is why I ask the question should this be Wayland protocol. Now that all GPU are DMABUF and Wayland compositors and Wayland applications are going to be moving all the window output around by DMABUF it kind of does not make sense to have it in the Wayland protocol.

    Weasel think about if you are going straight to the application PID and fd (file handles) with the recording software you have less bits of software to glitch up.

    Lot of people complain with OBS screen recording that pipewire crashed on them. Going to the Wayland protocol you are depending on the Wayland compositor to have this implemented correctly.

    Weasel I am absolutely not sure if the feature you are after should be implemented in Wayland protocol. Yes x.org bare metal with DRI based graphics cards being used you can get dmabuf of applications windows by going to the x.org compositor PID and going though the fd that are DMABUFs. Issue is its looking at each one to find dmabuf you are looking for because no metadata.

    How good would it be to have screen capture under Linux not care if you are running X11, Wayland or framebuffer terminal because all come just look at DMABUF metadata to find what you want to capture..

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    That information is stored in X11 server, Windows GDI and macOS backing buffers. That information does not come from the Windows manager or the Compositor on those platforms.
    Ok but legit who asked and who cares? I will say it again: it does not matter.

    Also gdi is a library. It runs all code in the context of the caller.

    Originally posted by oiaohm View Post
    In fact not easy with X11. You will have cases with opengl and Vulkan with X11 where the off screen window will not be rendering or the covered section of window will not be rendering. Yes you need to find the way to the DMABUF or equal that the opengl/vulkan is using and say do completely render this when it covered or off screen with X11 if you want to be capturing complete windows like that..
    idk what you're talking about, works completely fine for me with OBS on X11.

    Originally posted by oiaohm View Post
    OBS capturing a window under wayland will be using the DMABUF of the buffer that Window is on. Would it not be useful to be able to double check you got the wrong DMABUF object because the Windows metadata happened to be on the buffer.

    Capturing a specific window under Wayland or LibDRM is not knowing where it is on screen instead its knowing you have the right DMABUF.

    There are ways to list all DMABUF currently in existence on Linux and BSD and what processes they in fact origin from.

    libdrm can capture particular windows. Problem is that the metadata to be sure you have the right one is not on the DMABUF so resulting in having to talk to the Wayland compositor to find out what one is the right buffer so you can capture the output.

    This is my problem you have to work your way in most cases to the DMABUF or equal anyhow and being able to at the DMABUF that you had the right buffer/window would be a good thing.
    Last time I tried I wasn't able to do it with Crapland. I will need some convincing that it can be done before I attempt it again and waste my time. Here's a simple case:

    I fire a opengl/vulkan game. Windowed. Change "desktop" which basically moves it offscreen (e.g. if I change to desktop on the right, the window gets moved to the left by screen size). Record and preview in OBS must work 100% correct as if it was on the current desktop even if it's out of focus and not visible at all and off screen.

    Do it with a non-opengl/vulkan app as well. It must also work.

    No, I don't give a shit if the game stops rendering when it loses focus. I don't give a shit about such game. If possible, turn that feature OFF in-game.

    BTW no theory please. I want facts only.

    Leave a comment:


  • oiaohm
    replied

    Originally posted by Weasel View Post
    When I'm talking about moving window I mean the fucking position of the window, not its contents. You know, the position you can query with e.g. xwininfo.
    That information is stored in X11 server, Windows GDI and macOS backing buffers. That information does not come from the Windows manager or the Compositor on those platforms.

    Originally posted by Weasel View Post
    What if I want to capture a specific window, even if it's off-screen or obscured by another window on top, huh? I can easily do that with X11 (OBS can do it).
    In fact not easy with X11. You will have cases with opengl and Vulkan with X11 where the off screen window will not be rendering or the covered section of window will not be rendering. Yes you need to find the way to the DMABUF or equal that the opengl/vulkan is using and say do completely render this when it covered or off screen with X11 if you want to be capturing complete windows like that..

    OBS capturing a window under wayland will be using the DMABUF of the buffer that Window is on. Would it not be useful to be able to double check you got the wrong DMABUF object because the Windows metadata happened to be on the buffer.

    Capturing a specific window under Wayland or LibDRM is not knowing where it is on screen instead its knowing you have the right DMABUF.

    There are ways to list all DMABUF currently in existence on Linux and BSD and what processes they in fact origin from.

    libdrm can capture particular windows. Problem is that the metadata to be sure you have the right one is not on the DMABUF so resulting in having to talk to the Wayland compositor to find out what one is the right buffer so you can capture the output.

    This is my problem you have to work your way in most cases to the DMABUF or equal anyhow and being able to at the DMABUF that you had the right buffer/window would be a good thing.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    No open up the core X11 protocol and read it some time. I said the application move it window around. What you find this is output buffer moving not Window moving.

    Window and application output buffer turns out to be two different things.
    LMFAO, what? Are you serious right now?

    When I'm talking about moving window I mean the fucking position of the window, not its contents. You know, the position you can query with e.g. xwininfo.

    Originally posted by oiaohm View Post
    Then you ask for the feature. Then you need to work out where it should be if it missing..

    There is a screen capture application now for linux doing a overlay by libdrm that does not care if you are running Wayland or x11 because it putting it window/overlay on screen by libdrm. Think like a UAC application under windows where a normal application cannot see the window.
    What if I want to capture a specific window, even if it's off-screen or obscured by another window on top, huh? I can easily do that with X11 (OBS can do it).

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    Uhm, yes? I literally said it's part of the X11 protocol (window management). Not separate. So thanks for proving my point. LMAO.
    No open up the core X11 protocol and read it some time. I said the application move it window around. What you find this is output buffer moving not Window moving.

    Window and application output buffer turns out to be two different things.

    Originally posted by Weasel View Post
    All an app cares is IF IT CAN MOVE via the provided interface/API/protocol. And it can. I don't give a shit about the implementation detail..
    Then you ask for the feature. Then you need to work out where it should be if it missing..

    There is a screen capture application now for linux doing a overlay by libdrm that does not care if you are running Wayland or x11 because it putting it window/overlay on screen by libdrm. Think like a UAC application under windows where a normal application cannot see the window.


    Weasel https://wayland.app/protocols/drm-lease-v1 libdrm handle can be provided to application by Wayland compositor by libdrm lease or by some application running with root permission this can be a sudo application or dbus item.

    Weasel reality is Wayland protocol is bi-passable. So using libdrm you can force display a window at any absolute position you like of course this window can come completely unknown to the wayland compositor/x11 server. This is where it starts making more sense for the Wayland compositor to know what libdrm is having displayed on screen so they cannot be bipassed without their knowledge..

    This is why I question should this be wayland protocol or should this simple be libdrm dmabuf metadata.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    Weasel code yourself up a little X11 application that moves it window around by itself then load up a X11 server without Window manager or Compositor run program notice window still moves. Window position and means to move window is not part of Window manager or Compositor under X11 or Windows or MacOS.
    Uhm, yes? I literally said it's part of the X11 protocol (window management). Not separate. So thanks for proving my point. LMAO.

    Originally posted by oiaohm View Post
    What the point of what you wrote. Windows manager and compositor by X11, Windows and MacOS neither of them store window position and all of them Window manager and compositor missing you can still relocate window.
    Who the FUCK CARES where they store it, what the fuck is wrong with you? It can even store it in BIOS Flash if it fucking wanted to while keeping the exact same protocol. All an app cares is IF IT CAN MOVE via the provided interface/API/protocol. And it can. I don't give a shit about the implementation detail.

    Stop wasting my time with bullshit. I ain't reading the next wall of garbage.

    Leave a comment:

Working...
X