Announcement

Collapse
No announcement yet.

Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

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

  • #91
    Originally posted by oiaohm View Post

    That the problem. Trying to part solution that end up not being cursed in future. DRM Leading is basically full screen we don't have a window mode of it.

    DRM support would not be a big problem if Nvidia was on the same page as everyone else with their implementation. The reality is if direct DRM out was nice stable and uniform applications most likely would not have to pick up the bits it would be the toolkits.

    Graphic stack is a true head ache location.
    DRM leasing is an extreme solution to a simple problem...
    We have direct scanout already.

    Doing the former means giving developers an extra burden.

    Comment


    • #92
      Originally posted by tildearrow View Post

      DRM leasing is an extreme solution to a simple problem...
      We have direct scanout already.

      Doing the former means giving developers an extra burden.
      I see drm leasing as the nuclear option that devs implement to get around waylands... slow development, and that is IF drm leasing supports metadata passthrough, which i have no idea if it does

      Comment


      • #93
        Originally posted by Quackdoc View Post
        I see drm leasing as the nuclear option that devs implement to get around waylands... slow development, and that is IF drm leasing supports metadata passthrough, which i have no idea if it does
        drm leasing gives you a total control of the output so able to use all the interfaces as if you are compositor. Yes when you return the lease the compositor/X11 server is meant to restore everything to the way it was before. Yes the the nuclear option but it the generic option that can work be you running x11 or wayland.

        Basically drm leasing gives everything direct scanout does but with a polite way to ask the compositor/X11 server to let the device go so application can use it.

        Comment


        • #94
          Quackdoc It seems like Arch official FFMPEG has libdrm enabled, so I only need to build kodi-git from the AUR?

          Comment


          • #95
            Originally posted by Quackdoc View Post

            id only used it on a arm device, but apparently libreelec has support. I don't think most distros have kodi built with support for it. FFMPEG needs to be built using libdrm, then kodi needs to be built on that. and I think there is work being done to make it all easier to do, but I went to re-verify it working but am running into build errors now because ffmpeg can't keep a stable API for the life of it -_-

            but basically you need to make sure you have DRMPRIME renderer.

            I'd seen some people reccomend building these against master, but Im still running into build issues https://github.com/lrusak/xbmc/commi...no-ffmpeg-bump
            Building kodi-git from AUR doesn't work.

            Comment


            • #96
              Originally posted by s9209122222 View Post

              Building kodi-git from AUR doesn't work.
              you may need to edit the PKGBUILD to disable internal ffmpeg

              Comment


              • #97
                Originally posted by oiaohm View Post

                drm leasing gives you a total control of the output so able to use all the interfaces as if you are compositor. Yes when you return the lease the compositor/X11 server is meant to restore everything to the way it was before. Yes the the nuclear option but it the generic option that can work be you running x11 or wayland.

                Basically drm leasing gives everything direct scanout does but with a polite way to ask the compositor/X11 server to let the device go so application can use it.
                Direct scanout at least theoretically gives the possibility to use HDR in non-fullscreen applications, so long as the compositor is using per-window hardware planes. That's way more important for battery life on laptops than anything it might let you do with HDR, though, because compositing application windows into full-screen framebuffers is a big power suck.

                Comment


                • #98
                  Originally posted by yump View Post
                  Direct scanout at least theoretically gives the possibility to use HDR in non-fullscreen applications, so long as the compositor is using per-window hardware planes. That's way more important for battery life on laptops than anything it might let you do with HDR, though, because compositing application windows into full-screen framebuffers is a big power suck.
                  There is a problem that there is not that many hardware planes with most GPUs.

                  Comment


                  • #99
                    Originally posted by oiaohm View Post

                    drm leasing gives you a total control of the output so able to use all the interfaces as if you are compositor. Yes when you return the lease the compositor/X11 server is meant to restore everything to the way it was before. Yes the the nuclear option but it the generic option that can work be you running x11 or wayland.

                    Basically drm leasing gives everything direct scanout does but with a polite way to ask the compositor/X11 server to let the device go so application can use it.
                    ...but it's unnecessary, and it forces developers to implement yet another output method besides Wayland (and where's dealing with GBM huh?).
                    It also may pose problems in the future, like flicker due to DRM lease/Wayland compositor output switch and security issues.

                    You don't have to do all of this using X11 or Wayland with direct scanout... or even Windows/macOS.

                    And yeah, by the way neither Windows nor macOS use this convolution for exclusive full-screen.

                    Comment


                    • Originally posted by tildearrow View Post

                      ...but it's unnecessary, and it forces developers to implement yet another output method besides Wayland (and where's dealing with GBM huh?).
                      It also may pose problems in the future, like flicker due to DRM lease/Wayland compositor output switch and security issues.

                      You don't have to do all of this using X11 or Wayland with direct scanout... or even Windows/macOS.

                      And yeah, by the way neither Windows nor macOS use this convolution for exclusive full-screen.
                      https://docs.microsoft.com/en-us/win...xgi-flip-model

                      Flicker due to changing to direct scanout under windows does happen. Are there security issues to the Windows direct scanout yes. Do you have to implement different code in your program to use direct scanout under Windows yes they do.

                      The reality is Windows direct exclusive full-screen is fairly convoluted and has its issues.

                      Yes under MS windows you do a command that asks the DWM the windows compositor to stop outputting and let your application control the output. This is basically DRM lease.

                      tildearrow it might be different with MacOS but what I suggested is really the closest existing thing in Linux to how Windows does it and all the downsides are the same. Its acceptable for Windows to use their equal to DRM leasing to solve some of these problems yet now people like you say not to.

                      Most people have not really looked how Windows does direct scanout. Maybe this is not a good solution but using Windows as arguement against using DRM leasing is more showing that you don't know how it done. Yes windows does flicker at times when switch between their direct scanout and DWM output users seam to find this acceptable.

                      Comment

                      Working...
                      X