VDR Skin in FrameBuffer - Without X11 ?

    Yes, but I advise you to empty the function in the file "vnsi.c" like this :

    Code
    int cVnsiDevice::PlayAudio(const uchar *Data, int Length, uchar Id)
{
int ret = Length;

return ret;
}


    For the tests, it's a bit more complicated, you have to stop "Kodi" and "VDR" :

    Code
    systemctl stop kodi
systemctl stop service.multimedia.vdr-addon

    Then run manually to read debugging (see my VDR patch VDR Skin in FrameBuffer - Without X11 ? ) :

    Code
    /storage/.kodi/addons/service.multimedia.vdr-addon/bin/vdr.start

    Kodi side, you must use it on another box or computer, it will sometimes insist on the choice of the channel, because at times, the "Stream" changes, but "VDR" does not use the functions of playback audio/video.

    If you wish, I can make a video of the result...

    As you see, there is still work, and I planned to plan the month of July on, and August for the part "WebTV", we will see if it will be interesting to resume this part, when the project of addon will come out.

    I just finished successfully setting up QtWebEngine, everything is now functional, even the audio that was missing, I found where the problem came from, and resolved by disabling the support of pulseaudio, Alsa does work very well !

    However, I could not use the latest version, because it includes a chromium recent, which requires at least FFMPEG 3.4 for the support of codec AV1.

    Does anyone have release dates, concerning LibreELEC version with at least one FFMPEG 3.4 ?

    I currently use QtWebEngine 5.10.1, which requires a FFMPEG 3.3, but the compilation works with version 3.1 of Kodi.

    I have under YouTube an overrun of CPU that goes to 150%, but apparently, this is solved under the Falkon browser (I currently use my qtwebtvservice for web applications).

    Thank you for your feedback. ;)

    Yes I have seen, but I work on your Release stable, there is nothing planned for a future version 8.2.6 ? :)

    This will avoid me to redo a patch of Kodi 18, to add in its API, disabling the "CLinuxInputDevices", and other patches for compatibility with the /dev/fb1, I prefer to do when Kodi 18 will be in Stable.

    • Official Post
    Quote from CSylvain

    there is nothing planned for a future version 8.2.6

    No, there is nothing planed for the old stable - developement has shifted over two years ago to LE9 - due the VERY long dev phase of Kodi 18 we are late with an new release but nobody of us had touched 8.2 for ages. If you need something more recent use an LE9 pre Alpha/Alpha build (run "completely" at LE9 since an year).

    I see to integrate a full web browser, then I put online a test version.

    I will then follow the recommendations of CvH, to work on an environment V9.xx and to put especially the version 11 of Qt WebEngine, I do not think that I will need to modify my patches with each Alpha output of Kodi.

    I spent several hours putting Falkon, formerly QupZilla, and it's a horror, now you have to install a lot of modules of the KDE Framework, given the amount of lib that will load, it will saturate the boxes under ARM, so I start immediately the integration of otter-browser, the project looks promising, the developers are very active, to do something light, and looking like a web browser Opera.

    Screenshots : Otter Browser

    It was faster with otter-browser !

    Here are some screenshots under LibreELEC 8.2.5 Wetek Play 2 (Framebuffer OpenGL /dev/fb0) :

    20180802115551.png

    20180802120909.png

    Side deposit, I'm old school, I do not yet use offset "GIT", but a first share under "ZIP" : MEGA

    I'll share something cleaner by the end of the month, and in a new topic on the forum.

    For those who want to test, I prepare this in the week.

    Edited once, last by CSylvain (August 2, 2018 at 11:43 AM).

    • Official Post

    I'd ask that you solve the old-school problem sooner than later. Get code in a git repo so changes are under version control and the differences between your codebase and ours can be easily seen and understood. We will be quite happy to provide guidance and assistance, but only if we can comprehend how things work. Nobody will make the effort to review a collection of patch files in a mega share.

    Just trust in the folder which are new packages : packages/mediawebtv

    The package/addons/addon-depends, is only version updates, and the renaming of the .install_pkg folder for which it can not be installed in the image.

    The rest is only fixes for compilation under Ubuntu 18.04 LTS, so you can ignore. ;)

    • Official Post

    If you reach the point where you releasing something based on our codebase you have a GPL obligation to provide sources for your changes, and the easiest way to fulfil the obligation is pushing changes to an online repo, ideally github. If you want people to review work you need to make your work review-able. The easiest way of doing that is pushing changes to an online repo, ideally github. Spot the theme?

    Git can be tricky at first, but everyone started out as a novice user and everyone remembers that. If you need help to make the leap, ask.

    The result is unsatisfactory on the stability of the CPU, Qt WebEngine can not be stable on ARM boxes, I saw on forums, that the result is identical Raspberry Pi.

    Many are turning to a promising project called WPE (WPEWebKit), I'm looking at it, and currently testing the possibilities of making it work with Wayland, and especially Weston in OpenGL.

    Reflecting, I no longer need to patch Kodi (to switch the management of LinuxInputDevices), especially the Kernel, because it is Weston who will manage both windows with the support of opacity, and will guarantee complete compatibility with even PC processors.

    Looking at the buildroot 20180706, you need the driver version MALI r7p0, I tested it with Wetek Play 2 GXB_P200 in fb version, but it does not support it, even Kodi send me this error:

    Code
    ERROR in Mali driver:
* Device driver API mismatch
* Device driver API version: 800
* User space API version: 900
ERROR: Unable to create GUI. Exiting
corrupted size vs. prev_size
Aborted (core dumped)

    I think this is related to the Kernel.

    In short, I stop the support of Wetek Play 2, because I think that its processor will never be compatible with Wayland.

    I have a Raspberry Pi 3, so I will resume testing on it.

    EDIT :

    I found this patch, which makes me discover that I have not updated the GPU driver, maybe the error comes from there : GPU AML - mali update to r7p0 - Subtitles fix - improve AML rendering by wrxtasy · Pull Request #1 · CoreELEC/CoreELEC · GitHub

    I test you this tomorrow !

    Edited once, last by CSylvain (August 10, 2018 at 1:30 PM).

    • Official Post

    You need to look into the long-term technical direction that LE is taking with Kodi (and Kodi on Linux is adopting) and then use a mainline Amlogic kernel with a few patches (as changes are still working their way upstream) to have a proper DRM/KMS environment that will support GBM/V4L2 or GBM/Wayland. The code pieces for this are available and working today (not flawless, but useable). Qt also has GBM/V4L2 support written by one of our team members so that Plex (a Qt app) can use the same GBM/V4L2 environment for their embedded distro that is based upon LE's codebase. In the long-term (LE 10.0) Raspberry Pi will also switch to GBM/V4L2 using the open-source VC4 (V3D) drivers.

    The amlogic branch in my GitHub repo is rebased frequently but should give you a working mainline codebase to work from. If you compare that branch with the amlogic-meson-mali package in older 4.17 and 4.16 branches you can see how to build it with Wayland support; I dropped the Wayland dependency recently as Amlogic started shipping a GBM 'dummy' file (at my request) that doesn't require it in the latest buildroot.

    IMHO any major development needs to use the modern frameworks that are now in-place and your project will not have to reinvent the wheel when we drop support for older BSP kernels in the near future. All major work done against vendor BSP kernels is a wrong move.

    I understand your message, but I must take the direction of "WPE" for my project, and it works on a Wayland medium.

    But I think I can adapt to your future changes.

    I otherwise managed to launch it, it was the mali driver that was a problem, and which was to remain in version "r5p1".

    I am now in "r7p0", and it works very well, as well as the animation of the windows :

    20180811074739.png20180811074739.png

    I also launch Kodi, and it starts well, now I have to get the Wayland backend running, so that I can use it in API (flip windows!), Because it puts me a error :

    Code
    Error: Failed to connect to parent Wayland compositor: No such file or directory
display option: (none), WAYLAND_DISPLAY=wayland-0

    I think that is not looking at the right place : "/run/0-runtime-dir/wayland-0"

    But it starts well with the fbdev backend !

    EDIT :

    I have my answer here : 90562 – failed to create display when use "weston --backend=wayland-backend.so"

    Everything is perfect, I must leave it in "fbdev", as the very well done Amlogic in their buildroot :

    Code
    WAYLAND_DISPLAY=wayland-0 /usr/bin/weston --config=/storage/prj-lo
cal/etc/aml-weston.ini --backend=fbdev-backend.so --tty=1 --device=/dev/fb0 --
idle-time=0

    I go now to Kodi, because it runs basic "fbdev" for Amlogic, so I have to change some directives, or even attack some source code.

    To be continued !

    EDIT 2 :

    AMLogic, is the worst e-motional lift ! :

    Can not find this define EGL_PLATFORM_WAYLAND_EXT. ||

    Edited 2 times, last by CSylvain (August 11, 2018 at 10:29 AM).