AMDGPU TMZ + HDCP Should Allow Widevine DRM To Behave Nicely With AMD Linux Systems

[oiaohm]

I'm not sure what you are proposing here. One driver is broken so let's have every driver implement their own custom control panel so we can be sure to have a different user experience for every device and create piles of more work for multiple components.

This is not getting exactly what I am saying. Why you have used asking for own custom control panel is a particular issue of information.

The driver should not be dictating policy. The driver exposes capabilities. It's up to the user and desktop to handle the policy. Every user has a different idea of what they want. Some people aren't gamers and don't care if games only get 10 fps. They want to use the full resolution of their display. Others may want the opposite. That is their choice to make. Moreover, how is a vendor specific control panel going to solve this?

This is exactly what Nvidia current custom control panel on Windows gives to users with allowing to enable to disable scaling and so on.

What guidance are you proposing? I don't understand what you are getting at. No one can test every combination of drivers and desktops. There will always be issues on some combination of components, that's why vendors and distros have CI and QA teams and OEM do validated preloads. Also, it goes both ways. You can have a new desktop with an old driver and you can have a new driver with an old desktop. I don't really see what having a vendor specific control panel solves.

You have locked on on the Vendor specific bit. Missing what the vendor specific control panel is doing for user.

Yes you cannot test everything before releasing. This means you have to except not matter what you do quirks will get to end user that end user need to be able to deal with. User need effective interface to alter driver settings with that tool providing guidance.

What vendor specific control panels do on windows is allow user to change settings but also you will see Nvidia control panel at times detect you have X card and disable Y feature and warn of issue if you attempt to turn it back on so providing guidance to users to set the features as good as they can.

Yes you can be using old nvidia driver with old card and a new Nvidia control pannel and its giving you guidence on what setting will make that driver work the best that are based on information that only exists after that driver was released. This is the guidance this could in theory come from a generic control panel with vendor particular databases to be accessed heck desktop envornment databases as well providing user with information on what settings are safe default and any known issues from enabling features so user can make informed choice. Yes we have some generic setting configuration tools for Linux none provide any information if you are about to set something that is likely not to work due to driver issue.

[agd5f]

Except help them fix it does not work unless end users understand what to complain about to put pressure on them.

I'm not sure what you are proposing here. One driver is broken so let's have every driver implement their own custom control panel so we can be sure to have a different user experience for every device and create piles of more work for multiple components.

The combination of 4k output with a GPU cannot do 4k well is something the current KMS APi does not handle well. Just think you have a monitor that only takes 4K and a GPU that if it rendering 4K can only do 10 frames per second. There is a work around to the 4K out with a GPU that cannot render well at 4K can you upscale from 1K to 4K.

Now do your really want to implement up-scaling in kernel space? Remember there are many different ways to upscale.

The driver should not be dictating policy. The driver exposes capabilities. It's up to the user and desktop to handle the policy. Every user has a different idea of what they want. Some people aren't gamers and don't care if games only get 10 fps. They want to use the full resolution of their display. Others may want the opposite. That is their choice to make. Moreover, how is a vendor specific control panel going to solve this?

This is where you need to get out of your tunnel vision a lot. The reality here is Desktop people and end users have to deal with device quirks like it or not.
Reason why this is.
1) Desktop environments have to function with more than 1 version of drivers and of course some versions of drivers are going to have quirks. So the problem is already spread over random components with the support information being updated independently.
2) Users cannot always update to the latest and greatest driver.

This is missing basic limitation right. The KMS API can only provide guidance information from the driver the user currently has. Lets say after you released a driver you find it has X critical issue how well you get that to the end user/desktop developers in a unified way remember you cannot use the driver because the end user may not be able to update the driver.

There is need for guidance information about drivers issue to come from a tool outside the driver and kernel that can be update independent to both.

KMS was not design with a userspace part independent to driver to inform user when they need to update drivers or if particular issues are expected from the current version of driver they have. The KMS API in it current form cannot provide this guidance. This also leads to desktop environment developers and application developers creating their own quirk solution.

I personally believe desktop environments and applications should not have to be doing their own unique quirk solutions there should be a standardise framework to report on what quirks exist.

Big thing the way KMS currently does guidance its providing out of date guidance information when you get in the end user location stuck with a old version of a driver. Guidance information and driver do need to be kind of split. This is best laid plans of mice and men. You plan to make a perfect driver the reality you basically never do so since the driver is not perfect it cannot provide perfect guidance information either. There is no particular reason if you have a good design that guidance information could not be shipped independent to kernel and driver as it own independent up-dateable part this is what is in fact needed.

