All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Aaron Ma <aaron.ma@canonical.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Alex Deucher <alexdeucher@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Revert "vgaarb: Keep adding VGA device in queue"
Date: Mon, 13 May 2019 12:14:29 +0200	[thread overview]
Message-ID: <75236873-7a53-9106-cba5-b0353aae2eef@daenzer.net> (raw)
In-Reply-To: <1946afdf-f87f-c6bb-e492-be5c73707995@canonical.com>

On 2019-05-10 8:01 p.m., Aaron Ma wrote:
> On 5/10/19 11:46 PM, Michel Dänzer wrote:
>>> Given that the bug is a bit a mess I think we need to add a bit more
>>> context here in the commit message. My understanding:
>>>
>>> Goal of the revert commit was to make the integrated boot device the
>>> primary one, if we can't detect which one is the boot device, instead of
>>> the last one. Which makes some sense.
>>>
>>> Now people have relied on the kernel picking the last one, which usually
>>> is an add-on card, and therefore simply plugging in an add-on card allows
>>> them to overwrite the default choice. Which also makes sense, and since
>>> it's the older behaviour, wins.
>>>
>>> I think it'd be good to add a comment here that this behaviour has become
>>> uapi, e.g.
>>>
>>> 	/* Add at the front so that we pick the last device as fallback
>>> 	 * default, with the usual result that plug in cards are preferred
>>> 	 * over integrated graphics. */
>>>
>>> With that (or similar) and more commit message context:
>> The bug reporter's system doesn't have integrated graphics though, just
>> two plug-in cards. It's not clear to me yet that their expectation of
>> Xorg to pick any particular one of them without configuration was justified.
> 
> 
> This code is kind of fail safe.
> 
> When in hybrid graphic mode.
> It should fallback to integrated GPU, which should always be primary fb.
> So picking 1st (minor PCI ID number) GPU should make more sense.
> 
> When with multiple d-GPUs, we can't say which card should be the right
> one for users when no Xorg conf set.
> Usually BIOS will set the 1st (minor PCI ID number) d-GPU as primary.
> So aligning with BIOS setting will be better I think.

Right. The bug description even says that the card the reporter expected
Xorg to come up on is the "secondary" card in a PCIe 1x slot (whereas
the primary is in PCIe 16x). It seems pretty clear that your change
actually made things better, and the reporter was just relying on the
previous wrong behaviour. Therefore I resolved the report as not a bug,
and this patch should be dropped.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-05-13 10:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 14:29 [PATCH] Revert "vgaarb: Keep adding VGA device in queue" Alex Deucher
     [not found] ` <20190510142958.28017-1-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-05-10 15:42   ` Daniel Vetter
     [not found]     ` <20190510154208.GL17751-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-05-10 15:46       ` Michel Dänzer
     [not found]         ` <58ea5dae-be17-af97-0066-48feab80497e-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-05-10 18:01           ` Aaron Ma
2019-05-13 10:14             ` Michel Dänzer [this message]
2019-05-13 15:11               ` Daniel Vetter
2019-05-10 15:43 ` Michel Dänzer

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=75236873-7a53-9106-cba5-b0353aae2eef@daenzer.net \
    --to=michel@daenzer.net \
    --cc=aaron.ma@canonical.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.