Hi Emil, On Fri, Jan 23, 2015 at 8:42 AM, Emil Velikov <emil.l.veli...@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.veli...@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.veli...@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.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
