Posts by stuartiannaylor

    Thanks for the update, it's nice to get some insights into what's happening internally.


    For those of us not familiar with GBM, V4L2, etc. Can someone up-level a bit as to what all this work will mean for users? For example, how would a Pi3 user benefit from these changes?

    It might allow a return to Chromium across all devices as will allow standalone mode via the Chromium GBM backend.
    Generic Buffer Management via Mesa on the RockPro64 is the first time I have seen OpenGLES work with the Rockpro64 dunno how it is for you Pi guys but for the RK3399 & RK3288 finally its seems to be optimised and its quick.

    The odd micro stutters that I had on the Rockpro64 on occasional media files seems to be completely fixed.
    Dunno why on my board the network settings are correct via DHCP but network still seems slow and problemtic via Nic.
    Interface again is blindingly fast as is boot.
    The scrobbling and display from IMDB now shows correct even if updates seem slow.

    CvH if I want to start playing with some builds are you checking out just the latest or can we clone and checkout your repo?

    For a RockPro64 is there a specific device or is it just as above but



    PROJECT=Rockchip DEVICE=RK3399 ARCH=arm UBOOT_SYSTEM=box-trn9 make image

    Whoops PROJECT=Rockchip DEVICE=RK3399 ARCH=arm UBOOT_SYSTEM=rockpro64 make image

    I mean

    Plus out of curiosity does ARCH=aarch64 work or make much difference?

    Don't have a Pi but a Pi clone using a RK3399 RockPro64 which I am hoping might be able to go back to using Chromium browser rather than Chrome.

    Chromium on PaspberryPi?

    Also just been using the latest great images supplied by CvH where for me its a first of any image to see the RockPro64 actually employ OPenGL ES which I guess paves the way for DRM/GBM... ?

    So if you manage to build the Ozone-GBM mentioned in the link above by CvH are we actually getting somewhere close to getting an ARM version of OpenElec running Chromium like a normal addon?

    Running Chromium with Ozone-GBM on a GNU/Linux desktop

    Apols not Pi but a RK3399 Pi clone RockPro64 we have the same probs especially now Chrome rather than Chromium seems to be the choice in the addons.

    I noticed that OPenGL ES (DRM/GBM) is now working in your latest Leia images for the RockPro64, so does this mean that in Leia we could see a return to Chromium.
    The RK3399 is directly supported in ChromiumOS via the gru builds used by the Samsung & Asus chromebooks so I am hoping so.

    CvH link from above Running Chromium with Ozone-GBM on a GNU/Linux desktop

    I guess its the utgard vs midgard architecture of Mali-450 vs Mali-T860 of RK3288 vs RK3399.

    I gave up on the RK3288 and jumped ships to the RK3399 but have been generally bemused as my rationale was the OP1 (RK3399 ChromeOS rebrand) surely should have much work done already via Samsung & Asus, like are the ChromeOS drivers closed source?.
    Surely the Mali-T860 Rockchip drivers should of been done and dusted a long time back and why the Mali-450 has been so painful and quite at odds with the roadmap Rockchip promoted.
    I guess there is some politics at work that I don't understand but how much work has been done by key individuals is amazing, but Rockchip!!! like wtf?

    The GPU architecture in the RK3288 & RK3399 is different so utgard still has huge problems midgard of the RK3399 is starting to look like it is nearing complete.
    With my real life files on the RK3399 on a limited sample maybe 20+ a few files did show a very slight stutter, that I wasn't sure if encoding or playback.

    I am unhappy to hear the utgard is still stalling and blame Rockchip but don't think the partnership with Intel did both chips any good.

    RK3288 & RK3399 architecture difference of utgard vs midgard are likely to show difference in driver compatibility.

    Using real world files on a RockPro64 can only test at 1080p but the full OPenGL ES driver running is the first one I have seen.
    All video seems to play without stutter, no probs at all.

    The playback and driver seems much better as first time the CPU seems to be hardly being touched on playback and also corresponds to heatsink temp also.

    The version of Kodi seems to not be complete but beta http://cvh.libreelec.tv/test/rk3399/ with the movie imdb scrobbler seems a bit wack but video wise the drivers seem solid.

    I think its that the RTL8211F still hasn't packaged drivers as if you have a look in

    LibreELEC.tv/packages/linux-drivers/ LibreELEC.tv/packages/linux-drivers at master · LibreELEC/LibreELEC.tv · GitHub


    Has every common RTL device but the RTL8211F which is also common as used on the RockPro64.
    I just booted the new image http://cvh.libreelec.tv/test/rk3399/ which is amazing as first time seen the Mali drivers run under OpenGL ES and wow this boots fast. Its still the 8.0-beta 1.0 and think I noticed the same with the RockPro64 the Nic worked but boy is it slow and maybe its the lack of a specific driver?

    Probs need this including as don't think they where in the kernel.
    Linux source code: drivers/net/phy/realtek.c (v4.6) - Bootlin

    Anyone compiled this for ArmHF / Arm64?

    Its hard to find a sub $30 SoC that isn't capable of running chromium just like the specs of old X86 running LibreElec.
    I am actually not bothered about netflix just that occasional need to use a browser in a reverse 20/80 means without libreelec is broken for me and forced to use Android.

    I actually love LibreElec with Chromium find it broken without.
    Are any of the dev's getting onboard with Chromium web browser - EsMaSol


    AlwinEsch (Alwin Esch) · GitHub

    Esch Media Solutions · GitHub

    https://bitbucket.org/chromiumembedded/cef/overview