Yes guidance information newer than your current driver could tell you if you update driver you will fix X problem so then end user knows they can get on to distribution to update driver to fix their problem.

What guidance are you proposing? I don't understand what you are getting at. No one can test every combination of drivers and desktops. There will always be issues on some combination of components, that's why vendors and distros have CI and QA teams and OEM do validated preloads. Also, it goes both ways. You can have a new desktop with an old driver and you can have a new driver with an old desktop. I don't really see what having a vendor specific control panel solves.

[oiaohm]

Fix the root cause then. If a particular vendor's implementation is broken, help them to fix it rather than papering over it in some other component.

Except help them fix it does not work unless end users understand what to complain about to put pressure on them.

Maybe we should ask the GPU vendors to build an entire stack from driver to desktop to application so it will work perfectly with their hardware.

This is that you are tunnelled visioned

That's supposed to be handled in the KMS API. If there are cases where it's not, we should fix that rather than adding what amounts to extended driver bits up in the desktop.

The combination of 4k output with a GPU cannot do 4k well is something the current KMS APi does not handle well. Just think you have a monitor that only takes 4K and a GPU that if it rendering 4K can only do 10 frames per second. There is a work around to the 4K out with a GPU that cannot render well at 4K can you upscale from 1K to 4K.

Now do your really want to implement up-scaling in kernel space? Remember there are many different ways to upscale.

I would argue that those quirks should be handled in the driver as much as possible. Why spread all of that around to other random components? It's just more code to maintain and more places things can go wrong. I think it would make everyone's life easier. Desktop people should not have to deal with device quirks.

This is where you need to get out of your tunnel vision a lot. The reality here is Desktop people and end users have to deal with device quirks like it or not.
Reason why this is.
1) Desktop environments have to function with more than 1 version of drivers and of course some versions of drivers are going to have quirks. So the problem is already spread over random components with the support information being updated independently.
2) Users cannot always update to the latest and greatest driver.

The KMS API does provide this guidance. If desktops use the API wrong or ignore those bits,

This is missing basic limitation right. The KMS API can only provide guidance information from the driver the user currently has. Lets say after you released a driver you find it has X critical issue how well you get that to the end user/desktop developers in a unified way remember you cannot use the driver because the end user may not be able to update the driver.

There is need for guidance information about drivers issue to come from a tool outside the driver and kernel that can be update independent to both.

KMS was not design with a userspace part independent to driver to inform user when they need to update drivers or if particular issues are expected from the current version of driver they have. The KMS API in it current form cannot provide this guidance. This also leads to desktop environment developers and application developers creating their own quirk solution.

I personally believe desktop environments and applications should not have to be doing their own unique quirk solutions there should be a standardise framework to report on what quirks exist.

Big thing the way KMS currently does guidance its providing out of date guidance information when you get in the end user location stuck with a old version of a driver. Guidance information and driver do need to be kind of split. This is best laid plans of mice and men. You plan to make a perfect driver the reality you basically never do so since the driver is not perfect it cannot provide perfect guidance information either. There is no particular reason if you have a good design that guidance information could not be shipped independent to kernel and driver as it own independent up-dateable part this is what is in fact needed.

Yes guidance information newer than your current driver could tell you if you update driver you will fix X problem so then end user knows they can get on to distribution to update driver to fix their problem.

[agd5f]

Sorry to rain you idea here but KMS API is not really that standard. Nvidia in their closed source driver KMS support really still does not work correctly. The reality is you need something like Disman to use the KMS functionality from applications so that parties like Nvidia not implementing KMS API support fully equals broken applications and upset users for them.

Fix the root cause then. If a particular vendor's implementation is broken, help them to fix it rather than papering over it in some other component.

This is why you have fragmentation. You have stopped at desktop environments instead of having something from application side all the way though the desktop environment so making everyone standardise.

Maybe we should ask the GPU vendors to build an entire stack from driver to desktop to application so it will work perfectly with their hardware.

You have forgot quirks and limitations. Like just because a GPU can be set to output 4K does not mean gpu it will handle doing that well. I am not saying a vendor specific control panel should be the end goal. Making sure the end user has the information they need to made informed choices doing the configuration needs to be.

That's supposed to be handled in the KMS API. If there are cases where it's not, we should fix that rather than adding what amounts to extended driver bits up in the desktop.

