Cog not starting on CM3 with Buildroot 2022.02.1 build

[WoeMat]

Hello everyone,
I would like to get cog up an running on a raspberry CM3. I have allready set up the complete thing with Buildroot 2021.02.1 once and now I would like to update everything using Buildroot 2022.02.1.
Unfortunately I ran into the following message while starting cog.

#cog --platform=fdo http://127.0.0.1

(cog:3471): Cog-Core-WARNING **: 13:11:00.713: Platform module name 'fdo' is deprecated, please use 'wl' instead.

(cog:3471): Cog-Core-WARNING **: 13:11:00.721: cog_modules_get_preferred: preferred module 'wl' not supported

(cog:3471): Cog-WARNING **: 13:11:00.723: Cannot create platform: Could not find an usable platform module
wpe: could not load the impl library. Is there any backend installed?: libWPEBackend-default.so: cannot open shared object file: No such file or directory
Aborted

I have selected the fdo backend in Buildroot BR2_PACKAGE_WPEBACKEND_FDO and BR2_PACKAGE_COG_PLATFORM_FDO.

Ther versions in this Buildroot version are:
cog 0.12.4
wpe-backend-fdo 1.12
wpewebkit 2.34
weston 10.0

What am I missing?

Tanks

[philn]

Can you get a log? Set this env var: G_DEBUG_MESSAGES=all

[WoeMat]

You mean simply type
echo G_DEBUG_MESSGAES=all
and then run cog? There is no further output than the one I posted above if I do that. Or do I have to recompile cog with this option?

[philn]

export G_DEBUG_MESSAGES=all and run cog

[WoeMat]

As I allready mentioned, if I do that (even if the variable is spelled correctly ;) ) there is no more output if I run cog as the one I allready posted above. Is this env var used by cog itself or by some other programm I might not have selected in Buildroot?

I'm note sure on what to expect? Any more output while starting cog or is there a log created somewhere.

[philn]

cc @aperezdc our buildroot expert.

[WoeMat]

Sorry but I'm not familiar with all this yet. Can I contact @aperezdc somehow directly or do you think he will be replying to this discussion?

[aperezdc]

@WoeMat It looks like for some reason Cog cannot connect to the running Wayland compositor (Weston), but for confirmation it would be indeed good to have the debug output. The name of the environment variable is G_MESSAGES_DEBUG (as per the docs), so running Cog like this should give us the debug log:

G_MESSAGES_DEBUG=all cog --platform=wl http://127.0.0.1

If you want to both see the output and dump it to a file, we can add tee in there:

G_MESSAGES_DEBUG=all cog --platform=wl http://127.0.0.1 2>&1 | tee cog.log

For the sake of completeness, here you have a check list to try to troubleshoot the issue:

• Is a Wayland compositor (like Weston) running?
• Are you trying to run Cog under the same user account as the compositor?
• Is the XDG_RUNTIME_DIR environment variable set to the same value for the compositor and for running Cog? You can check the value used by Weston with xargs -0L1 echo < /proc/$(pidof weston)/environ | grep '^XDG_RUNTIME_DIR'.
• Does the user account used to run Cog have access to the GPU device nodes? For example if you are using the Mesa vc4 driver, you can check with test -w /dev/dri/card0 && echo OK.

I hope this helps, let us know how it goes 👀️

[WoeMat]

cog.log
Hi.
I attached the log provided by the command. Weston is running and I am exporting the XDG_RUNTIME_DIR in my startup script.
I can see the weston desktop and there is a file wayland-1 in mit XDG dir.

The only user is the root user and all programms are run with this user.

The XDG_RUNTIME_DIR also seems to be the same.

I have allready used this setup with Buildroot 2021.02 with weston 9.0 and an older version of cog and everything worked fine.

The driver check aslo replied OK

[aperezdc]

Thanks for checking things and for the log—that helps a bit! From the log message what is most likely failing is the wl_display_connect() which opens the connection to the compositor. Could you try setting WAYLAND_DISPLAY in the environment as well to make sure Cog tries to use the wayland-1 display? Like this:

G_MESSAGES_DEBUG=all WAYLAND_DISPLAY=wayland-1 cog --platform=wl http://127.0.0.1

I have a hunch that this might work.

[WoeMat]

Thanks for the reply. I will try that.