All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Dave Airlie <airlied@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes
Date: Mon, 20 Feb 2017 23:22:52 +0100	[thread overview]
Message-ID: <CAKMK7uF2AAjyfjSCtDrruwchi8uh8rTntdzL5cdoV9TCtCy0=A@mail.gmail.com> (raw)
In-Reply-To: <e191dc21-f92b-1e31-1999-3b653252d636@shipmail.org>

On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.

I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your control tool is
using (i.e. which ioctl), plus links to the source code for future
references. Also not sold on the immediate revert, this stuff has been
merged since months.
-Daniel

>
> /Thomas
>
>
> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>> Hi!
>>
>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>> node to tell DRM about the monitor layout...
>>
>> /Thomas
>>
>>
>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>> Looking at the ioctl permission checks I noticed that it's impossible
>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>> also don't work, so no joy with dma-bufs.
>>>
>>> The only way to do anything with a control node is by drawing stuff
>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>> entirely unused thing, and a cursory check shows that there does not
>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>> functions using DRM_MODE_CONTROL.
>>>
>>> Since I don't like dead uabi, let's remove it. But since this would be
>>> a really big change I think it's better to start out small by simply
>>> not registering anything. We can garbage-collect the dead code later
>>> on, once we're sure it's really not used anywhere.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 6efdba4993fc..f085e28ffc6f 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>              goto err_free;
>>>      }
>>>
>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>> -            if (ret)
>>> -                    goto err_minors;
>>> -    }
>>> -
>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>              if (ret)
>>
>> _______________________________________________
>> 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

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes
Date: Mon, 20 Feb 2017 23:22:52 +0100	[thread overview]
Message-ID: <CAKMK7uF2AAjyfjSCtDrruwchi8uh8rTntdzL5cdoV9TCtCy0=A@mail.gmail.com> (raw)
In-Reply-To: <e191dc21-f92b-1e31-1999-3b653252d636@shipmail.org>

On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.

I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your control tool is
using (i.e. which ioctl), plus links to the source code for future
references. Also not sold on the immediate revert, this stuff has been
merged since months.
-Daniel

>
> /Thomas
>
>
> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>> Hi!
>>
>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>> node to tell DRM about the monitor layout...
>>
>> /Thomas
>>
>>
>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>> Looking at the ioctl permission checks I noticed that it's impossible
>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>> also don't work, so no joy with dma-bufs.
>>>
>>> The only way to do anything with a control node is by drawing stuff
>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>> entirely unused thing, and a cursory check shows that there does not
>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>> functions using DRM_MODE_CONTROL.
>>>
>>> Since I don't like dead uabi, let's remove it. But since this would be
>>> a really big change I think it's better to start out small by simply
>>> not registering anything. We can garbage-collect the dead code later
>>> on, once we're sure it's really not used anywhere.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_drv.c | 6 ------
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 6efdba4993fc..f085e28ffc6f 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>>              goto err_free;
>>>      }
>>>
>>> -    if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> -            ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>> -            if (ret)
>>> -                    goto err_minors;
>>> -    }
>>> -
>>>      if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>>              ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>>              if (ret)
>>
>> _______________________________________________
>> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-20 22:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28  8:10 [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Daniel Vetter
2016-10-28  8:45 ` ✗ Fi.CI.BAT: warning for " Patchwork
2016-11-17  7:42 ` [PATCH] [RFC] " Daniel Vetter
2016-12-06  1:42   ` Mike Lothian
2016-12-06  1:47     ` Michel Dänzer
2016-12-06  1:55       ` Mike Lothian
2017-02-19 14:54 ` Thomas Hellstrom
2017-02-19 15:21   ` Thomas Hellstrom
2017-02-19 15:21     ` Thomas Hellstrom
2017-02-20 22:22     ` Daniel Vetter [this message]
2017-02-20 22:22       ` Daniel Vetter
2017-02-21  5:32       ` DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) Thomas Hellstrom
2017-02-21  5:32         ` Thomas Hellstrom
2017-02-21  5:34         ` David Airlie
2017-02-21  5:34           ` David Airlie
2017-02-21 10:52           ` Thomas Hellstrom
2017-02-21 10:52             ` Thomas Hellstrom
2017-02-21 11:11       ` [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes Thomas Hellstrom
2017-02-21 11:11         ` Thomas Hellstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uF2AAjyfjSCtDrruwchi8uh8rTntdzL5cdoV9TCtCy0=A@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@shipmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.