Insignia Flex8 (NS-P08W7100) Progress

[ouija]

Hey all,

Thought I'd just share some progress with getting Android-x86 running on my Insignia Flex 8 Tablet (NS-P08W7100)

It's been rather painful trying to get Android-x86 simply running on this darn machine, let alone trying to get the components working properly!

But so far, I've managed to get it working for the most part, with some things still to figure out, so if anyone reading this has any suggestions on fixes or certain things to try related to some of my remaining issues, I'm all ears!

First off:  I wasn't able to get the latest android-x86-8.1-r2 version to load properly on this tablet;  I believe this is due to some kernel incompatibility with the Cherry Trail processor / Intel HD Graphic Card -- It would simply show a blank (backlit) screen, and nothing more.   

However, I soon discovered that the Bliss-v7.2-android_x86_64-OFFICIAL-20171103-1727_k4.12_oto-installer version of Android-x86 *would* boot up properly, only to find that other issues existed.

I also discovered that I was able to boot newer versions of Android-x86 by using an external HDMI connection and setting "gfxpayload=1920x1200"  (or whatever resolution of the monitor connected is) to the grub command line (while also disabling the internal display using this "video=DSI-1:d" grub setting as well) would help to get things loaded, but would limit me to using an external display, and that's just not feasible since I want to use the tablet for portability.

After further testing, I found that Android-x86 builds based on kernel 4.12 seemed to work best with this unit, and for fun I decieded to give PheonixOS a try, and found that it too would load (once I fixed an issue with the USB/EFI installer), and discovered that it uses kernel 4.14.15 -- again, I'm not sure if it has to do with the kernel version or not, but I could not get any builds using kernel 4.9 / 4.19 / 4.20 to load at all.

There also may be an issue with the newer MESA versions possibly.

Regardless, I've chosen to continue with using PhoenixOSInstaller-v3.5.0 (Based on Android7.1) for this unit, mainly because it had the kernel modules present and loading for both the touchscreen [gslx680] and soundcard [bytcrrt5651].

I managed to extract the firmware for the touchscreen from the original Windows driver, and after much trial and error, figured out how to configure it and getting it working properly for Android.  I have pushed my changes to the gsl-firmware repo here: https://github.com/onitake/gsl-firmware/tree/master/firmware/insignia/flex8

So now that I had touchscreen working, I moved on to fixing issues with the soundcard today -- which I've partially managed to resolve.

As I said, PheonixOS had the bytcrrt5651 module loading properly, but there wasn't any sound output.   Again, after many google searches and testing, I figured out how to get sound working for the headphones only, by coming across similar issues and seeing what worked.

I had to download the asound.state file for the bytcrrt5651 from here: https://github.com/plbossart/UCM/tree/master/bytcr-rt5651 and copy it to /system/etc/alsa/bytcrrt5651.state

Note that the /etc/init.sh script will restore the setting in this file via alsa_ctl upon boot, as long as you ensure you name the file exactly like above. (bascially it runs 'alsa_ctl -f /system/etc/alsa/bytcrrt5651.state restore 0')

Then you need to configure the alsa_amixer settings, which I realized is essentially what is outlined in the bytcr-rt5651.conf file from that same repo above.   However, I stubled across this code https://github.com/s3k0/alsa_bytcr_x86 which then lead me to find https://groups.google.com/group/android-x86/attach/d1ffc290d6d56/alsa_bytcr_andx86.zip?part=0.1&authuser=0&view=1

And I found that by running the /alsa_cr.sh script, this would get sound working through the headphones! 

So now I've essentially merged this /alsa_cr.sh script into the /etc/init.sh script specific to my product model and have sound working now on startup. 

I also had to fix the orientation of the accelerometer for the device, by adding hal.sensors.iio.accel.matrix 0,-1,0,-1.0.0,0,0,-1 to the /etc/init.sh script as well, specific to my product model.

