Red Hat wil in de komende jaren werken aan betere hdr- en vrr-ondersteuning

Red Hat wil in de komende twee jaar werken aan de ondersteuning voor high dynamic range op Linux. De ontwikkelaars organiseren een hackathon om met een plan van aanpak te komen voor hoe hdr in de Gnome-desktopomgeving kan worden geïntegreerd.

Een aantal Red Hat-ontwikkelaars schrijven op hun wiki dat zij later dit jaar bijeen willen komen in Brno in Tsjechië voor een evenement dat Shell & Display Next heet. Dat is een hackathon waarin de ontwikkelaars willen werken aan een roadmap om hdr, maar ook vrr en andere gpu-technologieën in het besturingssysteem te verwerken. Er wordt daarnaast ook gewerkt aan verbeteringen in de Kernel Model Settings en Wayland api's voor Red Hat, zeggen de makers. Die moeten zo worden bijgewerkt dat het voor eindgebruikers makkelijker wordt met die instellingen te spelen, wat vooral voor hdr-ondersteuning belangrijk is. Tijdens de hackathon zijn niet alleen ontwikkelaars van Red Hat aanwezig, maar ook van Valve, Intel, AMD en Nvidia en van KDE.

De ontwikkelaars willen vooral om een roadmap op te stellen voor de komende een tot twee jaar. Naast hdr willen de ontwikkelaars ook variable refresh rate of vrr beter ondersteunen in de distro, maar ook 'toekomstige gpu-technologieën' moeten beschikbaar worden voor gebruikers via Mutter of de Shell. De ontwikkelaars willen zich specifiek richten op beeldtechnologieën die de Gnome-shell samen met de gpu-stack in Linux nodig hebben. Daar is hdr het hoofdvoorbeeld van, zeggen ze. "Het hackfest is bedoeld om ontwikkelaars van de beeldscherm- tot gpu-stacks bij elkaar te brengen, inclusief ontwikkelaars van freedesktop en die aan de upstreamkernel werken."

Als de Red Hat-hackathon succesvol is, zouden mogelijk ook andere distro's die Gnome als shell gebruiken daarvan kunnen profiteren. hdr-ondersteuning op Linux is al lange tijd een wens van veel ontwikkelaars, onder andere van die van Valve. Ontwikkelaars daarvan toonden laatst beelden van games die op Linux draaiden met hdr-ondersteuning.

Reacties (42)

[synoniem]

Alleen jammer dat het Redhat is. Waarschijnlijk maken ze het een verplicht onderdeel van systemd en daarmee een nog grotere oncontroleerbare binaire blob.

[rbr320]

HDR heeft betrekking op de Direct Rendering Manager in de kernel, je display server (Wayland), compositer (o.a. mutter) en je window manager (Gnome, KDE, etc.). Het heeft niets van doen met systemd. Jouw reactie en die van @damouze komen typisch van mensen die geen idee hebben wat systemd precies is en doet.

Systemd is een service layer voor GNU/Linux die leeft tussen de Linux kernel en applicaties in userspace die zich als services gedragen. Iets waar andere Unix-achtigen jaloers op (zouden moeten) zijn. Een servicelaag is er inderdaad verantwoordelijk voor om, nadat de kernel is gestart, de rest van het systeem te initialiseren, maar het doet daarnaast nog veel meer. Zo houdt het de geïnitialiseerde services in de gaten en start deze opnieuw op als ze zijn gecrasht. Ook kan het periodiek taken uitvoeren (systemd timers) en op aanvraag (netwerk)schijven mounten (automount). Roepen dat we moeten stoppen met het gebruik van systemd en terug moeten naar sysVinit of iets vergelijkbaars is hetzelfde als roepen dat Windows zijn opstartprocess met batch scripts zou moeten uitvoeren in plaats van de Service Manager.

Wat betreft de opmerking over een "oncontroleerbare binaire blob", de source code van systemd is gewoon openbaar, net als (vrijwel) alles wat Red Hat maakt. Daarnaast bestaat systemd netjes uit meerdere, relatief kleine binaries voor de individuele taken, die ook nog eens van elkaar gescheiden worden door middel van cgroups. Ook doet het gebruik van systemd niets af aan de modulariteit van Linux, je kunt prima de onderdelen die je niet wilt gebruiken uitschakelen en andere services activeren. Zo gebruik ik op mijn desktop niet systemd-timesyncd maar chrony, hoewel timesyncd voor de meeste gebruikers prima zal voldoen.

De haat richting systemd komt dus vooral van 2 groepen mensen. De eerste groep zijn mensen die geen idee hebben waar ze het over hebben maar blijven roepen dat systemd slecht is omdat dat nu eenmaal is wat ze op het internet hebben gelezen. De tweede groep heeft waarschijnlijk niet zozeer problemen met systemd maar met de persoon die lange tijd de hoofdontwikkelaar van systemd is geweest, Lennart Poettering. Ik begrijp deze tweede groep in zoverre dat ik ook vind dat Poettering er in mijn ogen wat rare en vooral verkeerde ideeën op na houdt over welke kant we op moeten met Linux, maar systemd is daar niet 1 van. Gelukkig is/was hij niet de enige in het ontwikkelteam, maar als ik bij Red Hat in het management had gezeten toen Lennart er nog werkte had ik er in ieder geval voor gezorgd dat hij zo min mogelijk contact zou hebben met eindgebruikers.

[Reactie gewijzigd door rbr320 op 26 juli 2024 01:02]

[damouze]

Ik weet wat HDR is.

Mijn afkeer van systemd heeft vooral te maken met het feit dat het de UNIX filosofie schendt: doe 1 ding en doe het goed.

Het programma dat als PID 1 draait, veelal 'init' genoemd, dient zich met het absolute minimum bezig te houden zodat andere programma's het elk het absolute minimum kunnen doen om hun onderdeel te initialiseren. Dat is het exact omgekeerde van wat systemd doet.

Overigens is ook sysv init strict genomen niet helemaal zuiver in deze, aangezien het ook meer doet dan het absolute minimum, maar het is in ieder geval nog wel uitwisselbaar met andere init systemen. Systemd is dat niet. En wat nog veel ernstiger is: bepaalde software pakketten werken alleen nog maar samen met systemd omdat ze afhankelijk geworden zijn van de core services van systemd. Linux, en Open Source en Free Software in het algemeen ging tot dusver altijd om de keuze. Die keuze wordt ernstig beperkt wanneer je niet zelf je init systeem meer kunt kiezen. Toegegeven, heel strict genomen ligt dat aan de softwarepakketten die zich afhankelijk maken van systemd en niet aan systemd zelf. Echter, het wordt wel gefaciliteerd doordat systemd inmiddels zijn eigen ecosysteem heeft opgebouwd.

Systemd heeft daarnaast behoorlijk wat last van scope-creep. Je geeft het zelf aan: je kunt heel veel van systemds built-in services uitschakelen en vervangen door iets anders. De vraag rijst echter dan: waarom heeft systemd ueberhaupt al die built-in services als deze reeds bestaan als losse software pakketten? Waarom ueberhaupt een systemd-timesyncd in plaats van iets als (open)ntpd? Waarom een built-in cron daemon, wanneer er al verschillende varianten van cron bestaan?

Voor wat betreft Poettering, ik heb inderdaad een afkeer van de man, maar die afkeer is niet de belangrijkste motivator voor mijn afkeer van systemd. Poettering valt in de categorie crackpot geniuses. Op heel veel vlakken is hij briljant, maar hij kan niet tegen kritiek en zijn standaardreactie op een bug report is zo'n beetje: jij doet het verkeerd, het ligt niet aan systemd (of aan pulseaudio, avahi, of welk ander programma hij ooit aan gewerkt heeft). Je opmerking over dat hij zover mogelijk weggehouden moet worden bij eindgebruikers, daar kan ik me dus uitstekend in vinden.

Zijn laatste idee is trouwens ook wel bijzonder. Hij stelt voor om de kernel en initrd in een enkele binary blob te stoppen (UKI). In beginsel lijkt dit heel redelijk. Behalve dat de binary blob vervolgens digitaal ondertekend moet zijn en dat die digitale handtekening vervolgens bekend moet zijn bij de UEFI BIOS en dat voor Linux secureboot dan een absolute vereiste wordt. Zelfs met de allerbeste bedoelingen wordt de kans op vendor lock-in dan vele malen groter. De digitale handtekeningen die de root-of-trust vormen voor UEFI secureboot komen bij de vendors zelf vandaan, die ze op hun beurt weer moeten aanvragen bij een bedrijf dat er strict genomen niet bij gebaat is wanneer er iets anders dan hun eigen besturingssysteem op een apparaat draait. Daarmee wil ik niet zeggen dat we dat bedrijf bij voorbaat moeten wantrouwen, alleen dat als het gaat om de keuze van OS, de macht heel erg bij de vendors en dat bedijf ligt en niet bij de eigenaar van het apparaat zelf. Als iemand of een bedrijf zijn apparaat, zijn eigendom, zo wil dichttimmeren dat niemand anders dan de personen die hij/het erop toelaat erbij kunnen en dat malware zo min mogelijk kans krijgt dan is dat zijn zaak, maar de keuze moet dan wel primair bij hem liggen, niet bij de fabrikant of leverancier van de software.

[30carbonclocks]

Behalve dat de binary blob vervolgens digitaal ondertekend moet zijn en dat die digitale handtekening vervolgens bekend moet zijn bij de UEFI BIOS en dat voor Linux secureboot dan een absolute vereiste wordt.

Een UKI hoeft niet digitaal ondertekend te zijn.

[damouze]

Ik zeg ook niet dat dat technisch noodzakelijk is, maar dat Poettering dit voorstelt.

[keranoz]

Sidenote: "binary blob" is een beetje dubbel. Blob = binary large object.

[damouze]

Blob is ook een normaal Engels woord, niet alleen een acroniem. Ik gebruikte het woord in die zin.

Anders had ik wel BLOB geschreven ;-).

[synoniem]

Ik ben redelijk op de hoogte van wat systemd inhoudt en zie met name de function creep waardoor er steeds meer in systemd gestopt wordt en ook steeds meer afhankelijkheden voor userspace software. Het enkele feit dat de source beschikbaar is zegt niet zoveel, dat is die van de kernel en kernel modules ook, hoe vaak controleer jij die? Als het alleen een init systeem inclusief respawning van services was had ik er geen problemen mee. Wat moet een initsysteem met een halfbakken ntp functie of met de aansturing van je netwerkconfiguratie of je homedirectory.

En nee je hoeft niet terug naar sysVinit er zijn prima andere init systemen beschikbaar en de diverse *BSD-en doen het ook prima zonder systemd. Je kunt overigens prima cgroups gebruiken zonder systemd. En voordat je de onwetend kaart trekt realiseer je dan dat ik al vanaf 1989 met de diverse unix systemen werk en gewerkt heb.

Wat meneer Poettering betreft die werkt inmiddels voor Microsoft waar zijn rare ideeën kennelijk zeer welkom zijn.

[UPPERKEES]

Volgens mij weet je niet wat je allemaal te danken hebt aan Red Hat.

[synoniem]

Red Hat dient vooral zijn eigen belangen en die van zijn eigenaar IBM. Dat wij er ook wat voordeel bij hebben is bijvangst en PR.

[UPPERKEES]

Ja, je weet dus niet wat je echt te danken hebt aan Red Hat. Ze zijn 1 van de grootste contributers aan de Linux kernel, GNOME, systemd (wat echt goed is, alle grote distros gebruiken het uit eigen vrije keus), Wayland, en ga zo maar door. Zonder Red Hat zou Linux echt niet zijn waar het nu is. Ja het is commercieel, maar ze doen het goed en geven terug aan de community. Even een vergelijking, Canonical (bedrijf achter Ubuntu) voegt minder commits toe aan de kernel als Microsoft. En ja Red Hat doet meer. In veel meer projecten.

[synoniem]

