Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

[s9209122222]

I wonder if they have a bug in it, no surprised, ffmpeg is hard to develop against

Is there other easier way to build KODI with ffmpeg?

[Quackdoc]

It always fails to build.

I wonder if they have a bug in it, no surprised, ffmpeg is hard to develop against

[s9209122222]

you may need to edit the PKGBUILD to disable internal ffmpeg

It always fails to build.

[oiaohm]

...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/windows/win32/direct3ddxgi/for-best-performance--use-dxgi-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.

[tildearrow]

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.

[oiaohm]

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.

[yump]

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.

[Quackdoc]

Building kodi-git from AUR doesn't work.

you may need to edit the PKGBUILD to disable internal ffmpeg

[s9209122222]

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.

[s9209122222]

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