[HN Gopher] HDMI Forum Rejects Open-Source HDMI 2.1 Driver Suppo...
___________________________________________________________________
HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought by
AMD
Author : jiripospisil
Score : 197 points
Date : 2024-02-28 20:53 UTC (2 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| silisili wrote:
| Serious question, what if they just ignore the Forum and do it
| anyways?
| mperham wrote:
| They will get sued and lose.
| baby_souffle wrote:
| > Serious question, what if they just ignore the Forum and do
| it anyways?
|
| Probably makes it tricky to get HDMI forum's blessing for any
| future devices. AFAIK, the hdmi standards are public-ish so
| anybody can create a device that is HDMI compatible but you're
| only allowed to put "HDMI" on the packaging / marketing
| material with the forum's blessing.
| xnyan wrote:
| HDMI((r)) is a trademark as well as a proprietary protocol. The
| only way to legally use the HDMI label is with approval of the
| forum.
| toast0 wrote:
| Just call it a 19-bin display connector in that case. Or only
| put in dual-mode display port connectors (DP++), and let
| people get passive adapters (maybe bundle them for a bit; you
| can probably label the passive adapters as HDMI)
| notpushkin wrote:
| > Just call it a 19-bin display connector in that case
|
| Flipper x Raspberry Pi did exactly that just a couple days
| ago: https://blog.flipper.net/introducing-video-game-
| module-power...
|
| > Video Out port: DVI-D signal in 640kh480 px, 60 Hz. The
| port supports a well-known video standard that we can't
| name due to copyright limitations :shush: The first letter
| is H, and the last one is I.
| 0xcde4c3db wrote:
| This is pretty much an actual strategy. The
| academic/crowdfunded ULX3S FPGA development board went with
| calling it "GPDI" (general-purpose digital interface).
| Other strategies include labeling the connector with a
| little TV/monitor icon, calling it "digital video", or just
| having a little diagram in the marketing/documentation
| material with it connected to a TV with a vaguely HDMI-
| shaped cable.
| Crosseye_Jack wrote:
| At best: Get kicked out of the forum and can never support HDMI
| products going forward.
|
| At Worse: Get sued for breaking NDA, lose, pay a metric fuck
| ton in damages, and get kicked out of the forum and can never
| support HDMI products going forward.
| amlib wrote:
| What if _someone_ makes an unofficial patch with HDMI 2.1
| support? You could at least compile your own damn kernel with
| the damn thing supported.
| Crosseye_Jack wrote:
| If _someone_ released an unofficial patch for the official
| OSS driver it might get by, it might get "DMCA'ed", though
| DMCA might not be the correct takedown method for patent
| violations (I'm just presuming this _someone_ released only
| their own code and nothing from AMD, so AMD wouldn't have a
| copyright claim over the code itself), but hey thats never
| stopped companies mis-using the DMCA in the past! To file a
| valid counter notice to a DMCA, that _someone_ would have
| to give details which the forum could then use to sue the
| publisher of the patch.
|
| But yeah even if the patch some how was made public, and it
| wasn't nuked out of orbit, ongoing support and bug fixes
| would be a pain in the ass. (Because as an example, no one
| from AMD would be allowed to touch the "patch code")
|
| <edit> If AMD's planned patch was leaked for example, as
| AMD had not officially released it, its not yet "open
| source" and because of that, not yet public, and I'm sure
| there will be a clause in the terms that state that AMD
| would have to go on the offensive to get their code removed
| from any public repos. </edit>
|
| When it comes to lawfare, The Forum wouldn't have to be in
| the right (in a legal sense), just have a big enough war
| chest to make everyone else's life a pain in the ass!
| rodgerd wrote:
| "HDMI" is a trademark. You can't claim to offer HDMI in any of
| your products.
|
| The patent pools around approximately all the codecs used for
| media delivery are heavily cross-licensed. That includes HDMI
| and HDCP, but also h.264 and h.265. Most likely AMD can't
| legally use hardware decoding or encoding of any popular codecs
| at that point. Good luck with game video, streaming, or playing
| media discs.
|
| So it would cost AMD - for example - their entire
| PlayStation/XBox business. At a minimum.
| mikece wrote:
| "Needless to say, open-source Linux advocates should try to use
| DisplayPort instead if at all possible."
|
| And at this point that's one of the several (many?) protocols
| that runs over a USB-C cable, right?
| conradev wrote:
| DisplayPort is packet-based and can be multiplexed with other
| USB-C traffic through a hub
|
| HDMI is not packet-based and so when it uses USB-C it takes
| over the entire cable (alt-mode)
| baby_souffle wrote:
| > DisplayPort is packet-based and can be multiplexed with
| other USB-C traffic through a hub
|
| This is part of why DP is $$$ compared to HDMI. I would love
| to see DP start eating HDMI's lunch after this and the
| absolute shit show that was the HDMI 2.0 roll out but cheaper
| to implement is almost certainly going to be the driving
| factor when it comes to consumer grade TV / Displays and no
| console or other set top box maker is going to bother putting
| display port on their device if nobody's got a TV that can
| use it.
| tverbeure wrote:
| > This is part of why DP is $$$ compared to HDMI.
|
| Why is that more expensive?
|
| In terms of complexity, implementing DP vs HDMI 2.1 is not
| materially different. They both have fixed rate links,
| packets, Reed-Solomon forward error correction, DSC, etc.
|
| But IIRC DP is royalty free, and HDMI is not.
| refulgentis wrote:
| It sounds like it might be more about "the market will
| pay more for the packet-based approach, and we shall
| charge what the market will bear"
| tverbeure wrote:
| Speaking about 'packet-based approach', the way it's
| presented in the popular press as if it's similar to
| Ethernet, is a pretty gross distortion, the impact of
| which is not nearly as much as people seem to think it
| is.
|
| You can check that there in this presentation
| (https://www.vesa.org/wp-content/uploads/2011/01/ICCE-
| Present...), page 32 and 33.
|
| The majority of DP traffic is still brute force video
| data, interspersed with heavily packetized secondary
| data.
|
| Over the years, I've spent many hours wading through
| DisplayPort data debug traces, and I've always wondered
| what people were smoking when they called it 'packetized
| like Ethernet'. It's just not true. (And FWIW: even old
| HDMI can transport secondary data packets just the way
| you can with DP. It's how audio-over-HDMI is done...)
| babypuncher wrote:
| It won't happen unless VESA gets serious about adding home
| theater specific features to DP that HDMI has had for 20
| years.
| wolfhumble wrote:
| > HDMI is not packet-based and so when it uses USB-C it takes
| over the entire cable (alt-mode)
|
| What does this exactly mean? I have an USB-C 4x1 Hub with
| HDMI that works at the same time as using 2 x USB-A 3.0, 1 x
| USB-C. Thanks!
| izacus wrote:
| It means that your hub uses DisplayPort to talk to the
| computer and then has a converter chip to convert to HDMI.
|
| Pretty much noone used HDMI Alt Mode on USB-C and is now
| deprecated IIRC.
| wolfhumble wrote:
| Okay, thanks!
| justsomehnguy wrote:
| Reminds me of Ethernet over HDMI.
| cesarb wrote:
| > HDMI is not packet-based and so when it uses USB-C it takes
| over the entire cable (alt-mode)
|
| AFAIK, when HDMI is used over USB-C, it's actually
| DisplayPort over USB-C; while a HDMI alt mode was specified,
| nobody actually implemented it, everyone instead implemented
| the DisplayPort alt mode and then used a DP-to-HDMI converter
| chip whenever an HDMI output was required.
|
| > DisplayPort is packet-based and can be multiplexed with
| other USB-C traffic through a hub
|
| That's the case only for USB4 (and AFAIK earlier Thunderbolt
| 3). Other USB-C ports with DisplayPort alt mode simply use
| some of the USB 3.x pairs for raw DisplayPort, and whenever
| the use of all four USB 3.x pairs is required for DisplayPort
| due to the target resolution, then only USB 2.x can be
| available (USB 2.x has its own dedicated pair in the cable).
| Cu3PO42 wrote:
| Yes. You can run "DisplayPort Alt Mode" over USB-C. You can
| also transport DP over Thunderbolt over USB-C.
|
| HDMI Alt Mode also was a thing, but is now deprecated.
| whalesalad wrote:
| I am using a displayport to usb-c to connect an amd gpu to an
| apple display and it works well.
| TedDoesntTalk wrote:
| You can run HDMI over ethernet CAT-6 cables, too.
| gamepsys wrote:
| You can run DP over USB-C. It's a use case they specifically
| support. However, if you are the cutting edge you will be using
| the actual DP cords. DP2.1 uses 80Gbit/s and Thunderbolt 3
| USB-C is only 40 GBit/s. Once you start pushing high
| resolutions (at least 4K) and high framrates the entire system
| will be bottle necked by the cable. Top end displays are always
| designed to take advantage of the latest DP port, and use the
| entire bandwidth.
|
| USB4 will push 120GBit/s. This will be enough for 8k 120hz/4k
| 240hz but not much more. This will probably be enough for high
| end consumer displays and GPUs for a decade out or so.
| fuzzy2 wrote:
| Actually, it is the only (display) protocol. HMDI Alt Mode,
| while specified, never really manifested and is effectively
| dead. DisplayPort is the only alternative and is more flexible
| anyway.
|
| Its packet-based nature is not relevant for DisplayPort Alt
| Mode, by the way, because it gets dedicated pins. Sometimes
| enough for two lanes, sometimes enough for four. It's
| hilariously consumer-unfriendly. Only Thunderbolt leverages the
| packet stuff and can transport up to eight lanes worth of
| DisplayPort.
|
| macOS does not support MST.
|
| Who is supposed to get this? I don't know.
| lucasyvas wrote:
| This seems like a bigger deal that it looks like - this flat out
| kills the legitimacy of HDMI in my mind. There's no reason to
| keep it.
| baq wrote:
| You're right but I don't think tv manufacturers care.
| lallysingh wrote:
| There are lots of TV manufacturers to choose from,
| thankfully.
| olyjohn wrote:
| Well if you find one that sells TVs with DisplayPorts, let
| us know.
| gorjusborg wrote:
| With all the garbage that comes on TVs now, this is just
| another reason to buy a monitor with an audio-out
| instead.
| Hamuko wrote:
| How many TV manufacturers actually use DisplayPort?
| whoopdedo wrote:
| Are there? This seems to be one of those illusion of choice
| industries where the different brands are only relabeling
| of the same factory reference designs.
| akira2501 wrote:
| I remember when markets were considered through the will of
| consumers. I miss those days.
| riehwvfbk wrote:
| HDCP
| Cu3PO42 wrote:
| DisplayPort supports HDCP.
| riehwvfbk wrote:
| In theory, but I think it's common for devices to only
| enable it on HDMI ports.
| SushiHippie wrote:
| Is there any reason I'd want to use HDMI instead of DisplayPort?
| alexsereno wrote:
| Masochism
| fnordpiglet wrote:
| Your device doesn't have display port interfaces I guess. So
| for instance if you have a raspberry pi, you're using HDMI one
| way or another.
| rodgerd wrote:
| Good luck finding an AV receiver or TV with DisplayPort.
|
| This pretty much locks any media players into proprietary
| drivers.
| Chabsff wrote:
| DisplayPort to HDMI converters trivially solve that. Let the
| TV consume HDMI all it wants while still "just" outputting DP
| from the computer.
| krs_ wrote:
| Are there DP -> HDMI 2.1 adapters available that supports
| 4k120hz with VRR and HDR? I've not seen any although I've
| not looked too hard.
| mianos wrote:
| There are many more displays that support hdmi. It is a simpler
| protocol. Display port is better and more modern, it's
| packetised so the timing is not fixed by the source like udp.
| HDMI is fixed timing and used to be much simpler hardware.
| tverbeure wrote:
| > HDMI is fixed timing and used to be much simpler hardware.
|
| What do you mean by 'fixed timing'? The fact that the
| transmission data rate is proportional to the pixel clock?
|
| We're talking HDMI 2.1 here, which uses FRL (fixed rate link)
| and thus has pixel clock decoupled from the pixel clock just
| like for DP, with data split into packets. There's not a lot
| of difference between DP and HDMI in terms of functionality
| and complexity.
| Tade0 wrote:
| In some laptops the HDMI port is managed by the integrated GPU
| and the DisplayPort by the discrete GPU, so ultimately it
| affects which GPU you're using.
| MegaDeKay wrote:
| Taking a bit of a step back from your question, this Hackaday
| article on why DisplayPort is so much better than HDMI from a
| technical perspective is great.
|
| https://hackaday.com/2023/07/11/displayport-a-better-video-i...
| TedDoesntTalk wrote:
| Does DisplayPort support audio?
| izacus wrote:
| Yes. (Although I'm not sure if it supports bitstreaming
| formats like Dolby Digital, Atmos and DTS.)
| betaby wrote:
| It does.
| adrian_b wrote:
| Yes, it does.
|
| I am writing this in Linux, while looking at a Dell monitor
| connected through DisplayPort, and my loudspeakers are
| connected to an audio output of the monitor.
| Strom wrote:
| If you want big resolutions and big refresh rates. For example
| I have a 4K screen with 144 Hz refresh rate. That sort of
| bandwidth can only be delivered right now via HDMI 2.1.
|
| Yes there are DisplayPort standards that can reach that, but in
| practice all the top end GPUs have only the old DisplayPort 1.4
| version. That means the only choices are to use HDMI 2.1 or to
| use video compression over DisplayPort 1.4.
|
| I will say that VESA has been very successful with their
| Display Stream Compression (DSC). Not that the algorithm is
| something special, but in terms of marketing. You never see
| monitor reviewers talk about the fact that using DSC will give
| you artifacts. VESA markets this compression as visually
| lossless, which every non-expert explains as actually lossless.
| In reality the losslessness is defined in the standard as when
| all the observers fail to correctly identify the reference
| image more than 75% of the trials. Beyond that, like with any
| compression, it will fail at high entropy images. Take for
| example this 2017 study titled _Large Scale Subjective
| Evaluation of Display Stream Compression_ [1] which found that
| _performance on some images was not visually lossless, however,
| those images were challenging images with high entropy_.
|
| --
|
| [1]
| https://www.researchgate.net/publication/317425815_Large_Sca...
| izacus wrote:
| That's great, but have you actually seen those artifacts
| ever?
|
| (DSC also has a great property of making the image delivery
| significantly more resilient to cable issues and thus much
| more reliable for most people using high res monitors.)
| Strom wrote:
| > _That 's great, but have you actually seen those
| artifacts ever?_
|
| No, I use HDMI 2.1 without DSC.
|
| Otherwise though, yes I have very good vision and work with
| images professionally. I do spot artifacts when they are
| there.
|
| I get it that not everyone needs perfect images. I mean,
| people watching YouTube certainly won't be able to tell if
| there is an additional artifact on top of the low bitrate
| video they're watching.
| Sakos wrote:
| DSC also has the great property of causing my RTX 3060 to
| crash if I try to watch videos on an external monitor and
| do the wrong thing on my main display. This issue has gone
| unresolved for over a year now. HDMI, DSC and NVIDIA can go
| eat a big bag of dicks.
| zokier wrote:
| [delayed]
| thomastjeffery wrote:
| Most displays that are marketed as a "TV" instead of a
| "monitor" are exclusively HDMI. This is why many TVs from ~2020
| don't have any 4K@120 input, despite actually displaying at
| 4K@120 (from the internal GPU that does frame interpolation),
| because HDMI 2.0 is limited to 4K@60.
| Cu3PO42 wrote:
| This is upsetting on principle alone. But I'm also upset because
| I have my PC hooked up to my TV for couch gaming and was hoping
| to do that on Linux sooner rather than later when HDR works
| properly. I wasn't aware HDMI 2.1 was another problem... I guess
| Windows is sticking around for that.
| macNchz wrote:
| FWIW I have my Linux desktop hooked up to a 4k/120hz TV via a
| $30 CableMatters DisplayPort->HDMI dongle that seemingly
| supports most of the relevant functionality, as far as I can
| tell. It even works very smoothly over a 50 foot active fiber
| optic HDMI cable. There is a ton of discussion about these
| dongles in the issue thread linked in the article.
| boomskats wrote:
| HDMI 2.0 is capable of doing 4k @ 120Hz, but only up to YCbCr
| 4:2:0 8bit instead of the full YCbCr 4:4:4 10bit (though I'm
| not sure how close wayland is to 10bit support). It will be
| fine for gaming, just not for everyday PC use.
|
| FWIW I also didn't realise this until just now. I've been
| running my desktop at 4k@120hz recently for the buttery smooth
| neovide, but have been noticing that text rendering, especially
| syntax-highlighted text, looks awful. I'd seen the same oled
| panel render text way better in WSL/Windows (both using a
| custom pixel geometry[0] via Mactype, but also without), so I
| spent more time than I'm willing to admit to wrapping my head
| around custom pixel layouts and hinting in freetype. But no,
| turns out it was this all along.
|
| If you want to see the effect of 420 vs 444 chroma subsampling
| on text rendering, this writeup[1] has some great test images
| and is well worth a read. Also, if you happen to have an LG
| OLED panel, you can get a little debug window that confirms
| your signal format and refresh rate, by pressing the green
| button on the remote 7-8 times.
|
| [0]: https://github.com/snowie2000/mactype/issues/720 [1]:
| https://www.rtings.com/tv/learn/chroma-subsampling
| Jun8 wrote:
| For the longest time (like, the past 15 years) I've wanted a
| cheap small box that can overlay custom info, eg text, on the TV.
| The reason such a thing does not exist, other than projects like
| Bunnie's NeTV (https://makezine.com/article/technology/review-
| hardware-hack...) is that decoding HDMI signals is illegal if
| you're not in the club. I think the ELI5 reason is that content
| providers are afraid of unauthorized copying of DVDs (try taking
| a screenshot of a frame from your DVD player on your laptop).
|
| I'd be willing to pay up to $199 for such a box if it has an open
| API to input overlay text and icons.
| salawat wrote:
| You are correct. Pay attention to the conspicuously lacking
| feature. Odds are there's industrial collusion to keep it that
| way.
| refulgentis wrote:
| It sounds like you've taken a deep long journey into the mess
| here: I'm curious, what does it take to be a member of the
| club?
|
| I hope it's not just FAANGs and blessed hardware OEMs...but it
| also sounds likely it must be, you can't let just anyone in if
| you're worried about the specs leaking...but then again that
| sounds weird too, in that, they used to provide the spec more
| openly until 2.1?
| metaphor wrote:
| HDMI adopter registration details here[1]; in general, $10k
| annual fee + royalties and of bunch of legalese. Prevailing
| list of 2451 adopters and affiliates here[2]; yes, AMD
| (listed as unabbreviated Advanced Micro Devices) has been a
| registered Adopter since Aug 2006 and is currently listed as
| a 2.1b licensee.
|
| [1]https://www.hdmi.org/register/adopterregister
|
| [2] https://www.hdmi.org/adopter/adoptersaffiliates
| bombcar wrote:
| You can get devices that "hack" HDMI to various other
| unprotected signals such as SDI. So you get a Decimator or
| something, covert HDMI to SDI, and then do the needful.
|
| Now that may not help you, as the devices that do SDI overlays
| run in the $1k range, but maybe something is out there like a
| ATEM SDI https://www.blackmagicdesign.com/products/atemsdi
| mschuster91 wrote:
| Blackmagic's Mini Converters are at their core nothing more
| than SerDes chips and an FPGA that does the protocol
| translation. I _think_ that the recent models with USB-C
| power supply inputs also have the data pins connected to the
| FPGA.
|
| Might be worth a try to check how hard BMD has locked down
| the FPGA bitstream.
| bombcar wrote:
| I know the Decimators would remove HDCP, as it's a known
| "trick" when trying to project from a Mac. But not sure
| which versions, and how well.
| goosedragons wrote:
| Is there a reason a RPi or whatever with a cheap USB HDMI
| capture card isn't a good option? I guess there might be a
| minor quality loss but it should do what you want.
| MenhirMike wrote:
| HDCP usually is an issue if you can't turn it off on the
| source. There are ways around that, though those are more
| than $199 if you're dealing with an HDMI 2.x source.
| 0cf8612b2e1e wrote:
| I thought there were cheap converters that could go HDMI
| 2->1?
| treflop wrote:
| I bought a HDMI 2.0 splitter that strips HDCP a while back
| for $20.
| thwarted wrote:
| While reading your comment I was reminded of the much touted
| key capabilities of the Video Toaster (late 80s), it's
| character generator and chromakey, used to do exactly that:
| overlaying text on video, for a fraction of the cost of what
| professional video production cost. And now, 30+ years later,
| we _still_ don 't have an accessible way to do that using
| modern video tech/protocols, but now it's about rent seeking
| and licencing rather than technical capability.
| jethro_tell wrote:
| That brings back some good memories. I had access to a video
| toaster setup a couple days a week after school as well as
| library checkouts of big vhs camera recorders. We'd get a
| stack of tapes, do the 1 day rental of a camera and record
| all over the neighborhood, then after school we'd take the
| tapes in to the studio and mix them together.
|
| All dumb shit, but you know we were kids.
| wmf wrote:
| There's tons of stuff out there. The ATEM Mini Pro can do
| keying and a bunch more for $300.
|
| In general, audio and video production have never been
| cheaper or more accessible. There's no conspiracy of The Man
| keeping people down.
| sottol wrote:
| I don't know if the ~$20 HDMI USB capture cards work on a
| raspberry pi, but connecting one to a pi or laptop and
| capturing the signal to a v4l stream, overlaying in software
| and then outputting on built-in HDMI out might work?
| dtx1 wrote:
| I don't know about quality but I guess a Raspberry Pi, HDMI
| Capture Card and OBS would do the trick and are within that
| price range.
| RobotToaster wrote:
| There appears to be at least one open source HDMI
| implementation https://github.com/hdl-util/hdmi
| tim-- wrote:
| From what I understand (and I could be _very_ wrong here) the
| biggest issue here is simply the amount of memory that is
| required in order to keep a copy of the current frame from a
| HDMI signal, and the fact that to modify anything in the HDMI
| signal, you need to decrypt (if watching a HDCP protected
| stream), decode each frame, and then finally re-encrypt the
| HDMI signal.
|
| I was looking into what would be necessary to build a HDMI
| switch that allowed for seamless switching of video between
| different inputs, and basically there was no hardware for it.
| The closest chips that I could find was Analog Devices' ADV7626
| and Lattice's SiI9777S.
|
| Lattice CP9777 might be worth having a look at if you can
| understand anything about the datasheet :)
| 4rt wrote:
| As far as I can see there's no need to re-encrypt the signal
| - just leave it as a non-HDCP stream?
|
| There are HDMI splitters which silently strip HDCP to output
| to two screens at once - they don't advertise this feature
| but they do it anyway in order to function. In order to
| achieve the overlay you'd just need one of these and then a
| non-HDCP-aware overlay apparatus before the display.
|
| https://www.reddit.com/r/VIDEOENGINEERING/comments/xme482/hd.
| ..
| mjevans wrote:
| It would be a LOT more seamless if the output didn't have any
| HDCP to re-synchronize. Though the different frame timings
| (gen-lock is a term you want to search for) between the
| inputs and outputs so such a system might introduce
| presentation latency which would have to be accounted for in
| the audio streams.
| echohack5 wrote:
| Maybe the closest thing to this is a Blackmagic box of some
| sort. I use a the Ultrastudio 4K to capture 4K60 output, pipe
| through OBS and pass through as well.
|
| Will run you $1K though. Corsair/Elgato has some solutions in
| your price range but the devil is in the details of precisely
| what you're trying to accomplish.
| justsomehnguy wrote:
| There is a lot of answers here already, but I would remind
| everyone, what if your target is _38-in-1_ DVD /HD/whatever to
| resell for $5 the only thing you need is a $30 cam pointed at
| the display.
|
| Yes, it's not pixel perfect. Thing is, the people who buys
| 38-in-1 _do not care_ about pixel perfect picture. They just
| want an affordable way to spend an hour and half with their
| family.
| babypuncher wrote:
| The really dumb thing is that nobody wants to copy DVDs or Blu-
| Rays via HDMI anyways. It's much more convenient to decrypt the
| discs directly with tools like MakeMKV.
|
| However, I suspect that isn't the real holdup here since
| DisplayPort also fully supports HDCP
| ysleepy wrote:
| Bunnie's work on HDMI mitm is really cool.
|
| https://fahrplan.events.ccc.de/congress/2011/Fahrplan/events...
| (Slides and long write up)
|
| His 28C3 talk https://www.youtube.com/watch?v=37SBMyGoCAU
| cultureulterior wrote:
| Seems like you could have a separate shell organization that
| built this functionality by looking at existing drivers, and just
| provide the patch to the kernel.
| betaby wrote:
| Since, say France, has no software patents, can that work be done
| in France and released thereafter? ( thinking of VLC example now
| )
| colordrops wrote:
| Would probably involve retaliation outside of France if they
| did this.
| nextaccountic wrote:
| I think that nouveau can do that. But AMD can't touch this code
| because it is an US company
| thomastjeffery wrote:
| The HDMI forum ought to be subject to anti-trust action.
| dusted wrote:
| wow, hdmi really wants to die that badly ?
| megous wrote:
| Is this about the movie industry again?
| coryfklein wrote:
| Can AMD fork HDMI, add in driver support, and call it their own
| standard that just so happens to be compatible with HDMI?
|
| I'm sure they wouldn't make such a move lightly, but is there
| something fundamental here about the laws or specifications that
| prevents them from doing this?
| dvdkon wrote:
| I think they could, simply by IP laws, but they have a contract
| with the HDMI Forum that probably doesn't allow that. They
| could cancel it (and reverse-engineer HDMI instead of going by
| the NDA'd spec), but I don't think they'd do that just for
| Linux support.
| nimish wrote:
| Hopefully someone leaks the spec. Maybe it's already available?
|
| Note that the latest VESA specs are also restricted.
|
| FWIW, it's easily possible to sniff the control channel of an
| HDMI or DP connection. At that point one could attempt to reverse
| engineer the enabling features.
___________________________________________________________________
(page generated 2024-02-28 23:00 UTC)