Linux/AM5728: GStreamer ducati plugin fails with X11

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. 

http://processors.wiki.ti.com/index.php/Processor_SDK_Building_The_SDK

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

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.