Finns det någon Linuxdist som är användarvänlig?

Nvidias DRM-del är FOSS, den är bara inte med i kerneln. Men det har vi redan berört.

AMD släpper öppna drivare och kör både deras stängda och öppna mot samma DRM, som är inbakat i kerneln och som de arbetar med upstream. Intel släpper enbart öppna drivare för GNU/Linux och *BSD:erna. Inget av det är i GPL och behöver inte vara.

Jag hade inga problem med att tolka vad du skrev. Jag försökte vara tydlig och försökte uttrycka mig på ett sätt som jag trodde du och andra skulle förstå och samtidigt vara öppen för att jag kunde ha misstolkat vad du skrev. Detta eftersom jag anser att termen videonivåer är tvetydig. Det var inte min mening att väcka anstöt.

Det jag pratar om är Video Quantization Ranges och följer man t.ex. HDMI 1.3 specen så ska alltid Limited range användas för RGB när videoformatet är matchar något av de format som definieras av CEA-861-D (förutom för 640x480p). Hur detta har ändrats i senare versioner av HDMI vet jag inte då jag inte har tillgång till nyare specar.

CEA-861-D specificerar bl.a. en rad vanligt förekommande format som används i film och TV sammanhang. Terminologin där är för övrigt CE video format och IT video format, där det senare används för att benämna alla format som inte definieras i CEA-861-D.

Nu är jag på intet sätt någon expert, men i detta sammanhang uppfattar jag Limited range och Full range som olika videonivåer och mao uppfattar jag termen videonivåer i detta sammanhang som en synonym för Video Quantization Ranges.

Som jag förstått det är det inte TV:n som begär nåt från datorn, utan TV:n (som är en HDMI sink) kommunicerar vad den kan till datorn (som är en HDMI source) och sen är det datorn som väljer vad den vill använda (inom ramen för vad standarden tillåter). Vilken Video Quantization Range som används bestäms då antingen implicit av vilket video format som används, eller genom att datorn explicit signalerar detta (i den mån det är möjligt).

Om TVn har någon form av användarinställning som gör att man "tvingar" den att tolka RGB enligt Full range så blir det troligtvis fel om man använder den och det kan man ju, precis som du säger, inte skylla på operativsystemet.

Däremot bör ju operativsystemet/drivrutinen välja bästa möjliga video format och Video Quantization Range utifrån vad TV:n kan och då ska det, givet att TV:n inte är tvingad till Full range, se rätt ut både för video och skrivbord.

Ser det inte rätt ut så är nånting definitivt fel. Felet behöver inte ligga i datorn, men om det ser rätt ut för videoklipp som spelas upp i ett fönster på skrivbordet men fel ut för skrivbordet i övrigt så tycker jag nog att det lutar åt att felet ligger på datorsidan. Spelar man upp video i fullskärm där ett annat video format används än det som används när skrivbordet visas kan ju felet lika gärna vara på TV-sidan.

Det är just för att de följer CEA/EIA som detta inträffar, där man manuellt måste ändra i både datorn och TVn (eventuellt att de kör något PC-läge i TVn som redan förväntar sig 0-255). TVn kommer inte ändra hur den identifierar sig för att du ändrar till full range (som kan heta normal, PC levels osv) i TVn, samma EDID-information skickas ut i båda fallen. Skrivbordet i Windows vet jag alltid kör 0-255 oavsett vilka nivåer du kör grafikkortet i. Allt i en Linux-distro (olika komponenter och program) kommer knappast köra rätt nivåer heller, därför enklast att köra 0-255 när man kan. Tycker för övrigt inte det är tvetydigt när det är etablerade begrepp och jag har använt limited i tråden också. En monitor (som det finns gott om med HDMI) skickar inte ut information som tyder på att den förväntar sig att man följer CEA/EIA (den kör ju DMT), så där är det inte problem man behöver uppmärksamma. Hårklyveri behöver vi inte ha, ord betyder olika saker och det framgår av hur man formulerar sig. @Laxpudding använder videonivåer respektive datornivåer i sin artikel här på Sweclockers. En videoredigeringssvit däremot kanske kallar RGB limited för studio RGB, men där hör du hur långt ifrån HDMI source och sink vi är.

