Posts by stuartiannaylor

    I installed chromium on various platforms and used the chrome launcher, you may need to hack the files as likely if linux you will be running chromium and the cmd line will change.

    On the Raspberry Pi I have compiled Kodi 18.5 on arch linux installed chromium with the launcher and it works great.
    Problem is "vpdau-vc4" from memory isn't loaded so no "hardware acceleration" on the pi.

    On Kodi 19 Alpha which has compile commands for GL or GLES ffmeg-mmal on the Pi seems to work great.
    As does the x11 compile but the python bit of addons seems to need more work as the chromium launcher doesn't seem to work.

    I don't really find X11 bloated on a Pi4 and it works great on x86_64 if you make your own standalone service with a distro.
    Arch is so fast on an old 2nd gen I3 that you could make your own.
    Its just a shame the default build of Kodi misses some of the essential kodi system addons of libreelec such as bluetooth pairing and such like.
    But apart from that there is little difference.

    So to cut a long story short Kodi19 is looking like it will support chromium and presuming LE will add it.
    But also Chromium Ozone has just reached beta which means you can have a Chromium-gbm so that Kodi18 could also have.

    Stuck on that one as compling Kodi GBM/X11/Wayland is a doddle but struggling with Chromium ozone but will give it a try again.

    I have been using Kodi/Chromium/Droidmote so that I can use a phone as a system keyboard/mouse to use for Chromium.
    It makes a perfect settop box device where its a media machine with occasional browser use and its so good like that.

    I am thinking Chromium_Ozone_GBM could be now even though its only entered Beta but with x11 Kodi19 GL/GLES is available on X11.GBM/Wayland so maybe it wait till then.

    Slightly bemused as Kodi19 is great and seems to run hardware accelerated and Arch RaspPi4 is kernel 4.19 and bemused as thought it would have to be 5.2/5.3 (somewhere when much of the MESA stuff went in)

    Using a phone as a remote would be a great idea but also got Chrome running so rather than Kodo specific would like to use a 'userland' generic remote keyboard.

    Does anyone no if its possible to install droidmote, unified remote or any other to libreelec so that chromium will also work as Kore is great for kodi but would really like to get Chrome going.

    AMD_x86_64 9.2 and just wondering where to begin even if its hacking something together ?


    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 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 at master · LibreELEC/ · GitHub

    Has every common RTL device but the RTL8211F which is also common as used on the RockPro64.
    I just booted the new image 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