search for: kmscube

...s of scanout it will import > >buffers created on the GPU into the display driver. Handles that > >userspace requests are those of the display driver so that they can be > >used to create framebuffers. > > > >This has been tested with some GBM test programs, as well as kmscube and > >weston. All of those run without modifications, but I'm sure there is a > >lot that can be improved. > > Tested with kmscube and Weston and I can confirm this works. However, EGL > clients inside Weston have their window filled with garbage (they seem to > run fi...

...u screen. For purposes of scanout it will import > buffers created on the GPU into the display driver. Handles that > userspace requests are those of the display driver so that they can be > used to create framebuffers. > > This has been tested with some GBM test programs, as well as kmscube and > weston. All of those run without modifications, but I'm sure there is a > lot that can be improved. Tested with kmscube and Weston and I can confirm this works. However, EGL clients inside Weston have their window filled with garbage (they seem to run fine otherwise). Do you also...

...import >> >buffers created on the GPU into the display driver. Handles that >> >userspace requests are those of the display driver so that they can be >> >used to create framebuffers. >> > >> >This has been tested with some GBM test programs, as well as kmscube and >> >weston. All of those run without modifications, but I'm sure there is a >> >lot that can be improved. >> >> Tested with kmscube and Weston and I can confirm this works. However, EGL >> clients inside Weston have their window filled with garbage (they...

...e corresponding userspace changes can be found here: > > > > libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/ > > mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/ > > > > I've verified that this works with kmscube's --atomic mode and Weston. > > Hi Ben, > > any thoughts on this series? I realize that this is somewhat suboptimal > because we're effectively adding a duplicate of the existing IOCTL with > only the "minor" extension of adding sync FDs/objects, but at the sam...

...d-style modifiers, this change does not advertise support for them. Doing so would imply compatibility between devices with incompatible memory layouts. Tested with Xorg 1.20 modesetting driver, weston at c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, kmscube hacked to use linear mod, and sway 1.5 Reported-by: Kirill A. Shutemov <kirill at shutemov.name> Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers") Link: https://lkml.org/lkml/2020/6/30/1251 Signed-off-by: James Jones <jajones at nvidia.com> --- drivers...

...as a DISPLAY_TARGET? > > The current patches in mesa for XBGR also lack enablement pieces for EGL, > Wayland and X11 compositing, but that's a different problem. EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's patches from a short while back, also upstream now). kmscube (with some patches that are upstream now) and weston both run OK for me. I think EGL/x11 is iffy though - haven't played with it. -ilia

...scanout it will import > > buffers created on the GPU into the display driver. Handles that > > userspace requests are those of the display driver so that they can be > > used to create framebuffers. > > > > This has been tested with some GBM test programs, as well as kmscube and > > weston. All of those run without modifications, but I'm sure there is a > > lot that can be improved. > > > > TODO: > > - use Nouveau headers to get at the prototype for creating a screen > > - implement enough support to seamlessly integrate with X &...

...to patch 3. > > The corresponding userspace changes can be found here: > > libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/ > mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/ > > I've verified that this works with kmscube's --atomic mode and Weston. Hi Ben, any thoughts on this series? I realize that this is somewhat suboptimal because we're effectively adding a duplicate of the existing IOCTL with only the "minor" extension of adding sync FDs/objects, but at the same time I don't have any go...

On Mon, Nov 12, 2018 at 05:51:53PM +0100, Robert Foss wrote: > > This series implements fence support for drm/virtio and > has been tested using qemu, kmscube and the below branches. > > Rob Herring solved a reference counting issue and > suggested a context check for the execbuf ioctl, his > changes have been included in the below commits to > keep the tree working at all commits. Patches added to qemu queue, should land in drm-misc-nex...

...u screen. For purposes of scanout it will import > buffers created on the GPU into the display driver. Handles that > userspace requests are those of the display driver so that they can be > used to create framebuffers. > > This has been tested with some GBM test programs, as well as kmscube and > weston. All of those run without modifications, but I'm sure there is a > lot that can be improved. > > TODO: > - use Nouveau headers to get at the prototype for creating a screen > - implement enough support to seamlessly integrate with X > - refactor some of the cod...