Man måste ju inte ändra något, Limited range fungerar, men i vissa fall med en aning reducerad kvalitet. Om man prompt vill köra Full-range så kan man behöva ändra manuellt ja.

Ock jag håller med dig. Ställer man om datorn eller TV:n manuellt så att dom inte följer HDMI standarden så sitter felet troligtvis bakom tangentbordet och det ska man inte skylla på OS:et.

Visst EDID kommer inte att ändras, men om TV:n stöder Full-range i de videoformat som CEA-861 definierar så borde den också signalera det i EDID informationen (*). I de fallen torde man ju inte heller behöva manuellt ändra nåt på TV:n.

*) Det jag specifikt menar är QS biten i VCDB (CEA-861-D kap 7.5.6)

En bra poäng. Detta har jag faktiskt inte funderat på förut. Är du säker på att monitorer verkligen alltid använder RGB med omfånget 0..255? Jag menar, det är inte säkert att man faktiskt ser någon större skillnad mellan Limited range och Full range, så det kan ju tänkas att Limited range används när man använder CEA/EIA format utan att man märker av det.

Jag kollade lite i HDMI 1.3 specen och jag funderar på om monitorer kanske identifierar sig som DVI enheter (kap 8.3.3). Annars kan jag tänka mig att dom faktiskt nyttjar QS biten.

Du klagade på att jag hittade på egna termer och jag har försökt förklara för dig varför jag uttryckte mig som jag gjorde. Jag förstår din ståndpunkt och du har troligtvis förstått min, så tänker jag tänker inte lägga ner mer tid på att debattera detta.

Däremot fortsätter jag gärna en diskussionen om det tekniska

Gällande andra svaret, om TVn hade ändrat till rätt nivåer automatiskt (hur nu det skulle gå till, den ser ju bara vilken upplösning, frekvens man kör?) så skulle de inte ens behöva ha en inställning man ändrar manuellt för vilka nivåer man vill köra.

@Laxpudding kanske kan säga något om hur monitorer normalt hanterar EDID över HDMI. Kan bara notera att monitorer ofta har PC-läge och AV/video-läge eller dylikt i menyerna eller likt många TVs där man får välja HDMI-läge på normal eller låg, som du måste ändra för att få det rätt där, och att manualerna ofta beskriver upplösningarna som VESA DMT. Problemet är inte unikt till TVs alltså, men problemet blir det omvända på datorskärmar, då "PC-läget" kommer vara det som skärmen förväntar sig och är förinställt på. Sen att analysera EDID-information från olika skärmar är inget jag sysslat med eller har intresse av. Vet att det finns produkter för att manipulera EDID-informationen i kedjan och de kan också sniffa EDID, men jag har inte gjort något där jag fått problem och behövt använda dessa produkter. Tror inte det finns någon bra lösning här, man får helt enkelt fippla i menyer.

@Petterk: Det enkla svaret är att det är varierar. Tyvärr. Själva principen är enkel, matcha nivåerna och det finns totalt fyra kombinationer av matchningar som jag visar i HDMI-artikeln.

I praktiken vet jag att det inte fungerar så och man måste bli detektiv varje gång. Trots att jag gjort den här inställningen på vad som är 500+ displayer kliar jag huvudet så gott som varenda gång. Till exempel kan betydelsen av "Normal" växla mellan videonivåer för YCbCr och datornivåer för RGB. Samsungs TV brukar fungera så. En del Sony-TV för åtminstone 2014 och 2013 hade omväxlare för detta djupt nere i menyerna. Men de tar effekt först när du bootar om TV:n.

