On 14/04/17 08:06, Oleksandr Andrushchenko wrote: > On 04/14/2017 03:12 AM, Stefano Stabellini wrote: >> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >>> >>> For some use cases when Xen framebuffer/input backend >>> is not a part of Qemu it is required to disable it, >>> because of conflicting access to input/display devices. >>> Introduce additional configuration option for explicit >>> input/display control. >> In these cases when you don't want xenfb, why don't you just remove >> "vfb" from the xl config file? QEMU only starts the xenfb backend when >> requested by the toolstack. >> >> Is it because you have an alternative xenfb backend? If so, is it really >> fully xenfb compatible, or is it a different protocol? If it is a >> different protocol, I suggest you rename your frontend/backend PV device >> name to something different from "vfb". >> > Well, offending part is vkbd actually (for multi-touch > we run our own user-space backend which supports > kbd/ptr/mtouch), but vfb and vkbd is the same backend > in QEMU. So, I am ok for vfb, but just want vkbd off > So, there are 2 options: > 1. At compile time remove vkbd and still allow vfb > 2. Remove xenfb completely, if acceptable (this is my case)
What about adding a Xenstore entry for backend type and let qemu test for it being not present or containing "qemu"? Juergen
