Rendering issues on Linux

Software
1

I recently updated the X stuff on my Debian sid-based laptop, and this had the effect of breaking rendering in Eeschema and Pcbnew:

1280×771 61.2 KB

Also, the black/white background option in Eeschema no longer has any effect: the background is always black.

At least one other user is having this issue with a different distribution. Anyone else? Anyone know of workaround or fix?

Pcbnew is usable if I use OpenGL rendering, but Eeschema remains essentially unusable.

I’ll file a bug report pending comments here.

Application: kicad

Version: 4.0.2+dfsg1-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.3.1,wx containers,compatible with 2.8)
Platform: Linux 4.4.0-4.slh.2-aptosid-686 i686, 32 bit, Little endian, wxGTK
Boost version: 1.58.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=OFF

X -version for xorg:

X.Org X Server 1.18.1
Release Date: 2016-02-08
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
Current Operating System: Linux sam 4.4.0-4.slh.2-aptosid-686 #1 SMP PREEMPT aptosid 4.4-16 (2016-03-08) i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-4.slh.2-aptosid-686 root=UUID=22c2bdd1-f717-4891-8d70-16be995c54df ro quiet video.use_native_backlight=1
Build Date: 09 February 2016  10:50:54AM
xorg-server 2:1.18.1-1 (http://www.debian.org/support) 
Current version of pixman: 0.33.6
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
2

What version of GTK is used?

3

What version of GTK is used?

$ dpkg -l libgtk2.0-0 libgtk-3-0

says

ii  libgtk-3-0:i386    3.18.9-1       i386           GTK+ graphical user interface library
ii  libgtk2.0-0:i386   2.24.30-1.1    i386           GTK+ graphical user interface library
4

If you can ensure GTK2 is used by wxWidgets it might be ok; there are known problems with the legacy canvas using GTK3 and these problems are bad enough that eeschema is unusable.

5

On my system kicad shows a dependence on libwxgtk3.0-0v5, and libwxgtk3.0-0v5 (as well as libwxgtk2.8-0) shows a dependence on libgtk2.0-0 (>= 2.24.0). I don’t see any dependencies on libgtk3. So I am assuming GTK2 is being used. Do you know of a way to be more certain?

6

If this this the official package package in debian, then there are some issues with the build scripts. The packager shall make sure that kicad is build against a wx3 that is built with gtk2 and NOT gtk3.

EDIT: So in this case report the issue to debian.

1 Like
7

@nickoe, as I noted in my previous post, in Debian sid it looks like libwxgtk3.0-0v5 (i.e., wxWidgets 3.0) depends on libgtk2.0-0 (>= 2.24.0). There do not appear to be any GTK3 dependencies. Or did I misunderstand something?

8

Has there been any progress in addressing this issue? It’s still present in the current Debian “testing” distribution, which is pretty rapidly headed towards a freeze and then a release as the next major Debian… so, the problem may soon start affecting even more people than it does today. Ive been unable to use KiCAD on my laptop for the best part of a year… it’s a big loss.

I’m unclear from the description as to whether the problem lies in GTK3, or in WxWidgets (when built against GTK3), or in the way that the KiCAD canvas uses WxWidgets, or whether it’s basically a “these three don’t play well together” compatibility situation.

In any case: WxWidgets is a standard library element built on Debian. Whether it’s being built against GTK2 or GTK3 I do not know - but I don’t believe that’s something that’s under the control of the scripts which build KiCAD for Debian. On a Debian box (and on Debian-based distros) WxWidgets will be whatever it is… and I suspect that building against GTK3 may be the standard.

So - can somebody clarify the actual cause of the problem? Is WxWidgets itself buggy when built against GTK3? or is KiCad perhaps assuming certain things about WxWidgets behavior that aren’t “guaranteed by design”, happen to work OK in a GTK2 build, and don’t work in a GTK3 build? Where does the problem actually lie?

I’m not sure it’d be possible for the Debian KiCAD build to pull in a whole, specially-built version of WxWidgets that uses only GTK2. That sort of “foreign library import” is a terror to try to maintain :frowning:

9

No progress. It is hard to tell what might be the root cause. Maybe using wx with gtk3 was just another way the issue manifests itself, but not exclusively – apparently.

10

Thanks for the quick response, Nick.

I do have some additional data to offer, and a workaround to report.

On the affected system, if I fire up kicad from a shell, I get a warning which suggests an ABI mismatch. It looks as if the application was built against a more recent version of the library interface than the actual library it’s using. That might or might not be significant.

21:03:56: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8).

I’ve observed that there are at least two symptoms of the problem. As others have noted, a lot of the image breaks up badly once it’s zoomed up, leaving it unreadable. And, in the schematic-capture, the screen display is always “black background, with white grid dots” even if a white background is selected in the preferences.

And, for the workaround: if I fire up the Xephyr X server ("additional X server session, running in a client window of your main session), and start up kicad with the DISPLAY environment variable pointing to this new screen-in-a-window, then everything looks good. Neither of the two symptoms I mentioned above occurred - the schematic display is fully readable at all zoom levels, and is displayed on the correct white background. The PCB-layout display is also fully readable and reasonable.

There are a boatload of differences between the properties of the two X servers. Xephyr behaves as a 4-bit-per-color display and does not advertise the DRI2, DRI3, XFree86-DGA, or Xfree86-VidModeExtension extensions.

So, my guess is that somehow, kicad/WxWidgets/GTK3 are running into problems when using direct rendering (perhaps only on some video chipsets?), and that these problems are bypassed when the X display connection from app to server is forced to use protocol-based rendering.

It’s not a great workaround, but it’s probably better than nothing. I can probably run a nearly-full-screen Xephyr window in a second virtual screen and run kicad in this.

11

If you can reproduce the issue. You should be able to get rid of the ABI mismatch by rebuilding wxgtk. Could you try that?

12

I pulled down “apt-get source libwxgtk3.0-0v5” and its build dependencies, did the Debian build, and installed the three relevant .deb files over top of the Debian “testing” versions.

When I launched kicad, the ABI-mismatch message no longer appeared. However, the rendering problems remain - I didn’t notice any change in behavior.

So, the ABI version mismatch doesn’t seem to have been at the root of the problem… it’s apparently elsewhere.

The .deb package version numbers seem to have been the same for the versions I built (ABI 1010) and the ones in the Debian binary-package repository. This suggests a bit of a glitch in the Debian build/release process, I suspect - the .deb version number should probably have been bumped. Confusing but I don’t think it’s at the root of this particular problem.

13

It’s sounding more like it could be an issue with particular Intel graphics chipsets. Is there some way you could check if the GPU drivers have been updated in the upgrade? It is possible that there’s a regression (or a new bug) in the driver.

14

I had the same problem and could find a solution that worked, at least for me. Possibly the problem relates to the controller of Intel graphics cards. What I did was to create a Xorg configuration file /usr/share/X11/xorg.conf.d/20-intel.conf, with the follow information:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
EndSection

And that’s it, now it’s working ok!
I hope this could help you

16

@mithat and @pdgarrone Can you tell us what exact graphics card you are using?

17

I’m using a laptop with a Intel Pentium P6000 processor and integrated graphic card Intel HD Graphics

18

I have added this info on https://kicad.org/help/known-system-related-issues/#_intel_graphics

19

Something seems to have changed in the Debian “testing” distribution during the past couple of months. I’m not sure whether it’s a change in GTK3 (I just got a new version in today’s update), or a kernel change to the GPU driver, or a change in X, or in Kicad itself, or ???, but the problem appears to be gone. Zooming of both schematics and PCB images works properly, with all text being cleanly and properly rendered, and all lines and arcs appearing correct.

There was much rejoicing in Mudville :slight_smile:

20

This issue is still happening (ubuntu 18.04) and on non intel graphics for me.

21

Please see https://bugs.launchpad.net/ubuntu/+source/kicad/+bug/1767652

tldr; Ubuntu 18.04 did not test KiCad well and compiled it against an incompatible library. You’ll need to use the ppa

Version 5:
http://ppa.launchpad.net/js-reynaud/kicad-5/

Version 4:
http://ppa.launchpad.net/js-reynaud/kicad-4/

2 Likes