Därför måste man med testmönster komma fram till "rätt svar" för varje kombination av utrustning av källa och display. Att lista ut vad som ger datornivåer (när det är målet) och vilka kombinationer som ger videonivåer (när det är målet) är tyvärr ett måste. Då måste man använda testmönster.

Detta kan i sin tur kompliceras ytterligare av att det internt kan leda till andra problem. Till exempel att andra reglage påverkas av dessa inställningar så att man måste dra i ett brightness-reglage eller liknande för att komma rätt. Testmönster, testmönster, testmönster...

Skrev jag "testmönster"?

@Laxpudding: Kör du med någon vanlig bild eller app för testmönster, eller en dedikerad signalgenerator?

@martinot: Beror på. I första hand signalgenerator om vi talar om AV, hemmabio etc. I andra hand via datorn till exempel Calman Client. Men bara en så enkel sak som http://www.lagom.nl/lcd-test/black.php och http://www.lagom.nl/lcd-test/white.php säger väldigt mycket.

För HTPC-liknande situationer kör jag AVSHD709 som finns som mp4:or. Där ska man också tänka på att programvaran för uppspelning och codec-paket ofta påverkar nivåerna ytterligare. Det gör att man ganska snabbt når kanske dussinet eller fler kombinationer av parametrar som påverkar nivåerna.

Tack för info! Jag arbetar mer på nivån "Hrrm, en svart låda! Mata in parameter X och se vad som kommer ut" eftersom det aldrig finns någon dokumentation som i klartext beskriver hur sakerna fungerar.

Mest extrema exempel jag träffat på är videoboxar från Black Magic Design vilka flaggar ett signalomfång om 16-255. Men de arbetar endast i 16-235-omfång ifråga om den signal den skickar ut på hårdvara. Internt kan mjukvaran i Davinci Resolve påstå andra nivåer än vad som faktiskt skickas. Ändrar man i Davinci Resolve till Full Levels för 0-255-omfång matchar hårdvara och mjukvara. Fast då ändras inte metadata utan det flaggas fortfarande 16-255-omfång vilket får skärmarna att visa helt fel.

Lite offtopic från Linux-distar (jag har inte hängt med i tråden) men det är ett exempel på att man aldrig kan förutsätta något. Man måste bekräfta med testmönster.

Quantum Data 780A och sedan ett par månader den mer potenta kombon av Murideo Six-G och Six-A. Den senare var helt avgörande för att komma på vad som var fel med Davinci/Black Magic-prylarna.

Trevligt!

För att återknyta till fenomenet vi upplever när vi kopplar in en PC till en TV och ställer om datorn till datornivåer. Finns det någon konsument TV eller projektor du har stött på där man inte behöver manuellt ändra till datornivåer/full-range även på den sidan? Blir det någon skillnad att mata ut datornivåer från video-generator? Eller är det alltid att ställa in både källa och mål, och köra testmönster som gäller.

@Petterk: Det fortfarande en kombination av sink och source och deras utbyte av metadata. Så man kan få TV-apparater som på automatik svarar rätt mot en signalgenerator. Men i praktiken med annan källa kan det bete sig annorlunda i vilket fall.

Arghh, det suger att inte ha tillgång till nyare specar Snordyra är dom också! Hade dom kostat några hundra hade jag köpt senaste versionerna, men jag tänker inte lägga $350 på att köpa CEA specen och sen hosta upp ytterligare $5000 för få tillgång till HDMI specen bara för att stilla min nyfikenhet.

Dock har jag hittat en par dokument som jag faktiskt kan länka till: Compliance Testing, Functional Testing and Debugging of HDMI Interfaces Application Note (PDF)

Jag antar att det är ok att länka till dokumentet här på forumet eftersom länken går till Rohde & Schwarz websida. Detta är egentligen ett dokument som beskriver en Rohde & Schwarz produkt, men det finns några insikter om HDMI/CEA standarden att hämta i det.

Ett annat dokument är en presentation från ett föredrag som hölls av en kille på Cisco: Colorspaces and HDMI (PDF)

