dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Robert Foss <robert.foss@collabora.com>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Mauro Rossi <issor.oruam@gmail.com>,
	Chih-Wei Huang <cwhuang@linux.org.tw>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] xf86drm: add drmOpenByFB
Date: Fri, 29 May 2020 10:20:23 -0400	[thread overview]
Message-ID: <CADnq5_N9cdqFFgQdm=yWgaR80=ZM=0YbBvY4PqZBrpGkfTunzA@mail.gmail.com> (raw)
In-Reply-To: <20200529104859.33af5eed@eldfell.localdomain>

On Fri, May 29, 2020 at 3:49 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 28 May 2020 17:46:08 +0800
> Chih-Wei Huang <cwhuang@linux.org.tw> wrote:
>
> > The main problem we're trying to solve is to
> > find the DRM device of the primary framebuffer (fb0).
>
> Hi,
>
> I would say that is a completely wrong starting point. Please, let
> fbdev die in peace/pieces. Do not make any new code that relies on
> fbdev existing.
>
> Why do you think you want to follow the setup fbdev has? How do you
> know fb0 is the device you want and not fb1? How do you guarantee that
> fb0 is the device you want?
>
> "It was right on where I tested it" is no guarantee if you do not
> understand how it actually is chosen under the hood. If you know how it
> is chosen under the hood, you can do the same yourself without relying
> on deprecated stuff (fbdev).
>
> It is fbdev that should follow the DRM setup, not pick a DRM device
> based on fbdev.
>
> People already mentioned looking at device properties via libudev API.
> If you cannot have libudev (I believe it does not need udev daemon,
> btw.), then you can look at the same information directly in sysfs. Use
> the information about the DRM devices themselves from sysfs to decide
> which one to pick, and never look at fbdev anything. Or polish the
> patch Emil proposed if boot_vga indeed matches what you actually want
> to find.
>
> I think Daniel Vetter explained nicely what boot_vga means. Is your
> problem that the device may not be a PCI device, but a platform device
> for instance?
>
> Display servers use heuristics, for example if no device has boot_vga,
> then pick the platform device (since there usually is only one with KMS
> capabilities). Here are couple of examples.
>
> Weston wants a device with KMS capabilities, because it currently
> doesn't support using more than one KMS device and it also doesn't
> explicitly support a separate render device:
> https://gitlab.freedesktop.org/wayland/weston/-/blob/8.0.0/libweston/backend-drm/drm.c#L2546-2631
>
> Mutter is primarily looking for a hardware rendering capable device,
> because it can use any number of KMS devices in addition to a rendering
> device, separate or same device:
> https://gitlab.gnome.org/GNOME/mutter/-/blob/3.37.1/src/backends/native/meta-renderer-native.c#L3904-3953
>
> Neither is probably perfect, but they are totally better than picking
> based on fb0.

As an example, on my system with multiple GPUs, the one that the bios
lights up is the last one Linux enumerates when loading the GPU
drivers.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2020-05-29 14:20 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
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 [this message]

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='CADnq5_N9cdqFFgQdm=yWgaR80=ZM=0YbBvY4PqZBrpGkfTunzA@mail.gmail.com' \
    --to=alexdeucher@gmail.com \
    --cc=cwhuang@linux.org.tw \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=issor.oruam@gmail.com \
    --cc=ppaalanen@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).