Asus PN50 challenge

  • Do you expect that the audio passthrough issues on Intel (e.g. NUC11PAHi)

    The audio passthrough issue has been reported to Intel driver people but no one's in a hurry to fix it.

    May I ask you which machine you own yourself or plan to purchase?

    I own an Asrock J4105B-ITX (Gemini Lake) board. I plan to upgrade it at some point to a Tiger Lake based mini-ITX board (most likely Celeron 6305 or Pentium Gold 7505) when they are available.

  • Current work-in-progress HDR code from lrusak's git repo (which I use for my LE builds) does not work on AMD. No idea when or if it will ever work.


    But the biggest concern should be AMD's linux GPU driver quality, which is kinda crap. I encountered some nasty issues when testing LE on Athlon 200GE APU with Vega graphics.


    The audio passthrough issues on Intel are nothing compared to general crappiness of AMD drivers.

    You are using the wrong branch :) I've used HDR on my AMD vega-m. It's very much WIP though. AMD drivers also don't expose the colorimetry property yet so there is no way to flag bt2020 to the monitor (this is apparently going to be implemented this year though).


    Also, the AMD drivers (IMO) are some of the best.

  • You are using the wrong branch

    I used this one. Is it the right one? HDR worked on Gemini Lake and (reportedly) on Tiger Lake. Didn't work on Athlon 200GE.

    Also, the AMD drivers (IMO) are some of the best.

    Ok, but I can make a list of weird issues that are exclusive to AMD and not present on Intel.


    Like this issue for example which I reported to AMD almost a year ago and it is still not fixed.

  • Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.

    the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.

  • Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.

    Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC's like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC's. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up.


    the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.

    Agreed. Its old enough that its price is a great value these days compared to newer NUCs. I have a ODROID H2+ which is very similar. I just can't use it d/t the audio issue for now.

    Edited 2 times, last by pletopia: Merged a post created by pletopia into this post. ().

  • Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC's like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC's. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up

    I just see a bit more benefit these days upgrading back end hardware (network, NAS etc) rather than trying to load up everything on a front end device, as an example look at how well the Netflix app works on your average Smart TV, there's not a lot of front end processing power required, because all the heavy lifting is done at the back end.


    I still like Kodi, it's great for what it is don't get me wrong, but there's a lot of other UI's out there that get by just fine on potato SoC's too, and running x86 as a HTPC has always felt like too much overkill to me.

  • Well I had some time to work on the PN50 today.
    I got stuck trying to setup my ir remote.

    ir-keytable returns No devices found

    and in dmesg it shows

    Code
    [ 3.338380] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [ 3.338382] ite_cir: Using model: ITE8708 CIR transceiver
    [ 3.338385] ite-cir 00:02: IR PNP Port not valid!


    Using LibreELEC (community): nightly-20210313-c5d7822


    Any ideas?


    PS Just saw 10.0 Beta 1 has been released. dmesg output is the same

    Edited 2 times, last by beredim ().

  • I know my answer is not what you have asked for: But have you ever considered using a Flirc?

    In case you don‘t know what a Flirc is:

    A Flirc is a small USB plug which translates signals from any IR remote into keyboard presses. Makes it pretty easy to create a working keyboard.xml and the best is you don‘t have to hassle with ir-keytables. ;)

  • I have also tried following the same methodology described in
    📡 Getting the Fintek IR receiver to work with Linux | @GregNau – Apps and Blog

    &

    Getting the IR receiver to work with Haswell NUCs - The NUC Blog

    So for the PN50 I figure the commands should be:

    Code
    modprobe -r ite-cir
    echo "auto" > "/sys/bus/acpi/devices/ITE8708:00/physical_node/resources"
    modprobe ite-cir

    After this, dmesg output remains the same:

    Code
    [  997.359200] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [  997.359203] ite_cir: Using model: ITE8708 CIR transceiver
    [  997.359207] ite-cir 00:02: IR PNP Port not valid!

    and ir-keytable still returns No devices found.

    1. There is one more direction to look at, that is this mail thread I found, regarding the PN50 specifically:

    ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
    Sadly, this mail thread never resolved to something, as far as I can tell. I am not sure, but I think it indicates the cir module in the PN50 is somewhat different than what the driver expects.


    2. The /sys/bus/acpi/devices/ITE8708:00/physical_node/resources has the following contents:

    Code
    state = active
    io 0x280-0x28f
    irq 10
    dma disabled

    However, /proc/interrupts doesn't show IRQ 10 as being used:

    Code
    pn50:~ # cat /proc/interrupts
                CPU0       CPU1       CPU2       CPU3
       0:         38          0          0          0  IR-IO-APIC    2-edge      timer
       8:          0          0          1          0  IR-IO-APIC    8-edge      rtc0
       9:          0          1          0          0  IR-IO-APIC    9-fasteoi   acpi
      11:          0          0          0          0  IR-IO-APIC   11-edge      AMDI0010:01
      25:          0          0          0          0   PCI-MSI 4096-edge      AMD-Vi
      26:          0          0          0          0  IR-PCI-MSI 20480-edge      PCIe PME
      27:          0          0          0          0  IR-PCI-MSI 34816-edge      PCIe PME
      28:          0          0          0          0  IR-PCI-MSI 36864-edge      PCIe PME

    Edited once, last by beredim ().

  • Success

    Code
    [    4.677490] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [    4.677492] ite_cir: Using model: ITE8708 CIR transceiver
    [    4.677492] ite_cir: TX-capable: 1
    [    4.677493] ite_cir: Sample period (ns): 8680
    [    4.677493] ite_cir: TX carrier frequency (Hz): 38000
    [    4.677494] ite_cir: TX duty cycle (%): 33
    [    4.677494] ite_cir: RX low carrier frequency (Hz): 0
    [    4.677494] ite_cir: RX high carrier frequency (Hz): 0
    [    4.758949] rc rc0: lirc_dev: driver ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter
    [    4.759098] ite_cir: driver has been successfully loaded


    I am attaching the kernel patch I made
    linux-9999-pn50.patch.txt


    It was that email thread I posted earlier
    ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
    where the answer was hiding, but it took a lot of effort from my part.
    First time building LibreELEC, first time writing a patch and so on.

    ir-keytable now works correctly :D

    I'll need some help pushing this, at least as a patch to libreelec project, and possibly to the linux drivers. Can anyone help with this? pinging chewitt

    As far as I can tell after digging through dozens of forums/posts/reddits this is the first publicly documented instance of the IR module in the PN50 actually working

  • If you'd like to learn sending something upstream I'm always happy to coach on the process - it's not that hard and we can review to spot the normal ettiquette mistakes before you send the patch. If not, I'd deferr to HiassofT who will understand what the change does - I don't code :)

  • I was thinking of a double approach:


    1. Do a pull request on the LibreELEC github, with the above patch, so that it hopefuly becomes a part of the future stable LE 10.0

    That way I can soon go back to using nightlies to further test the PN50 (at least until the next beta), instead of having to compile my own builds.


    2. In addition, try to push this upstream to the appropriate linux mailing list, so that it becomes a part of the kernel drivers at some point, and possibly also backported (if that's an option). I'm not really sure how long that's going to take.

    So for 1 I guess I'll do a PR on github. Does that sound good?

    And for 2 I'll start by dropping an email on the linux-media list

  • Start with 2, and also send the email to Sean Young (he's the IR remote maintainer). When he acceptet your patch create a PR for LibreELEC, ideally with a link to the linux media patchwork URL.


    so long,


    Hias

  • Yes, I see what you mean.

    According to that email thread it's the motherboard that is reporting the wrong register length of 16 in the ACPI tables

    (while the device is still supposed to have an register length of 8 )
    So by changing the register length to 16 in the driver, I am borking every other motherboard with correct ACPI tables, and possibly the PN50 in case a BIOS update fixes the value in the future.


    I'll try your approach.


    * It's a mystery to me how this ended up being an issue. It seems ASUS has been using the same ITE8708 since ages ago.