And that's basically where I'm at now -- A working Android-x86 tablet with sound (headphones only), touchscreen, rotation, backlight/brightness (worked out of the box!).   I'd love to be able to get the internal speaker working for sound output, so I'm open to any suggestions (and yes, I've tried playing around with alsa_amixer to try and get it working, to no avail)   The alsa_cr_spk.sh script didn't work either... 

I'd also like to get the tablet's "Windows Key" working, and possibly the [Intel(R) AVStream] camera as well (neither of which I've looked into yet).

If anyone has any ideas or suggestions on what to try next, please let me know, and I hope this post helps others to achieve the same results on thier Flex8 tablets without costing them as much time and research as it has me! :)

[youling 257]

Delete the old asound.state file, 4 years ago, delete your system/etc/alsa/bytcrrt5651.state 

open terminal, do these command, then upload new bytcrrt5651.state file by yourself.

these command from https://raw.githubusercontent.com/plbossart/UCM/master/bytcr-rt5651/HiFi.conf

https://raw.githubusercontent.com/plbossart/UCM/master/bytcr-rt5651/bytcr-rt5651.conf

su

sh /sdcard/Download/bytcrrt5651.txt

sh /sdcard/Download/speaker.txt

alsa_ctl store bytcrrt5651 -f /system/etc/alsa/bytcrrt5651.state

[ouija]

On Tuesday, July 16, 2019 at 9:17:16 PM UTC-6, youling 257 wrote:

Delete the old asound.state file, 4 years ago, delete your system/etc/alsa/bytcrrt5651.state 

Same thing;  Headphones work without issue, but no speaker output...   Thanks for your assistance however, I'll use this newer apprach! 

Let me know if you have any other suggestions!

Also, anyone know how to get a "hardware" key mapped to the Android 'back' function?  This tablet has a physical "Windows" key (touch sensitive), but I'm not sure if it's even possible to support this in Android-x86...

[youling 257]

ASoC: Intel: bytcr_rt5651: Add support for externar amplifier enable … ASoC: Intel: bytcr_rt5651: Fix using the wrong GPIO for the ext-amp o…

you need 4.19 kernel, if < 4.19, do these command,

su

echo 368 > /sys/class/gpio/export

echo 1 > /sys/class/gpio/gpio368/value

[ouija]

Just tried updating the Kernel in PheonixOS to 4.19.15 (http://bbs.phoenixstudio.org/en/showthread.php?tid=9661) but my device now fails to load / setmode properly.

Back in working Kernel 4.14.15 and tried the /sys/class/gpio/export in the current kernel, but for some odd reason, it isn't taking effect -- the /sys/class/gpio/gpio368 pin isn't being created (no directory/file is actually exported or exists)  It doesn't seem to like using "368"... if I export "369", it works, but not "368".... 

Any suggestions on how to fix this?  Boooo.

[youling 257]

cat /sys/kernel/debug/gpio, what output?

在 2019年7月17日星期三 UTC+8下午2:17:35，ouija写道：

[ouija]

gpiochip4: GPIOs 315-317, parent: platform/INT0002:00, INT0002 Virtual GPIO:

 gpio-317 (                    |ACPI:Event          ) in  lo IRQ

gpiochip3: GPIOs 318-372, parent: platform/INT33FF:03, INT33FF:03:

 gpio-365 (                    |?                   ) out lo    

 gpio-368 (                    |?                   ) in  hi IRQ

 gpio-372 (                    |?                   ) out lo    

gpiochip2: GPIOs 373-396, parent: platform/INT33FF:02, INT33FF:02:

 gpio-381 (                    |power               ) in  hi IRQ

gpiochip1: GPIOs 397-455, parent: platform/INT33FF:01, INT33FF:01:

 gpio-400 (                    |ACPI:Event          ) in  hi IRQ

 gpio-401 (                    |reset               ) out hi    

 gpio-416 (                    |ACPI:OpRegion       ) out lo    

 gpio-438 (                    |ACPI:OpRegion       ) out hi    

gpiochip0: GPIOs 456-511, parent: platform/INT33FF:00, INT33FF:00:

 gpio-499 (                    |volume_up           ) in  hi IRQ

 gpio-501 (                    |volume_down         ) in  hi IRQ

 gpio-504 (                    |shutdown            ) out hi    

[ouija]

Found out today that this unit will also run kernel 4.18 as well without running into this blankscreen / i915 modeset issue that I get with other builds.

So, I tested out a custom build of Android-x86 8.1-r2 with kernel 4.18, and was able to export the gpio pin 368 without issue, however, the speaker output *still* doesn't work. (but headphones do)

I am having other odd issues with 4.18 as well, including battery charging indicator not working, and the IIO acellerometer sensor isn't working at all either.

I also noticed that this 4.18 kernel is loading the snd_hdmi_lpe_audio kernel module which wasn't loading properly in PhoenixOS 4.14, so I had to blacklist this (for now) to test your scripts.  I also tried setting gpio pin 367 (as this matched more with the pin offset as per https://github.com/danielotero/linux-on-hi10/issues/8) but the system would freeze up when doing this under kernel 4.18.

And in testing this, I also realized that I should have been trying to set pin 362 with Kernel 4.15, since it is supposed to be 22 steps away from the initial pin for kernel less than 4.16... If I get back to that lower version, I'll give that a shot.

I also tested kernel 4.14.24 with Android-x86 8.1-r2, but it causes a reboot on this device (finiky son of a bitch that it is).

I'll see if I can get these issues with 4.18 resolved and try and stick with it, else I be moving back to Phoenix soon enough.

[youling 257]

cat /sys/kernel/debug/gpio, if you see which one is "speaker-amp"; if no "speaker-amp", no idea, have to test >4.19 kernel.

Your device can't boot 4.19 kernel, you need try 5.1 kernel.

[ouija]

Okay... I'll try 5.1 next, 4.19 doesn't seem to boot.

Got PhoenixOS running again, and tried gpio pin 418 (which is what it should be for this kernel), but still no sound.

[ouija]

Finally got kernel 5.1 compiled (after fixing a ton of compile errors) but this unit won't boot with it. Seems it can only run up to kernel 4.18, tried a few versions of 4.19 with no success, but may try a few more, as I found out the Android-x86 4.14.24 kernel doesn't work on this device
But the PhoenixOS 4.14.15 does.

Also had too many issues with iio sensors not working properly with Android-x86 8.1r2, haven't tested 7.1 with one of these kernels but will tomorrow and see if maybe that is better, but Pheonix seems to be the most stable on this sucker so far... Just wish the kernel was open sourced.

Is there a possible DSDT edit that may fix the GPIO pin issue?

[ouija]

Alrighty... wasted a rainy day on this sucker again, and while I made some progress, I still don't have any sound output from the internal speakers.

It's definitly due to missing patches/additions to the rt5651 codec and driver, as youling 257 mentioned above (see related patches here: https://patchwork.kernel.org/project/alsa-devel/list/?submitter=582)

but unfortunatly, I cannot get this device to boot with any kernel later than 4.18, and all the patches have been added from 4.19 onwards. 

I did try to create a patch for my device similar to the one here: https://github.com/Orochimarufan/linux/commit/00bc6f7 to try and see if getting the gpio pin set this way would help in any way, and while I did manage to get it patched and showing in the kernel debug, as so:

-------------------------------------------------------------

gpiochip4: GPIOs 225-227, parent: platform/INT0002:00, INT0002 Virtual GPIO:

 gpio-227 (                    |ACPI:Event          ) in  lo IRQ

gpiochip3: GPIOs 228-313, parent: platform/INT33FF:03, INT33FF:03:

 gpio-307 (                    |spken               ) in  lo IRQ

 gpio-309 (                    |80860F14:03         ) in  hi IRQ

gpiochip2: GPIOs 314-340, parent: platform/INT33FF:02, INT33FF:02:

 gpio-322 (                    |power               ) in  hi IRQ

gpiochip1: GPIOs 341-413, parent: platform/INT33FF:01, INT33FF:01:

 gpio-344 (                    |ACPI:Event          ) in  hi IRQ

 gpio-366 (                    |ACPI:OpRegion       ) out lo    

 gpio-393 (                    |ACPI:OpRegion       ) out hi    

gpiochip0: GPIOs 414-511, parent: platform/INT33FF:00, INT33FF:00:

 gpio-492 (                    |volume_up           ) in  hi IRQ

 gpio-494 (                    |volume_down         ) in  hi IRQ

-------------------------------------------------------------

There still isn't any audio output from the speakers, however.   Not sure if I need a different alsa configuration or something to get this working

Here's a gist of the patch I created to achieve this: https://gist.github.com/ouija/1bb721ea4ea9092a507f4dd6bfce42e6

However, this didn't seem to help the sound output. This "spken " gpio pin should be the speaker, with the seond one being for headphone jack plugin detection I believe.

Headphones are still working.  I thought I almost had it here, but no go -- if anyone has any suggestions, I'm all ears :)

[youling 257]

now, gpio-307 ( |spken ) in lo IRQ, need change it to hi.

so, echo 307 > /sys/class/gpio/export, echo 1 > /sys/class/gpio/gpio307/value, it will be "gpio-307 ( |spken ) in hi IRQ".

在 2019年7月21日星期日 UTC+8下午5:34:39，ouija写道：

[ouija]

"If at first you don't succeed, try, try again."

I've FINALLY managed to get (terrible) sound out of the internal speaker on this unit (running kernel 4.16)!!!!!

What I did to achieve this was update that gist of mine that I based off of the code at https://github.com/Orochimarufan/linux/commit/00bc6f7 and reverse it to set the GPIO pin as hi instead of low, which took a little guesswork and luck to achieve (since I'm fairly new at all this, but not Linux in general, or hacking in code for that matter).

I even updated it so that it is now appearing as "speaker-amp" as well, just cause youling 257 originally said it should, so why not? hahaha.

Good news is that I now have sound coming from the internal speakers after running those two update scripts (bytcrrt5651.txt and speaker.txt)

Bad news is that it is super quiet, but I know that the alsa configuration can be modified to account for this  (Please share how to do this if you want to save me some time to figure it out on my own!)

Regardless, the damn thing is FINALLY WORKING!   Only took me over a week to achieve... uggh.. :)

Here's the update version of my gist, (which replaces the /kernel/sound/soc/codecs/rt5651.c file of a custom kernel 4.16 build): https://gist.github.com/ouija/1bb721ea4ea9092a507f4dd6bfce42e6

I'm going to attempt to make a revised version to support kernel 4.18 (as I'd like to be running the latest kernel I can on this unit) but there's some major difference with this codec file and 4.16, as well as a few other ACPI errors I need to address, but it also enables the Intel HDMI Audio support out of the box (however, this needs to be blacklisted I believe, in order to get the alsa to initialize to the internal speaker).

I'll keep updating this thread with my progress, and am just super happy to finally be making some!

Huge thanks to youling 257 for his help with getting me to this point!  I couldn't have done it without you.

[ouija]

UPDATE: After testing a bit further, it's not so much "quiet" as it is missing channels or something... some sounds appear to be loud, others not so much... it depends what is playing (I've just been using random YouTube videos for testing).

There's also a lot of "line noise" (white noise or hissing) that comes through randomly, and goes away.. but always there when sound is playing... Headphones sound good, with a little noise/hiss before audio plays

Also, since I didn't explicitly state it earlier, I'm now using Android-x86 8.1-r2 with Kernel 4.16, and I managed to fix the issues with the acelleromter sensors using the setprop ro.iio.accel.quirks no-trig method (haven't added to the init.sh file yet but will soon), which wasn't needed with earlier versions of Android.

Here's how the GPIO kernel debug now looks:

gpiochip4: GPIOs 225-227, parent: platform/INT0002:00, INT0002 Virtual GPIO:
 gpio-227 (                    |ACPI:Event          ) in  lo IRQ

gpiochip3: GPIOs 228-313, parent: platform/INT33FF:03, INT33FF:03:

 gpio-309 (                    |80860F14:03         ) in  hi IRQ

gpiochip2: GPIOs 314-340, parent: platform/INT33FF:02, INT33FF:02:
 gpio-322 (                    |power               ) in  hi IRQ

gpiochip1: GPIOs 341-413, parent: platform/INT33FF:01, INT33FF:01:

 gpio-341 (                    |speaker-amp         ) out hi   

 gpio-344 (                    |ACPI:Event          ) in  hi IRQ
 gpio-366 (                    |ACPI:OpRegion       ) out lo   
 gpio-393 (                    |ACPI:OpRegion       ) out hi   

gpiochip0: GPIOs 414-511, parent: platform/INT33FF:00, INT33FF:00:
 gpio-492 (                    |volume_up           ) in  hi IRQ
 gpio-494 (                    |volume_down         ) in  hi IRQ

I also believe that gpio-344 is the headphone jack detection, which I'm going to attempt to patch in as well..

[ouija]

UPDATE #2:  Sound is now working beautifully!!!

Apparently the reason the sound was so tinny/hollow was because it was using a stereo output, but this device only has a mono speaker, and running it as stereo causes all sorts of strange audio anomalies ---- so we need to utilize an alsa init for doing this;  I followed the MonoSpeaker.conf file I found here: https://fossies.org/linux/misc/alsa-lib-1.1.9.tar.bz2/alsa-lib-1.1.9/src/conf/ucm/codecs/rt5651/MonoSpeaker.conf?m=t and made another alsa amixer script for the "monospeaker" (attached) and running this after the initial bytcrrt5651 initialization fixes the internal speaker output and sound quality!

Now I just gotta tie into the GPIO event for the headphones and get it to automatically switch between the two outputs.   However, I believe with kernel 4.16, I'll need to patch jack detection into the 5651 module/codec, as I don't think it's in there.

I did get sound working with kernel 4.18 as well (which has the kernel jack detection), but this kernel appears to have issues with the battery status indicator not working properly [along with the ACPI Error: Invalid zero data length in transfer buffer (20180531/exfield-400) error on boot] , and the "+2" patch for the drivers/acpi/acpica/exfield.c file (found here: https://groups.google.com/d/msg/android-x86/PkYpy3Y-lPw/hLP4p41mAAAJ) causes the entire system to freeze at boot and doesn't even allow it to "Detect Android-x86" -- Not sure if maybe I need the "Dollar Cove" drivers for this as mentioned here: https://groups.google.com/d/msg/android-x86/jTkVo4lo-S4/wrUJXDd0BgAJ

I keep flip-flopping back and forth between 4.18 and 4.16 -- If I can't get this headphone jack detection working under 4.16, then I'll possibly try another attempt at fixing the battery status and ACPI error in 4.18.

I also got HDMI audio output working in both 4.18 and 4.16, where each were a little different from one another, in that 4.18 loads in the snd_hdmi_lpe_audio module automatically on boot, but 4.16 needs to modprobe it (and subsequently the card id changes between them)  There is is "aweful workaround" that you have to use here to get it to output properly: https://groups.google.com/d/msg/android-x86/ZmG-biOnNDI/tFe0ieiaz90J

On my device, I had to move /dev/snd/pcmC1D2p to /dev/snd/pcmC0D0p   (after moving the original /dev/snd/pcmC0D0p to /dev/snd/pcmC0D0p_orig)

I'll add this as an entry to init.h for my device eventually.

Making some great progress on this tablet, and excited to actually be using it for something!  (These past few weeks have been the most I've ever used it since I originally purchased it, because it's truly an awful Windows 10 machine, but it's turinng out to be a really nice, quick and responsive Android tablet instead!)

I'll keep posting back with my progress....

[ouija]

Back to using Kernel 4.18 now, realizing that I don't read things fully, I had the answer staring me in the face at this link: https://groups.google.com/forum/#!msg/android-x86/jTkVo4lo-S4/GpLUCedXBgAJ

There's this [1/6] ACPICA: Update for generic_serial_bus and attrib_raw_process_bytes protocol patch that needs to be reversed from the 4.18 kernel in order to get it to boot and remove the ACPI error that is occuring

This patch can be found here: https://patchwork.kernel.org/patch/10625187/

So now I'm in the process of getting 4.18 working with sound and input switching based on jack detection.

Note that I had to update the bytcrrt5651.txt, monospeaker.txt and headphone.txt files to work better with 4.18, since it loads the snd_intel_lpe_audio driver by default (and this subsequently becomes card0, so the scripts need to be updated to support the rt5651 on card1)

I also had to rewite this revised rt5651.c codec file with the speaker-amp GPIO insertion for 4.18;   I may actually create a patch file for this but for now there is an update gist at: https://gist.github.com/ouija/3fe49db8cd8809a392ce3ca628c28235

Slowly getting there! :)

[ouija]

UPDATE #3:  After several hours of debugging, I've finally managed to get kernel 4.18 running without issues on the Insignia Flex8 (NS-P08W7100)

The major issue with 4.18 is related around these ACPI changes referenced here: https://groups.google.com/forum/#!msg/android-x86/jTkVo4lo-S4/GpLUCedXBgAJ but instead of reverting the https://patchwork.kernel.org/patch/10625187/ patch, it's far better to apply ALL the patches in this series:

• [0/6] ACPICA version 20181003

• [1/6] ACPICA: Update for generic_serial_bus and attrib_raw_process_bytes protocol

• [2/6] ACPICA: Rename some of the Field Attribute defines
• [3/6] ACPICA: Update for field unit access
• [4/6] ACPICA: Split large interpreter file
• [5/6] ACPICA: Never run _REG on system_memory and system_IO

As well as applying this [4.20,regression,fix] ACPICA: Fix handling of buffer-size in acpi_ex_write_data_to_field() which is ultimately what will make 4.18 run on this device.

However, 4.18 has changes to the extcon (axp288) battery driver that seemed to have broken the charging indicator status.   This is what had been giving me the most grief with 4.18, and I thought the issue had something to do with this "+2" length patch that you'll come across in other posts (see: https://groups.google.com/forum/#!msg/android-x86/PkYpy3Y-lPw/hLP4p41mAAAJ) but this patch BREAKS 4.18 and should not be used (and rather use the above ACPICA patches above instead).

To fix the battery charging indicator, I figured out that it has something to do with this extcon: axp288: Set USB role where necessary patch that has been applied to the extcon driver in kernel 4.18;  Simply reverting the two affected files to the commits prior to this (and rebuilding kernel) fixed the battery status!

Here's quick links to the raw data for the files that need to be replaced:

kernel/drivers/extcon/Kconfig --> https://raw.githubusercontent.com/torvalds/linux/c698316661096e036b54448039b35e1c2c5809f0/drivers/extcon/Kconfig

kernel/drivers/extcon/extcon-axp288.c --> https://raw.githubusercontent.com/torvalds/linux/d82e233cee26ceacb9feb937a21bfb61b1826860/drivers/extcon/extcon-axp288.c

This fixes the last major issue I was having with 4.18, and now it's loading without any ACPI related errors on boot and making it past the 'Detecting Android-x86' screen without issue!

4.18 has a little better driver support that 4.16 does, and my primary reason for wanting to utilize it is because it has working 'input' detection for the bytcr-rt5651 sound card, and I've managed to write a script to tie into this event and have it automatically change the alsa_amixer settings to (mono) speaker or headphones on the fly, based on the headphone jack detection.

You can see a copy of this "jack-detect.sh" script here: https://gist.github.com/ouija/dfcea332abec753d53f012e62541c187 -- which I've added to the init.sh do_bootcomplete() function, specifically targeted for this device.   I also have added code here to apply the 'dirty fix' for HDMI audio, and I *might* need to update this jack-detect.sh script to monitor the hdmi input and re-init the audio when hdmi is disconnected (or I may have already done so!)

I'll create a github repo later with my custom kernel changes and notes for this device for my own documentation and for others to utilize in order to have Android-x86 running on their devices as well as it is on mine!

Super impressed with how well this sucker is working now, turning it from a once terrible, regrettable purchase into something actual useful and somewhat powerful!

[ouija]

UPDATE #4:   Managed to resolve issue with sleep on this device, which apparently only supports "suspend to idle" (or freeze power state) on cherrytrail / baytrail devices.

Essentially the problem is that the backlight of the screen remains on when the device is asleep, unless you set the power state to freeze (ie: echo freeze > sys/power/state)

I've seen people using Tasker to achieve a similar concept of applying this state when the system becomes idle, but I'd rather not rely on an app to do this but rather have a script running behind the scenes, so I wrote one, which you can find at https://gist.github.com/ouija/a1e5389172bd79c75977ae9671b639fc

You can add this to the init.sh script under the do_bootcomplete() function, with a case switch defined for your particular device, for example something like this:

case "$(cat $DMIPATH/uevent)" in

*NS-P08W7100*)

# Run headphone jack detection script

sh /etc/insignia/jack-detect.sh > /dev/null 2>&1 &

# Run sleep freeze state script

sh /etc/insignia/sleep.sh > /dev/null 2>&1 &

;;

esac

This script basically checks when the device is asleep, and if so, it sets the power state to freeze.   It does this ever 30 seconds, so the device doesn't immediately go into "freeze" mode when you press the power button to put it to sleep, which I found more user-friendly in that the device is a little slower to "wake" from a freeze state then the default state, so having a 30 second buffer is nice when you accidentally put the device to sleep or need to quickly wake it after doing so :)

Hope this is useful to others; I'm going to create a separate post just for this script so that it can be more easily found by anyone else looking to achieve something similar.

[ouija]

UPDATE #5:

Okay so I'm pretty much done with this device for now -- Managed to get most everything working fairly well, minus the cameras (ov2680 and ov5648) but all attempts at this have been feeble and gotten me nowhere.

Since I'm stuck at using 4.18, which also lacks support for the Intel(R) Imaging Signal Processor 2401, I did manage to get the ov2680 kernel module built and loaded, but that's about it -- no camera was detected, and that's when I learned that the ISP2401 is missing from the kernel, so I tried to build in support for it but failed miserably.   I'm not sure if I'll be able to get these functional (which I'm willing to live with for now) but as always, I'm open to suggestions!