Ja en wiens belang dienen ze daarmee, juist die van hen zelf. Ze leven van services en certificeringen. Dacht je nou echt dat het liefdadigheid was van Red Hat? Wat naïef.

[jb044]

Geld verdienen is niet vies, in deze wereld is het nu eenmaal een noodzaak. Redhat doet het best aardig en gelooft niet alleen in opensource maar belijdt dat ook. Fat kun je niet van ieder commercieel bedrijf zeggen.

Eerlijk is eerlijk: ze zouden niet staan waar ze staan als ze niet konden voortborduren op reeds beschikbare opensource. Maar toch meestal is opensource heel cool en leuk totdat er code gedeeld moet worden, Redhat is zeker niet zo'n bedrijf. Ik heb daar wel respect voor, nog even los van de enorme significante bijdragen die ze leveren aan het eco-systeem, zoals door anderen al opgemerkt.

[UPPERKEES]

Open licenties, of wil je nou zeggen dat je betaald voor Linux, GNOME, etc? Je betaald voor de support. Wat optioneel is, want door de open licenties is gewoon alles open source. Vandaar ook Alma en Rocky Linux...

[bzzzt]

Doet het feit dat Red Hat OSS code schrijft en beschikbaar stelt iets af aan het feit dat ze er geld mee verdienen? Je kan het ook als een win-win situatie zien.

[jerisson]

Je beseft dat "Free" bij Linux en de GPL niet slaat op gratis maar op vrij? Om Richard Stallman te quoten: "Think free as in free speech, not free beer."

Red Hat mag gerust geld verdienen aan wat ze binnen de Linux community doet. Uiteraard is dat voor hun eigen voordeel. Maar ik vind het eerder naïef om te denken dat Linux zou staan waar het nu staat als er geen geld bij gemoeid was.

[Hydranet]

Je kan de documentatie van systemd online lezen.
https://www.freedesktop.org/wiki/Software/systemd
http://0pointer.de/blog/projects/the-biggest-myths.html

[ViPER_DMRT]

Het probleem van de gehele upstart rebelion is dat ze alle 150 denken dat upstart een toekomst heeft.

Get with the program son, parallelization overload, snapshotting system state en kan zelfs units installeren zonder deze dan ook meteen verplicfht om te starten. (it's a trap, don't do it )

[Yarisken]

Ik zit op windows 10 met mijn htpc aangesloten op mijn TV.
Ik draai een pak dockers. Mocht linux HDR ondersteunen dan switch ik direct over.
HDR is de enige reden dat ik windows gebruik. De kleurenpracht is gewoon schitterend.

[Gotiniens]

Mijn vero 4k+ is een linux gebaseerde kodi htpc, en ondersteunt ook HDR. Ik gok dat dit nieuwsbericht alleen over toevoegen van HDR in gui applicaties gaat.

[HollowGamer]

Weet je zeker dat Kodi - HDR support heeft? Volgens mij zitten er delen in de kernel, maar is het geen (volledige) HDR implementatie - dat is juist wat RH wilt oppakken.

[Gotiniens]

Mijn TV (LG C8) geeft regelmatig aan dat ik HDR aan het kijken ben. Welke vorm van HDR is mij niet helemaal duidelijk, iig niet dolby vision, daar is een andere pop up voor.

P.s. ik heb even mijn collectie gecheckt mijn TV geeft regelmatig aan een HLG HDR signaal te ontvangen van mijn kodi box.

[Reactie gewijzigd door Gotiniens op 26 juli 2024 01:02]

[HollowGamer]

Ja, maar dat betekent volgens mij nog niet dat HDR wordt gebruikt. Dus het signaal kan wel aangeven dat HDR er is, maar ik dacht dat de window manager/compositor er dan wel iets mee moet doen en die logica is er dus (nog) niet.

[ViPER_DMRT]

You'll know op een LG OLED :-)
It is.

[SlasZ]

