Linux/AM5728: GStreamer ducati plugin fails with X11

The software team have been notified. They will respond here.

It does not help with our use case.
We consider porting our applications to sitara. These mostly use gtk and X11 and want to do minimal changes. These applications use component for video playback on specific area in screen. One of applications is cctv system displaying 4 ip camera outputs,another is playing adverts.

We want to use several gstreamer pipelines while X are running. Also we want to display them with sink that does display on part of screen effectively(ideally glimagesink). With ximagesink we reach cpu bottleneck(partially because of videoconvert).

Is this possible to do or dead end?

There is no issue to use gstreamer pipeline when using X11. The problem you are running is because you are using kmssink to display while running X11. DRM (Display subsystem driver framework) resource should be owned by single master. When you run X11 along with kmssink, both of them try to own the DSS DRM resource and hence the application runs into conflict and fail. You need to use special plugin that doesn't  try to open the DRM resource but shares with the X11 windows manager. For ex, in Processor SDK release, we support Wayland  manager. To run gstreamer pipeline with Wayland manager, you need to use waylandsink, you cannot use kmssink with it. 

Bit of google suggests that gstreamer plugin for X video sink is ximagesink. We do not package it with our filesystem. You can try to build it using arago and use it and see if it helps. 

Here's the link to build the SDK using Arago. Check the recipes for gstreamer plugin build and see if you can add ximagesink to the list and build it. 

That is not problem here. Problem is that you could not use libdce while X are running, no sink involved.
Even simple query on codec version fails as gst-inspect-1.0 ducatih264dec fails on libdce initalization.
kmssink was used purely as verification that plugins were compiled correctly to test that equivalent commands without X work.
Then with drmopen hack of libdce a gstreamer pipelines using ducati appear to work. It uses ximagesink and it is slow because it also needs videoconvert of vpe output.

Okay, I overlooked the ducati plugins. IVA-HD codec works optimally when the video buffers are allocated from specialized memory called TILER. TILER memory is managed by OMAP DRM driver and hence libdec2 tries to open "omapdrm" driver when it finds OmapDrm_FD value as -1. There is an API in libdce named dce_set_fd() through which it can receive the omapdrm handle from other user layer component owning the DRM resource, in your case X11.

Refer to viddec3test source file where the application owns the DRM resource and then use the dce_set_fd() API to pass the omapdrm fd to libdce.

git.ti.com/.../viddec3test.c

In your case, possibly X11 manager implementation is owning the DRM resource and you may need to make call to dce_set_fd in that backend component.

That example couldn't be compiled. I couldn't test if this solution works or if problem persists.

Local compilation fails because there is no libdri2 in system, only xcb-dri2. 

In arago omapdrmtest is compiled only for wayland. For X it fails on dependency  that ti-xsgx-ddk-um is used instead of ti-sgx-ddk-um. When I tried to change that ... bitbake omapdrmtest ended with following errors:

ERROR: Nothing PROVIDES 'virtual/libgl' (but /home/devel/ti/tisdk/sources/oe-core/meta/recipes-graphics/mesa/libglu_9.0.0.bb, /home/devel/ti/tisdk/sources/oe-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb DEPENDS on or otherwise requires it)
ERROR: mesa PROVIDES virtual/libgl but was skipped: PREFERRED_PROVIDER_virtual/libgl set to mesa-gl, not mesa
ERROR: mesa-gl PROVIDES virtual/libgl but was skipped: PREFERRED_PROVIDER_virtual/mesa set to mesa, not mesa-gl
ERROR: mesa PROVIDES virtual/libgl but was skipped: PREFERRED_PROVIDER_virtual/libgl set to mesa-gl, not mesa

ping, it was week since last reply. Is there any example that could be compiled at all?

Processor SDK only supports Wayland manager, so please do not expect that out of box examples would be compiling or running for X11. The reference to videc3test.c source code was provided to study the code on how the DRM device fd is passed by the application to the libdce layer.

To understand your issue better, may be let me go back one step and ask for more information. DRM device can be opened multiple times. The restriction on DRM device is only on DRM kernel mode setting (KMS) and not on buffer management. There can be only one master for doing KMS but the buffer management can be done by multiple masters. It seems, in your application involving X, call from inside drmopen itself fails.

In your hack, you have to put "do{} while()" loop. What happens if you don't put a while loop?? Is the DRM driver installed by that time?

I am also trying to understand if that second argument in drm() API call is causing some conflict. Do you know how is the drmopen() API is called by X??

As I wrote in previous post it is competely useless example because it simply can't get file descriptor that you stated because it needs dri2. It gets file descriptor and does following:

DRI2Connect(dpy, root, DRI2DriverDRI, &driver, &device)

global_fd = open(device, O_RDWR);

drmGetMagic(global_fd, &magic);

DRI2Authenticate(dpy, root, magic);

 omap_device_new(global_fd);

which is impossible without library with these DRI2 calls

I didn't see problem with loop here. It was from previous attempt of porting libdce to debian where open randomly failed.

I don't know about how X uses that as it was provided only as binary package.

Hi Ondrej,

It seems that you are referring to display-x11.c file. Please don’t refer to it as it is dead legacy code in the application that needs to be removed. I just referred viddec3test source file from that application.

You may want to replace the drmOpen(“omapdrm”, “platform:omapdrm:00”) with drmOpen(“omapdrm”,NULL) call and check how it behaves.  /dev/dri/card0 is a control node. If an app opens card0 after somebody has opened it, it will automatically be opened as a render node ie no mode setting allowed. However if that app (libdce2) only needs buffer management, it should not open card0 as it might get full control if it happens to be the first one to open it.

It would be easier just to say that example is broken than making excuses. That file and display-kms/wayland are only place that sets file descriptor and kms/wayland isn't relevant here.

and drmOpen("omapdrm",NULL) gives same error as before.