You are missing something important. You know the hardware. You have the chance to know where all the quirks/skeletons on the driver side are. With that information you should be able to work out what information end application/end user needs to in fact make a informed choice how the graphics card is configured so they don't configure by guess work. Knowing this information allows you to in fact create guide lines on what desktop developers should include in their API and configuration tools to be useful to end user. Problem here desktop developers cannot be expected to understand all the different quirk stuff in graphics driver they really do need graphic driver developers like you to take guiding hand. Remember GPU releases and desktop environment releases don't line up.

End users ask for vendor particular configuration tools to get guidance from the tool. Now if you don't want vendor particular tools then instead you need a vendor particular databases/files with quirks and limit information so the desktop environment provided tools can process to provide user with guidance on what is sane configuration.

I would argue that those quirks should be handled in the driver as much as possible. Why spread all of that around to other random components? It's just more code to maintain and more places things can go wrong. I think it would make everyone's life easier. Desktop people should not have to deal with device quirks.

The desktop is not my problem answer is not right. The desktop environment cannot provide users with great configuration guidance information if the driver developers/vendor does not provide that information. It takes two to tango as the saying goes. KMS API does not provide configuration guidance information like what is the Max a card will handle well. Of course most people coming from windows what they think of it ask for configuration guidance is vendor particular control panel. Yes dealing with desktop users is a little tricky sometime the item they are asking for is only example of what they want takes a bit to work out what they really want. Configuration guidance is horrible lacking.

The KMS API does provide this guidance. If desktops use the API wrong or ignore those bits, we can help them fix that. If the KMS API is missing something, we can try to fix it. I don't see what a vendor specific modesetting control panel really provides other than a way to add a bunch of corporate logos and cool animations. I guess that has some value depending on who you ask. I think this is where Linux and windows differ. Windows is all about product differentiation. Linux tends to focus on the the greater good (the rising tide lifts all boats). If you are going to fix something, try and make everyone's experience a little better. Rather than adding a vendor specific control panel as some sort of workaround, let's fix the root cause.

[oiaohm]

Even before RANDR, X had a standard way of configuring monitors and modes, it just involved editing a configuration file and restarting X, so it wasn't exactly user friendly.

This proves you are young. The X11 configuration files are not part of the X11 standard. So third parties implementing X11 servers that we use to have from different Unix those configuration files for doing monitors was not uniform.

The uniform in configuration come from reference implementation Xfree86 that came X.org in current day but even in 1998 there were still commercial X11 servers with unique configuration files for setting up monitors. It was the Xrandr work that brought this finally to end.

The reality when we had multi commercial X11 servers we had multi different ways of configuring monitors and modes. Why Xrandr brings it to end in a lot of ways is you now have applications using Xrandr so those making third party x11 servers had to make there stuff compatible with Xrandr so application work. Then it came more effort to avoid the standard way than what it was worth.

I think something like Disman is great. It may get us back to a universal configuration interface at the desktop level. At the kernel level we already have a standard interface, the KMS API.

Sorry to rain you idea here but KMS API is not really that standard. Nvidia in their closed source driver KMS support really still does not work correctly. The reality is you need something like Disman to use the KMS functionality from applications so that parties like Nvidia not implementing KMS API support fully equals broken applications and upset users for them.

The driver have always provided a standard interface to configure them, regardless of vendor. RANDR for X, and the KMS API for kernel modesetting. The desktop environments have used these APIs for years. But they choose to store user configuration details in different ways depending on how they were architected or how they evolved over time.

This you need to look at how .desktop files came into existence. Simple you can ignore how the desktop environments have done things as long as you can get enough applications to use it they will work out some way to be compadible.

As driver developers, we provided stable APIs for desktop environments to use for years and desktops have used them successfully for years. We're not experts when it comes to desktop applications. I'm not sure what additional value we provide in this case.

This is why you have fragmentation. You have stopped at desktop environments instead of having something from application side all the way though the desktop environment so making everyone standardise.

To this point, why have a vendor specific configuration tool in the first place? That just spreads more vendor specific stuff. The current desktop environments handle this all well today, other than the fact that the lack of a common API makes it hard to produce a vendor specific control panel hard. So this begs the question, why do we need a vendor specific tool for modesetting to begin with? All of the kernel drivers use the KMS API, so it's not like there is vendor specific logic required for each GPU.

