Subject: Re: [nmr_sparky] Cannot see the spectrum in Sparky
From: Tom Goddard
Date: Sep 4, 2015

Previous: 1028 Next: 1030


The blank spectrum display seems very likely to be a problem with the X11 server. I am a bit surprised that Mandars attempt to roll back the X11 updates did not work. I think that was the right thing to try. I dont think the problem will be related to graphics drivers because Sparky does not use OpenGL rendering -- all contour drawing and peak markers and text is done using Tk and Xlib. Sparky includes Tk so that is not likely the problem. Im surprised by the report that the slice panels (vS) at the edge of the spectrum work because those are using the same line drawing at the spectrum contour plot. One possible culprit is that Sparky asks for BackingStore on the spectrum window. This is an X11 capability where whatever is drawn is remembered so the application doesnt have to redraw it if it gets covered by another window and then uncovered. I dont recall why Sparky asks for this -- I think it was just for better performance so it doesnt have to redraw contours. I think Woonghee called this feature double buffering (that is usually a graphics driver term, while backing store is the X11 term). The fact that X11 remote display to another computer (where Sparky displays correctly) works, seems to clearly indicate the problem is with an X11 server update. So it is puzzling why Mandars rollback of X11 updates did not fix the problem. I see in Mandars List1.txt that he did not roll back some packages libX* that might be related but it doesnt seem likely judging by their names. Looking at the 64-bit Linux Sparky shared libraries in sparky/lib I think libtk8.4.so is where all the graphics is done and it depends directly only on system libraries libX11.so, libdl.so (dynamic loader), libm.so (math), libc.so (C library). The libX11.so lets Sparky connect the the X11 server so of course any change in the server could be responsible for the problem.

Sorry I have no good suggestion. All signs point to an X11 server problem. I dont have an effected Linux system to test on.

Tom


On Sep 4, 2015, at 12:32 PM, Woonghee Lee [nmr_sparky] nmr_sparky@yahoogroups.com wrote:

Hi Mandar,

ssh should be run from other computer not the same one you have problem.
VNC is okay even if you run it on localhost because the drawing scheme
is different from regular X11, but ssh localhost still uses same display
schemes so the problem persists.

Woonghee

On Fri, 2015-09-04 at 13:51 -0500, Mandar Naik
[nmr_sparky] wrote:

[Attachment(s) from Mandar Naik included below]
Hi,

Attached is a long list (List1.txt) of packages that yum updates and
leads to problem with Sparky. In my first attempt I withheld every
package with X11 in its name (List2.txt). I still had problem in
Sparky so List2 is not the culprit.


I then downgraded Mesa to version 9.2 and installed Nvidia propriety
driver but that did not help either. The last stupid attempt based on
your earlier post of it working on remote display, ssh -X localhost
also doesnt help. Will keep trying. Please let me know if you suspect
any package that cause this issue and I can try to downgrade it.
Thanks

-mandar



On Thu, Sep 3, 2015 at 6:02 AM, Mandar T. Naik
wrote:
Yes, Problem in Kde4.x and TDE (Fork of KDE 3).
Thanks
-mandar


On 9/3/2015 1:23 AM, Woonghee Lee
[nmr_sparky] wrote:


I found that this happens when Sparky is executed in the
physically running X11 display.
So, if I run VNC server on the CentOS 6.7, and also run
Sparky in the VNC viewer executed in the same machine, it
works fine. Also, remote run from other computer is fine.
Those are two quick solutions for now.

I would like to know if KDE or XFCE is also problematic.


Woonghee




On Wed, Sep 2, 2015 at 4:56 PM, e.ab
[nmr_sparky] nmr_sparky@yahoogroups.com wrote:



Thanks,
Turns out I did update some yum packages, just didnt remember.
So that will be the reason.
Any advice for downgrading ?

thanks, Eiso

---In nmr_sparky@yahoogroups.com ,
woonghee791113 wrote :


If you stick with 6.5, you will have problems when
installing 32bit
libraries because they only keep the latest version,
so yum forces you
to upgrade existing 64bit libraries to the newest as
well to match with
32bit libraries. So, it is kind of frustrating. I
just found that new
X11 does not correctly support double buffering with
Tk. Hopefully, I
can resolve this problem soon. People may run
Virtual Machines in the
servers for while until the fix is released.

Woonghee

On Wed, 2015-09-02 at 14:39 -0500, Mandar T. Naik

[nmr_sparky] wrote:

Hi,
Happened to me on Monday after yum
update. Seems CentOS 6.7 is out
and as many as 400+ packages were updated.
I am sorry but I did not
make note of yum history. I suspect the
X server gets updated and
cause this problem. I fooled around trying
to roll-over but that did
not work.
Then I decided to upgrade to CentOS 7.
Please do not try the in-place
upgrade! It broke my system. I finally
made a DVD install. Sparky runs
in CentOS 7 but many old software wont.
No 32-bit support in CentOS
7. May be there is a work around but I
decided to downgrade to
original CentOS 6.5. It seems things are
back to normal although the
newly installed NMRFAM Sparky comes with a
blue background. Never ran
it before and have only seen brown or gray
colors for old sparky.
People on CentOS and related Linux may
want to hold on with update
till this issue is nailed.
Best regards
-mandar

On 9/2/2015 2:36 PM, Woonghee Lee

[nmr_sparky] wrote:


Hi,

You may be using Scientific Linux 6 that
is built on RHEL 6.
I am trying to figure out what is going
on, but it is more likely
faulty
X11 libraries shipped out with RHEL, and
in that case, it will not
be a
easy fix. I will report if I can find a
way to fix this problem.

Woonghee

On Wed, 2015-09-02 at 11:47 -0700,
e.ab
[nmr_sparky]
wrote:

Hi,

I seem to have the same problem with
sparky.
On my machine sparky stopped
displaying the spectra, just like in
the
attachment earlier
in this thread.The contour panel on
the right still works as well
as
the trace (vS)
l
It was working fine before the weekend
and Im not aware of having
changed
anything to the system or in
userspace. Im not doing automatic
updates.

Its an old version of sparky 3.110
that has worked fine for a
long
time. .
If I try the new NMRFAM sparky the
result is the same.

Im on scientific linux.
uname -a
Linux pppp2 2.6.32-504.1.3.el6.x86_64
#1 SMP Tue Nov 11 14:19:04
CST
2014 x86_64 x86_64 x86_64 GNU/Linux


Does any one have a clue what could be
wrong?

many thanks,
Eiso