linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Daniel Axtens <dja@axtens.net>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Hans de Goede <hdegoede@redhat.com>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	David Airlie <airlied@linux.ie>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Will Deacon <will.deacon@arm.com>,
	"Liuxinliang (Matthew Liu)" <z.liuxinliang@hisilicon.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Zou Rongrong <zourongrong@gmail.com>,
	daniel.vetter@intel.com
Subject: Re: [PATCH 0/4] Allow non-legacy cards to be vgaarb default
Date: Tue, 25 Jul 2017 13:22:43 +0200	[thread overview]
Message-ID: <a61222c6-e548-1e3b-f6f7-63952b90ac13@redhat.com> (raw)
In-Reply-To: <87r2x6vj7t.fsf@linkitivity.dja.id.au>

On 07/24/17 01:15, Daniel Axtens wrote:
> Hi Ard,
> 
>> But the fact remains that we are going about this the wrong way.
>> Whether a graphics card decodes legacy VGA ranges or not has *nothing*
>> to do with whether or not it is in fact the primary device on a
>> non-x86 system, and so I still think the VGA arbiter should be omitted
>> entirely for such platforms, and Xorg should be fixed instead.
> 
> OK, I see where you're coming from. I've been trying to keep my changes
> small as I don't want to end up on the hook for the almost limitless
> range of problems that changing this sort of code can have, but I do
> take your point that it's a bit of an ugly hack of a solution.
> 
> Say we were to change Xorg instead. What would correct Xorg behaviour
> look like? Xorg would need to honour the boot_vga file if it existed so
> as not to break x86, etc. So your proposed Xorg - if it couldn't find a
> default card that way, and if there was no helpful config file info,
> would arbitrarily pick a card that has an Xorg driver? In other words,
> much like the proposed kernel approach but at a different level of the
> stack?
> 
> Are there other graphical applications we care about (other than Xorg)
> that would need to be patched? I'm happy to do the Xorg patch, but I
> don't know if anything other than Xorg keys off the boot_vga file.
> 
> I'm not fundamentally opposed to this approach if the Xorg community is
> happy with it, the kernel community is happy with it, and no-one expects
> me to provide patches to any other user-space applications that depend
> on boot_vga.

Ard both identified the Xorg commit that I would have, and CC'd Hans
which I would have recommended as well.

I assume the symptom is that now there's a class of platform GPU devices
that is neither PCI nor legacy VGA, so neither the kernel's boot_vga
logic matches it, nor Xorg's commit in question.

I agree that it should be possible to add more logic to Xorg to detect
this kind device as primary. However, I share Daniel's worry that it
wouldn't cover all user space apps -- I see "Wayland this, Wayland that"
on reddit every week.

Having practically zero background in gfx development (either kernel or
Xorg), I think the problem is that vga_default_device() /
vga_set_default_device(), which -- apparently -- "boot_vga" is based
upon, come from "drivers/gpu/vga/vgaarb.c". Namely, the concept of
"primary / boot display device" is tied to the VGA arbiter, plus only a
PCI device can currently be marked as primary/boot display device.

Can these concepts be split from each other? (I can fully imagine that
this would result in a userspace visible interface change (or addition),
so that e.g. "/sys/devices/**/boot_gpu" would have to be consulted by
display servers.)

(Sorry if I'm totally wrong.)

... Hm, reading the thread starter at
<https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg120851.html>,
and the references within... It looks like this work is motivated by
hardware that is supposed to be PCI, but actually breaks the specs. Is
that correct? If so, then I don't think I can suggest anything useful.
Specs exist so that hardware vendors and software authors follow them.
If hardware does not conform, then software should either refuse to work
with it, or handle it with quirks, on a case-by-case basis. I guess this
means that I don't agree with the

  broad[] suggest[ion] that a more generic solution would be better

which seems to disqualify me from the discussion, as it must have been
suggested by people with incomparably more experience than what I have :)

Thanks
Laszlo

  reply	other threads:[~2017-07-25 11:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19  1:28 [PATCH 0/4] Allow non-legacy cards to be vgaarb default Daniel Axtens
2017-07-19  1:28 ` [PATCH 1/4] powerpc: simplify and fix VGA default device behaviour Daniel Axtens
2017-07-19  1:36   ` Benjamin Herrenschmidt
2017-07-19  1:28 ` [PATCH 2/4] vgaarb: allow non-legacy cards to be marked as default Daniel Axtens
2017-07-19  1:28 ` [PATCH 2/3] vgaarb rework Daniel Axtens
2017-07-19  1:28 ` [PATCH 3/3] extend to arm Daniel Axtens
2017-07-19  1:28 ` [PATCH 3/4] powerpc: replace vga_fixup() with generic code Daniel Axtens
2017-07-19  1:28 ` [PATCH 4/4] arm64: allow non-legacy VGA devices to be default Daniel Axtens
2017-07-19  1:55 ` [PATCH 0/4] Allow non-legacy cards to be vgaarb default Daniel Axtens
2017-07-19  8:25 ` Ard Biesheuvel
2017-07-20 23:52   ` Daniel Axtens
2017-07-21  9:05     ` Ard Biesheuvel
2017-07-23 23:15       ` Daniel Axtens
2017-07-25 11:22         ` Laszlo Ersek [this message]
2017-07-25 15:56           ` Gabriele Paoloni
2017-07-26 10:45             ` Laszlo Ersek
2017-08-11 22:05             ` Bjorn Helgaas
2017-07-25 22:20           ` Daniel Axtens

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=a61222c6-e548-1e3b-f6f7-63952b90ac13@redhat.com \
    --to=lersek@redhat.com \
    --cc=airlied@linux.ie \
    --cc=alex.williamson@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.vetter@intel.com \
    --cc=dja@axtens.net \
    --cc=gabriele.paoloni@huawei.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=will.deacon@arm.com \
    --cc=z.liuxinliang@hisilicon.com \
    --cc=zourongrong@gmail.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).