HDMI Forum förbjuder AMD att dela källkoden till HDMI 2.1-drivrutin

Har det med HDCP att göra ?

HDCP stands for High-bandwidth Digital Content Protection. The purpose of HDCP is to protect digital copyrighted content as it travels from a device to your TV

Först och främst misstänker ju jag att det främst är interaktionen DRM <-> DMCA som är viktig för rättighetsinnehavarna.
Dvs att det automatiskt blir olagligt att gå runt ett kopieringsskydd som finns på plats, inte att kopieringsskyddet behöver vara oknäckbart.

Men OM då detta handlar om något DRM-relaterat som AMD skulle behöva inkludera så kan det ju isf handla om hur långt man från officiellt håll (HDMI, dess partners som AMD) i vad man publicerar innan man tummat så mycket på det hela att det kanske slutar räknas.

Och jag antar att själva problemet egentligen snarast är alla de rättighetsrelaterade avtal som kräver att detta DRM finns hela vägen till uppspelande komponent. HDMI är förmodligen "too big to fail" snarare än att de inte öht förstår hur verkligheten ser ut.

Håller du med om att det finns gott om exempel på öppna implenentationer av proprietära protokoll/standarder osv där de tagits fram genom reverse engineering? SAMBA i Linux/MacOS, LibreOffice och LAME är några exempel. Är dessa olagliga?

Om källkoden för AMD:s HDMI 2.1-kod skulle läckas skulle det definitivt underlätta reverse engineering av standarden. Nu är antagligen få här jurister och man skulle kunna argumentera att den som sett den läckta källkoden inte kan göra reverse engineering då den har förkunskap om specen. Min gissning är att detta inte håller rättsligt i praktiken. Den tänkta kod jag syftar på är en helt ny implementation utifrån utvecklarens förståelse av HDMI 2.1-standarden.

Sen en detalj. Källkoden tillhör AMD, specifikationen tillhör HDMI Forum.

Och en fråga - menar du att det är omöjligt att skriva en FOSS drivrutin av HDMI 2.1 oavsett hur den tagits fram eller är det just en kopia av AMD:s kod du syftar på?

Vad är det du lutar dig mot när du kommer med detta påstående? På samma sätt du argumenterar för att öppen källkod skulle vara mer sårbar på grund av mängden ögon på koden kan man vända på det. Öppen källkod kan lättare granskas avseende eventuella brister än ett slutet dito och bårde på så vis vara säkrare.

Min uppfattning är att detta är en evig fråga inom IT. Det finns starka ekonomiska incitament bakom de som menar att sluten källkod är bättre. Ssmtidigt är det allmänt vedertaget att security by obscurity är dålig design. Vi har även Kerckhoffs princip som relaterar till det förra begreppet. Principen kan sammanfattas med att ett korrekt implementerat kryptografiskt system ska vara lika säkert även om all information om det blir känt sånär som på nyckeln. Detta formulerades om av den amerikanske professorn Steven M. Bellovin som:

