Originally posted by F.Ultra
View Post
Announcement
Collapse
No announcement yet.
HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought By AMD
Collapse
X
-
Originally posted by sophisticles View Post
Not entirely accurate.
If a patent holder licenses their technology to one party they must license it to anyone willing to pay the licensing fees.
However, even FRAND licensing is problematic in the open source world, as there is no process to require payment for use of the IP in the software domain.
- Likes 2
Comment
-
Originally posted by Panix View PostSo, you're saying Windows has more choice??!?!?
Windows users could buy just about any peripheral, WiFi card, USB display etc and they will always have a Windows driver in some form, either through Windows Update or a vendor bundled driver. Nobody on Windows ever had to browse compatibility lists to find out if wifi card A or USB monitor B works on Windows or not.
Windows users have access to so many different kinds of commercial, enterprise and appliance management software that macOS and Linux users can only dream of.
- Likes 3
Comment
-
I've always found it odd that Display port isn't so popular on displays, many TV's don't have any support for it at all which is a shame since DP is actually really nice, It's used in phones, Highend embedded use (DSI still is far more popular, not sure why, probably a cost thing?) Laptops etc. Really weird that TVs never adopted it to me
- Likes 1
Comment
-
Originally posted by skeevy420 View PostEvery single relevant Wayland protocol could be updated to include a possible entry and exit point or be setup to expose how it does what for a plugin to interact with and then all the compositors could be updated to use the new protocols. I know how unfeasible and unrealistic that sounds and I think a lot of that defeats the purpose of what makes Wayland secure.
There is a reason why vulkan layers are done the way they are and the issues these have..
Then you have to consider what Wayland debugging tools show.
Its in your wayland debugging tools skeevy420.
Capture and debug/modify Wayland connections. Contribute to mchalupa/wldbg development by creating an account on GitHub.
Notice this is sitting man in middle between compositor and application. So application sends some new Wayland protocol the compositor cannot know the man in the middle can prevent the compositor from knowing about it.
X11 xserver with DDX run into a stack of problems. Like not being able to remove DRI1 stuff because Nvidia DDX module was still using it.
Vulkan layers work as man in middles but there are issues with these being libraries that can come back and bite.
Vulkan Loader. Contribute to KhronosGroup/Vulkan-Loader development by creating an account on GitHub.
Yes todo what you talked about you would have to write something like this for Wayland and get all wayland compositors to agree. Lot could be done by altering libwayland-server.
skeevy420 one option is make a generic wayland compositor for all that matches up to the Vulkan loader trampoline that then passes you down a list of proxy/debugging style wayland man in middles that can intercept/modify/process all Wayland commands to add the missing protocols the wayland compositor you have does not support..
Vulkan is design that layers can make up for features the bare metal driver is missing of course not everything can be implemented somethings if the base driver is missing under Vulkan they cannot be emulated.
Vulkan model you don't update the drivers. Take the vulkan mode you don't update the old compositors. You just put a thin layer on top to hide as much as possible that its a old compositor..
So far no one has really taken interest in taking the debugging man in middle compositors and extend them to be wayland protocol injection into older Wayland compositors.
Remember the good part here is with Vulkan layer design as driver gets updated with a new highly optimized way to doing a feature being emulated in a layer you can remove the layer. Same could apply to Wayland compositors with man in the middle proxy compositors on top as the Wayland compositor updates to support new Wayland protocol you just stop using the man in middle proxy compositor providing that feature.
- Likes 2
Comment
-
Originally posted by NeoMorpheus View PostBut sadly, we are surrounded by morons, that blindly worship Ngreedia, whom would right away start saying all kinds of stupid things against AMD because it doesn't have a HDMI port.
AMD's great at pushing open standards and technologies. Does anyone care about G-Sync these days? Even Nvidia had to cave in to supporting FreeSync-capabie monitors (or at least Adaptive-Sync?) because it was just cheaper and did the same thing so the market was flooded with them. The same could be true of DisplayPort vs HDMI. The same will be true of FSR vs DLSS, especially if Xbox and PlayStation use AMD cards again for the next generation.
Speaking of FreeSync, I believe this tech on Nvidia cards only works over DisplayPort, so I imagine that not too many people are using HDMI even in the Nvidia camp.Last edited by boltronics; 29 February 2024, 02:53 AM.
- Likes 6
Comment
-
-
Originally posted by dlq84 View PostVESA should come up with a competing solution with the same features and more, until then hdmi is a necessary evil. Should be inevitable now that HDMI Forum has gotten hubris.
- Likes 5
Comment
Comment