I added Odroid C2 build to Index of /testing/825-smb-chunk-64k/
and created a 2nd test version here Index of /testing/825-smb-chunk-32k/ with a slightly different patch
I added Odroid C2 build to Index of /testing/825-smb-chunk-64k/
and created a 2nd test version here Index of /testing/825-smb-chunk-32k/ with a slightly different patch
Something else: It is just more hw accel for encryption and decryption not video. Generic benefit the most with 6-8 times faster AES for e.g. disc encryption.
I build a 8.2.5 test version with a patch that wrxtasy suggested.
You find it here Index of /testing/825-smb-chunk-64k/
I started another build for Odroid C2 with the same patch, but when that is finished i am in bed, so that needs to wait until tomorrow morning.
release: 8.90.005-1.0-#180917 (only Generic RPi RPi2 Slice Slice3)
- based on LibreELEC (Leia) v8.90.005 ALPHA – LibreELEC
- added EXT4 filesystem encryption in the kernel config (not yet tested)
but only for Project Generic and RPi, because it needs kernel 4.1 or later
release: 8.90.004-1.0-#180909
- based on LibreELEC (Leia) v8.90.004 ALPHA – LibreELEC
release: 8.90.005-1.0-#180915
- based on LibreELEC (Leia) v8.90.005 ALPHA – LibreELEC
- clean build
You dont need to install any patches. When you have problems please install LibreELEC version on which my build is based on and check if the problem is also there.
download link http://sky42.libreelec.tv/release/9.0/
If you dont use any of the encryption additions i made, then my images have no benefit for you and you should use the official build.
or use Custom Update Channel in LE settings
- set Automatic Updates manual
- enable Show Custom Channels
- change Custom Channel 2 to http://sky42.libreelec.tv/.9/ or for all channels http://sky42.libreelec.tv/
- choose the Update Channel LibreELEC-9.x-sky42-1.x
- and now use Available Versions and choose
What was changes in my version
- /flash 1024MB
- show Builder Name in Kodi Sytem Info an LE Settings now part of LE
- enable kernel config for ext4 filesystem encryption (only Genereic, RPi, Rockchip) since #180928
- enable kernel config for more crypto modules
- enable kernel config enable more hardware crypto acceleration
- enable kernel config for dm-crypt
- added fscryptctl, cryptsetup and dependency lvm2-minimal
- curl: enable protocol support for scp, sftp, smb, smbs
- some S905/S912 patches i find are needed
If you have any problems please install offcial LibreELEC version on which my build is based on and test again. If the problem is the same it is most likely not my build.
Builds for Projects/Devices:
Generic
RPi: devices RPi RPi2 Slice Slice3
Amlogic: devices KVIM LePotato Odroid_C2 WeTek_Hub WeTek_Play_2
Rockchip: devices MiQi RK3328 RK3399 TinkerBoard (since #181007)
WeTek_Play
WeTek_Core
daily use by me: Generic
tested booting: RPi2
just build and never tested: RPi Slice Slice3 KVIM LePotato Odroid_C2 WeTek_Hub WeTek_Play_2 WeTek_Play WeTek_Core MiQi RK3328 RK3399 TinkerBoard
If you are interested why i build this read here LE 9 kernel config with more crypto modules, hardware acceleration and dm-crypt
The following links are only for people who are interested in the source code of my builds.
And i do have a GitHub account now and you find the source here sky42src (sky42) · GitHub
in the branches like
GitHub - sky42src/LibreELEC.tv at 9.0.0-190130
Comparing LibreELEC:9.0.0...sky42src:9.0.0-190130 · LibreELEC/LibreELEC.tv · GitHub
Have Fun
sky42
some updates ... what was done:
now with new version numbers and custom update channels see post #155
release #180909 download http://sky42.libreelec.tv/release/8.2/
8.2.5-1.3-#180909
- no change except the new version number
8.2.5-3.3-#180909
- kernel update 4.14.67
8.2.5-6.3-#180909
- kernel update 4.18.5
8.2.5-7.3-#180909
- kernel update 4.18.5
- Mesa 3D update 18.1.8
The Team LibreELEC did give me space on there server, so that you now find my latest releases under http://sky42.libreelec.tv/. But there will only be the last 1 or 2, so that i not use so much space.
I did change the version numbers:
1.42.x -> 1.x with Custom Update Channel LibreELEC-8.x-sky42-1.x
3.42.x -> 3.x with Custom Update Channel LibreELEC-8.x-sky42-3.x
6.42.x -> 6.x with Custom Update Channel LibreELEC-8.x-sky42-6.x
7.42.x -> 6.x with Custom Update Channel LibreELEC-8.x-sky42-7.x
Now you can use Custom Update Channel in LE Settings
- set Automatic Updates manual
- enable Show Custom Channels
- change Custom Channel 2 to http://sky42.libreelec.tv/ or for just 8.x channels http://sky42.libreelec.tv/release/.8/
- choose a Update Channel LibreELEC-8.x-sky42-Y.x where Y is the 8.2.5-Y.42.z version you use so far
- and now use Available Versions and choose
the new places for download
http://sky42.libreelec.tv/release/8.2/
HiDrive mirror
And to see the size difference here some ls with my LE master version 1725942 patched with all the crypto stuff and 8.90.004 which was not build by my, but as far as i can tel that is LE master 1725942.
kernel
sky42@howcome:/zfs/sky42/libreelec/sky42$ ls -lg 9.0/*/*.kernel 8.90.004/*/KERNEL
-rw-r--r-- 1 sky42 16007536 Aug 31 17:05 8.90.004/Generic/KERNEL
-rw-r--r-- 1 sky42 7231208 Aug 31 13:21 8.90.004/RPi2/KERNEL
-rw-r--r-- 1 sky42 7066200 Aug 31 14:29 8.90.004/RPi/KERNEL
-rw-r--r-- 1 sky42 16019824 Sep 1 07:49 9.0/Generic/LibreELEC-Generic.x86_64-9.0-devel-20180901074840-1725942.kernel
-rw-r--r-- 1 sky42 7230464 Sep 1 07:26 9.0/RPi2/LibreELEC-RPi2.arm-9.0-devel-20180901072539-1725942.kernel
-rw-r--r-- 1 sky42 7070584 Sep 1 07:24 9.0/RPi/LibreELEC-RPi.arm-9.0-devel-20180901072412-1725942.kernel
-rw-r--r-- 1 sky42 7230872 Sep 1 07:28 9.0/Slice3/LibreELEC-Slice3.arm-9.0-devel-20180901072730-1725942.kernel
-rw-r--r-- 1 sky42 7069736 Sep 1 07:29 9.0/Slice/LibreELEC-Slice.arm-9.0-devel-20180901072847-1725942.kernel
system
sky42@howcome:/zfs/sky42/libreelec/sky42$ ls -lg 9.0/*/*.system 8.90.004/*/SYSTEM
-rw-r--r-- 1 sky42 235331584 Aug 31 17:05 8.90.004/Generic/SYSTEM
-rw-r--r-- 1 sky42 138616832 Aug 31 13:21 8.90.004/RPi2/SYSTEM
-rw-r--r-- 1 sky42 138149888 Aug 31 14:29 8.90.004/RPi/SYSTEM
-rw-r--r-- 1 sky42 235986944 Sep 1 07:49 9.0/Generic/LibreELEC-Generic.x86_64-9.0-devel-20180901074840-1725942.system
-rw-r--r-- 1 sky42 139218944 Sep 1 07:26 9.0/RPi2/LibreELEC-RPi2.arm-9.0-devel-20180901072539-1725942.system
-rw-r--r-- 1 sky42 138743808 Sep 1 07:25 9.0/RPi/LibreELEC-RPi.arm-9.0-devel-20180901072412-1725942.system
-rw-r--r-- 1 sky42 139358208 Sep 1 07:28 9.0/Slice3/LibreELEC-Slice3.arm-9.0-devel-20180901072730-1725942.system
-rw-r--r-- 1 sky42 138891264 Sep 1 07:29 9.0/Slice/LibreELEC-Slice.arm-9.0-devel-20180901072847-1725942.system
No i did some testing with my new builds and here are the results for hardware accelerated AES.
The 0901-luks version is with all usable hardware acceleration on and 0901-noni is the same just hardware acceleration swited of in the kernel.
short version:
# NUC D34010WYK i3-4010U 1.7 GHz Haswell
BUILDER_VERSION="0901-luks"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 883.8 MiB/s 887.6 MiB/s
# NUC D34010WYK i3-4010U 1.7 GHz Haswell
BUILDER_VERSION="0901-noni"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 110.5 MiB/s 112.4 MiB/s
# HTPC i3-8100 3.6 GHz Coffe Lake
BUILDER_VERSION="0901-luks"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 2077.3 MiB/s 2073.5 MiB/s
# HTPC i3-8100 3.6 GHz Coffe Lake
BUILDER_VERSION="0901-noni"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 272.2 MiB/s 264.4 MiB/s
# RPi2
BUILDER_VERSION="0901-luks"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 22.7 MiB/s 19.5 MiB/s
# RPi2
BUILDER_VERSION="0901-noni"
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 12.1 MiB/s 12.8 MiB/s
Display More
TL;DR
full output of the tests
# NUC D34010WYK i3-4010U 1.7 GHz Haswell
kodi7:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-luks"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 455111 iterations per second for 256-bit key
PBKDF2-sha256 592415 iterations per second for 256-bit key
PBKDF2-sha512 410241 iterations per second for 256-bit key
PBKDF2-ripemd160 366634 iterations per second for 256-bit key
PBKDF2-whirlpool 318135 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 324.9 MiB/s 1373.8 MiB/s
serpent-cbc 128b 39.6 MiB/s 275.7 MiB/s
twofish-cbc 128b 84.7 MiB/s 172.1 MiB/s
aes-cbc 256b 242.1 MiB/s 1050.9 MiB/s
serpent-cbc 256b 42.5 MiB/s 275.3 MiB/s
twofish-cbc 256b 87.4 MiB/s 172.0 MiB/s
aes-xts 256b 883.8 MiB/s 887.6 MiB/s
serpent-xts 256b 273.4 MiB/s 264.8 MiB/s
twofish-xts 256b 169.9 MiB/s 169.9 MiB/s
aes-xts 512b 726.1 MiB/s 721.3 MiB/s
serpent-xts 512b 273.6 MiB/s 265.0 MiB/s
twofish-xts 512b 169.6 MiB/s 170.0 MiB/s
# NUC D34010WYK i3-4010U 1.7 GHz Haswell
kodi7:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-noni"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 455111 iterations per second for 256-bit key
PBKDF2-sha256 595105 iterations per second for 256-bit key
PBKDF2-sha512 388361 iterations per second for 256-bit key
PBKDF2-ripemd160 366122 iterations per second for 256-bit key
PBKDF2-whirlpool 317750 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 98.7 MiB/s 118.3 MiB/s
serpent-cbc 128b 40.1 MiB/s 276.7 MiB/s
twofish-cbc 128b 82.4 MiB/s 172.2 MiB/s
aes-cbc 256b 82.3 MiB/s 91.8 MiB/s
serpent-cbc 256b 42.3 MiB/s 276.7 MiB/s
twofish-cbc 256b 87.5 MiB/s 172.8 MiB/s
aes-xts 256b 110.5 MiB/s 112.4 MiB/s
serpent-xts 256b 272.4 MiB/s 264.4 MiB/s
twofish-xts 256b 169.2 MiB/s 168.9 MiB/s
aes-xts 512b 89.0 MiB/s 89.1 MiB/s
serpent-xts 512b 273.0 MiB/s 264.4 MiB/s
twofish-xts 512b 169.3 MiB/s 169.4 MiB/s
# HTPC i3-8100 3.6 GHz Coffe Lake
twang:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-luks"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 924670 iterations per second for 256-bit key
PBKDF2-sha256 1249792 iterations per second for 256-bit key
PBKDF2-sha512 902388 iterations per second for 256-bit key
PBKDF2-ripemd160 727167 iterations per second for 256-bit key
PBKDF2-whirlpool 717220 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1107.0 MiB/s 3462.3 MiB/s
serpent-cbc 128b 88.6 MiB/s 681.9 MiB/s
twofish-cbc 128b 202.2 MiB/s 374.0 MiB/s
aes-cbc 256b 838.4 MiB/s 2750.3 MiB/s
serpent-cbc 256b 90.1 MiB/s 681.9 MiB/s
twofish-cbc 256b 204.2 MiB/s 374.0 MiB/s
aes-xts 256b 2077.3 MiB/s 2073.5 MiB/s
serpent-xts 256b 662.3 MiB/s 674.7 MiB/s
twofish-xts 256b 369.1 MiB/s 368.3 MiB/s
aes-xts 512b 1955.1 MiB/s 1943.9 MiB/s
serpent-xts 512b 662.5 MiB/s 675.0 MiB/s
twofish-xts 512b 368.7 MiB/s 367.8 MiB/s
# HTPC i3-8100 3.6 GHz Coffe Lake
twang:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-noni"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 932896 iterations per second for 256-bit key
PBKDF2-sha256 1249792 iterations per second for 256-bit key
PBKDF2-sha512 905506 iterations per second for 256-bit key
PBKDF2-ripemd160 742617 iterations per second for 256-bit key
PBKDF2-whirlpool 717220 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 227.2 MiB/s 263.1 MiB/s
serpent-cbc 128b 87.8 MiB/s 681.8 MiB/s
twofish-cbc 128b 198.8 MiB/s 374.2 MiB/s
aes-cbc 256b 180.8 MiB/s 200.0 MiB/s
serpent-cbc 256b 90.1 MiB/s 681.8 MiB/s
twofish-cbc 256b 204.2 MiB/s 374.1 MiB/s
aes-xts 256b 272.2 MiB/s 264.4 MiB/s
serpent-xts 256b 662.5 MiB/s 675.3 MiB/s
twofish-xts 256b 369.3 MiB/s 368.6 MiB/s
aes-xts 512b 208.0 MiB/s 203.9 MiB/s
serpent-xts 512b 662.5 MiB/s 675.3 MiB/s
twofish-xts 512b 369.2 MiB/s 368.4 MiB/s
# RPi2
kodi01:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-luks"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 64503 iterations per second for 256-bit key
PBKDF2-sha256 88086 iterations per second for 256-bit key
PBKDF2-sha512 53455 iterations per second for 256-bit key
PBKDF2-ripemd160 60014 iterations per second for 256-bit key
PBKDF2-whirlpool 11342 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 12.5 MiB/s 20.0 MiB/s
serpent-cbc 128b 10.3 MiB/s 11.3 MiB/s
twofish-cbc 128b 16.3 MiB/s 17.8 MiB/s
aes-cbc 256b 10.9 MiB/s 15.0 MiB/s
serpent-cbc 256b 10.3 MiB/s 11.3 MiB/s
twofish-cbc 256b 16.3 MiB/s 17.8 MiB/s
aes-xts 256b 22.7 MiB/s 19.5 MiB/s
serpent-xts 256b 11.1 MiB/s 11.4 MiB/s
twofish-xts 256b 17.7 MiB/s 18.1 MiB/s
aes-xts 512b 17.3 MiB/s 14.8 MiB/s
serpent-xts 512b 11.1 MiB/s 11.5 MiB/s
twofish-xts 512b 18.0 MiB/s 18.1 MiB/s
# RPi2
kodi01:~ # grep BUILDER_VERSION /etc/os-release ; cryptsetup benchmark
BUILDER_VERSION="0901-noni"
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 64631 iterations per second for 256-bit key
PBKDF2-sha256 87732 iterations per second for 256-bit key
PBKDF2-sha512 53368 iterations per second for 256-bit key
PBKDF2-ripemd160 59795 iterations per second for 256-bit key
PBKDF2-whirlpool 11326 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 11.7 MiB/s 13.0 MiB/s
serpent-cbc 128b 10.0 MiB/s 11.3 MiB/s
twofish-cbc 128b 15.6 MiB/s 17.7 MiB/s
aes-cbc 256b 10.6 MiB/s 11.0 MiB/s
serpent-cbc 256b 10.1 MiB/s 11.1 MiB/s
twofish-cbc 256b 15.9 MiB/s 17.3 MiB/s
aes-xts 256b 12.1 MiB/s 12.8 MiB/s
serpent-xts 256b 10.4 MiB/s 11.4 MiB/s
twofish-xts 256b 17.3 MiB/s 18.1 MiB/s
aes-xts 512b 11.3 MiB/s 11.3 MiB/s
serpent-xts 512b 11.1 MiB/s 11.5 MiB/s
twofish-xts 512b 17.9 MiB/s 18.0 MiB/s
Display More
Why should there be hardware acceleration and more crypto moduls in the kernel:
Hardware acceleration with AES-NI is 6-8 times faster. That is the case for many things like https, other SSL connections, SSH and also disk encryption. The kernel encryption/decryption implemetation is faster than just userspace software, becasue it is more optimized and using even hardware acceleration if possible, when you enable optimization/acceleration.
When the kenrel supports a more complete set of encryption, than the community is able to build addons that are using/needing the kernel crypto support.
Why would some one use disk encryption:
There are at least 2 reasons.
One is encryption at rest, so that data on the disk are encrypted and you can throw it away without thinking about the data. For HDDs you can overwrite them, when they are still working, but failed HDDs have still data and you can not properly delete them. The seconds case can be solved with a degausser, but thats about $ 20.000 (i bought 2 at work). For SSDs proper deleting through overwriting is not really possible, because of wearleveling technics of the SSD controller you will never reach all flash cells.
The 2nd one is protecting your data, because you dont want somebody to access them. But these data are only cold secure, that means if it is swicthed off nobody can access it without your password or key. I see that used more and more for portable data devices (HDD, SSD, USB Stick). Also Android does encrypt the user data by default since Android 6, when you setup a PIN or password. iPhones doing that a lot longer.
I propose to add more support for encryption and dm-crypt in the kernel. Encryption will be faster for e.g https and the community can build addons based on that.
I would also like to include cryptsetup in LE, so that it is possible to use encrypted block devices. If cryptsetup is not included i can still build a addon, when the dm-crypt kernel support is included.
With cryptsetup it is possible to use luks, loopaes, veracrypt, truecrypt encrypted devices. A veracrypt USB disc needs to be first open by cryptsetup and then you could normal mount e.g. a ntfs filesystem. There is no GUI for that in my proposal. I am not the right person to build a GUI portion for that, but with the kernel support and cryptsetup it is poosible to build a addon for that.
The kernel image is growing about 16KB on Generic x86_64 and the system image about 1.5MB (cryptsetup included).
I have now (finally) my own github account with a forked LibreELEC repo and created Pull Requests for the features, but so far only in my own repo.
For cryptsetup and dependencies:
and this wil only be build if the kernel supports CONFIG_DM_CRYPT. The next 3 PR will do that.
For the kernel modules i have covered 3 projects so far:
I am happy to provide patches for the other architectures. On Generic/RPi2 i use this every day (my LE userdata is encrypted).
If somebody wants to try, you will find my builds here HiDrive and in the noni subfolder is a version without crypto hardware acceleration. The easiest way to test ist "cryptsetup benchmark --cipher aes-xts" with and with out hw acceleration. I will also add the pure le master, so that you can see the size difference and this will be in the orig subfolder.
Thanks for reading and hopefully considering it
sky42
Thanks for the advice. I did think about it some time. Now i have done some more tests and minimized my patches. I also write a application, but still not sure about the new Subject "kernel support for encryption + adding dm-crypt" for a new thread i will open.
Here is my draft:
------------------------------
Why should there be hardware acceleration and more crypto moduls in the kernel:
Hardware acceleration with AES-NI is 6-8 times faster. That is the case for many things like https, other SSL connections, SSH and also disk encryption. The kernel encryption/decryption implemetation is faster than just userspace software, becasue it is more optimized and using even hardware acceleration if possible, when you enable optimization/acceleration.
When the kenrel supports a more complete set of encryption, than the community is able to build addons that are using/needing the kernel crypto support.
Why would some one use disk encryption:
There are at least 2 reasons.
One is encryption at rest, so that data on the disk are encrypted and you can throw it away without thinking about the data. For HDDs you can overwrite them, when they are still working, but failed HDDs have still data and you can not properly delete them. The seconds case can be solved with a degausser, but thats about $ 20.000 (i bought 2 at work). For SSDs proper deleting through overwriting is not really possible, because of wearleveling technics of the SSD controller you will never reach all flash cells.
The 2nd one is protecting your data, because you dont want somebody to access them. But these data are only cold secure, that means if it is swicthed off nobody can access it without your password or key. I see that used more and more for portable data devices (HDD, SSD, USB Stick). Also Android does encrypt the user data by default since Android 6, when you setup a PIN or password. iPhones doing that a lot longer.
I propose to add a more support for encryption and dm-crypt in the kernel. Encryption will be faster for e.g https and the community can build addons based on that.
I would also like to include cryptsetup in LE, so that it is possible to use encrypted block devices. If cryptsetup is not included i can still build a addon, when the dm-crypt kernel support is included.
With cryptsetup it is possible to use luks, loopaes, veracrypt, truecrypt encrypted devices. A veracrypt USB disc needs to be first open by cryptsetup and then you could normal mount e.g. a ntfs filesystem. There is no GUI for that in my proposal. I am not the right person to build a GUI portion for that, but with the kernel support and cryptsetup it is poosible to build a addon for that.
The kernel image is growing about 16KB on Generic x86_64 and the system image about 1.5MB (cryptsetup included).
here is my patch for Generic x86_64
kernel support for encryption and adding dm-crypt
sky42-kernel-config-Generic-x86_64-encryption-4.18-v2.patch.txt
cryptsetup package.mk and depedencies lvm2-minimal
I am happy to provide patches for all the other architectures. With RPi2 and Wetek_Play i already did this a while ago. On Generic x86_64 i use this every day (my LE userdata is encrypted).
Thanks for reading and hopefully considering it
sky42
------------------------------
some updates ... what was done:
special Spectre/Meltdown update with protection up too Foreshadow L1TF from 3 days ago
checker v39+ from here GitHub - speed47/spectre-meltdown-checker: Spectre & Meltdown vulnerability/mitigation checker for Linux
and if you are into details how to protect read here L1TF - L1 Terminal Fault — The Linux Kernel documentation
and some more insides here L1TF - L1 Terminal Fault Attack - CVE-2018-3620 & CVE-2018-3646 - Red Hat Customer Portal
8.2.5-3.42.3-4.14.63 in Generic here HiDrive
- kernel 4.14.63
8.2.5-6.42.3-4.18.1 in Generic here HiDrive
- kernel 4.18.1
8.2.5-7.42.3-4.18.1 in Generic here HiDrive
- kernel 4.18.1
Sorry rene12345 i have no idea what your issue could be.
And to see what is possible on resolution and fps you can use "xranr".
For me it looks like
QuoteDisplay Moretwang:~ # xrandr
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
DP1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1600mm x 900mm
3840x2160 60.00 + 50.00 59.94 30.00 25.00 24.00 29.97 23.98*
4096x2160 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98
1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98
1920x1080i 60.00 50.00 59.94
1280x1024 60.02
1360x768 60.02
1152x864 59.97
1280x720 60.00 50.00 59.94
1024x768 60.00
800x600 60.32
720x576 50.00
720x480 60.00 59.94
640x480 60.00 59.94
720x400 70.08
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1920x1080i 60.00 + 50.00 59.94
1920x1080 60.00* 50.00 59.94
1280x720 60.00 50.00 59.94
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 60.00 59.94
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
On the DP1 is a active DP 1.2 Adapter to HDMI 2.0 and the HDMI1 port is connected to my AVR just for audio
No that is not normal, that does even work on my haswell. But you can setup what should be hardware decoded under Settings -> Player -> Videos, but settings level needs to be expert. VAAPI needs to be on and you can switch on all the codecs.