On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco <stevenfalco@xxxxxxxxx <mailto:stevenfalco@xxxxxxxxx>> wrote:
On 1/11/22 03:24 PM, Seth Hillbrand wrote:
> We will not directly disable running in a VM.
>
> Our stance is that if there are issues running KiCad in a VM, they should be reported to the maker of the VM, not KiCad.
I'm going to have to disagree with that stance a little, Seth. The initial bug report https://gitlab.com/kicad/code/kicad/-/issues/8944 <https://gitlab.com/kicad/code/kicad/-/issues/8944> was from a Virtualbox user. Then I saw the problem using the native Linux KVM. Two different VM implementations. And I think the root cause was a KiCad bug where the code didn't properly test for GLX_EXT_swap_control_tear. So reporting to either of those VM makers would not have been effective, in this case.
Root cause was Mesa/X11 reporting that it was able to handle a call to GLX_EXT_swap_control_tear. And then crashing when that call was made.
The "fix" was to test for a Mesa driver and then prevent it from calling the adaptive sync.
I stand by the statement that this is a bug in other programs (in this case, the Mesa driver used by the VM softwares.
KiCad can work around this issue (and all of the other fallback issues as well). But then, that is where developer time goes instead of into developing new schematic and layout features that will be of use to our whole userbase.
This is why we will not be focussing on supporting VMs or fallback graphics in the future.
