On 1/11/22 04:02 PM, Seth Hillbrand wrote:
On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco <stevenfa...@gmail.com
<mailto:stevenfa...@gmail.com>> 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.
I stand corrected.
Steve
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
