Wayland support for TX2

Hello,

I am trying to run Weston on the sample rootfs supplied with L4T R28.1. I have flashed the rootfs onto the TX2, and copied Weston from Linux_for_Tegra/weston.tbz2, but I get the following error when executing weston:

root@tegra-ubuntu:~# weston --tty=3
Date: 2017-08-22 UTC
[07:09:03.744] weston 1.7.0
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0
               Build: 1.7.0 configure.ac: bump to version 1.7.0 for release (2015-02-13 20:47:09 -0800)
[07:09:03.744] OS: Linux, 4.4.38-tegra, #1 SMP PREEMPT Thu Jul 20 00:49:07 PDT 2017, aarch64
[07:09:03.745] Starting with no config file.
[07:09:03.745] Loading module '/usr/lib/aarch64-linux-gnu/weston//egloutput-backend.so'
[07:09:03.749] initializing egloutput backend
[07:09:03.749] Loading module '/usr/lib/aarch64-linux-gnu/weston//gl-renderer.so'
[07:09:03.752] EGL_EXT_device_base not available[07:09:03.752] failed to get EGL devices from gl renderer
[07:09:05.776] fatal: failed to create compositor

Do you have any pointers on how to run Weston on L4T R28.1? I want to get Weston running on the sample rootfs to later port it to work with the Yocto layer I am using for my project.

Hi JonatanP,

Sorry that weston is not yet fully supported on rel-28.1. I am checking what functions are working now.

Hi JonatanP,

Please use following steps to run weston and following apps.

sudo service lightdm stop #off x11
mkdir /tmp/xdg
chmod 700 /tmp/xdg
sudo XDG_RUNTIME_DIR=/tmp/xdg weston --idle-time=0 &

Hello WayneWWW,

Thank you for the instructions. I installed L4T R28.1 via JetPack, and now it works fine. I previously flashed the rootfs manually using flash.sh, and this seems to have been my issue.

I would now like to run Weston in my custom Yocto layer, can you indicate where I can find the source code of the weston version used in L4T? I need to link it against the rest of the libraries in my rootfs.

Hi JonatanP,

Sorry that we don’t release the source code of weston. We are using 1.7.0 weston. The lib are mostly in /usr/lib/aarch64-linux-gnu and /usr/lib/weston.

What function will you use in Yocto? Our weston is not yet fully supported and I am afraid that might cause error.

Hello WayneWWW,

I am building a complete Linux system for the TX2, and I am using only a small portion of the NVIDIA pre-compiled rootfs (such as graphics drivers and firmware). This works well enough for drivers and very low-level software, because there is a minimal set of external dependencies from these libraries.

For Weston, I have issues using the binary version, since Weston is designed to link against many external libraries in the system, such as libjpeg, libpng, libxml2, libz, cairo, etc… My system uses very recent versions of a lot of these libraries, and having a pre-compiled version of Weston, which links against older versions is a problem (and is also likely to cause future issues, when I need to update one of the libraries Weston depends upon).

With the sources, I can make any modifications necessary to Weston to make it compatible with the rest of my rootfs, or possibly forward-port the NVIDIA-specific backend needed by Weston to use the NVIDIA graphics driver.

I am completely OK with the source code for Weston not being completely supported by NVIDIA, and I understand that I will need to make modifications to it to get it working correctly. Would it be possible for you to share it somehow?

Thank you for your assistance.

Another option might be a statically linked binary?

Hello snarky,

A statically linked binary would be an option, yes.

Making the sources available for the modifications made to Weston would have other benefits for TX2 users as well, such as giving a reference in how to make other compositors (such as QtWayland) work on the TX2. Having the sources available to the community also means that modifications can be ported to newer versions of Weston.

Either a statically linked binary, or sources would be much appreciated!

Hi JonatanP,

After discussed internally, we cannot release the source of wayland/weston. Please grab the opensource wayland and use it directly.

Hello WayneWWW,

Alright, I understand. I am working around this by using QtWayland for now, which already has support for the NVIDIA driver without any further patches.

Thanks for investigating the issue!

Sorry that we cannot share the weston from NV.

If any user wants to try wayland clients, I’ve verified the weston-terminal and weston-simple-egl clients from opensource that could work.

git clone git://anongit.freedesktop.org/wayland/weston

I too am attempting to run the vanilla weston included in Jetpack 3.2 (L4T 28.2).

But it doesn’t appear to want to start:

root@baba:~# service lightdm stop 
root@baba:~# mkdir /tmp/xdg
root@baba:~# chmod 700 /tmp/xdg
root@baba:~# export XDG_RUNTIME_DIR=/tmp/xdg
root@baba:~# weston
[15:00:45.371] weston 1.7.0
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0
               Build: 1.7.0 configure.ac: bump to version 1.7.0 for release (2015-02-13 20:47:09 -0800)
