Onboard: Add onboard virtual keyboard to scarthgap

[pratheekshasn]

Summary of Changes

The PR adds the virtual keyboard "Onboard" to scarthgap.

Justification

#AB2491688 requires the keyboard to be present on scarthgap as well.

The virtual keyboard "Onboard" (present on kirkstone) had been removed from scarthgap due to build errors on python 3.12. This PR adds back the same to scarthgap with corrections required for python3.12.

Implementation

Changes that differ from kirkstone:
The recipe also adds CFLAGS -Werror=declaration-after-statement to remove build errors that get generated when the recipe builds the source of Onboard.

Other required changes can be seen in this PR in the meta-openembedded layer.

The keyboard can now be launched and used just like in kirkstone.

Testing

• I have built the core package feed with this PR in place. (bitbake packagefeed-ni-core)

Tested by installing the built IPK on a VM.

• Keyboard launch
• Type on keyboard by clicking on the keys
• Click on other windows (like the file explorer) to test that the keyboard goes to the background
• Click on any window or textbox where something can be typed to test that the keyboard is back in focus and can type

Signed-off by: Pratheeksha S N pratheeksha.s.n@ni.com

• I certify that the contents of this pull request complies with the Developer Certificate of Origin.

[chaitu236]

@pratheekshasn you mentioned offline that there were issues getting onboard work on cRIO and some segfault issue; have they been addressed? Is this really ready for review?

[pratheekshasn]

@pratheekshasn you mentioned offline that there were issues getting onboard work on cRIO and some segfault issue; have they been addressed? Is this really ready for review?

The cRIO issue can be solved by tweaking a couple of values in onboard-settings, so yes, this is ready for review.

Here are the similarities and differences between kirkstone and scarthgap for onboard:

Setting	Kirkstone	Scarthgap	Comments
Appear on system boot	No	No
Appears immediately when process is started through CMD	Yes	No
Default value of Onboard-settings: Auto show-> External keyboards-> Don’t auto-show while external keyboards are connected	True	False
Appears whenever mouse focus is on a textbox (or a typeable window)	No	Yes	Kirkstone behaves the same as Scarthgap if the settings are made the same as scarthgap (Don't show while external keyboards are connected)
Disappears when mouse focus is on a non-typeable window	Yes	Yes
ps ax | grep onboard	python3 usr/bin/onboard --not-show-in=GNOME, GNOME-Classic:GNOME --startup-delay=3.0	python3 usr/bin/onboard	Launching the process on scarthgap with the same CMD line arguments does not result in the same behaviour as kirkstone, i.e., it doesn't show up immediately when the process is started through CMD, it appears only after I click on a textbox.

[amstewart]

Commits look good now; thanks. Just squash them down into a single commit for the pull.

What is your intention with regards to upstreaming the recipe fixes? Are you trying to upstream the meta-OE PR with yocto first?

[chaitu236]

The cRIO issue can be solved by tweaking a couple of values in onboard-settings

Can you describe what these settings are? Are these settings part of this PR?

[chaitu236]

Default value of Onboard-settings: Auto show-> External keyboards-> Don’t auto-show while external keyboards are connected

I'm a little confused here; you mention that for scarthgap the setting is False. But in onboard-defaults.conf there is this

[auto-show]
# Enable autoshow when there's no keyboard detected.
enabled=True
keyboard-device-detection-enabled=True
keyboard-device-detection-exceptions=['::noserial']

which seems to imply that the setting is true. This file is also exactly the same as kirkstone's. Does that mean that despite the same settings as kirkstone onboard works differently on scarthgap and ignores these settings? Or am I misunderstanding?

[pratheekshasn]

Sorry about the confusion, the default value of Auto show-> External keyboards-> Don’t auto-show while external keyboards are connected is true in both kirkstone and scarthgap. I double-checked this today by formatting the cRIOs and reinstalling the image and onboard on it.

When we set the value through the command line (via gsettings set org.onboard.auto-show keyboard-device-detection-enabled false), or through the onboard-settings UI, the values get stored in dconf's database. It doesn't affect onboard-defaults.conf.

Furthermore, we suspect that the mousetweaks warning that gets thrown might be preventing onboard from launching immediately (like in kirkstone).

Setting	Kirkstone	Scarthgap	Comments
Appear on system boot	No	No
Appears immediately when process is started through CMD	Yes	No
Default value of Onboard-settings: Auto show-> External keyboards-> Don’t auto-show while external keyboards are connected	True	False True
Appears whenever mouse focus is on a textbox (or a typeable window)	No	Yes	Kirkstone behaves the same as Scarthgap if the settings are made the same as scarthgap (Don't show while external keyboards are connected)
Disappears when mouse focus is on a non-typeable window	Yes	Yes
ps ax | grep onboard	python3 usr/bin/onboard --not-show-in=GNOME, GNOME-Classic:GNOME --startup-delay=3.0	python3 usr/bin/onboard	Launching the process on scarthgap with the same CMD line arguments does not result in the same behaviour as kirkstone, i.e., it doesn't show up immediately when the process is started through CMD, it appears only after I click on a textbox.
On launch of onboard	Appears immediately, throws no warnings on the terminal	Does not appear unless we disable keyboard detection. Throws mousetweaks warnings and acpid warnings
On launch of onboard-settings	Throws mousetweaks warning, then launches.	Throws mousetweaks warning, then launches.
On close of onboard-settings	Throws "critical" warning about tab_label not being found	Closes without issues

I think we can still go ahead and submit this PR that makes the onboard keyboard at least appear, albeit with a workaround. For the issue of it not showing up on a cRIO target when it can still show up in a VM, it can be fixed as a separate work item. What are your thoughts, @chaitu236?

[chaitu236]

Appears immediately when process is started through CMD

If you mean launching onboard via terminal, I don't think we care about this use case; the only requirement is that the virtual keyboard appears when text fields are focused without launching the process manually or putting in any workarounds (i.e., like kirkstone).

Launching the process on scarthgap with the same CMD line arguments does not result in the same behaviour as kirkstone, i.e., it doesn't show up immediately when the process is started through CMD, it appears only after I click on a textbox.

Launching onboard process from terminal is just a debugging step we used to figure out why the keyboard wasn't appearing; if everything works correctly, we shouldn't have to launch it from terminal so we don't need to care about this difference except for debugging purposes.

Does not appear unless we disable keyboard detection. Throws mousetweaks warnings and acpid warnings

We do need to find a fix for this before we submit/upstream as we do want the keyboard to appear without user intervention or workarounds (like in kirkstone).

I think we can still go ahead and submit this PR that makes the onboard keyboard at least appear, albeit with a workaround.

Like we discussed, it'd be better to identify the correct fix as we're not in a rush to add this package back.