From: Daniel Axtens <dja@axtens•net>
To: Laszlo Ersek <lersek@redhat•com>,
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: Wed, 26 Jul 2017 08:20:18 +1000 [thread overview]
Message-ID: <87lgncupjx.fsf@linkitivity.dja.id.au> (raw)
In-Reply-To: <a61222c6-e548-1e3b-f6f7-63952b90ac13@redhat.com>
Hi Laszlo,
Thanks for your input!
>> 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.
You're right, the issue is that the primary/boot device is tied to the
VGA arbiter.
>
> 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.)
Yes, they can be split or a way of marking the default vga device that
doesn't depend on the arbiter can be added.
(But there is some question about what it actually means to be a boot
vga card - it's better defined on an x86 system, but on a ppc or arm64
system we're reduced to guessing based on the first driver loaded.)
> (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 :)
Originally this was brought to the fore through a PCI bridge that wasn't
spec compliant, and originally I proposed a simple quirk: [0]. However,
that highlighted the related issue that platforms that don't use legacy
resources still go through the VGA arbiter process which is built around
legacy resource arbitration. Changing that behaviour also fixes the
issue with the non-spec-compliant bridge because the new model doesn't
rely upon the particular part of the spec that the bridge violates.
I'm not fussy about how we solve this problem, so long as we solve this
problem somehow.
Regards,
Daniel
[0]: https://patchwork.ozlabs.org/patch/787003/
>
> Thanks
> Laszlo
prev parent reply other threads:[~2017-07-25 22:20 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
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 [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=87lgncupjx.fsf@linkitivity.dja.id.au \
--to=dja@axtens$(echo .)net \
--cc=airlied@linux$(echo .)ie \
--cc=alex.williamson@redhat$(echo .)com \
--cc=ard.biesheuvel@linaro$(echo .)org \
--cc=benh@kernel$(echo .)crashing.org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=daniel.vetter@intel$(echo .)com \
--cc=gabriele.paoloni@huawei$(echo .)com \
--cc=hdegoede@redhat$(echo .)com \
--cc=lersek@redhat$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-pci@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=will.deacon@arm$(echo .)com \
--cc=z.liuxinliang@hisilicon$(echo .)com \
--cc=zourongrong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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