kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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.

Seth

On Tue, Jan 11, 2022 at 12:22 PM Mark Robson <markxr@xxxxxxxxx> wrote:

> I use Kicad in a Linux VM, and it sort of works ok, it's really convenient.
>
> Obviously there are limits with software rendering, the 3d viewer is slow
> but otherwise it's ok.
>
> Mark
>
> On Tue, 11 Jan 2022 at 20:11, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>
>> > IMHO, we shouldn't remove anything that helps to deal gracefully with
>> the diversity of situations (like a virtual machine), graphics hardware and
>> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>>
>> The fallback engine we use today does not have feature-parity with the
>> accelerated engine, and that is not an easily-solvable problem.
>> Continuing to support it will continue to hold us back.
>>
>> Putting aside the issue of virtual machines (our stance is that we don't
>> need to spend effort on supporting VMs because KiCad itself should run fine
>> on the host OS), we need to push forward into more modern
>> hardware-accelerated graphics APIs in order to make it possible to
>> implement some desirable features, help performance on large designs, etc.
>>
>> The idea is that instead of being stuck on some "lowest common
>> denominator" OpenGL, we can instead for example use DirectX on Windows and
>> Metal on macOS.
>>
>> -Jon
>>
>> On Tue, Jan 11, 2022 at 3:02 PM Steven A. Falco <stevenfalco@xxxxxxxxx>
>> wrote:
>>
>>> On 1/11/22 02:33 PM, pmx wrote:
>>> >
>>> >
>>> > Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
>>> >>> I don't think the dialog would help any in the situation you are
>>> describing with the artifacts on the screen. It was only shown on first
>>> start, so it wouldn't give the choice in future runs (which would be after
>>> you notice all the artifacts). You can change the rendering backend in the
>>> preferences pane though, so you can switch back to the fallback graphics
>>> that way.
>>> >>
>>> >> I'm describing two situations.  One is the artifacts on my desktop,
>>> and one is the segfault on VMs.  As long as the window opens and is
>>> somewhat usable, then one can select fallback graphics easily from
>>> preferences, as you said.  The bigger problem is on the VMs where it
>>> crashes before the window gets a chance to even open.  I'll look at the
>>> issue you linked and see if that helps.  I'll also try a test build from
>>> the tip of the 6.0 branch and see how that behaves.
>>> >>
>>> >> I'm more concerned that fallback graphics might be removed entirely
>>> at some point.  Hopefully accelerated mode will be bullet-proof before that
>>> decision is made.
>>> >>
>>> >>     Steve
>>> >
>>> > Unless there is much work involved to keep both backends working in
>>> the future, I strongly feel that a fallback graphics engine is a must and
>>> should be kept alive, even if this requires some (moderate...) effort.
>>> >
>>> > IMHO, we shouldn't remove anything that helps to deal gracefully with
>>> the diversity of situations (like a virtual machine), graphics hardware and
>>> video drivers... and their possible bugs ! (as stated about X11/Mesa).
>>> >
>>> >
>>> > @ Steven :
>>> > About the possibility to choose a graphics backend, in any situation,
>>> and indeed before a segfault  happens 😁 :
>>> >
>>> > What about a command line option (when launching Kicad), to force a
>>> specific graphics backend, including a "safe" fallback ?
>>> > Should be quite straightforward.
>>>
>>> The segfault is fixed in the latest 6.0 code, so I guess there is no
>>> longer a need for either the dialog or a command.
>>>
>>> However, some of the visual artifacts are still happening even with the
>>> latest 6.0 code, therefore the fallback graphics mode is still essential.
>>>
>>> I've added another video showing what it looks like when I resize the
>>> pcbnew screen.  Please see comment
>>> https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and
>>> https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
>>> for details.
>>>
>>> I'm a little concerned that new users seeing these artifacts won't know
>>> what to do about them, and may give up.
>>>
>>>         Steve
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


-- 
[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.com    info@xxxxxxxxxxxxx