Otherwise, everything else is running pretty good in this unit now!

I wrote another script to change the audio output based on HDMI input, which works well enough to change over to the HDMI output when a connection is detected, but sometimes fails to re-initialize back to the on-board card when disconnected (the volume mixer stops working and volume is MAX or nothing, until a reboot).   I also had to apply the following patches to fix an issue with the kernel that prevents Android/Linux from changing the status (/sys/class/drm/card0/card0-HDMI-A-2/status) of the HDMI connection properly on disconnect:

• drm/i915: Fix the HDMI hot plug disconnection failure (v2)
• drm/i915: delay hotplug scheduling

I'd like to formally ask Chih-Wei Huang to add this to the main 4.19 branch if possible, since I believe this issue still exists in 4.19 as well...

I also added a few more patches to fix certain issues that I came across:

• Power button event firing twice, causing device to go back to sleep after waking up (Seems to have been applied to kernel 4.19)
• Enabled Bluetooth for the rtl8723bs (Seems to have been applied to kernel 4.19)
• Wifi (rtl8723bs) signal strength fix (Seems to have been applied to kernel 4.19)
• Wifi (rtl8723bs) missing-return-for-cfg80211 (Seems to have been applied to kernel 4.19)
• Wifi (rtl8723bs) indicate disconnection when disconnecting patch (New and should likely be added to kernel 4.19?)
• drm-i915-Disable-preemption-and-sleeping-while-using-the-punit-sideband patch (prevents freezing issues related to cstates and the i915, see: https://bugzilla.kernel.org/show_bug.cgi?id=109051#c1000)
• Some additional battery (excon) related patches

I also added reboot=acpi and intel_idle.max_cstate=1 to further circumvent random freezups due to the c-state bug present in baytrail/cherrytrail devices.

With all of this and my little helper scripts, this unit is pretty damn function, and makes for a nice little unit -- rather than the dusty paperweight that it has been for the past two years!

I have created a repository for the Insignia Flex 8 with all of the kernel patches I currently have in place on this device, along with the additional helper scripts, firmware and changes that I've added to both init.sh and build.prop.  Basically everything I've done up until this point.

I'll add more detailed info to it hopefully soon, and maybe even a link to the system.img file that I've built so that others can just download and use this and save themselves countless hours of building and testing :)

Enjoy...