Als je de Kodi app gebruikt op je TV dan dient jouw Linux box enkel als aanbieder van streams. Als een stream HDR informatie bevat is het je TV die dit decodeert en toont, je Linux box hoeft daar helemaal niets voor te doen of HDR te ondersteunen.
Gebruik je de HDMI-uit van je box als bron dan is het anders en moet je OS wel HDR ondersteunen.

[Jeanpaul145]

Als dat zo zou zijn, waar hebben ze Valve dan voor nodig? Het ontwikkelwerk dat door hun gedaan en gefinancierd wordt gaat toch echt in de eerste plaats om games dacht ik zo...

[Hydranet]

Ik draai al meer als tien jaar GNU/Linux op mijn desktop en ik mis hdr op de desktop niet. Op mijn tv heb ik hdr en voor films is het wel een mooie toevoeging, ik heb kan mijn monitor wel in verschillende modus instellen dat de kleuren wat feller lijken. Dat is niet hetzelfde als hdr maar goed genoeg voor mij op dit moment maar toch een leuk vooruitzicht dat er aan gewerkt word om hdr te laten werken op GNU/Linux.

Ik draai een pak dockers

Je draait geen dockers maar containers, Docker is een platform om containers op te kunnen draaien met de Docker engine maar je hebt meerdere Platforms om containers op te kunnen draaien

[Reactie gewijzigd door Hydranet op 26 juli 2024 01:02]

[bzzzt]

Het probleem is dat je op een bepaald moment misschien wel een foto of film in HDR wil bewerken en zonder ondersteuning dat dus niet op een Linux systeem kan doen.

[Yarisken]

Idd containers :-). Draait wel vlot op windows docker desktop moet ik zeggen. Maar ben meer een linux man.

[Elbino]

Volgens mij ligt er al jaren een voorstel hoe HDR te implementeren op Wayland (default display protocol op Gnome). Kwestie van oppakken en uitvoeren? Vind het overigens bijzonder dat er nog altijd geen HDR implementatie is op Linux.

[Ventieldopje]

Dat ligt niet alleen bij Wayland waarschijnlijk maar aan de hele stack er onder, dat moet ook mee. Zal dus wel iets gecompliceerder liggen.

[psychicist]

Brno ligt in Tsjechië en Red Hat heeft daar een kantoor. Deze ontwikkelingen zouden wel goed zijn, hoewel ik de features tot nu toe niet gemist heb.

[Reactie gewijzigd door psychicist op 26 juli 2024 01:02]

[CAPSLOCK2000]

Ik wacht al een tijdje op HDR dus ik ben hier blij mee.

Die moeten zo worden bijgewerkt dat het voor eindgebruikers makkelijker wordt met die instellingen te spelen, wat vooral voor hdr-ondersteuning belangrijk

Deze zin is een beetje dubbelzijdig. Je kan het lezen als dat HDR belangrijk is voor gebruikers, en dat klopt.
Maar er volgens mij staat et dat HDR best wel moeilijk is om goed te krijgen voor iedereen en er daarom veel getest moet worden. Hoe sneller je iets maakt dat tenmiste een beetje werkt, hoe sneller mensen kunnen beginnen met testen.

[damouze]

Red Hat kan beter focussen op het tegengaan van vendor lock-in en security leaks. Bijvoorbeeld door weer het inherent veiligere sysv init weer te gaan gebruiken in plaats van systemd en het laatste plan van Poettering, te weten UKI, niet in gebruik te nemen.

[maartenbe99]

Ben ook benieuwd om te weten waarom sysv init veiliger zou zijn dan systemd.

