Myy

Members
  • Content Count

    361
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Myy got a reaction from Igor in Architecture for adding additional desktop enviromnents, and application groups   
    Greetings,
     
    I'm currently modifying the Armbian build system, making it easier to add new desktop environments and application groups.
     
    This architecture is subject to heavy modifications until it is merged with the current Armbian build system.
     
    A repository with the modified build system is available here : https://github.com/Miouyouyou/armbian-desktop
     
    Currently, I only tested adding Ubuntu Focal + XFCE and application groups, since I had to make sure that
    the postinst and create_desktop_package.sh were actually aggregated correctly, now that they're split into multiple files,
    and, for comparison, we only have such scripts for XFCE.
     
    Also :
    the current list of packages for XFCE include unrelated packages (like neverball), added to test the packages files aggregation; there's a lot of debug messages added here and there, in order to have an overview of the current build state.  
    The actual packages list for other desktop environments and distributions, along with the scripts, still have to be added. (They're currently empty)
     
    That said, I'd like to have a few maintainers test (quickly) the new architecture, in order to check if there isn't any obvious feature missing.
     
     
    So, here's how to add a desktop environment with the new architecture :
     
    Adding a desktop environment
     
    Currently, only official repositories are supported.
     
    Let's say that you want to add that new desktop environment "superduperde", that is now available on official on Debian/Ubuntu repositories.
    First, focus on one specific distribution like focal (Ubuntu) or buster (Debian). In our example, will take focal.

    We'll create our first configuration 'full', which should provide the DE along with all its specific apps, widgets and the kitchen sink.
     
    Create the directory config/desktop/focal/environments/superduperde/config_full Create the file config/desktop/focal/environments/superduperde/config_full/packages Open the packages file, add the list of packages for apt.  
    Then select it in the configuration menu, or pass the following variables to ./compile.sh :
    BUILD_DESKTOP="yes" RELEASE="focal" DESKTOP_ENVIRONMENT="superduperde" DESKTOP_ENVIRONMENT_CONFIG_NAME="config_full"
    Then test the resulting image !
     
    Adding an appgroup
     
    Appgroups are roughly the same. Let's say that you want to add remotecontrol to the appgroups for Ubuntu focal :
     
    Create the directory config/desktop/focal/appgroups/remotecontrol Create the file config/desktop/focal/appgroups/remotecontrol/packages Open the packages file, add the list of packages for apt.  
    Tale a look at https://github.com/Miouyouyou/armbian-desktop#the-architecture-added-to-the-build-system, for a more detailed documentation of the new architecture, and how to add special packages files for specific boards, and desktop configurations, along with specific debian/postinst and armbian/create_desktop_packages.sh files.
     
     
    What needs to be quickly tested :
     
    Modifying an existing desktop environment (gnome, kde, ...). Adding a new desktop environment or window manager (mate-desktop, i3, fluxbox, ...) Adding a new appgroup Bonus points for adding a desktop environment with Wayland support (but remember that default installations come with terrible OpenGL support on most boards !)  
     
     
  2. Like
    Myy got a reaction from lanefu in Architecture for adding additional desktop enviromnents, and application groups   
    Greetings,
     
    I'm currently modifying the Armbian build system, making it easier to add new desktop environments and application groups.
     
    This architecture is subject to heavy modifications until it is merged with the current Armbian build system.
     
    A repository with the modified build system is available here : https://github.com/Miouyouyou/armbian-desktop
     
    Currently, I only tested adding Ubuntu Focal + XFCE and application groups, since I had to make sure that
    the postinst and create_desktop_package.sh were actually aggregated correctly, now that they're split into multiple files,
    and, for comparison, we only have such scripts for XFCE.
     
    Also :
    the current list of packages for XFCE include unrelated packages (like neverball), added to test the packages files aggregation; there's a lot of debug messages added here and there, in order to have an overview of the current build state.  
    The actual packages list for other desktop environments and distributions, along with the scripts, still have to be added. (They're currently empty)
     
    That said, I'd like to have a few maintainers test (quickly) the new architecture, in order to check if there isn't any obvious feature missing.
     
     
    So, here's how to add a desktop environment with the new architecture :
     
    Adding a desktop environment
     
    Currently, only official repositories are supported.
     
    Let's say that you want to add that new desktop environment "superduperde", that is now available on official on Debian/Ubuntu repositories.
    First, focus on one specific distribution like focal (Ubuntu) or buster (Debian). In our example, will take focal.

    We'll create our first configuration 'full', which should provide the DE along with all its specific apps, widgets and the kitchen sink.
     
    Create the directory config/desktop/focal/environments/superduperde/config_full Create the file config/desktop/focal/environments/superduperde/config_full/packages Open the packages file, add the list of packages for apt.  
    Then select it in the configuration menu, or pass the following variables to ./compile.sh :
    BUILD_DESKTOP="yes" RELEASE="focal" DESKTOP_ENVIRONMENT="superduperde" DESKTOP_ENVIRONMENT_CONFIG_NAME="config_full"
    Then test the resulting image !
     
    Adding an appgroup
     
    Appgroups are roughly the same. Let's say that you want to add remotecontrol to the appgroups for Ubuntu focal :
     
    Create the directory config/desktop/focal/appgroups/remotecontrol Create the file config/desktop/focal/appgroups/remotecontrol/packages Open the packages file, add the list of packages for apt.  
    Tale a look at https://github.com/Miouyouyou/armbian-desktop#the-architecture-added-to-the-build-system, for a more detailed documentation of the new architecture, and how to add special packages files for specific boards, and desktop configurations, along with specific debian/postinst and armbian/create_desktop_packages.sh files.
     
     
    What needs to be quickly tested :
     
    Modifying an existing desktop environment (gnome, kde, ...). Adding a new desktop environment or window manager (mate-desktop, i3, fluxbox, ...) Adding a new appgroup Bonus points for adding a desktop environment with Wayland support (but remember that default installations come with terrible OpenGL support on most boards !)  
     
     
  3. Like
    Myy got a reaction from Werner in Architecture for adding additional desktop enviromnents, and application groups   
    Greetings,
     
    I'm currently modifying the Armbian build system, making it easier to add new desktop environments and application groups.
     
    This architecture is subject to heavy modifications until it is merged with the current Armbian build system.
     
    A repository with the modified build system is available here : https://github.com/Miouyouyou/armbian-desktop
     
    Currently, I only tested adding Ubuntu Focal + XFCE and application groups, since I had to make sure that
    the postinst and create_desktop_package.sh were actually aggregated correctly, now that they're split into multiple files,
    and, for comparison, we only have such scripts for XFCE.
     
    Also :
    the current list of packages for XFCE include unrelated packages (like neverball), added to test the packages files aggregation; there's a lot of debug messages added here and there, in order to have an overview of the current build state.  
    The actual packages list for other desktop environments and distributions, along with the scripts, still have to be added. (They're currently empty)
     
    That said, I'd like to have a few maintainers test (quickly) the new architecture, in order to check if there isn't any obvious feature missing.
     
     
    So, here's how to add a desktop environment with the new architecture :
     
    Adding a desktop environment
     
    Currently, only official repositories are supported.
     
    Let's say that you want to add that new desktop environment "superduperde", that is now available on official on Debian/Ubuntu repositories.
    First, focus on one specific distribution like focal (Ubuntu) or buster (Debian). In our example, will take focal.

    We'll create our first configuration 'full', which should provide the DE along with all its specific apps, widgets and the kitchen sink.
     
    Create the directory config/desktop/focal/environments/superduperde/config_full Create the file config/desktop/focal/environments/superduperde/config_full/packages Open the packages file, add the list of packages for apt.  
    Then select it in the configuration menu, or pass the following variables to ./compile.sh :
    BUILD_DESKTOP="yes" RELEASE="focal" DESKTOP_ENVIRONMENT="superduperde" DESKTOP_ENVIRONMENT_CONFIG_NAME="config_full"
    Then test the resulting image !
     
    Adding an appgroup
     
    Appgroups are roughly the same. Let's say that you want to add remotecontrol to the appgroups for Ubuntu focal :
     
    Create the directory config/desktop/focal/appgroups/remotecontrol Create the file config/desktop/focal/appgroups/remotecontrol/packages Open the packages file, add the list of packages for apt.  
    Tale a look at https://github.com/Miouyouyou/armbian-desktop#the-architecture-added-to-the-build-system, for a more detailed documentation of the new architecture, and how to add special packages files for specific boards, and desktop configurations, along with specific debian/postinst and armbian/create_desktop_packages.sh files.
     
     
    What needs to be quickly tested :
     
    Modifying an existing desktop environment (gnome, kde, ...). Adding a new desktop environment or window manager (mate-desktop, i3, fluxbox, ...) Adding a new appgroup Bonus points for adding a desktop environment with Wayland support (but remember that default installations come with terrible OpenGL support on most boards !)  
     
     
  4. Like
    Myy reacted to Werner in Armbian v20.11 (Tamandua) Planning Thread   
    Release Candidate Code Freeze Date: 2020-10-18 
    Release Date: 2020-11-XX 
    Release Candidate Branch Link: TBD
    Release Changelog: TBD
    Release Coordinator: TBD
    Testing Tracking Sheet: TBD (google sheets)
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. Once the release is complete, this thread should be locked and unpinned.
    ---
     
    Our next release date is coming and perhaps its time to discuss what to push into 20.11, what not, resolve open questions and distract from most used keyword for past few weeks.
     
     
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000@ebin-dev @Heisath@chwe@ning@lanefu@gprovost@aprayoga@5kft
    @JMCC@karabek@Igor@martinayotte@tkaiser@selfbg@Siraj@jock@going ... (please mention whoever is missed)

    Meeting on IRC in Saturday, October 3rd, at 2 pm GMT is being prepared - this is reasonable good timing for US / EU folks.
     
    Agenda:
     
    check meeting attendees (if nick is not self explanatory, add your forum/Github handle. Just say hi or something) present tasks, bugs or project you are working on (open discussion if there will not be much people, otherwise meeting officer call people out). Jira should be open in not already. cycle Jira backlog: discuss task / bug (one at a time) assign to person / release / tag re-prioritise cycle open issues and PR on build engine board status update on download pages and build engine (wip, supported, eol) choosing upcoming release officer (so far it was Igor and Lane) misc / open discussion
    Tips:
    when you got a voice, be concise (1-2 min) and make it clear when you stop. ("No more, I'm done") channel is recorded so a summary and adjustments to Jira can made afterwards, ideally along with the meeting Meeting location is IRC channel #armbian on Freenode. (previous session as an example)  
    Ideally it would be that prior to this meeting we all update tasks/project statuses in Jira - who still does not have access shall PM to @lanefu or @Igor - reviewing, prioritising and releasing goes faster this way.
  5. Like
    Myy reacted to ejolson in Rock64 Focal Fossa Memory Frequency   
    Here is a performance comparison between the original 786MHz memory clock and the reduced 333MHz clock when running John McCalpin's stream memory bandwidth benchmark.
     


    The performance reduction for the scale operation was measured to be about 2.26 times which is slightly less than the expected 786/333=2.36 factor loss expected by just dividing out the clocks.
    In real world applications much of this performance reduction might be mitigated by cache memory; however, it would seem having a 600MHz setting might be a better compromise between super slow and super unstable.
     
    At any rate, I'll be performing some stress tests over the next few days to determine whether the system is really stable now.  For reference, I also have a thread running on the Pine64 forum
     
    https://forum.pine64.org/showthread.php?tid=11209&pid=76363#pid76363
     
    and will update both as resolved as soon as I verify the system is now stable.
  6. Like
    Myy reacted to axzxc1236 in Logout leads to black screen and lightdm-gtk-greeter eats a whole CPU core (Tinkerboard S, Focal Desktop)   
    so......... about my previous setup.
    AN UPDATE BROKE IT
    That forced me to scramble with my Tinkerboard system this whole day, a lot of system re-flash happened.
    And I finally figured out what broked it.
     
    Good news is that I am able to get xrdp+xfce working now, and no lightdm-gtk-greeter cpu problem.
     
    The new instruction are:
    1. Download Armbian_20.05.1_Tinkerboard_focal_current_5.4.43_desktop.img.xz
        (Now I think about it you might be also make xrdp work in the newer image with slightly different instruction, but that (5.4.43) is the version of image I am having success with, so I recommend who ever doing this also use the same version)
        (I am not going to re-flash my system with newer version of image to just test it, so I recommend you stick with 5.4.43 version)
    2. Flash it to your Tinkerboard (S)
    3. Boot it and complete basic configuration (create an account)
    4. Install/Enable xrdp from `sudo armbian-config`
    5. Reboot and try to connect to Tinkerboard, RDP should work at this moment. (Or I might be missing important details after the whole afternoon's testing, I am sorry if that's the case)
    6. do `sudo apt update`
    7. do `sudo apt install linux-focal-root-current-tinkerboard=20.05.2`
    8. do `sudo apt-mark hold linux-focal-root-current-tinkerboard` (that package will break xrdp somehow in 20.08.1 version (DON'T ask me why, I don't know, this is the package that I isolated the issue to), this command will block all future upgrade to this package)
    9. do `sudo apt install sddm` (change your display manager to sddm!!)
    10. reboot just in case
    11. test your RDP connection, it should work
    12. do `sudo apt upgrade` to upgrade rest of the system.
  7. Like
    Myy reacted to elpokoloko in Teamviewer-host fb0 shows only after connecting monitor.   
    Thanks for the response. @Myy
     
    For anyone following this thread and who is looking for quick fix for TeamViewer. I managed to resolve it with $3 Dummy HDMI plug. 
     
    I will look into your suggestions as I think there should be better way than use dummy plug.
     
    Thanks again for your time.
     
    P.S.: Is the CONFIG_FB_VIRTUAL=y suppose to go to boot.cmd/armbianEnv.txt or I just need to follow this guide. Sry for stupid question.
     
  8. Like
    Myy got a reaction from elpokoloko in Teamviewer-host fb0 shows only after connecting monitor.   
    I guess that you could always try to recompile your kernel and enable the "Virtual Framebuffer" driver ( CONFIG_FB_VIRTUAL=y ) and see how it goes.
    This should create a virtual /dev/fbX node... If you don't plug your monitor on startup, this one should be /dev/fb0 . Else, you'll have to play with udev to either force vfb to /dev/fb0 or the rockchip driver to /dev/fb1.
     
     
  9. Like
    Myy got a reaction from NicoD in panfrost on RK3288 and GPU on 600MHz problems   
    Here's the (very late) pull request : https://github.com/armbian/build/pull/2149
  10. Like
    Myy got a reaction from NicoD in panfrost on RK3288 and GPU on 600MHz problems   
    Thanks for testing ! I guess we can include this patch in the next release, then.
  11. Like
    Myy got a reaction from Werner in Wifi AP kernel bug in kernel 5.4.44   
    I'm trying to understand the issue, but it seems rather bizarre.
     
    Basically, when freeing the station_info structure in nl80211_send_station, kfree is called with a somewhat valid pointer, but then kfree (SLUB version) trips when calling PageCompound on the page of the provided pointer.
     
    My best bet is that the structure isn't initialized correctly, leading some fields to be initialized with garbage values. However, it seems strange that everything goes without any bug until that specific point.
     
     
     
  12. Like
    Myy got a reaction from Werner in Wifi AP kernel bug in kernel 5.4.44   
    Ok, that clearly seems to be a badly initialized structure issue. Changing struct station_info sinfo; by struct station_info sinfo = {0}; in drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c : rtw_cfg80211_indicate_sta_assoc remove the BUG calls on a client connection.
    Now, I'll have to test it in a real environment, to check if the Wifi connection works and is stable.
     
    I'll post a clean patch tomorrow.
  13. Like
    Myy reacted to NicoD in [Development] RK3399 media script   
  14. Like
    Myy got a reaction from Tido in panfrost on RK3288 and GPU on 600MHz problems   
    Thanks for testing ! I guess we can include this patch in the next release, then.
  15. Like
    Myy got a reaction from Tido in panfrost on RK3288 and GPU on 600MHz problems   
    Sooo, I tried to fix the issue, using a 5.8-rc3 kernel... While the frequencies are back, there's some heavy glitches with Panfrost drivers and I don't know if that's due to kernel changes (entirely plausible) or if that's due to the patch.
    I'll try test a 5.8-rc3 kernel without this patch, just to check who's the culprit.
     
    Meanwhile, here's a patch that brings 500Mhz frequencies back for Mali GPU on RK3288 boards : https://gist.github.com/Miouyouyou/0dad9c4a321349166bbc9d49ffec315a
    From 73258d32daf3a661281bb5c77c5e2e06c7ff714e Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Fri, 3 Jul 2020 02:02:18 +0200 Subject: [PATCH] arm: dtsi: rk3288: add GPU 500 Mhz OPP again Undoing the very bizarre mainline kernel patch, 75481833c6dbab4c29d15452f6b4337c16f5407b which main purpose is to sync some 3.14 kernels hacks to mainline kernels, for reasons that only matter for a few Chromebooks, and shove it down the throat of every RK3288 user. If you need to avoid the GPU going to 500 Mhz on Chromebooks, remove the OPP entry inside the DTS that actually matters to RK3288 Chromebooks. Meanwhile, the 600 Mhz operating point can prove to be unstable on some RK3288 boards, while 500 Mhz works fine. https://forum.armbian.com/topic/13515-panfrost-on-rk3288-and-gpu-on-600mhz-problems/ Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- arch/arm/boot/dts/rk3288.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index a66412547..ef7457f79 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -1312,6 +1312,10 @@ opp-400000000 { opp-hz = /bits/ 64 <400000000>; opp-microvolt = <1100000>; }; + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1200000>; + }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <1250000>; -- 2.27.0  
  16. Like
    Myy got a reaction from Werner in panfrost on RK3288 and GPU on 600MHz problems   
    Thanks for testing ! I guess we can include this patch in the next release, then.
  17. Like
    Myy reacted to jock in panfrost on RK3288 and GPU on 600MHz problems   
    Applied the patch, left the rk3288 with 5 hours of this:
     
    it worked without an itch, dmesg was clean.
  18. Like
    Myy got a reaction from NicoD in panfrost on RK3288 and GPU on 600MHz problems   
    Sooo, I tried to fix the issue, using a 5.8-rc3 kernel... While the frequencies are back, there's some heavy glitches with Panfrost drivers and I don't know if that's due to kernel changes (entirely plausible) or if that's due to the patch.
    I'll try test a 5.8-rc3 kernel without this patch, just to check who's the culprit.
     
    Meanwhile, here's a patch that brings 500Mhz frequencies back for Mali GPU on RK3288 boards : https://gist.github.com/Miouyouyou/0dad9c4a321349166bbc9d49ffec315a
    From 73258d32daf3a661281bb5c77c5e2e06c7ff714e Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Fri, 3 Jul 2020 02:02:18 +0200 Subject: [PATCH] arm: dtsi: rk3288: add GPU 500 Mhz OPP again Undoing the very bizarre mainline kernel patch, 75481833c6dbab4c29d15452f6b4337c16f5407b which main purpose is to sync some 3.14 kernels hacks to mainline kernels, for reasons that only matter for a few Chromebooks, and shove it down the throat of every RK3288 user. If you need to avoid the GPU going to 500 Mhz on Chromebooks, remove the OPP entry inside the DTS that actually matters to RK3288 Chromebooks. Meanwhile, the 600 Mhz operating point can prove to be unstable on some RK3288 boards, while 500 Mhz works fine. https://forum.armbian.com/topic/13515-panfrost-on-rk3288-and-gpu-on-600mhz-problems/ Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- arch/arm/boot/dts/rk3288.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index a66412547..ef7457f79 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -1312,6 +1312,10 @@ opp-400000000 { opp-hz = /bits/ 64 <400000000>; opp-microvolt = <1100000>; }; + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1200000>; + }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <1250000>; -- 2.27.0  
  19. Like
    Myy reacted to TonyMac32 in panfrost on RK3288 and GPU on 600MHz problems   
    https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm/boot/dts/rk3288cg-opp.dtsi
     
    is the vendor opps for the rk3288-C (Tinker/chromebook version)
     
    If it isn't a "C", then it wouldn't have 600 MHz Mali or faster than 1.6 GHz CPU according to Rockchip (I don't know about the "W")
     
    @Myy  Wow, that patch is garbage, I didn't even notice that.  It's worse than you are summarizing:
     
    "NPLL is necessary for 500 MHz, ancient krusty kernel suxors and doesn't have this OPP, so in case someone hypothetically someday maybe in theory thinks about possibly re-purposing the NPLL like the ancient kernel did, make mainline suck too for everyone."
     
    Yikes.
     
    I don't see any reason to not reintroduce that OPP for Armbian use, as far as I know this purely hypothetical situation has not taken place.
  20. Like
    Myy reacted to Werner in Patchfolder cleanup helper   
    The output for target files which are affected by multiple patches is now better.

  21. Like
    Myy got a reaction from Werner in Patchfolder cleanup helper   
    Interesting approach.
     
    I'd just like to mention that factorizing is required, if the patches apply to the same file AND the same blocks (functions, DTS, ...).
     
    If you create THAT big patch that add 50 entries to a single DTS file, and the mainline DTS file gets updated with the addition of, like, 3 entries out of the 50, then you won't be able to apply your big patch AND you'll need to rework it.
    Since you won't be able to apply it again, you can either pray that 3-way merging works, or you'll have to do a copy-paste of every missing entry from the patch, back to the DTS file AND regenerate a patch from there.
     
    Now, if you got 5 patches affecting "that same function" or "that same DTS block", then yes, merging is required.
     
    Anyway, this tool should greatly help in reducing the number of patches. Just don't do a blind factorization, it will back-fire very quickly.
  22. Like
    Myy reacted to Werner in Patchfolder cleanup helper   
    Ever since patchfolders were created for different branches and different board families it has become more and more a nightmare to maintain these folders and keep them clean.
     
    Instead of taking the approach to clear one or more of these folders by myself, last but not least due to lack of necessary skills, I was thinking maybe I can provide some tools that make such tasks a little easier for somebody else.
    Last but not least was (and still is) this a perfect opportunity to pratice with my quite new Python skills.
     
    https://github.com/EvilOlaf/refactorpatches
     
    What this script basically does is break down all patches in a certain folder and check which files are targeted by each individual diff (if you choose to split them up) and sort the output by the target file.
    This way it should be an easy thing to merge patches that affect the same file and therefore it is no longer necessary to take care about the order to apply them.
     
    Requirements from apt: patchutils, python3
    Requirements from Pypi: none but just make sure the prettytable.py is in the same folder as main refactor.py.
     
    I have tested this with random patch folders for kernel patches and for what it is expected to do at the current state it seems to just work as it should.
    There is still a ton of room for improvements.
     
    Let me know what do you think or if it is useful at all. Even if it is not I had fun coding and using Python
     

  23. Like
    Myy reacted to Kwiboo in Mainline VPU   
    No problems! :-)
     
     
    I can recommend you to look at https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-work-in-progress that is the branch that will continue to see updates as I prepare ongoing work for upstream.
    With this updated branch (work rebased on top of media_tree master) and latest 4.2.2-rkvdec ffmpeg branch vp9, h264 (high 10 and high 422) and hevc (main 10) should be usable.
    There is still one bit not properly being configured for hevc so there are some videos that produce small artifacts while decoding.
     
    Hoping to have initial patchset with focus on rkvdec fixes and rkvdec/hantro support for h264 interlaced/field encoded on media mailing list before the weekend is over :-)
  24. Like
    Myy got a reaction from Werner in No HDMI signal on Tinkerboard Samsung TV   
    This might be due to the lack of some YUV configurations support in the Rockchip DRM drivers used in mainline kernels.
    I'll try some new HDMI patches next week, against mainline kernels, see if that resolve these kind of situations.
  25. Like
    Myy got a reaction from aaditya in Mainline VPU   
    Same thing here.
     
    As always, I think it will come down to :
     
    Generating a H264 sample frame Looking at the documentation about how to send this to the driver Get the result  
    But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
     
    If that's still the case with the 5.7, I'll try to build a test framework.
     
    Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
    As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
    And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
     
    I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.