Thread (13 messages) read the whole thread 13 messages, 3 authors, 2013-02-28

RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver

From: Haiyang Zhang <haiyangz@microsoft.com>
Date: 2013-02-22 04:11:55
Also in: lkml

From: Olaf Hering
Sent: Thursday, February 21, 2013 10:53 AM
To: Haiyang Zhang
Cc: FlorianSchandinat@gmx.de; linux-fbdev@vger.kernel.org; KY Srinivasan; jasowang@redhat.com; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org
Subject: Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver

On Tue, Feb 19, Haiyang Zhang wrote:
quoted
In my test, the vesafb doesn't automatically give up the emulated video device,
unless I add the DMI based mechanism to let it exit on Hyper-V.
From reading the code, it seems to do that via
do_remove_conflicting_framebuffers(). hypervfb does not set apertures
etc, so that function is a noop.
We are currently allocating a new framebuffer for hyperv_fb, which is different
from the framebuffer for the emulated video. So this cannot be detected by
do_remove_conflicting_framebuffers() based on apertures_overlap().
My point is that with this new driver distro kernel will have no console
output until hypervfb is loaded. On native hardware there is at least
vesafb which can display something until initrd is running. So if the
hypervisor allows that hypervfb can shutdown the emulated vesa hardware
then it should do that.
Since the generic vga driver starts to work early in the boot process, the console
messages are still displayed without vesafb. Actually, I didn't see any console 
messages missing when comparing it to the original VM before my patch.

Thanks,
- Haiyang
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help