Hi,
Out of curiousity, though, why not populate the edid block at init? Something like:
I think we need runtime generation of EDID when supporting following cases;
(a) terminal service -Assume that we use qemu-kvm and seabios/vgabios for Terminal service, (as same as Windows Server). -Thin client that run VNC client connect. -qemu may want to ask guest that new (virtual) display is connected and update its resolution. --qemu may trigger guest OS as if your note-PC triggered when connecting projector. --Guest OS request EDID of new (virtual) display -- seabios/vgabios ask qemu about preferable resolution. -- seabios/vgabios return EDID that offer resolution that is good for client.
(b) vnc client resolution change
- vnc client change its resolution.
- qemu may ask guest OS refresh its resolution.
- Seabios/vgabios report a preferred resolution as EDID.
If we don't need such feature (in future), populating the edid block at init is ok.
I think we should populate at init time.
BTW: a CONFIG_EDID would be nice.
As Gred suggest me, we can add bochs api that offer preferable resolution, and use it for above scenario, that may be great.
Indeed ...
I'm sorry I don't know how trigger guest os from host when VNC client connect or change its resolution.
... but seabios doesn't need to worry about this.
The usual way the (virtual) hardware signals such changes to the os is to raise an interrupt, and the os gfx card driver handles it. No seabios involved here. Even if seabios would handle the interrupt and update the edid there would still be the problem that there simply is no bios interface which seabios could use to inform the guest os.
sea(vga)bios should just use what it finds at boot time and not worry about any changes while the guest is running. If something changes seabios will pick it up on the next reboot.
cheers, Gerd