[15:00:45.371] OS: Linux, 4.4.38-tegra, #1 SMP PREEMPT Thu Mar 1 20:49:20 PST 2018, aarch64
[15:00:45.371] Starting with no config file.
[15:00:45.371] Loading module '/usr/lib/aarch64-linux-gnu/weston//egloutput-backend.so'
[15:00:45.375] initializing egloutput backend
[15:00:45.375] Loading module '/usr/lib/aarch64-linux-gnu/weston//gl-renderer.so'
[15:00:45.621] warning: EGL_EXT_buffer_age not supported. Performance could be affected.
[15:00:45.621] warning: EGL_EXT_swap_buffers_with_damage not supported. Performance could be affected.
[15:00:45.621] compositing all EGL clients to the primary plane
[15:00:45.621] atomic page flips are not allowed
[15:00:45.621] drmModeGetResources failed
[15:00:45.621] failed to create outputs
[15:00:46.675] fatal: failed to create compositor

“drmMode* failed” give me a vague hint that this could be mesa/tegra driver related?

Thanks for your time!

Do be sure NVIDIA’s libraries are in place and not overwritten:

sha1sum -c /etc/nv_tegra_release

Jimmy Pettersson,

I just tried with my tx2 and it works fine.

“drmModeGetResources failed” → Looks like there is some problem in detecting DRM device.

Could you try to run DRM renderer in MMAPI sample and see if it works?

root@baba:~# sha1sum -c /etc/nv_tegra_release
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketserver.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomxilclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvidia-egl-wayland.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamerautils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_graphics.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvosd.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_2d_v2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtestresults.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_vic.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamlog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvparser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_image.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_parser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcameratools.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvimp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnet.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libscf.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_contentpipe.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtnr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstorehdfx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtvmr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstream_camconsumer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstoredefog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_video.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvavp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvll.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvdc.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcolorutil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvapputil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvos.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvodm_imager.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcam_imageencoder.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvwinsys.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstreamproducer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvexif.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtx_helper.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvideocodec.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so: OK
nvidia@baba:~/tegra_multimedia_api/samples/08_video_dec_drm$ ./video_dec_drm ~/Videos/sample.MOV H264
Set governor to performance before enabling profiler
Failed to query video capabilities: Inappropriate ioctl for device
NvMMLiteOpen : Block : BlockType = 261 
TVMR: NvMMLiteTVMRDecBlockOpen: 7647: NvMMLiteBlockOpen 
NvMMLiteBlockCreate : Block : BlockType = 261 
Failed to query video capabilities: Inappropriate ioctl for device
Starting decoder capture loop thread
TVMR: cbBeginSequence: 1179: BeginSequence  1280x720, bVPR = 0
TVMR: LowCorner Frequency = 0 
TVMR: cbBeginSequence: 1529: DecodeBuffers = 6, pnvsi->eCodec = 4, codec = 0 
TVMR: cbBeginSequence: 1600: Display Resolution : (1280x720) 
TVMR: cbBeginSequence: 1601: Display Aspect Ratio : (1280x720) 
TVMR: cbBeginSequence: 1669: ColorFormat : 5 
TVMR: cbBeginSequence:1683 ColorSpace = NvColorSpace_YCbCr601
TVMR: cbBeginSequence: 1809: SurfaceLayout = 3
TVMR: cbBeginSequence: 1902: NumOfSurfaces = 13, InteraceStream = 0, InterlaceEnabled = 0, bSecure = 0, MVC = 0 Semiplanar = 1, bReinit = 1, BitDepthForSurface = 8 LumaBitDepth = 8, ChromaBitDepth = 8, ChromaFormat = 5
TVMR: cbBeginSequence: 1904: BeginSequence  ColorPrimaries = 2, TransferCharacteristics = 2, MatrixCoefficients = 2
Video Resolution: 1280x720
APP_INFO : mastering display data not found
Input file read complete
TVMR: NvMMLiteTVMRDecDoWork: 6531: NVMMLITE_TVMR: EOS detected
[b][ERROR] (NvDrmRenderer.cpp:182) <renderer0> Couldn't open device: drm-nvdc
Error in setting up drm renderer[/b]
TVMR: TVMRBufferProcessing: 4974: Consume the extra signalling for EOS 
<b>Error in query_and_set_capture</b>
Exiting decoder capture loop thread

Im gonna do a complete system re-flash to see if it improves things.

Thanks for your input!

I’m wondering whether or not you are logged in as a user in group “video”? Those have permission for GPU access. Sometimes error messages lack clarity, and the message you have is not detailed. Normally users “nvidia” and “ubuntu” are in group “video”.

Also, you are using remote forwarding instead of logged in locally, then this too would change things.

After a re-flash and trying as nvidia user the error message went away (didn’t try as root user yet) and weston initialized properly.