On 10/31/2018 3:35 PM, Tobias Klausmann wrote:
Hi,
comments and suggestions inline
On 31.10.18 23:00, L A Walsh wrote:
sudo wireshark QStandardPaths: wrong ownership on runtime directory /var/run/user/5013, 5013 instead of 0 QStandardPaths: wrong ownership on runtime directory /var/run/user/5013, 5013 instead of 0 nl80211 not found. libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast
...hmmmm.... 💡 (Ah!)
(rpm -qf wireshark + -qi :) Name : wireshark-ui-qt Version : 2.6.2 Release : 2.1 Distribution: openSUSE Tumbleweed
sudo setcap cap_net_raw+ep /usr/bin/wireshark wireshark& [1] 31423 Ishtar:law/bin> nl80211 not found. libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast
So why isn't wireshark installed with cap_net_raw? At least it gets rid of 1 error message. This one:
libGL error: No matching fbConfigs or visuals found
Your XServer drivers and or Opengl/mesa seems to be broken (or not installed?!)
I looked for swrast & found: /usr/lib64/dri/kms_swrast_dri.so /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/updates/swrast_dri.so The first two come from the Mesa rpm. I didn't have the latest, but did have them installed. Now I think I have close to the latest (in TW): Mesa-18.1.6-205.1 Mesa-dri-18.1.6-205.1 Mesa-gallium-18.1.6-205.1 Mesa-libEGL1-18.1.6-205.1 Mesa-libGL1-18.1.6-205.1 Mesa-libGLESv1_CM1-18.1.6-205.1 Mesa-libGLESv2-2-18.1.6-205.1 Mesa-libglapi0-18.1.6-205.1 Mesa-devel-18.1.6-205.1 Mesa-dri-devel-18.1.6-205.1 Mesa-libEGL-devel-18.1.6-205.1 Mesa-libGL-devel-18.1.6-205.1 Mesa-libGLESv1_CM-devel-18.1.6-20 Mesa-libGLESv2-devel-18.1.6-205.1 Mesa-libglapi-devel-18.1.6-205.1 libLLVM6-6.0.1-1.1 libOSMesa8-18.1.6-205.1 libdrm2-2.4.93-1.1 libdrm_amdgpu1-2.4.93-1.1 libdrm_intel1-2.4.93-1.1 libdrm_nouveau2-2.4.93-1.1 libdrm_radeon1-2.4.93-1.1 libglvnd-1.0.0-1.2 libOSMesa-devel-18.1.6-205.1 libdrm-devel-2.4.93-1.1 libglvnd-devel-1.0.0-1.2 ---
seems pervasive -- even doing a "make xconfig" for kernel configuration. I keep wondering what the GL-enhanced kernel-config does? Anyone know or why libGL would be needed for an X-GUI ("make xconfig") of the kernel?
I can't find a thread to this eMail at the ML archive, so it seems to be the first one.
--- Search on swrast. For that matter, you can search on "libGL error: failed to load driver: swrast" in google and see tons of references. Reproducible in FreeBSD, Apple, Ubuntu. Someone posted about the problem related to Redhat, and got a answer telling him "you have a broken openGL install or broken driver." (seems to be a common reply on this problem, but so far, hasn't been the case). That user was lucky for their app as they could use and alternate output format that gave them their graph, however for openGL: "Apparently there are issues with the OpenGL/Mesa implementation." --- *sigh* - not too informative but a widely seen problem.
: Where is the connection you make between running wireshark (with the Qt frontend) to do with a kernel config?
I think you just made it (next paragraph). :-)
Anyway, wireshark-qt uses Opengl rendering if available (as i suspect xconfig is as well, it brings up make qconfig for me, so that one uses Qt as well).
If you want to get rid of it, install the corresponding OpenGL driver for your hardware, or swrast if you run in a VM.
AFAIK, they are installed on both server and client. On server (cygwin) they are in package dri-drivers:
locate swrast /lib/dri/swrast_dri.so /usr/src/debug/xorg-server-1.20.1-1/glx/glxdriswrast.c cygcheck -f /lib/dri/swrast_dri.so dri-drivers-18.0.5-1
I'm not sure why it searches on swrast at all, since openGL seems to be somewhat supported glewinfo shows 3188 extensions. 2723 extensions are supported while 744 extensions are not glxinfo shows support up to openGL version 1.4 (4.6.0 NVIDIA 416.34) (and alot of lines for routines supported). GLXspheres displays in 2560x1600 @ 73.2 frames/sec = 295.2 Mpixels/sec. Says that it was using indirect context. GLXgears never seems to synchronize and only shows the initial plot with a claim of 5015.046 FPS (think it is talking to itself). For whatever reason the swrast issue is common and not very helpful, however for programs that ignore the error and use feature-probing, it seems moderate functionality can be gained, but most see the the error and just stop trying w/GL. TBH, I was more amused about getting the swrast error when running an x-based (using qt) 'xconfig' as I was wondering how openGL would be used in a kernel-config tool. But then you had to go and be serious...so thought I'd take the time to recheck my crossing of 't''s and dotting of 'i''s and see if in doing so I could fix some other problem or someone else would see something. Thanks! -linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org