In other words — design your system assuming that your opponents know it in detail. (A former official at NSA's National Computer Security Center told me that the standard assumption there was that serial number 1 of any new device was delivered to the Kremlin.)

Ja Clean room design är termen jag söker i detta fall. Saxat från wikipediaartikeln:

"Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners."

Detta är rätt nära vad som skulle kunna hända vid en hypotetisk läcka av AMD:s kod/reverse engineering. Specen blir känd -> ny kod kan skrivas utifrån denna.

Skulle vilja se dina belägg för detta för det strider mot all praxis, erfarenhet och kunskap inom it-säkerhet.

All mjukvara, gäller både stängd och öppen, innehåller total avskrivning av legalt ansvar så det är också en punkt du kan stryka helt. Den enda part som du kan hålla legalt ansvarig för är din leverantör och det gör du då via direkt kontrakt och då kvitter det stort om koden är öppen eller stängd.

Stor risk? DSC är visuellt lossless och då få fall med artefakter som man kan googla sig till handlar om dåliga kablar.

Nej för HDCP har de redan stöd för i HDMI2.0 som fungerar utan problem med AMD:s drivrutiner, det är enbart 2.1 stödet som HDMI inte tillåter. Så det har inget med DRM eller med kopieringsskydd att göra utan att HDMI IF inte vill att den dyra specifikationen för 2.1 ska kunna publiceras på minsta vis.

Om det finns kloka människor ( och de finns), kan de genom att titta på den ursprungliga/originala koden bygga sin egen. (Till och med förbättra den.)
Man behöver blind copy-paste. Man behöver uppfattningen om hur den fungerar, för att kunna bygga alternativa mjukvarolösningar.

Beror på vem du frågar

Men min åsikt är förmodligen inte.
HDCP går att kringgå, och är inte särskilt komplicerat.
Det här är något som alla som någonsin försökt spela in eller streama Playstation 3 spel har behövt göra.

Det du pratar om har redan provats.

ReactOS behövde spendera väldigt lång tid (runt ett år om jag minns rätt) på att riva ut kod skriven av en utvecklare som visade sig ha läst läckt källkod av någon Windows-version. Allt som revs behövde skrivas om eftersom det var funktionalitet som användes och det satte käppar i hjulen för all annan utveckling som inte längre kunde testköras mot ett fungerande kodträd.

Kort sagt så skulle det inte hjälpa alls med läckt källkod, snarare tvärt om eftersom du måste hålla de som har läst den läckta koden borta. Det enda vi kan göra är att vänta och se om AMD kan implementera stödet i firmware istället, om inte på existerande kort så kanske på framtida.

Man kan fortfarande tänka sig scenariot att man utifrån en läckt källkod formulerar en specifikation för standarden. Denna specifikation kan skickas till en annan grupp utvecklare. De kam sedan skrivan en helt egen implementation. Detta är ju i princip https://en.wikipedia.org/wiki/Clean_room_design och borde vara ok.

Det här är ju så dåligt.

Det sätter ju Linux-användare i en tråkig rävsax.

Ska man välja AMD så att man får drivrutiner som är open source, men där HDMI 2.1-funktionaliteten saknas? Eller ska man välja Nvidia där drivrutinerna är stängda men (antar jag?) man får access till HDMI 2.1?

Det minst dåliga sättet för AMD att lösa detta vore att lägga in HDMI 2.1-stödet i en binär blobb som användarna får välja om de laddar eller ej. Men allra bästa är ju om HDMI Forum drar åt helvete med sin stängda källkod.

Efter fiaskot med ReactOS så tror jag att få är villiga att ta den risken, även om det skulle gå att komma undan med i domstol. Typiskt har man juridisk rådgivning med sig om man ger sig in i något sådant och få privatpersoner kommer att betala för det.

För de som ändå vill ha en fungerande lösning så går det att använda en speciell modell av DP->HDMI-adapter som diskuteras i denna tråd: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_221... . Om man vill ha VRR så finns det även en firmware till adaptern med stöd för det här: https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_226... .

Jag har inte testat lösningen själv och jag vet inte hur svårt det är att byta firmware på adaptern men lösningen finns.

Jag är ingen jurist och det finns ju många domstolar världen över. Svårt att veta. Jag tror dock att clean room design kommer att leva vidare. Egentligen är väl ReactOS i sin helhet exempel på det.

Det finns ju dock knappt några moderna exempel på det.
I Wikipedia är väl senaste Sony 1999?

Det löser väl inget i det här specifika fallet?

Både Intel och Nvidia har stöd för HDMI 2.1 med sina öppna Linux-drivrutiner, Intel genom att bara ha DP i GPUn och konvertera till HDMI med en extern krets och Nvidia genom att implementera de känsliga delarna i firmware.

Fast om man redan har ett AMD-kort och kommer på att man vill använda HDMI 2.1 så blir det problem förstås.

Borde det inte vara möjligt för AMD att ta fram en firmware uppdatering som lägger till implementationen i firmware på befintliga kort? Vore nog den smidigaste för de få som har behovet om nu möjligt.

troligtvis inte för de har ingen krets att lägga det i, t.ex nVidia har en hel risc-v cpu (GSP) på kortet som hanterar sånt här, det har inte AMD.

Ah, låter krångligare då. :/