Oops, the FBIOPAN_DISPLAY ioctl error was a stupid mistake on mistake on my part.? Thanks for the info on where the validation code was.? Comparing against that made it easy to find the mistake.? It's working now, well...where I have been able to get over-allocation working!? Thanks for the help.? If I can't get the over-allocation to work on my other systems, I'll take it up in

...changes can be found here: > > > > > > libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/ > > > mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/ > > > > > > I've verified that this works with kmscube's --atomic mode and Weston. > > > > Hi Ben, > > > > any thoughts on this series? I realize that this is somewhat suboptimal > > because we're effectively adding a duplicate of the existing IOCTL with > > only the "minor" extension of adding sy...

...not advertise support > for them. Doing so would imply compatibility > between devices with incompatible memory layouts. > > Tested with Xorg 1.20 modesetting driver, > weston at c46c70dac84a4b3030cd05b380f9f410536690fc, > gnome & KDE wayland desktops from Ubuntu 18.04, > kmscube hacked to use linear mod, and sway 1.5 > > Reported-by: Kirill A. Shutemov <kirill at shutemov.name> > Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers") > Link: https://lkml.org/lkml/2020/6/30/1251 > Signed-off-by: James Jones <jajones at nv...

...patches in mesa for XBGR also lack enablement pieces for EGL, >>> Wayland and X11 compositing, but that's a different problem. >> >> >> EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's >> patches from a short while back, also upstream now). kmscube (with >> some patches that are upstream now) and weston both run OK for me. I >> think EGL/x11 is iffy though - haven't played with it. >> >> -ilia >> > > There are some from Daniel which unify the handling of formats inside egl, > not with any abgr2101...

...U requests to the Nouveau screen. For purposes of scanout it will import buffers created on the GPU into the display driver. Handles that userspace requests are those of the display driver so that they can be used to create framebuffers. This has been tested with some GBM test programs, as well as kmscube and weston. All of those run without modifications, but I'm sure there is a lot that can be improved. TODO: - use Nouveau headers to get at the prototype for creating a screen - implement enough support to seamlessly integrate with X - refactor some of the code to be reusable by other drivers...

On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote: > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding at nvidia.com> > > > > Irrespective of whether or not the device has any usable outputs, the > > modesetting helpers will try to register all the resources such as CRTCs > > and planes.

...gt; >> The current patches in mesa for XBGR also lack enablement pieces for EGL, >> Wayland and X11 compositing, but that's a different problem. > > EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's > patches from a short while back, also upstream now). kmscube (with > some patches that are upstream now) and weston both run OK for me. I > think EGL/x11 is iffy though - haven't played with it. > > -ilia > There are some from Daniel which unify the handling of formats inside egl, not with any abgr2101010 definitions though. Indeed...

...then patch 4 should be squashed into patch 3. The corresponding userspace changes can be found here: libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/ mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/ I've verified that this works with kmscube's --atomic mode and Weston. Thierry Thierry Reding (6): drm/nouveau: Split nouveau_fence_sync() drm/nouveau: Add nouveau_fence_ref() drm/nouveau: Support fence FDs at kickoff drm/nouveau: Support sync FDs and syncobjs drm/nouveau: Support DMA fence arrays drm/nouveau: Allow zero p...

...depending on these patches that I plan to send out in the coming days or weeks. The final result allows Nouveau and Tegra DRM to negotiate for a framebuffer modifier and then go into a render/scanout loop using fences for synchronization. All of this was tested using a slightly modified version of kmscube. Thierry Thierry Reding (3): drm/nouveau: Split nouveau_fence_sync() drm/nouveau: Support fence FDs at kickoff drm/nouveau: Support DMA fence arrays drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++++++++++++++- drivers/gpu/drm/nouveau/nouveau_bo.h | 2 + drivers/gpu/drm/nouveau/no...

In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)