I conected a HDMI display with resolution 1280 x 1024 60 Hz and touch-screen connected through USB.
I connected an USB mouse too (to double check).
I set docker-compose.yaml to navigate to www.toradex.com
Here is what I see:
cog is not open fullscreen but it takes only a portion of the screen
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, it seems that you are experiencing issues with the Cog container on a Verdin iMX8M-Plus module where the touch screen and mouse are not functioning as expected. Here are some points to consider:
Fullscreen Issue: Cog not opening in fullscreen might be related to the configuration of the Weston compositor or the Cog container itself. Ensure that the Weston configuration (weston.ini) is set up correctly to support fullscreen applications. You might need to adjust the weston.ini file to ensure that the Cog application is launched in fullscreen mode.
Touch Screen and Mouse Functionality: The touch screen and mouse not working with Cog but working with Chromium suggests a possible configuration or compatibility issue with Cog. Since Cog is a minimal launcher for WebKit WPE, it might not handle input devices the same way Chromium does. Ensure that the necessary input devices are correctly passed to the Cog container. You might need to check if the touch and mouse devices are being recognized by the container and if any additional configuration is required.
Mouse Pointer Visibility: The issue with the mouse pointer being visible only outside of Cog could be related to how Cog handles input focus and rendering. This might require further investigation into the Cog container’s configuration or Weston settings.
Unfortunately, without more specific details or logs, it’s challenging to provide a definitive solution. You might want to check the logs of both the Weston and Cog containers for any errors or warnings that could provide more insight into the issue. Additionally, consulting the Toradex community or support channels might provide more targeted assistance for this specific behavior.
Please, also check if these links can help you solve your problem:
For the mouse cursor, in my experience the cursor is actually “invisible”. But, it’s still possible albeit difficult to move the invisible cursor and click on things. The mouse scroll wheel even works as well.
Meaning we can’t easily test if these commits even “fix” the issue or not. In summary, it seems like these issues are something that need to be addressed on the Cog side of things.
Hi @jeremias.tx
with this kind of issues, I think that cog could not be a realistic alternative to implement a kiosk (at the moment, at least).
The mouse it’s only for my test, but the touch doesn’t work at all. I don’t talk about multitouch, swiping and so on, I talk about a simple one-finger touch.
It doesn’t work at all.
I had already seen that cog package for Debian bookworm is stuck to 0.16.1 (quite old) and so I opened an issue to the mantainers to ask for having it updated.
Cog mantainers suggested to build 0.18.4.
I tried and I can see that the mouse works as expected.
The one-finger touch doesn’t work reliably, but scroll works. Strange.
/----------/
EDIT:
Do you think that torizon/cog container could be built including the updated cog 0.18.4?
cog 0.16.1 is really old (and buggy)
Moreover, cog can be started maximized setting the environment variable in docker-compose.yaml
I had already seen that cog package for Debian bookworm is stuck to 0.16.1 (quite old) and so I opened an issue to the mantainers to ask for having it updated.
It’s very unlikely that the Debian maintainers (who are probably different than the Cog maintainers from Igalia) will bump it. Major-bumping within a Debian Stable release is mainly done for security or stability, not for getting new software.
Do you think that torizon/cog container could be built including the updated cog 0.18.4?
cog 0.16.1 is really old (and buggy)
Jeremias and I let our project management know about this, so it’s a matter of prioritization.
One could always of course use Cog from Alpine (cog - Alpine Linux packages) or use a multi-staged build to build cog and transplant the binaries to a torizon/wayland-base as well.
use a multi-staged build to build cog and transplant the binaries to a torizon/wayland-base as well.
This is what I tried to do with this PR I’ve just opened to commontorizon.
I’ve opened to commontorizon (instead of torizon/containers) because I understood that commontorizon is a little bit more “experimental” than torizon/containers.
But I’m not sure if I understood properly.
If you prefer, I can open the same PR to troizon/containers
Yea, something like that should work (actually quite smart to build it from the .dsc instead of source code, makes it for a cleaner Dockerfile overall, better than my previous suggestions).
I wouldn’t merge this change on torizon-containers specifically because we need to make sure our package state is “consistent” with the upstream Debian, basically meaning we’d backport the whole package into our feed, but as you said Common Torizon is more experimental so it should be fine there.
Have you experienced any of the previous bugs you related with this newer version?
With this new release, mouse cursor works as expected (not hidden).
Touch screen is a little bit strange: scroll works perfectly, but one-finger click is not consistent. I cannot say it doesn’t work, but sometimes it doesn’t work…
I need to investigate
dget http://deb.debian.org/debian/pool/main/w/wpewebkit/wpewebkit_2.46.1-1.dsc
cd wpewebkit-2.46.1
sed -i 's/dpkg-dev[^,]*,//' debian/control
apt build-dep .
debian/rules binary
I tried but compiling on the Verdin SoM is really really slow.
I need to find away to cross compile wpewebkit to build a .deb package that can be copied and installed to the SoM.
Thanks @leon.tx,
I haven’t understood the purpose of the tool.
The problem is that I use an Azure environment (DevOps + Azure Container Registry) and not github. So I’m not so expert about github actions.
I’ll try to use it on my forked commontorizon/container project to see if I’m able to have it working.
If I’m right, I imagine that it’s not straightforward using the action (that uder the hood uses torizon/build-deb-action that is a shell wrapper around dpkg-buildpackage) with the proposed way from lgalia (dget + ... + debian/rules)
I opened this issue on github because as far as I understand, using dget to download the sources to be built is not a supported scenario (at the moment).
Hi @leon.tx
I tried using torizon/torizon-deb-ci to build cog and wpewebkit, but I haven’t been able to have it working.
See here.
Do you have any suggestions?
This is what I learnt.
As I wrote, there is one thing I don’t understand: if I start from the torizon/cog container (which has cog 0.16.1 installed) and I run the same commands, I don’t see the missing libwpewebkit-2.0-dev dependency. But I don’t understand why.
For this reason I tried to install the official cog 0.16.1 into a plain bookworm container, but I see the libwpewebkit-2.0-dev dependency issue.
Can you explain this difference, please?
Moreover, it’s impossible for me to build wpewebkit, because on github free plan there is the 6 hour time limit for a job in a github action (see here).
A github paid plan is necessary to build wpewebkit
/---- EDIT ----/
I tried with Github Actions self-hosted runner but I can’t use it because torizon/torizon-deb-ci already specifies runs-on
Do you think that a new input parameter to specify the runner can be added?
Something like
on:
workflow_call:
inputs:
runner:
description: 'Runner to be used for this workflow'
required: false
type: string
default: 'ubuntu-latest'
Your suggestion here could make sense.
I think we did not implement this reusable workflow this way as it was not needed for our needs.
Therefore, if you want to be able to use an input for the runner, I would recommend that you fork this repository and do the changes needed.
If you want, you can submit a pull request and the Torizon team will evaluate if this can be merged into the repository or not.
It has been merged into main branch.
But I can’t proceed because it seems that github doesn’t allow this: Called workflows cannot be queued onto self-hosted runners across organizations/enterprises. Failed to queue this job. Labels: 'self-hosted'.
As far as I can read on github,
it seems not possible to use a public reusable workflow with a self-hosted runner
Therefore, I think the only way out here is to fork our reusable workflow in your organization/account and reference the reusable workflow repository that you have.
This requires rebasing from time to time, but this seems to be a GitHub limitation.
