[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACvgo51skbWdw8E8RftZZjA2wUV0_RHPCiPbSR42XPY9aCfg6w@mail.gmail.com>
Date: Thu, 10 Sep 2015 16:04:37 +0100
From: Emil Velikov <emil.l.velikov@...il.com>
To: Gerd Hoffmann <kraxel@...hat.com>
Cc: ML dri-devel <dri-devel@...ts.freedesktop.org>,
Dave Airlie <airlied@...hat.com>,
open list <linux-kernel@...r.kernel.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH 5/5] virtgpu: mark as a render gpu
On 10 September 2015 at 15:52, Gerd Hoffmann <kraxel@...hat.com> wrote:
> Hi,
>
>> > Dave? Looking at the ioctls they are all fine for render nodes, there
>> > isn't anything modesetting related in the device-specific ioctls.
>> >
>> > Correct?
>> >
>> Unless I've overdone the coffee this time - modesetting is done via
>> the card# node, while render via either card# or renderD#.
>
> Exactly, thats why anything modesetting-related must be disabled for
> renderD#. Looking at the virtio-gpu device-specific ioctls I don't
> think there is anything doing modesetting (which we would have to leave
> out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe
> there is a global switch to flip DRM_RENDER_ALLOW for the whole list ...
>
IMHO the idea of having a 'global' switch sounds quite good, yet there
isn't one atm :-( It will be quite useful as we get more render only
devices.
DRIVER_RENDER doesn't do that unfortunately (which I think was the
original assumption), it only instructs drm core to create the
renderD# device/node.
Hope this clears up any ambiguity from my earlier replies :-)
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists