>
>
> > And when the user provides an EDID one should parse it and set the
> default
> > resolution to match it. But that's a less important feature.
>
> It's more complex than you might think, and (to me personally) it seems
> to require more time than its importance justifies.
>
> https://bugzill
On 04/22/20 09:42, Hou Qiming wrote:
> A little off topic thing: isn't the default resolution supposed to be
> 1024x768?
No.
> This is the Microsoft regulation which all my physical devices
> seem to follow:
>
> https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/6afc8979-df62-4d8
A little off topic thing: isn't the default resolution supposed to be
1024x768? This is the Microsoft regulation which all my physical devices
seem to follow:
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/6afc8979-df62-4d86-8f6a-99f05bbdc7f3
And when the user provides an EDID
On 04/20/20 16:13, Gerd Hoffmann wrote:
> Hi,
>
>> So I would say that the symptom you see is a QEMU v4.1.0 regression.
>> The QemuRamfbGraphicsOutputSetMode() function in the OVMF ramfb
>> driver certainly needs the QemuFwCfgWriteBytes() call to work, for
>> changing the resolution.
>
> Oh? Qem
Hi,
> The proper way to enable ramfb resolution change again is adding sanity
> checks for ramfb resolution / pointer / etc. on the QEMU side.
Pointer *is* checked. ramfb creates a mapping, and if that fails due to
the pointer not being valid it bails out.
Sanity-checking the resolution is th
Hi,
> So I would say that the symptom you see is a QEMU v4.1.0 regression. The
> QemuRamfbGraphicsOutputSetMode() function in the OVMF ramfb driver
> certainly needs the QemuFwCfgWriteBytes() call to work, for changing the
> resolution.
Oh? QemuRamfbGraphicsOutputSetMode() can be called multip
On 04/17/20 05:22, Hou Qiming wrote:
> I'm glad we can reach a consensus that ramfb needs sanity checks. And well,
> I'm probably at fault with the hijacking.
>
> Your QEMU/TCG in QEMU/TCG example also made me realize a deeper problem,
> though: your setting still can't escape the host display / p
I'm glad we can reach a consensus that ramfb needs sanity checks. And well,
I'm probably at fault with the hijacking.
Your QEMU/TCG in QEMU/TCG example also made me realize a deeper problem,
though: your setting still can't escape the host display / physical GPU
issue. The middle display layers be
On 04/16/20 06:38, Hou Qiming wrote:
> Very good point, I did neglect ramfb resolution changes... But there is one
> important thing: it *can* cause a QEMU crash, a potentially exploitable
> one, not always a guest crash. That's what motivated my heavy-handed
> approach since allowing resolution ch
Very good point, I did neglect ramfb resolution changes... But there is one
important thing: it *can* cause a QEMU crash, a potentially exploitable
one, not always a guest crash. That's what motivated my heavy-handed
approach since allowing resolution change would have necessitated a good
deal of s
(CC Gerd, Qiming, Marcel, qemu-devel for ramfb:)
On 04/14/20 23:20, valerij zaporogeci wrote:
[snip]
> There is a Boot Manager UI display problem, I don't know if this is
> qemu problem, but with the ARM (both 32 and 64 bits, the qemu version
> is 4.2.0, the OVMF is fresh), and using "ramfb" dev
11 matches
Mail list logo
