Keyboard issues within resin-wpe

I am using running resin-wpe and the keyboard will only accept alphanumeric character entries, and ignores the other keys completely. To preface, I did modify the image using the instructions within their base-image folder: , but the issue existed beforehand. Are there any changes that can be made to the image, or perhaps a global or environment variable that can be set within resin to rectify this?

@csmjulian this should be fixed now :slight_smile:

@petrosagg you’re awesome man. This image is hands down the best to run videos on! Question for you. With your knowledge of WPE Webkit and Yocto builds, what would be the solution to handling scanning and connecting to a wireless network? I’ve attempted wpa_supplicant and connman and so far both are erroring out and I can’t figure out why. Any suggestions?

1 Like

Glad to hear :slight_smile: If you want something along the lines of your device setting up a hotspot and then connecting from your phone to set up credentials you can use

Is this what you’re looking for?

I’ve tried, and it doesn’t work with resin-wpe since the yocto build removes apt-get, and also using a phone to set up credentials is not feasible for my project. I need to be able to have my resin application accept the input directly. I could modify the image to contain the same packages needed in resin-wifi-connect and try to accomplish the same thing through my application, but all I know it uses is dnsmasq.

@csmjulian, sorry for the late response, but somebody from the team just pointed me to this forum thread. I am the maintainer of WiFi Connect.

WiFi Connect communicates with NetworkManager using the D-Bus API interface. dnsmasq is used only for the phone scenario, where a captive portal is created, so it should not interest for your use case.

A couple of months I wrote some code based on what WiFi Connect does as a NodeJS module to help a user migrate his fleet to resinOS v2 from resinOS v1:

The module provides two functions:

  1. listAccessPoints - this one returns a list with all available SSIDs of nearby networks
  2. connectToAccessPoint - to be used after an access point SSID is chosen

You may check the examples folder for example usage:

Running the NodeJS runtime can be an overkill for something like that (the particular user already used ElectronJS, so I targeted his use case). WiFi Connect v3 and v4 are written in Rust for this reason, but Rust has a very steep curve and forking it to support something like that will be quite a lot of work.

In the future we are planning on providing functionality which will allow alternative input methods other than the one with the captive portal, but we do not have concrete plans for when this could possibly happen.