really amazing work on all this Felix! Do I understand you correctly and I need some kind of ‘special’ cable/soldering/breakout board to do the ‘always on’ device mode? Can you tell me what to get so I’ll be able to help you test?
It means it would have to be decided at Kernel compile time whether you want USB Host mode by default (i.e. without special cable) or if you want USB Device mode.
My thinking was that USB Host mode would probably be the more likely use-case for the normal user because USB Device mode is only really useful for debugging. In that case you’d only need a special cable if you want the device to show up as a networking device for postmarketOS debugging.
I’ll include that in the testing image tonight.
Unfortunately, some recent changes on the Kernel have broken the way USB OTG works on this SoC.
So the testing image must wait until I get that sorted out…
I’m sure there are better ways, but to start I found that critical notifications will turn the screen back on. I have the wyoming-satellite working pretty well now (with local openwakeword). Added this to the startup command:
A minor downside is a bunch of stacked up notifications. Tried using --replace-id to keep it to one, but then only the first one wakes the screen.
I’m using the regular screen blanking to turn it back off, although I had to disable is-alsa-playing in /etc/sleep-inhibitor.conf for that to work while wyoming is running.
Note that you will want to flash the version of lk2nd that comes with this release to boot. Otherwise the Himax touchscreen driver will not be enabled in Linux.
This version has all the changes mentioned in the previous update: WiFi stability improvements, increased availability of RAM. I also implemented the cap at 177MHz (default is 200 MHz) for the SDIO bus that the downstream kernel has in place. It seems the Himax variant needs it, otherwise the WiFi card randomly disappears. Unfortunately it also shaves off almost 100Mbit/s in my iperf3 tests. But 160 MBit/s is still good enough on this device for me. I certainly prefer stability over max throughput here, especially since the device has comparatively tiny storage
USB OTG might not work at all on this release, but the USB Gadget (i.e. ethernet device showing up) works. Tested this both on the Focaltech and Himax variant (courtesy of @mattmon, thanks again!) and it works fine on both.
On the Himax variant you may want to go in to the display settings and switch the scaling to 125% and then back to 100% to resolve the weird scaling issue.
Let me know how testing goes
I don’t expect any weirdness from the Himax touch driver, as it is rather simple and doesn’t actually do that much other than pulling a few bytes over the I2C bus.
This new image is definitely working on the Himax models, although it still has some weird scaling issues; it looks like it defaults to 200% and some spillover still happens at the lock screen until after you turn it down.
Has your git repo for pmbootstrap been updated yet? I’m itching to make another SXMO image to try on these (I had sound issues with my last one, exacerbated by frequently-dropping WiFi).
Yes, with the files from my releases it’s usually simply:
edl w boot lk2nd.img
edl w userdata lenovo-cd-18781y-rootfs.img
This is a Linux based firmware. Not Android based, so no Android apps will function on this. For flashing instructions, see above.
Yeah, this seems to be a Phosh bug.
Just pushed the latest changes to my repo. It might be a bit messy as it’s still a work in progress, so I rebase and force push a lot at the moment. Sorry for that. I’m getting very close to having this upstreamed into pmOS properly
I see a few issues and wonder if this expected or you have seen:
Display scaling - didn’t seem to persist after I set 100% although after a couple of tries, it seems to have stuck to 100%
I can’t seem to delete an apps. In ‘software’ I get an error EDIT: restarted and the error is: Message recipient disconnected from message bus without replying
keyboard is quite small and doesn’t take up the available horizontal space. It’s usable but a little tricky (maybe a double Jack Daniels would help steady my fingers!)
Firefox as installed is very buggy graphically with boxes appearing and screen corruption. Tab headers are sometimes at the top, sometimes at the bottom. Seems a bit all over the place.
I will now begin the process of pushing all the changes for the drivers that I made to the upstream kernel. For that it would be good to have some testing from the community.
I would appreciate if people would be willing to provide me with Tested-by lines I can include in the patches I send to the Kernel mailing list. This is described here: submitting-patches.rst « process « Documentation - kernel/git/torvalds/linux.git - Linux kernel source tree
Note that it would have to include your real name and email address which will be visible in the Kernel commit log for eternity. It may also entail people contacting you at that email address in the future to test changes that touch areas that my patches enabled to work in the first place.
I basically need two areas tested:
WiFi
This should work as far as connecting to your wifi and having decent transfer speeds (I use iperf3 to measure) both RX/TX. There was an initial bug with WPA3 networks being slow (like 20 Mbit/s) but I fixed that. In my testing, on a 5GHz WiFi 5 network with 80MHz channel width, I generally see around 160 Mbit/s on average for both RX and TX.
The following error is known to me, but I don’t know whether it can be fixed in the driver. It occurs after the Group Rekeying Interval set on your AP expires (the default is often 1hr) and causes the WiFi to reconnect, briefly losing connection. The following message can be observed in dmesg:
[ 2756.310677] ath10k_sdio mmc1:0001:1: failed to install key for vdev 0 peer 76:ac:b9:67:85:bb: -110
[ 2756.310720] wlan0: failed to set key (2, ff:ff:ff:ff:ff:ff) to hardware (-110)
[ 2756.311492] wlan0: deauthenticating from 76:ac:b9:67:85:bb by local choice (Reason: 1=UNSPECIFIED)
there may be a
[ 2756.575288] ath10k_sdio mmc1:0001:1: Got RX ind from invalid peer: 101
sprinkled in for good measure.
Touchscreen
The touchscreen should function normally and be reasonably accurate. Because it’s a capacitive in-cell type display there should be no need for manual calibration.
If you happen to be able to test any of these areas by the end of this week and are willing to provide that Tested-by line I’d be happy to include it in my patch submissions. If you don’t want your real name and email to be associated with your account on this forum you can also PM it to me.
The format should be like this: Tested-by: Felix Kaechele <[email protected]>
Haven’t tested that yet. Sounds like a postmarketOS bug. They are switching the whole system to systemd right now, so that may be an effect of that.
I saw this when the scaling was not at 100%. At 100% the keyboard was the entire width of the screen and keys are almost the same size as my fingertips.
Have you also seen the display settings showing the wrong orientation? e.g. mine is sitting in portrait but the orientation shows landscape. Is that something to do with the way the screen is setup?
The resolution is also wrong - shown as 800x1280 (16:10) Unless i’m missing something, that should be 800x1280 (10:16) in portrait.