Jag antar även här att dokumentet är ok att länka till eftersom dokumentet finns att tillgå via anordnarens hemsida. Finns en del matnyttigt att plocka i detta dokument också.

Sen har jag faktiskt hittat att HDMI 1.3 specen numera är gratis. Man kan signa upp sig på http://www.hdmi.org/manufacturer/specification.aspx och sen kan man ladda hem den. Eller så går man till Wikipedia och tar den därifrån. Notera dock att man utöver HDMI specen behöver ha fatt i CEA-861-D.

Jag tror faktiskt inte Q biten ska ignoreras, iaf inte alltid. Kolla i app note:n från Rohde & Schwarz så ser du att det finns testfall för HDMI 1.4. Förvisso bara två testfall, men ändå Jag är lite osäker på om man kan lita på att det som som står i CEA specen gäller för HDMI. HDMI (iaf 1.3) hänvisar till CEA-861, men sen åsidosätter HDMI specen vissa delar (iaf tolkar jag det så).

Det finns säkert fall där source/sink inte kan läsa EDID respektive skicka infoframe, men då är det nog generalknas. En HDMI source ska enligt spec alltid läsa EDID. Vad jag förstår ska en HDMI sink tillhandahålla en EDID (annars tror jag att den blir behandlad som en DVI sink). Det är tom rekommenderat att EDID ska kunna läsas när sinken är avstängd. En source som inte skickar någon infoframe blir nog behandlad som en DVI source.

I teorin borde det se rätt ut utan att fippla med något, såtillvida att bilden borde ha rätt gråskala och vara utan färgstick. Däremot kan det ju bli lite mindre detaljrikt. Jag menar, ta exemplet att sinken inte stöder full-range för CE format. Det vet isf PC:n (drivare/grafikkort) och då ska den konvertera sin representation till den som kommer att användas.

Å andra sidan så har vi ju @Laxpudding's erfarenheter (och presentationen jag länkade till ovan) som helt klart visar på att det inte funkar i praktiken.

Standarden känns rätt rörig så det förvånar mig inte om det finns en massa hel- eller halvkassa implementationer. Sen är det i min erfarenhet så att standarder och obligatoriska finesser/beteenden i dem inte alltid fullt så obligatoriska som man kan tro. Tillverkare tenderar att behandla saker som testas i ev. typprov som obligatoriska, saker om inte testas i typprov får oftast, artigt uttryckt, "mindre kärlek".

Vill man få koll på vad som egentligen funkar i en spec så brukar det vara bra att börja med att kolla på testfallen i typprovsspecen. Finns det inget testfall för en finess eller ett beteende i typprovsspecen så kan man nog utgå från att det blir strul om man vill nyttja den finessen eller förlita sig på det beteendet.

Jag läste häromkvällen nåt om någon som hade moddat/flashat om EDID rommet i sin TV efter att ha upptäckt att hans HDTV identifierade sig som en gammal 15" CRT tjock-TV

Som du noterat så finns det sinks som inte ens har korrekt EDID (rena DVI-skärmar har alltid EDID, precis som tidigare VGA länge hade så handlar mest om vad som finns där då standarden byggts ut med åren, det är ju något som kommer från VESA) så vi behöver inte ens tvivla om att grejer inte testas fullt ut.

Hans Verkuil (Cisco-snubben) har jag noterat bidrar till Linux-drivare gällande HDMI, och kommer från gamla Tandberg som Cisco tog över i vårt grannland i väst. Han är alltså kernel-utvecklare och en Linux-relaterad person. Jobbar också mycket med V4L i allmänhet. Senare är inte så konstigt då det handlar om ett företag som sysslar med system för videokonferens.

Har inte heller tillgång till CEA-861-F och HDMI 2.0, så vet inte exakta formuleringen där. Något med hur YQ används ska dock ha ändrats.

