From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Gerd Hoffmann <kraxel@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
David Airlie <airlied@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"open list:DRM DRIVER FOR BOCHS VIRTUAL GPU"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v3] drm/bochs: add edid support.
Date: Tue, 30 Oct 2018 11:28:24 +0200 [thread overview]
Message-ID: <87y3afokav.fsf@intel.com> (raw)
In-Reply-To: <20181030090632.GJ21967@phenom.ffwll.local>
On Tue, 30 Oct 2018, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote:
>> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
>> > On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> > > Recent qemu (latest master branch, upcoming 3.1 release) got support
>> > > for EDID data. This patch adds guest driver support.
>> > >
>> > > EDID support in qemu is not (yet) enabled by default, so please use
>> > > 'qemu -device VGA,edid=on' for testing.
>> >
>> > Any chance of making this use drm_get_edid() (requires an i2c_adapter)
>> > or at least drm_do_get_edid()?
>>
>> I'll have a look at using drm_do_get_edid(). drm_get_edid() will not
>> fly as there is no i2c adapter in the first place.
>
> Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world
> flakiness of sinks (it's where all the retry logic resides), if you don't
> have a i2c_adapater (because the hw has some magic "give me an edid"
> block). For virtual hw we hopefully don't randomly drop bits on the floor
> between the guest and host. Imo totally fine as-is.
>
> E.g. we also don't feed the VBT edid through drm_do_get_edid either.
But nowadays we do handle the debugfs EDID override and the EDID
firmware loading in drm_do_get_edid(), so using that gives you those
features.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Gerd Hoffmann <kraxel@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
David Airlie <airlied@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
"open list\:DRM DRIVER FOR BOCHS VIRTUAL GPU"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v3] drm/bochs: add edid support.
Date: Tue, 30 Oct 2018 11:28:24 +0200 [thread overview]
Message-ID: <87y3afokav.fsf@intel.com> (raw)
In-Reply-To: <20181030090632.GJ21967@phenom.ffwll.local>
On Tue, 30 Oct 2018, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote:
>> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
>> > On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> > > Recent qemu (latest master branch, upcoming 3.1 release) got support
>> > > for EDID data. This patch adds guest driver support.
>> > >
>> > > EDID support in qemu is not (yet) enabled by default, so please use
>> > > 'qemu -device VGA,edid=on' for testing.
>> >
>> > Any chance of making this use drm_get_edid() (requires an i2c_adapter)
>> > or at least drm_do_get_edid()?
>>
>> I'll have a look at using drm_do_get_edid(). drm_get_edid() will not
>> fly as there is no i2c adapter in the first place.
>
> Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world
> flakiness of sinks (it's where all the retry logic resides), if you don't
> have a i2c_adapater (because the hw has some magic "give me an edid"
> block). For virtual hw we hopefully don't randomly drop bits on the floor
> between the guest and host. Imo totally fine as-is.
>
> E.g. we also don't feed the VBT edid through drm_do_get_edid either.
But nowadays we do handle the debugfs EDID override and the EDID
firmware loading in drm_do_get_edid(), so using that gives you those
features.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2018-10-30 9:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 13:45 [PATCH v3] drm/bochs: add edid support Gerd Hoffmann
2018-10-29 13:45 ` Gerd Hoffmann
2018-10-29 17:44 ` Jani Nikula
2018-10-29 17:44 ` Jani Nikula
2018-10-29 17:44 ` Jani Nikula
2018-10-29 20:05 ` Gerd Hoffmann
2018-10-29 20:05 ` Gerd Hoffmann
2018-10-30 9:06 ` Daniel Vetter
2018-10-30 9:06 ` Daniel Vetter
2018-10-30 9:28 ` Jani Nikula
2018-10-30 9:28 ` Jani Nikula [this message]
2018-10-30 9:28 ` Jani Nikula
2018-10-30 9:44 ` Daniel Vetter
2018-10-30 9:44 ` Daniel Vetter
2018-10-29 20:05 ` Gerd Hoffmann
-- strict thread matches above, loose matches on Subject: below --
2018-10-29 13:45 Gerd Hoffmann
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=87y3afokav.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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.