[Mesa-dev] [PATCH] egl/dri2: implement platform_null.

[Haixia Shi]

Hi Emil,

On Fri, Jan 23, 2015 at 8:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Might be worth having a look at how platform_drm does it. But we warned
> there be dragons :)

It seems platform_drm would cast disp->PlatformDisplay to a gbm_device
and use it if available; otherwise it always uses the first normal
node (/dev/dri/card0).

Can it be assumed that if render nodes are available then it would
always be the first one (/dev/dri/renderD128)? Otherwise I still think
it is correct to run a for loop to try all the available render nodes
(renderD128..renderD191)

Thanks,
Haixia

On Fri, Jan 23, 2015 at 8:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 23/01/15 02:00, Haixia Shi wrote:
>> Hi Emil,
>>
>> On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 22/01/15 22:23, Haixia Shi wrote:
>>>> Hi Emil
>>>>
>>>> On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> Hi Haixia Shi,
>>>>>
>>>>> On 22/01/15 17:35, Haixia Shi wrote:
>>>>>> Try the render node first and use it if available. Otherwise fall back to
>>>>>> normal nodes.
>>>>>>
>>>>> What is the use-case for such a platform - I assume it's worth
>>>>> mentioning in the commit message ?
>>>>>
>>>>> No other platform picks the device at random as seen below. Why did you
>>>>> choose such an approach ? It seems like one can easily shoot themselves
>>>>> by using it.
>>>>
>>>> CC Stephane. The goal here is just to pick the first available node
>>>> for off-screen rendering only.
>>>>
>>> Hmm I'm guessing that using the drm/gbm platform is out of the question
>>> ? Iirc there has been a bit of love on the gbm topic, and afaiu this
>>> solution is to be used with minigbm ?
>>
>> Yes this solutions is to be used with minigbm.
>>
>>>
>>> What I'm thinking here is:
>>> If you're testing a device with provides two or more nodes (be that the
>>> classic card or the render ones), one cannot guarantee that the kernel
>>> module for hw#1 will be loaded first. Thus even if one presumes that
>>> they are working on (testing) hw#1 that may or may not be the case.
>>>
>>> Not 100% sure on the module order part, so I could be wrong.
>>
>> I don't have a good answer for that... any suggestion on how best to
>> pick the right one?
>>
> Might be worth having a look at how platform_drm does it. But we warned
> there be dragons :)
>
>>>>>> +         char *card_path;
>>>>>> +         if (asprintf(&card_path, node_path_fmt, base + i) < 0)
>>>>>> +            continue;
>>>>>> +
>>>>>> +         dri2_dpy->fd = open(card_path, O_RDWR);
>>>>> If you open a normal node (card%d) I believe that you'll need an
>>>>> authenticate hook in dri2_egl_display_vtbl. Does things work without it
>>>>> on your system/platform ?
>>>>
>>>> You're correct; normal node would require the legacy auth hook, and it
>>>> would only work without auth if the process is run as root, which is
>>>> why we're trying render nodes first.
>>>>
>>> So you're saying that people without render nodes should run egl(mesa)
>>> as root ? That does not sound like a wise suggestion imho.
>>>
>>> Basically what I'm trying to say is - if you have a fall-back to normal
>>> nodes, some form of auth ought to be in place.
>>
>> I see your point. Would it be cleaner if we simply require render node
>> to be present? The normal node (card%d) and the auth hook is more
>> trouble than its worth.
>>
> It's up-to you if you want to keep it.
> I'm just pointing out that having a fall-back that (a) mostly fails,
> without giving a clear indication as to why, or (b) forces you to run
> the app as root is counter-intuitive (not the best security practise)
> for most people.
>
>
> -Emil