From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Date: Tue, 16 Jun 2020 10:51:56 +0000 Subject: Re: [RFC PATCH 0/4] DirectX on Linux Message-Id: <20200616105156.GE1718@bug> List-Id: References: <20200519163234.226513-1-sashal@kernel.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dave Airlie Cc: Sasha Levin , linux-hyperv@vger.kernel.org, sthemmin@microsoft.com, "Ursulin, Tvrtko" , Greg Kroah-Hartman , haiyangz@microsoft.com, LKML , dri-devel , Chris Wilson , spronovo@microsoft.com, Linux Fbdev development list , iourit@microsoft.com, "Deucher, Alexander" , kys@microsoft.com, wei.liu@kernel.org, Hawking Zhang > > Having said that, I hit one stumbling block: > > "Further, at this time there are no presentation integration. " > > > > If we upstream this driver as-is into some hyperv specific place, and > > you decide to add presentation integration this is more than likely > > going to mean you will want to interact with dma-bufs and dma-fences. > > If the driver is hidden away in a hyperv place it's likely we won't > > even notice that feature landing until it's too late. > > > > I would like to see a coherent plan for presentation support (not > > code, just an architectural diagram), because I think when you > > contemplate how that works it will change the picture of how this > > driver looks and intergrates into the rest of the Linux graphics > > ecosystem. > > > > As-is I'd rather this didn't land under my purview, since I don't see > > the value this adds to the Linux ecosystem at all, and I think it's > > important when putting a burden on upstream that you provide some > > value. > > I also have another concern from a legal standpoint I'd rather not > review the ioctl part of this. I'd probably request under DRI > developers abstain as well. > > This is a Windows kernel API being smashed into a Linux driver. I don't want to be > tainted by knowledge of an API that I've no idea of the legal status of derived works. > (it this all covered patent wise under OIN?) If you can't look onto it, perhaps it is not suitable to merge into kernel...? What would be legal requirements so this is "safe to look at"? We should really require submitter to meet them... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D786C433DF for ; Tue, 16 Jun 2020 10:52:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DA4A320776 for ; Tue, 16 Jun 2020 10:52:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728483AbgFPKwL (ORCPT ); Tue, 16 Jun 2020 06:52:11 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:53542 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728435AbgFPKwL (ORCPT ); Tue, 16 Jun 2020 06:52:11 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id C6A1E1C0BD2; Tue, 16 Jun 2020 12:52:09 +0200 (CEST) Date: Tue, 16 Jun 2020 12:51:56 +0200 From: Pavel Machek To: Dave Airlie Cc: Sasha Levin , "Deucher, Alexander" , Chris Wilson , Ville Syrj??l?? , Hawking Zhang , "Ursulin, Tvrtko" , linux-hyperv@vger.kernel.org, sthemmin@microsoft.com, Greg Kroah-Hartman , haiyangz@microsoft.com, LKML , dri-devel , spronovo@microsoft.com, wei.liu@kernel.org, Linux Fbdev development list , iourit@microsoft.com, kys@microsoft.com Subject: Re: [RFC PATCH 0/4] DirectX on Linux Message-ID: <20200616105156.GE1718@bug> References: <20200519163234.226513-1-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-hyperv-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org > > Having said that, I hit one stumbling block: > > "Further, at this time there are no presentation integration. " > > > > If we upstream this driver as-is into some hyperv specific place, and > > you decide to add presentation integration this is more than likely > > going to mean you will want to interact with dma-bufs and dma-fences. > > If the driver is hidden away in a hyperv place it's likely we won't > > even notice that feature landing until it's too late. > > > > I would like to see a coherent plan for presentation support (not > > code, just an architectural diagram), because I think when you > > contemplate how that works it will change the picture of how this > > driver looks and intergrates into the rest of the Linux graphics > > ecosystem. > > > > As-is I'd rather this didn't land under my purview, since I don't see > > the value this adds to the Linux ecosystem at all, and I think it's > > important when putting a burden on upstream that you provide some > > value. > > I also have another concern from a legal standpoint I'd rather not > review the ioctl part of this. I'd probably request under DRI > developers abstain as well. > > This is a Windows kernel API being smashed into a Linux driver. I don't want to be > tainted by knowledge of an API that I've no idea of the legal status of derived works. > (it this all covered patent wise under OIN?) If you can't look onto it, perhaps it is not suitable to merge into kernel...? What would be legal requirements so this is "safe to look at"? We should really require submitter to meet them... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADB67C433E0 for ; Tue, 16 Jun 2020 10:52:12 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8BA6220739 for ; Tue, 16 Jun 2020 10:52:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BA6220739 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EC3406E899; Tue, 16 Jun 2020 10:52:11 +0000 (UTC) Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1CEF46E899 for ; Tue, 16 Jun 2020 10:52:11 +0000 (UTC) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id C6A1E1C0BD2; Tue, 16 Jun 2020 12:52:09 +0200 (CEST) Date: Tue, 16 Jun 2020 12:51:56 +0200 From: Pavel Machek To: Dave Airlie Subject: Re: [RFC PATCH 0/4] DirectX on Linux Message-ID: <20200616105156.GE1718@bug> References: <20200519163234.226513-1-sashal@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , linux-hyperv@vger.kernel.org, sthemmin@microsoft.com, "Ursulin, Tvrtko" , Greg Kroah-Hartman , haiyangz@microsoft.com, LKML , dri-devel , Chris Wilson , spronovo@microsoft.com, Linux Fbdev development list , iourit@microsoft.com, "Deucher, Alexander" , kys@microsoft.com, wei.liu@kernel.org, Hawking Zhang Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > > Having said that, I hit one stumbling block: > > "Further, at this time there are no presentation integration. " > > > > If we upstream this driver as-is into some hyperv specific place, and > > you decide to add presentation integration this is more than likely > > going to mean you will want to interact with dma-bufs and dma-fences. > > If the driver is hidden away in a hyperv place it's likely we won't > > even notice that feature landing until it's too late. > > > > I would like to see a coherent plan for presentation support (not > > code, just an architectural diagram), because I think when you > > contemplate how that works it will change the picture of how this > > driver looks and intergrates into the rest of the Linux graphics > > ecosystem. > > > > As-is I'd rather this didn't land under my purview, since I don't see > > the value this adds to the Linux ecosystem at all, and I think it's > > important when putting a burden on upstream that you provide some > > value. > > I also have another concern from a legal standpoint I'd rather not > review the ioctl part of this. I'd probably request under DRI > developers abstain as well. > > This is a Windows kernel API being smashed into a Linux driver. I don't want to be > tainted by knowledge of an API that I've no idea of the legal status of derived works. > (it this all covered patent wise under OIN?) If you can't look onto it, perhaps it is not suitable to merge into kernel...? What would be legal requirements so this is "safe to look at"? We should really require submitter to meet them... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel