From: Simon Ser <contact@emersion.fr>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Robert Foss <robert.foss@collabora.com>,
Emil Velikov <emil.l.velikov@gmail.com>,
Mauro Rossi <issor.oruam@gmail.com>,
"cwhuang@linux.org.tw" <cwhuang@linux.org.tw>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] xf86drm: add drmOpenByFB
Date: Sun, 24 May 2020 19:25:12 +0000 [thread overview]
Message-ID: <2xZF5q7722pK-_L_0jQjYv33oMS6WS4Jm06tbVwUo9SQO9QBv48_HaVhzVHTb2OLnz3JUj3O1uRYn_y-JWGrWpD3c8J0y8Mr_qgwbNzsxDE=@emersion.fr> (raw)
In-Reply-To: <CAKMK7uGKps4AfLKTSP2HZTHd1cm+1dMD9r8M9rKobqwXGgv5EQ@mail.gmail.com>
On Sunday, May 24, 2020 8:53 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sat, May 23, 2020 at 5:44 PM Mauro Rossi issor.oruam@gmail.com wrote:
>
> > OpenByFB is introduced to overcome GPU driver loading order issue
> > on a device with multiple GPUs, e.g. Intel iGPU and Nvidia dGPU
> > where the first drmfb kernel module loaded will become device file
> > /dev/dri/card0 and the second will become /dev/dri/card1
> > The use case is to prefer Intel iGPU over dGPU, or viceversa,
> > in a deterministic and reliable manner.
> > OpenByFB function opens the DRM device with specified fb and node type,
> > thus enabling gralloc to open the correct device node of the primary fb,
> > regardless of the GPU driver loading order.
>
> The fbdev load ordering is as inconsistent/random as the dri node
> loading. Well more so, because you might have random firmware fbdev
> drivers hanging out there. Hence I'm not following how this solves
> anything for your problem.
>
> I think usually what userspace does it look at the boot_vga property
> of the underlying device in sysfs, and prefer that one.
Yes. See [1] for an example of how to do this.
[1]: https://github.com/swaywm/wlroots/blob/5c942bd5972afee9a68cb15c14aa83b4b0aaf82d/backend/session/session.c#L331
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-24 19:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-23 15:44 [PATCH] xf86drm: add drmOpenByFB Mauro Rossi
2020-05-23 21:36 ` Simon Ser
2020-05-24 18:53 ` Daniel Vetter
2020-05-24 19:25 ` Simon Ser [this message]
2020-05-28 9:46 ` Chih-Wei Huang
2020-05-28 12:38 ` Emil Velikov
2020-05-29 7:48 ` Pekka Paalanen
2020-05-29 14:20 ` Alex Deucher
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='2xZF5q7722pK-_L_0jQjYv33oMS6WS4Jm06tbVwUo9SQO9QBv48_HaVhzVHTb2OLnz3JUj3O1uRYn_y-JWGrWpD3c8J0y8Mr_qgwbNzsxDE=@emersion.fr' \
--to=contact@emersion.fr \
--cc=cwhuang@linux.org.tw \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=issor.oruam@gmail.com \
--cc=robert.foss@collabora.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).