Systemd support native het sandboxen van applicaties door het gebruik van cgroups v2 (https://www.redhat.com/sysadmin/mastering-systemd) wat dus dezelfde functionaliteit kan bieden zoals OCI containers.
Ik vind het persoonlijk wel jammer dat veel packages deze instellingen niet hebben staan in de meegeleverde service files. Maar sandboxing is wel by default enabled door het gebruik van slices, maar dit is minder streng.

[damouze]

Je hebt een proces op pid 1 met een grote attack surface, doordat er 1 monolitisch proces is dat de complete initialisatie van het systeem moet doen.

Zet dat tegenover iets als sysv init, of nog beter minit, dat het absolute minimum doet om het systeem voldoende op gang te krijgen en het stokje vervolgens overdraagt aan het volgende onderdeel dat weer een stuk van de initialisatie doet en het stokje overdraagt aan het onderdeel erna, enzovoorts.

[maartenbe99]

Sysvinit heef op dat vlak een kleinere attach surface, Maar sysvinit doet enkel maar het absolute minimum om een systeem te starten. Systemd doet veel meer zaken (in de vorm van verschillende gebundelde processen) naast het opstarten van het system zoals het mounten van filesystems, meer complexe monitoring met watchdog, sandboxing, on demand service activation (vb initd), cronjobs (systemd heeft timers) ... Waardoor je op een Sysvinit systeem meer kleinere processen nodig hebt om hetzelfde te bereiken wat ook de attack surface groter maakt.

Dit maakt beide manieren vulnerable op een verschillende manier. Beide systemen hebben daarbij voor en nadelen.

Bij sysvinit is het voordeel dat het allemaal afzonderlijke processen wat meer past bij de unix filosofie (do one thing and do it well), de keuze bestaat om enkel de processes mee te installeren dat je nodig heb en kan kiezen uit verschillende mogelijkheden.
Een nadeel van Sysvinit is dat je meer zelf moet schrijven in de vorm van shell scripts wat ook kwetbaarheden kan meebrengen.

Systemd heeft dan het voordeel van de goede integratie (denk aan journald voor logging), de verschillende sandboxing functies (zoals privilege dropping, toegang beperken to bepaalde mappen, private tmp mappen, verschillende namespaces, netwerkisolatie ... Wat heel jammer is dat dit niet als default is bij veel meegeleverde servicefiles).
Er zijn ook een paar grote nadelen, zoals dat het een kleine groep mensen is dat keuzes maakt over hoe systemd zaken aanpakt (ik denk hierbij aan de bug waarbij als het user veld invalid is systemd by default het proces gaat draaien als root, wat ondertussen is opgelost - https://github.com/systemd/systemd/issues/6237), het moeilijk is om nog af te stappen van systemd doordat alle programma's er dependencies op hebben, het een all-in-one pakket is waarbij je vaak functies niet gebruikt (systemd-boot, networkd, resolved, timesyncd...) , de mogelijkheid dat users (dynamisch) processes kunnen opspinnen met systemd wat totaal niet gewenst is op servers en wat niet kan worden uitgeschakeld.

Wat voor mij een veel groter probleem is met RHEL based systems is dat netwerkconfiguratie standaard gebeurt met NetworkManager. Dit is desktop software dat draait op een server met bepaalde functionaliteiten dat totaal onnodig zijn op een server (wifi ondersteuning, dynamische switching tussen interfaces) en dat de configuratie gebeurt over dbus (ook een niet gewilde dependency van systemd op servers) ipv een configuratiebestand. Er is integratie voor de klassieke netwerkconfiguratie van RHEL, maar het reloaden van het netwerk past niet altijd de gemaakte wijzigingen toe.

[synoniem]

Inderdaad op de desktop kan systemd weinig kwaad omdat die in de regel toch maar één gebruiker heeft. Op een server maar ook in embedded systemen wil je dat allemaal niet maar dat mag je van de fanboys niet zeggen.

[HollowGamer]

Kan je ook uitleggen waarom systemd voor jou potentieel onveilig is?

[damouze]

Je hebt een proces op pid 1 met een grote attack surface, doordat er 1 monolitisch proces is dat de complete initialisatie van het systeem moet doen.

Zet dat tegenover iets als sysv init, of nog beter minit, dat het absolute minimum doet om het systeem voldoende op gang te krijgen en het stokje vervolgens overdraagt aan het volgende onderdeel dat weer een stuk van de initialisatie doet en het stokje overdraagt aan het onderdeel erna, enzovoorts.

[bzzzt]

Je hebt dus precies dezelfde attack surface, maar dan verdeeld over verschillende onderdelen...

[Pirate_Pete]

*typo, Valva moet denk ik Valve zijn : )