LE 9.0-devel for more Hardware (Gemini / Coffee / Cannon / Ice Lake, AMD Vega / Raven APU) and luks, lvm2, dm-raid

    Quote from sky42

    milhouse i am struggeling to rebuild your #0610b with kernel 4.17. That reset.sh applies both patches and after that it becomes tricky. For the live of it i could not figure out how to build it with all the packages updates, which are not in those patches. Probably i need to create a github account. I tried without.

    That package problem aside, i try to build just with libreelec.patch and project.patch. The first fail is i need a milhouse.buildcode, but that was easy fixable.

    The second one with a clean build

    I had the same problem as i first tried your 00_mesa1811_xorg120_combo.txt patch and then failed back to PR2739 to get Mesa 18.1.1.

    It was fresh checkt out and nothing else than reset.sh followed by make image was done.

    Ah yes... to actually build that repo (rather than just review the patches) you'll need my own custom build system which is mentioned here: Python not building

    milhouse.buildcode would be created by my build scripts.

    In addition to the patches my build system automatically updates the source tarballs of several packages (kodi, libcec, libnfs, pvr.* etc.) which you are most likely missing.

    With my build scripts if you wanted to recreate my build, you'd use "./totalbuild.sh -s x86-next" and that would Generic with the 4.17 kernel (pulling the latest PRs from github, so you're not always guaranteed a successful build!)

    The main configuration files are lepull.dat and ipatches.dat, with profiles (ie. x86-next) defined in profiles.dat.

    Quote from milhouse

    I enabled Frame Buffer Compression as in theory it should increase the effective memory bandwidth - have you had any problems with it?

    I do fear problems with unwilling hardware, as the quote says "check its availability on your hardware before enabling this option" and we dont know all hardware where it is running on. Just a precaution.

    Quote from sky42

    I do fear problems with unwilling hardware, as the quote says "check its availability on your hardware before enabling this option" and we dont know all hardware where it is running on. Just a precaution.

    Possibly a standard "here be dragons" warning with all new kernel features - I'd hope AMD DC would be able to identify when FBC isn't available in the GPU hardware and try not to use it (which would be the sane thing to do)... only one way to find out!

    KarstenL680

    The GLk HDMI patch in milhouse build #0611c should be automatic without the kernel parameter. The code for i915.glkhdmi=2 is not in the kernel. Please test removing the kenrel command and check if it is like before with my build and i915.glkhdmi=2. It should be. If it is not workin i have a idea what it could be and will find out how to fix it. The patch is written vor Intel Gemini Lake NUC and i hope it works with asrock too.

    My builds still need the command line parameter.

    I am trying at the moment to rebuild milhouse test build and put my changes on top of that.

    Semi ot

    23.98 refresh rate solution is only for Gemini architecture or for all Intel architecture ?

    I ask because me and many other users have this bug in combination with AVR

    Only solution set Kodi GUI at 30hz

    If I set 50, 59.94 or 60hz I get black screen switching back from 23.98

    This problem occurs on chromebox with broadwell and on braswell

    No, milhose build is not working on my Asrock J5005-ITX, sky42s build with commandline parameter was working fine so far.

    milhouse build is running fine on my AMD B350 Board qith Ryzen 2400G CPU

    Edited once, last by KarstenL680 (June 11, 2018 at 10:39 PM).

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    LibreELEC-Generic.x86_64-9.0-devel-20180610225948-df52423-kodi-5da94d1-4.17 on intel j5005

    That is a interessting and unexpected outcome, because the patch was explicitly for Gemini Lake NUC.

    milhouse

    The "final" GLK HDMI bugfix seems not to work at least not for porkchop999 and his box is the target of the patch. Probably using the one with command line parameter.

    Debug Log on a fresh install if its any help

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    milhouse

    The last 5 posts here 105887 – (ford) [GLK] no signal after switch resolution from [email protected] say that the final GLK HDMI bugfix is not that final and at the moment the way is to use the workaround with i915.glkhdmi=2 with one of the two patches in this post #44 i created from here ubuntu-4.15.0-23.25...4.15.0-23.25-glktesting and slightly changed for 4.16 (4.17 works too) and backported for 4.14. There is no harm in doing this, because it is off by default and you need to enable it as kernel parameter. Here in this thread are kind of confirmations that my 4.14 backport is working.

    Sadly no developer checked my backpot no answer in this thread GLK HDMI workarounds backport to 4.14 needs a review.

    Quote from milhouse

    New build #0612b, this includes the GLK workaround (enabled with i915.glkhdmi=2:(

    Tested on NUC7PJYH connected to a Samsung LED TV over Yamaha AVR. No signal on every boot, I have to switch off/on the TV to get a picture.

    After Kodi started, switching resolution seems to be ok so far.