You have forgot quirks and limitations. Like just because a GPU can be set to output 4K does not mean gpu it will handle doing that well. I am not saying a vendor specific control panel should be the end goal. Making sure the end user has the information they need to made informed choices doing the configuration needs to be.

The only thing required is that there is a common way to do it. As I said before, the drivers already provide a common API to configure the displays and the desktop environments have used the successfully for years. It's not like the the functionality is ill-defined, it's just not standard. To your point, I'm a driver developer, I can't really tell desktop developers what features they need in their API to make sure it's a good fit for their desktop environment.

You are missing something important. You know the hardware. You have the chance to know where all the quirks/skeletons on the driver side are. With that information you should be able to work out what information end application/end user needs to in fact make a informed choice how the graphics card is configured so they don't configure by guess work. Knowing this information allows you to in fact create guide lines on what desktop developers should include in their API and configuration tools to be useful to end user. Problem here desktop developers cannot be expected to understand all the different quirk stuff in graphics driver they really do need graphic driver developers like you to take guiding hand. Remember GPU releases and desktop environment releases don't line up.

End users ask for vendor particular configuration tools to get guidance from the tool. Now if you don't want vendor particular tools then instead you need a vendor particular databases/files with quirks and limit information so the desktop environment provided tools can process to provide user with guidance on what is sane configuration.

The desktop is not my problem answer is not right. The desktop environment cannot provide users with great configuration guidance information if the driver developers/vendor does not provide that information. It takes two to tango as the saying goes. KMS API does not provide configuration guidance information like what is the Max a card will handle well. Of course most people coming from windows what they think of it ask for configuration guidance is vendor particular control panel. Yes dealing with desktop users is a little tricky sometime the item they are asking for is only example of what they want takes a bit to work out what they really want. Configuration guidance is horrible lacking.

[agd5f]

I am old enough to have used X11 before Xrandr existed yes back then X11 every driver configuration file did the stuff differently as well. Like it or not history repeats.

Even before RANDR, X had a standard way of configuring monitors and modes, it just involved editing a configuration file and restarting X, so it wasn't exactly user friendly.

https://www.phoronix.com/scan.php?page=news_item&px=Disman-XDC2020

We have a KDE developer with Disman starting to do a universal xrandr replacement. Really agd5f you need to stop saying there is no single underlying protocol and instead working out what you want in a single underlying protocol to replace xrandr and possible working with Disman developer to get it. Yes Disman could in time allow xrandr to be removed from X11 as well.

I think something like Disman is great. It may get us back to a universal configuration interface at the desktop level. At the kernel level we already have a standard interface, the KMS API.

Of course every wayland compositor r is storing them different have you as driver makers provided display makers with any guidance or easy standard way todo it?

The driver have always provided a standard interface to configure them, regardless of vendor. RANDR for X, and the KMS API for kernel modesetting. The desktop environments have used these APIs for years. But they choose to store user configuration details in different ways depending on how they were architected or how they evolved over time.

Really as long as driver developers don't get together and pick a solution to replacement xrandr for wayland the fragmentation will last.

As driver developers, we provided stable APIs for desktop environments to use for years and desktops have used them successfully for years. We're not experts when it comes to desktop applications. I'm not sure what additional value we provide in this case.

By the way I remember when I was in the arguement about creating .desktop files for storing menu system fairly universally between Linux desktops that every desktop was unique configuration was also a stupid arguement used back then as why each party could get away with being hands off.

To this point, why have a vendor specific configuration tool in the first place? That just spreads more vendor specific stuff. The current desktop environments handle this all well today, other than the fact that the lack of a common API makes it hard to produce a vendor specific control panel hard. So this begs the question, why do we need a vendor specific tool for modesetting to begin with? All of the kernel drivers use the KMS API, so it's not like there is vendor specific logic required for each GPU.

agd5f really everything you wrote reads to me I write this so I don't have to step forwards and start laying out what a xrandr replacement should have so I don't have to talk to people like Roman Gilg doing Disman to in fact get one. My problem I am not graphical driver developer I cannot really tell any party Roman Gilgs doing Disman what interfaces are absolutely for sure required and what way they have to be structured to make sense on the hardware side.

The only thing required is that there is a common way to do it. As I said before, the drivers already provide a common API to configure the displays and the desktop environments have used the successfully for years. It's not like the the functionality is ill-defined, it's just not standard. To your point, I'm a driver developer, I can't really tell desktop developers what features they need in their API to make sure it's a good fit for their desktop environment.

[oiaohm]

