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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@xxxxxxxxx]
> Sent: Tuesday, February 19, 2013 11:51 AM
> To: Haiyang Zhang
> Cc: FlorianSchandinat@xxxxxx; linux-fbdev@xxxxxxxxxxxxxxx; KY Srinivasan;
> jasowang@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer
> Driver
> 
> On Fri, Feb 15, Haiyang Zhang wrote:
> 
> > @@ -508,6 +544,18 @@ static int __init vesafb_init(void)
> >  	int ret;
> >  	char *option = NULL;
> >
> > +#if IS_ENABLED(CONFIG_HYPERV_FB)
> > +	/*
> > +	 * On Hyper-V both the emulated and synthetic video devices are
> > +	 * available. To avoid conflicts, we disable vesafb for the
> emulated
> > +	 * video if hyperv_fb is configured.
> > +	 */
> > +	if (is_hyperv()) {
> > +		pr_info("Disabled vesafb on Hyper-V.\n");
> > +		return -ENODEV;
> > +	}
> > +#endif
> 
> What is the reason for this hook? Is it not possible to claim the
> display like its appearently done by other drivers (like radeonfb can
> take over display from vesafb)?

The emulated video device is a separate device from the synthetic video.
The synthetic driver can only take control of the synthetic video, but not
the emulated video.

Actually, we already have a similar mechanism in ata/ata_piix.c to disable
emulated IDE drive on Hyper-V, so it won't conflict with the synthetic drive.

Thanks,
- Haiyang

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux