* HDCP Content Type Interface @ 2019-09-09 15:54 Lakha, Bhawanpreet 2019-09-10 7:45 ` Jani Nikula 2019-09-12 7:47 ` Ramalingam C 0 siblings, 2 replies; 9+ messages in thread From: Lakha, Bhawanpreet @ 2019-09-09 15:54 UTC (permalink / raw) To: Ramalingam C, Daniel Vetter, dri-devel@lists.freedesktop.org Cc: Deucher, Alexander [-- Attachment #1.1: Type: text/plain, Size: 956 bytes --] Hi all, This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. What are your thoughts? and what would be a good way to deal with it? Thanks, Bhawan [-- Attachment #1.2: Type: text/html, Size: 1771 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-09 15:54 HDCP Content Type Interface Lakha, Bhawanpreet @ 2019-09-10 7:45 ` Jani Nikula 2019-09-12 7:47 ` Ramalingam C 1 sibling, 0 replies; 9+ messages in thread From: Jani Nikula @ 2019-09-10 7:45 UTC (permalink / raw) To: Lakha, Bhawanpreet, Ramalingam C, Daniel Vetter, dri-devel@lists.freedesktop.org Cc: Deucher, Alexander On Mon, 09 Sep 2019, "Lakha, Bhawanpreet" <Bhawanpreet.Lakha@amd.com> wrote: > Hi all, > > This is regarding the recent hdcp content type patch that was merged > into > drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) > > There are displays on the market that advertise HDCP 2.2 support and > will pass authentication and encryption but will then show a > corrupted/blue/black screen (the driver cannot detect this). These > displays work with HDCP 1.4 without any issues. Due to the large > number of HDCP-supporting devices on the market we might not be able > to catch them with a blacklist. Has this been confirmed with some other HDCP source than the recently merged HDCP 2.2 support? I.e. has it been confirmed the issue is really in the sinks rather than in the source support? BR, Jani. > > From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the > same thing. Meaning that this interface doesn't allow us to force the > hdcp version. Due to the problems mentioned above we might want to > expose the ability for a user to force an HDCP downgrade to a certain > level (e.g. 1.4) in case they experience problems. > > What are your thoughts? and what would be a good way to deal with it? > > > Thanks, > > Bhawan > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-09 15:54 HDCP Content Type Interface Lakha, Bhawanpreet 2019-09-10 7:45 ` Jani Nikula @ 2019-09-12 7:47 ` Ramalingam C 2019-09-12 14:23 ` Harry Wentland 1 sibling, 1 reply; 9+ messages in thread From: Ramalingam C @ 2019-09-12 7:47 UTC (permalink / raw) To: Lakha, Bhawanpreet Cc: Deucher, Alexander, Daniel Vetter, dri-devel@lists.freedesktop.org On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: > Hi all, > > This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) > > There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. > > From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. > > What are your thoughts? and what would be a good way to deal with it? Hi, As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel supposed to exercise the highest version of HDCP supported on panel and platform. As we implement the HDCP spec support, if a device is non-compliant with HDCP spec after completing the HDCP authentication, I dont think we need to worry about it. In case if you want to track and implement a quirk for it, like not to project the HDCP2.2 capability, you can use the receiver id of that panel to track it. Thanks, -Ram > > > Thanks, > > Bhawan _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 7:47 ` Ramalingam C @ 2019-09-12 14:23 ` Harry Wentland 2019-09-12 14:49 ` Ramalingam C 2019-09-12 14:57 ` Jani Nikula 0 siblings, 2 replies; 9+ messages in thread From: Harry Wentland @ 2019-09-12 14:23 UTC (permalink / raw) To: Ramalingam C, Lakha, Bhawanpreet Cc: Deucher, Alexander, Daniel Vetter, dri-devel@lists.freedesktop.org On 2019-09-12 3:47 a.m., Ramalingam C wrote: > On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: >> Hi all, >> >> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) >> >> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. >> >> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. >> >> What are your thoughts? and what would be a good way to deal with it? > Hi, > > As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel > supposed to exercise the highest version of HDCP supported on panel and > platform. > > As we implement the HDCP spec support, if a device is non-compliant with > HDCP spec after completing the HDCP authentication, I dont think we need > to worry about it. > Tell that to our (or your) customers. In this case an enduser might plug in a bad monitor or TV and be unable to play protected content. What if we add a new enum value to the content_type property that says "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? Harry > In case if you want to track and implement a quirk for it, like not to > project the HDCP2.2 capability, you can use the receiver id of that panel > to track it. > > Thanks, > -Ram >> >> >> Thanks, >> >> Bhawan _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 14:23 ` Harry Wentland @ 2019-09-12 14:49 ` Ramalingam C 2019-09-12 19:19 ` Harry Wentland 2019-09-12 14:57 ` Jani Nikula 1 sibling, 1 reply; 9+ messages in thread From: Ramalingam C @ 2019-09-12 14:49 UTC (permalink / raw) To: Harry Wentland Cc: Deucher, Alexander, Daniel Vetter, Lakha, Bhawanpreet, dri-devel@lists.freedesktop.org On 2019-09-12 at 14:23:05 +0000, Harry Wentland wrote: > On 2019-09-12 3:47 a.m., Ramalingam C wrote: > > On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: > >> Hi all, > >> > >> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) > >> > >> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. > >> > >> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. > >> > >> What are your thoughts? and what would be a good way to deal with it? > > Hi, > > > > As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel > > supposed to exercise the highest version of HDCP supported on panel and > > platform. > > > > As we implement the HDCP spec support, if a device is non-compliant with > > HDCP spec after completing the HDCP authentication, I dont think we need > > to worry about it. > > > > Tell that to our (or your) customers. > > In this case an enduser might plug in a bad monitor or TV and be unable > to play protected content. > > What if we add a new enum value to the content_type property that says > "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? "content type" is for defining the stream type. Adding an entry into it sounds like polluting it. Separate uAPI for forcing a HDCP version might be need. Or wondering on using the sysfs of connector for this dirty job!? -Ram > > Harry > > > In case if you want to track and implement a quirk for it, like not to > > project the HDCP2.2 capability, you can use the receiver id of that panel > > to track it. > > > > Thanks, > > -Ram > >> > >> > >> Thanks, > >> > >> Bhawan _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 14:49 ` Ramalingam C @ 2019-09-12 19:19 ` Harry Wentland 0 siblings, 0 replies; 9+ messages in thread From: Harry Wentland @ 2019-09-12 19:19 UTC (permalink / raw) To: Ramalingam C Cc: Deucher, Alexander, Daniel Vetter, Lakha, Bhawanpreet, dri-devel@lists.freedesktop.org On 2019-09-12 10:49 a.m., Ramalingam C wrote: > On 2019-09-12 at 14:23:05 +0000, Harry Wentland wrote: >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: >>> On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: >>>> Hi all, >>>> >>>> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) >>>> >>>> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. >>>> >>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. >>>> >>>> What are your thoughts? and what would be a good way to deal with it? >>> Hi, >>> >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >>> supposed to exercise the highest version of HDCP supported on panel and >>> platform. >>> >>> As we implement the HDCP spec support, if a device is non-compliant with >>> HDCP spec after completing the HDCP authentication, I dont think we need >>> to worry about it. >>> >> >> Tell that to our (or your) customers. >> >> In this case an enduser might plug in a bad monitor or TV and be unable >> to play protected content. >> >> What if we add a new enum value to the content_type property that says >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > "content type" is for defining the stream type. Adding an entry into it > sounds like polluting it. > For sure > Separate uAPI for forcing a HDCP version might be need. Or wondering on > using the sysfs of connector for this dirty job!? > Did a bit more digging... On other OS we got a monitor quirk for a few displays and also something similar to a module parameter to force disable HDCP 2.x support. It looks like there aren't too many quirky receivers so that might be an acceptable solution. I'm still thinking a connector property might be useful to force a certain HDCP version but maybe I'm overthinking it. Harry > -Ram >> >> Harry >> >>> In case if you want to track and implement a quirk for it, like not to >>> project the HDCP2.2 capability, you can use the receiver id of that panel >>> to track it. >>> >>> Thanks, >>> -Ram >>>> >>>> >>>> Thanks, >>>> >>>> Bhawan _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 14:23 ` Harry Wentland 2019-09-12 14:49 ` Ramalingam C @ 2019-09-12 14:57 ` Jani Nikula 2019-09-12 19:21 ` Harry Wentland 1 sibling, 1 reply; 9+ messages in thread From: Jani Nikula @ 2019-09-12 14:57 UTC (permalink / raw) To: Harry Wentland, Ramalingam C, Lakha, Bhawanpreet Cc: Deucher, Alexander, Daniel Vetter, dri-devel@lists.freedesktop.org On Thu, 12 Sep 2019, Harry Wentland <hwentlan@amd.com> wrote: > On 2019-09-12 3:47 a.m., Ramalingam C wrote: >> On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: >>> Hi all, >>> >>> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) >>> >>> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. >>> >>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. >>> >>> What are your thoughts? and what would be a good way to deal with it? >> Hi, >> >> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >> supposed to exercise the highest version of HDCP supported on panel and >> platform. >> >> As we implement the HDCP spec support, if a device is non-compliant with >> HDCP spec after completing the HDCP authentication, I dont think we need >> to worry about it. >> > > Tell that to our (or your) customers. Agreed, let's rather not. > In this case an enduser might plug in a bad monitor or TV and be unable > to play protected content. > > What if we add a new enum value to the content_type property that says > "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? In general, I think if the fix is to teach the user to jump through hoops in case the output is not working, it is really not a fix. Would, say, a set top box or a Blu-ray player have a setting to force HDCP 1.4, and a troubleshooting item in the manual to select that if the display does not work? Or would OS X have that? If broken HDCP 2.2 sink support is a widespread problem (is it?), what do other HDCP sources do? If it's a Linux issue, what are we doing wrong or different? BR, Jani. > > Harry > >> In case if you want to track and implement a quirk for it, like not to >> project the HDCP2.2 capability, you can use the receiver id of that panel >> to track it. >> >> Thanks, >> -Ram >>> >>> >>> Thanks, >>> >>> Bhawan > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 14:57 ` Jani Nikula @ 2019-09-12 19:21 ` Harry Wentland 2019-09-13 8:14 ` Daniel Vetter 0 siblings, 1 reply; 9+ messages in thread From: Harry Wentland @ 2019-09-12 19:21 UTC (permalink / raw) To: Jani Nikula, Ramalingam C, Lakha, Bhawanpreet Cc: Deucher, Alexander, Daniel Vetter, dri-devel@lists.freedesktop.org On 2019-09-12 10:57 a.m., Jani Nikula wrote: > On Thu, 12 Sep 2019, Harry Wentland <hwentlan@amd.com> wrote: >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: >>> On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: >>>> Hi all, >>>> >>>> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) >>>> >>>> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. >>>> >>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. >>>> >>>> What are your thoughts? and what would be a good way to deal with it? >>> Hi, >>> >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel >>> supposed to exercise the highest version of HDCP supported on panel and >>> platform. >>> >>> As we implement the HDCP spec support, if a device is non-compliant with >>> HDCP spec after completing the HDCP authentication, I dont think we need >>> to worry about it. >>> >> >> Tell that to our (or your) customers. > > Agreed, let's rather not. > >> In this case an enduser might plug in a bad monitor or TV and be unable >> to play protected content. >> >> What if we add a new enum value to the content_type property that says >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > > In general, I think if the fix is to teach the user to jump through > hoops in case the output is not working, it is really not a fix. > > Would, say, a set top box or a Blu-ray player have a setting to force > HDCP 1.4, and a troubleshooting item in the manual to select that if the > display does not work? Or would OS X have that? > Not sure. AFAIU on other OS we're currently dealing with this through monitor quirks. We can probably pull the same quirks to DRM. > If broken HDCP 2.2 sink support is a widespread problem (is it?), what > do other HDCP sources do? If it's a Linux issue, what are we doing wrong > or different? Not a Linux issue and not overly widespread. Looks like a handful of receivers are problematic. Harry > > > BR, > Jani. > > > >> >> Harry >> >>> In case if you want to track and implement a quirk for it, like not to >>> project the HDCP2.2 capability, you can use the receiver id of that panel >>> to track it. >>> >>> Thanks, >>> -Ram >>>> >>>> >>>> Thanks, >>>> >>>> Bhawan >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HDCP Content Type Interface 2019-09-12 19:21 ` Harry Wentland @ 2019-09-13 8:14 ` Daniel Vetter 0 siblings, 0 replies; 9+ messages in thread From: Daniel Vetter @ 2019-09-13 8:14 UTC (permalink / raw) To: Harry Wentland Cc: Deucher, Alexander, Lakha, Bhawanpreet, dri-devel@lists.freedesktop.org On Thu, Sep 12, 2019 at 9:21 PM Harry Wentland <hwentlan@amd.com> wrote: > > > > On 2019-09-12 10:57 a.m., Jani Nikula wrote: > > On Thu, 12 Sep 2019, Harry Wentland <hwentlan@amd.com> wrote: > >> On 2019-09-12 3:47 a.m., Ramalingam C wrote: > >>> On 2019-09-09 at 15:54:50 +0000, Lakha, Bhawanpreet wrote: > >>>> Hi all, > >>>> > >>>> This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) > >>>> > >>>> There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. > >>>> > >>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. > >>>> > >>>> What are your thoughts? and what would be a good way to deal with it? > >>> Hi, > >>> > >>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel > >>> supposed to exercise the highest version of HDCP supported on panel and > >>> platform. > >>> > >>> As we implement the HDCP spec support, if a device is non-compliant with > >>> HDCP spec after completing the HDCP authentication, I dont think we need > >>> to worry about it. > >>> > >> > >> Tell that to our (or your) customers. > > > > Agreed, let's rather not. > > > >> In this case an enduser might plug in a bad monitor or TV and be unable > >> to play protected content. > >> > >> What if we add a new enum value to the content_type property that says > >> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"? > > > > In general, I think if the fix is to teach the user to jump through > > hoops in case the output is not working, it is really not a fix. > > > > Would, say, a set top box or a Blu-ray player have a setting to force > > HDCP 1.4, and a troubleshooting item in the manual to select that if the > > display does not work? Or would OS X have that? > > > > Not sure. AFAIU on other OS we're currently dealing with this through > monitor quirks. We can probably pull the same quirks to DRM. > > > If broken HDCP 2.2 sink support is a widespread problem (is it?), what > > do other HDCP sources do? If it's a Linux issue, what are we doing wrong > > or different? > > Not a Linux issue and not overly widespread. Looks like a handful of > receivers are problematic. Could we just mass-import that quirk list (since it seems it's not unreasonable big) and be done with this? -Daniel > Harry > > > > > > > BR, > > Jani. > > > > > > > >> > >> Harry > >> > >>> In case if you want to track and implement a quirk for it, like not to > >>> project the HDCP2.2 capability, you can use the receiver id of that panel > >>> to track it. > >>> > >>> Thanks, > >>> -Ram > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Bhawan > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-09-13 8:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-09-09 15:54 HDCP Content Type Interface Lakha, Bhawanpreet 2019-09-10 7:45 ` Jani Nikula 2019-09-12 7:47 ` Ramalingam C 2019-09-12 14:23 ` Harry Wentland 2019-09-12 14:49 ` Ramalingam C 2019-09-12 19:19 ` Harry Wentland 2019-09-12 14:57 ` Jani Nikula 2019-09-12 19:21 ` Harry Wentland 2019-09-13 8:14 ` Daniel Vetter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.