It's not the look that is the problem, it's the fact that every desktop environment manages displays and stores user configurations in their own way. With the migration to wayland compositors, each compositor manages the display configuration directly, so you would need to go through whatever API this compositors either provide or don't provide. There is no longer a single underlying protocol like RANDR on X used to provide. On top of that every desktop environment stores the user preferences differently and often changes how they store them with each update. For things that are driver specific (e.g., power management related stuff or mesa driver options), you could do a GUI more easily, but there are already GUIs for those things.

I would say this is one huge mother excuse. I am old enough to have used X11 before Xrandr existed yes back then X11 every driver configuration file did the stuff differently as well. Like it or not history repeats.

https://www.phoronix.com/scan.php?page=news_item&px=Disman-XDC2020

We have a KDE developer with Disman starting to do a universal xrandr replacement. Really agd5f you need to stop saying there is no single underlying protocol and instead working out what you want in a single underlying protocol to replace xrandr and possible working with Disman developer to get it. Yes Disman could in time allow xrandr to be removed from X11 as well.

Of course every wayland compositor r is storing them different have you as driver makers provided display makers with any guidance or easy standard way todo it?

Sorry agd5f you have to remember we have randr for X11 because Jim Gettys from HP and Keith Packard from Intel decided to sort it out. Yes Jim heavy foot with Gnome at the time linked up with a driver developing Keith at the time. Since to make Randr well required both sides to make the Wayland version will most likely require a team of both sides again we can expect a lot of unique per compositor stuff to disappear.

Really as long as driver developers don't get together and pick a solution to replacement xrandr for wayland the fragmentation will last.

By the way I remember when I was in the arguement about creating .desktop files for storing menu system fairly universally between Linux desktops that every desktop was unique configuration was also a stupid arguement used back then as why each party could get away with being hands off.

agd5f really everything you wrote reads to me I write this so I don't have to step forwards and start laying out what a xrandr replacement should have so I don't have to talk to people like Roman Gilg doing Disman to in fact get one. My problem I am not graphical driver developer I cannot really tell any party Roman Gilgs doing Disman what interfaces are absolutely for sure required and what way they have to be structured to make sense on the hardware side.

[agd5f]

True.
The reason that I want AMD to make a control panel for Linux is indeed more to have those features developed in the driver so even if AMD doesn't have the time to develop a fancy control panel, someone else can make a simple control panel if the features are already implemented and there's an API interface available.
I guess that there are quite a few developers who would like to do this part and me as a user I don't care how bad it would look visually as long as it works.
It can even be one page only window with buttons, sliders, drop-downs and an OK button.
And I don't expect all the features to be available from day one, one at at time would be fine too.

It's not the look that is the problem, it's the fact that every desktop environment manages displays and stores user configurations in their own way. With the migration to wayland compositors, each compositor manages the display configuration directly, so you would need to go through whatever API this compositors either provide or don't provide. There is no longer a single underlying protocol like RANDR on X used to provide. On top of that every desktop environment stores the user preferences differently and often changes how they store them with each update. For things that are driver specific (e.g., power management related stuff or mesa driver options), you could do a GUI more easily, but there are already GUIs for those things.

[smitty3268]

Perhaps I'm a bit slow today (I suspect weak coffee) but I don't understand the logic here.

If we spend time on implementing a control panel before the underlying driver code exists that just further delays the driver work and means that we have to implement driver interface logic before we know what the best driver interface will be.

If you had said "the reason that I do not want AMD to make a control panel for Linux" then the rest of the post would have been consistent AFAICS.

Not to speak for him, but i think he was just using that as a quick way of saying he wanted those features in the linux driver without needing to list them all out explicitly or say the "control panel features" rather than just "control panel". I think the underlying assumption there is also that AMD isn't working on those features in the linux drivers, or at least not fast enough for his preferences, and that if AMD committed to working on a linux control panel it would be a sign that those features were coming soon.

[bridgman]

The reason that I want AMD to make a control panel for Linux is indeed more to have those features developed in the driver so even if AMD doesn't have the time to develop a fancy control panel, someone else can make a simple control panel if the features are already implemented and there's an API interface available.

Perhaps I'm a bit slow today (I suspect weak coffee) but I don't understand the logic here.

If we spend time on implementing a control panel before the underlying driver code exists that just further delays the driver work and means that we have to implement driver interface logic before we know what the best driver interface will be.

If you had said "the reason that I do not want AMD to make a control panel for Linux" then the rest of the post would have been consistent AFAICS.