Hi,
> > QemuRamfbDxe registers as VenHw device with a fresh generated uuid.
> > The uuid should probably go to some header file, suggestions where to
> > place it best?
>
> (1) Under "OvmfPkg/Include/Guid/". The file "VirtioMmioTransport.h" is a
> minimal example.
Ok.
> (4) Once you add the v
On 06/06/18 10:49, Gerd Hoffmann wrote:
> edk2:
>QemuRamfbDxe driver, x86 wireup, incomplete arm wireup.
I'm looking at the patches very cursorily right now:
> Notes on QemuRamfbDxe:
>
> QemuRamfbDxe registers as VenHw device with a fresh generated uuid.
> The uuid should probably go to some
Hi,
> > Maybe we should for now just scratch the idea of an virtio-ramfb device.
> > Linux doesn't need it, and windows wouldn't use the virtio part of it so
> > a standalone ramfb device would work equally well.
>
> If that works for you, it works for me best!
Ok, pushed updated branches.
q
On 06/05/18 15:16, Gerd Hoffmann wrote:
> On Tue, Jun 05, 2018 at 02:07:27PM +0200, Laszlo Ersek wrote:
>> On 06/05/18 13:06, Gerd Hoffmann wrote:
>>> Hi,
>>>
>> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
>> drivers in OvmfPkg that could otherwise drive this de
On Tue, Jun 05, 2018 at 02:07:27PM +0200, Laszlo Ersek wrote:
> On 06/05/18 13:06, Gerd Hoffmann wrote:
> > Hi,
> >
> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
> drivers in OvmfPkg that could otherwise drive this device, ignore it --
> another (platfor
On 06/05/18 13:06, Gerd Hoffmann wrote:
> Hi,
>
I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
drivers in OvmfPkg that could otherwise drive this device, ignore it --
another (platform) driver in OvmfPkg will pick it up instead".
>>>
>>> pci capability for
Hi,
> >> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
> >> drivers in OvmfPkg that could otherwise drive this device, ignore it --
> >> another (platform) driver in OvmfPkg will pick it up instead".
> >
> > pci capability for ramfb could be useful (also for linux). I'
On 05/31/18 10:43, Gerd Hoffmann wrote:
> Hi,
>
> Resuming an old discussion ...
>
>>> From
>>> the guests point of view there is no difference between
>>>
>>> (a) qemu -device virtio-ramfb, and
>>> (b) qemu -device virtio-gpu-pci -device ramfb-testdev
>>>
>>> On the host side the differenc
Hi,
Resuming an old discussion ...
> > From
> > the guests point of view there is no difference between
> >
> > (a) qemu -device virtio-ramfb, and
> > (b) qemu -device virtio-gpu-pci -device ramfb-testdev
> >
> > On the host side the difference is that (a) is a single QemuConsole
> > whic
On 04/25/18 16:07, Gerd Hoffmann wrote:
> Hi,
>
>>> We should make sure that any device model that combines ramfb with
>>> another PCI display device is not matched by the OVMF driver for that
>>> PCI display device. IOW, we should use separate PCI IDs or subsystem
>>> IDs (I don't recall the de
Hi,
> > We should make sure that any device model that combines ramfb with
> > another PCI display device is not matched by the OVMF driver for that
> > PCI display device. IOW, we should use separate PCI IDs or subsystem
> > IDs (I don't recall the details off-hand). I'd like to avoid messing
>
Hi all,
On 23 March 2018 at 13:27, Laszlo Ersek wrote:
> Adding Ard and Marc, and keeping the context undisturbed for his sake.
> Comments at the bottom.
>
> On 03/23/18 13:25, Gerd Hoffmann wrote:
>> Hi,
>>
>> Ok folks, here is a experimental patch series for a legacy free boot
>> framebuffer.
On 03/23/18 18:07, Gerd Hoffmann wrote:
> On Fri, Mar 23, 2018 at 04:12:21PM +0100, Laszlo Ersek wrote:
>> On 03/23/18 15:51, Gerd Hoffmann wrote:
>>> Hi,
>>>
I believe the only point of this device model (and the associated guest
fw driver) is Windows-on-KVM/aarch64.
>>>
>>> The other
On Fri, Mar 23, 2018 at 04:12:21PM +0100, Laszlo Ersek wrote:
> On 03/23/18 15:51, Gerd Hoffmann wrote:
> > Hi,
> >
> >> I believe the only point of this device model (and the associated guest
> >> fw driver) is Windows-on-KVM/aarch64.
> >
> > The other one is vgpu boot display.
>
> Interestin
On 03/23/18 15:51, Gerd Hoffmann wrote:
> Hi,
>
>> I believe the only point of this device model (and the associated guest
>> fw driver) is Windows-on-KVM/aarch64.
>
> The other one is vgpu boot display.
Interesting. I know nearly nothing about vgpu, but I hoped it'd come
with its own UEFI GOP
Hi,
> I believe the only point of this device model (and the associated guest
> fw driver) is Windows-on-KVM/aarch64.
The other one is vgpu boot display.
And maybe killing vga emulation. Well, at least be able to not use it
any more for UEFI guests. It's so much crazy stuff in vga emulation
Adding Ard and Marc, and keeping the context undisturbed for his sake.
Comments at the bottom.
On 03/23/18 13:25, Gerd Hoffmann wrote:
> Hi,
>
> Ok folks, here is a experimental patch series for a legacy free boot
> framebuffer. If you want play with it I recommend getting the bits from
>
>
Hi,
Ok folks, here is a experimental patch series for a legacy free boot
framebuffer. If you want play with it I recommend getting the bits from
https://www.kraxel.org/cgit/qemu/log/?h=sirius/ramfb
because they come with an updated seabios and a new vgabios rom and an
experimental OVM
18 matches
Mail list logo
