Hi Paul, On Di 28 Okt 2014 12:46:10 CET, paul.szabo wrote:
Dear Mike,If it is not possible to dynamically detect if 16 or 32 bit encoding is used on the server-side (the client-side should be the flexible part), then your patch has to wait for that rewrite to come (a design change then is absolutely ok and wanted). I don't think we should break compatibility within the 3.5.0.x release series. So again, do you see an option for detecting the server-side encoding (or querying it or triggering/enforcing it via a nxagent cmdline option)?That would be do-able, but probably not practical. The two nxproxy-ies could somehow try to detect whether the other is also capable of BIG-REQUESTS, and if so use 32-bit encodings and not use the HIDE_BIG_REQUESTS_EXTENSION setting; but if not then fall back to 16-bit and to hide. That would make the code even more messy (and likely, buggy) than it is now.PS: How do you test if the BIG-REQUESTS implementation works? With TexPower, you said. What do I have to do to trigger the BIG-REQUESTS bug if nx is not patched?It is texworks from http://tug.org/texworks http://code.google.com/p/texworks/wiki/Building All you need to trigger the bug is to run texworks. Having scrutinized things, it does QueryExtension on BIG-REQUESTS; if not getting it (because of nxproxy hide as now), then sends "broken" (ill-formatted) X11 stream that crashes the "nxproxy -C" side. With my patches, it uses BIG-REQUESTS just fine. --- One of my users told me that my patched nxproxy would crash when using kile (on his special TeX file), seems it is the "nxproxy -S" side that crashes. I am now working on reproducing this, and intend to fix. I have asked my users to test nxproxy, and will attempt to fix all issues as they become apparent. When nxproxy seems "stable", I intend to make it the default: start "nxproxy -S" with Xorg on the thin client, and start "nxproxy -C" and do the xauth and DISPLAY "switcheroo" within the GDM2 Xsession. I will report back here as I go. Cheers, Paul
While working on that (have I mentioned this before? Have written too many mails today already...):
A generic nxproxy has to be Big+Little Endian safe. The X2Go project is about to start a cooperation with IBM and we are about to get sponsored a PowerPC64 build machine (BE afair). So while juggling with bits and bytes, please consider Endianness during your awesome patch work!!!
(NX is a complete pile of patches, actually, but the nx-libs repo is far more advanced than anything else out there derived from the NX3.5 series).
Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpWdP5RVBAha.pgp
Description: Digitale PGP-Signatur
