On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
Dave.
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
Dave.
Thanks and regards, Mythri.
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add.
Thanks and regards, Mythri.
-- Jesse Barnes, Intel Open Source Technology Center
On Thu, Mar 24, 2011 at 2:51 AM, K, Mythri P mythripk@ti.com wrote:
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add.
Something just occurred to me. Why do video input drivers need EDID? Perhaps I'm betraying my youth here, but none of my TV tuners have the ability to read EDIDs in from the other side of the coax/RCA jack, and IIUC they really only care about whether they're receiving NTSC or PAL. The only drivers that should be parsing EDIDs are FB and KMS drivers, right?
So why should this be a common library? Most kernel code doesn't need it. Or is there a serious need for video input to parse EDIDs?
~ C.
Corbin Simpson schrieb:
On Thu, Mar 24, 2011 at 2:51 AM, K, Mythri P mythripk@ti.com wrote:
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add.
Something just occurred to me. Why do video input drivers need EDID? Perhaps I'm betraying my youth here, but none of my TV tuners have the ability to read EDIDs in from the other side of the coax/RCA jack, and IIUC they really only care about whether they're receiving NTSC or PAL. The only drivers that should be parsing EDIDs are FB and KMS drivers, right?
Traditional TV (PAL/NTSC) supports only a very limited amount of modes and furthermore within one country it's about 1 or 2 different ones that are typically needed. It looks like todays TVs support most of those but I've also seen some terrible cropping or a wrong aspect ratio on TVs. Let's say that had a relative simple job and they didn't do it always too well, so getting the information via EDID is better than forcing the user type the info in via a remote or doing it wrong.
So why should this be a common library? Most kernel code doesn't need it. Or is there a serious need for video input to parse EDIDs?
It's true that most kernel code does not need it as it is only useful for display output systems (and only the ones that can be connected to something sending EDID data) but it would be good anyway. Because sharing code that should fulfill the same purpose is always a good idea. But of course only if the scope is clearly limited as we don't want to end up with a mess that nobody dares touching again as it became to complex. So I totally agree that we should share the common stuff we all need and adding the extras one needs in the subsystem/driver. This is good because it looks like we'll have 3 display subsystems within the kernel for a long future and with a common library the same patch would not need to be done 3 times but only once. Or even more often if drivers have there private EDID implementation which I just throw out of mine to replace it later with a common one.
Regards,
Florian Tobias Schandinat
Hi Florian,
<snip>
So why should this be a common library? Most kernel code doesn't need it. Or is there a serious need for video input to parse EDIDs?
It's true that most kernel code does not need it as it is only useful for display output systems (and only the ones that can be connected to something sending EDID data) but it would be good anyway. Because sharing code that should fulfill the same purpose is always a good idea. But of course only if the scope is clearly limited as we don't want to end up with a mess that nobody dares touching again as it became to complex. So I totally agree that we should share the common stuff we all need and adding the extras one needs in the subsystem/driver. This is good because it looks like we'll have 3 display subsystems within the kernel for a long future and with a common library the same patch would not need to be done 3 times but only once. Or even more often if drivers have there private EDID implementation which I just throw out of mine to replace it later with a common one.
Precisely my point . Also if there are some bad TV models which doesn't adhere to standard EDID, It would help to add quirks. Anyone out there want to help me split the DRM code ? As i don't want DRMer's to fret over changed code :).
Thanks and regards, Mythri.
Regards,
Florian Tobias Schandinat
On Thu, 24 Mar 2011, K, Mythri P wrote:
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
Does the DRM EDID-parser also process blocks beyond the first one and also parses SVD entries similar to what I've recently added to fbdev? Yes, we definitely need a common EDID parses, and maybe we'll have to collect various pieces from different implementations.
Thanks Guennadi
This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add.
Thanks and regards, Mythri.
-- Jesse Barnes, Intel Open Source Technology Center
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
On Thu, Mar 24, 2011 at 3:13 PM, Guennadi Liakhovetski g.liakhovetski@gmx.de wrote:
On Thu, 24 Mar 2011, K, Mythri P wrote:
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" mythripk@ti.com wrote:
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythripk@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30...
This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well.
If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high.
I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM.
If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need.
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
Does the DRM EDID-parser also process blocks beyond the first one and also parses SVD entries similar to what I've recently added to fbdev? Yes, we definitely need a common EDID parses, and maybe we'll have to collect various pieces from different implementations.
At the moment there is only limited support for looking up things like the hdmi block and checking for audio.
Alex
Thanks Guennadi
This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability.
Do you really think the differences between your code and the existing DRM code are irreconcilable?
On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add.
Thanks and regards, Mythri.
-- Jesse Barnes, Intel Open Source Technology Center
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Gunnedi,
<snip>
Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code.
Does the DRM EDID-parser also process blocks beyond the first one and also parses SVD entries similar to what I've recently added to fbdev? Yes, we definitely need a common EDID parses, and maybe we'll have to collect various pieces from different implementations.
As far as I know , it does not parse SVD ,But it should not be that difficult to add. We could take the SVD parsing from your code . In the RFC i have posted I parse for detailed timing and other VSDB blocks. Also the parsing should be based on the extension type for multiple 128 byte blocks.
Thanks and regards, Mythri.
Thanks Guennadi
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Corbin Simpson -
Dave Airlie -
Florian Tobias Schandinat -
Guennadi Liakhovetski -
Jesse Barnes -
K, Mythri P