Vill man köra en TV som monitor vill man nog aldrig att den ska konvertera nivåer och dylikt. Det var det TS pratade om att göra, därför han pratade om generella skrivbords-distributioner. Kan du inte stänga av bildbehandling, köra utan overscan alltså typ pixelmappat osv kommer du snabbt bli tokig om du gör annat än sitter i något 10-fot-gränssnitt. Ser inte hur det skulle vara krångligare att göra än reg-hack och liknande du har behövt använda i Windows till ganska nyligen. Det viktiga där är ju bara att du har en TV som går att använda som monitor, där du kan ställa in RGB quant till full, där du kan stänga av all bildbehandling, där du kan köra pixelmappat. För närvarande är det bara Nvidia som har en grafisk kontrollpanel i GNU/Linux, men kan inte se hur Intel skulle gjort något fel här. xrandr, det officiella verktyget fungerar som förväntat, vill man att den ska byta automatiskt till RGB full så har jag länkat skriptet från OpenELEC i tråden, som bara är en service du behöver starta. Trådskaparen är däremot inte intresserad av att pröva några nya lösningar. Hur som helst, en annan TV hade inte gjort det enklare då TV-modellerna förmodligen har inställningarna för att det inte fungerar automatiskt oavsett hur rätt källan är i sin sak så du troligtvis hade fått samma resultat med andra modeller. Plus att du förmodligen vill ändra inställningar i menyerna i vilket fall som helst, så så mycket smidigare går det inte att göra.

Med en datorskärm får man som sagt det omvända problemet istället, tveksamt stöd och behöva fippla i menyerna för att köra vanliga videokällor. Det är bara att notera att man får kompromissa. Sen finns det anledning till att det finns produkter som kan manipulera EDID riktade mot konsumenter och liknande. Det behövs ibland manipulation för att få grejerna att fungera, för att korrigera fel prylar gör.

I Intels drivrutiner kom hur som helst denna kommentar i en ändring ganska nyligen, se spoilern.

/*
 * CEA-861-F:
 * "When transmitting any RGB colorimetry, the Source should set the
 *  YQ-field to match the RGB Quantization Range being transmitted
 *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 *  set YQ=1) and the Sink shall ignore the YQ-field."
 */

Edit, varför de kör denna lösning i HDMI 2.0 vet jag inte, men resultatet bör bli att du sätter YQ och Q till samma range (YQ=1, Q=2) och då bortser HDMI sink från YQ? Som den ändå borde bortse från när man matar RGB? Hur som helst är det något som Intels drivrutin har fått stöd för, så den skickar säkert ut rätt värde på Q också. Sedan långt tidigare.

/*
 * CEA-861-F:
 * "When transmitting any RGB colorimetry, the Source should set the
 *  YQ-field to match the RGB Quantization Range being transmitted
 *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 *  set YQ=1) and the Sink shall ignore the YQ-field."
 */

Jag såg den patchen innan. Det går inte att veta varför utan att läsa specen och dessutom antagligen ha tillgång till protokoll eller liknande från standardiseringsmötena (så att man ser bakgrunden till varför). En ren gissning från min sida är att det kan vara nån form av skadekontroll av något vanligt fel dom sett, typ att en massa TV apparater kollar på YQ biten istället för Q biten för RGB (vore inte första gången nåt sånt har hänt). Men det är som sagt ren spekulation.

Fanns ens YQ innan HDMI 2.0 och CEA-861-F? Hur som helst, oavsett vad man kör för inställningar så kommer grejerna bete sig annorlunda mot vad man tänkt sig. Därför tror jag inte det blir så mycket bättre än att man får ställa in saker både på source och sink, så som rätt nivåer. Här fungerar ju iaf Intels drivrutin, det har varit problem även på Windows tidigare att ställa in "RGB full range" för både AMD, Intel och Nvidia och krävt lite olika lösningar. Även om det kommit till att det räcka med med kontrollpanelerna i Windows nu så är det som sagt inget man kan vänta sig fungerar utan att gräva lite i menyer. Med TV som skärm ska man förvänta sig att grafiken kommer ställas in på limited, så långt följer både TV och dator standarden och fungerar som förväntat. Men som sagt, både datorer och TVs har kommit så långt att man inte bör fastna utan att hitta en lösning. Då HDMI är baserat på DVI ska man ha riktig otur om man lyckats skaffa något som inte lirar efter lite handpåläggning.

Hur mycket som helst. Listan kan göras helt sjukt lång.

Om du har ett modulärt system, är det bara kärnan som utgör systemet? Kärnan gör inte så mycket utan SCI, minneshantering m.m och inte heller utan verktygskedjan eller alla saker som körs i user space. Jag ser ingen mening med att stycka upp kritiken av Linux utifrån det, något som knappast gör saker enklare eller tydligare.

Skickades från m.sweclockers.com

Ja det är väl välkänt om du plockar en random dist för privatpersoner så hoppar du in i just deras variant av "ekosystemet".
Och massor av organisationer och personer har sina egna idéer, så det landar i rätt så olika paketering.

Därför finns det produkter som RHEL, SUSE Enterprise Server, Oracle m.m.

Låter som att man vaknat lite på fel sida idag?
Linux distributioners ekosystem och koncepten kring dem kan säkerligen vara svåra att greppa för en oinsatt.
Personligen tycker jag att ex. pakethanteringssytemen som du nämner fungerar förträffligt för mina ändamål, det finns dem som tycker att pillandet i Windows ex. googla runt och ladda ner programvara från främmande sajter och sedan installera dem i sekventiell ordning är minst lika störande som när paketberoenden inte lirar korrekt. Detta leder direkt till kontentan att folk är olika och ser saker på olika sätt samt föredrar olika lösningar, vilket i sig ger upphov till alla forks inom Linux världen. Take it or leave it.

Håller med om det. Nu tycker jag iofs. att det blivit bättre i både Windows och MacOS med deras egna butiker som innebär att man kan inte måste gå ut lika ofta till okända och potentiellt osäkra källor för programinstallation och uppdateringar. (Vi är inte helt där än, men går åt rätt håll ivf.)

Helt klart är det så, alla OS idag har möjlighet till någon typ av pakethantering och det är underbart att man slipper den extra handpåläggningen i de sammanhangen.
Men precis som du nämner: de är inte där ännu, men det rör på sig i rätt riktning!

Jag vet inte men de dagar jag behöver komma i kontakt med Windows så svär jag över dess dumhet och oförmåga att vara effektivt. Är ett Linuxsystem något för alla (på det sätt det ser ut idag)? Garanterat inte. Det kräver i de allra flesta fall att man har intresse att förstå systemet (och det tar år av erfarenhet innan man gör ordentligt).

I mitt tycke så är det mesta logiskt i ett Linux-system. Jag vet hur det beter sig och jag vet vad jag kan göra för att få det att bete sig som jag vill, något som är omöjligt på Windows/MacOS. Sen finns det en hel del lösningar som är smartare i andra *nix-system, mer specifikt OpenBSD/FreeBSD men som helhet finns det inget bättre system idag än Linux, i mitt tycke.

Kort och gott; Linux låter mig vara effektiv och sköta mitt jobb på ett effektivt sätt utan att vara ivägen, tvärtom, det är mitt hjälpmedel.

(Jag kommer själv från en Windows-bakgrund från början. Det är svårt att sätta sig in i ett nytt system utan att jämföra med hur saker fungerar i Windows. Visst är det så att det finns saker som inte fungerar, alls, eller lika bra i Linux som de gör på Windows. I många fall dock så finns det en anledning bakom eller så finns det andra lösningar på problemet som man inte känner till. Samtidigt är det jobbigt att lära sig saker på nytt helt enkelt och de flesta av oss är för bekväma för att göra det ordentligt. Vi vill bara att saker och ting ska fungera )