NXv3 (redistributed) https://cgit.arctica-project.org/nx-libs/atom?h=upgrade-libX11 2016-08-24T21:09:23+00:00 2016-08-24T21:09:23+00:00 Ulrich Sibiller uli42@gmx.de 2016-08-01T23:06:35+00:00 urn:sha1:be7ca020f9eb5656713b4afe1f0ed0837449ef8d This basically repeats commit bad67799229b94ea2ba0174319949766ad1c2fc6 after the upgrade to libX11 1.3.4. 2016-07-28T11:21:29+00:00 Mike Gabriel mike.gabriel@das-netzwerkteam.de 2016-07-28T11:21:29+00:00 urn:sha1:46fef31507fd2a5ba80fd3824bb00514497fc30f 2016-07-28T11:20:38+00:00 Mike Gabriel mike.gabriel@das-netzwerkteam.de 2016-07-28T11:20:38+00:00 urn:sha1:e9a3734ae3ab5623c63c4fd0a97e1eeb23d98f41 2016-07-28T10:59:37+00:00 Mike Gabriel mike.gabriel@das-netzwerkteam.de 2016-07-28T10:59:37+00:00 urn:sha1:bff330577ffa041edf842e93008c67348680723a 2016-07-28T10:16:23+00:00 Mike Gabriel mike.gabriel@das-netzwerkteam.de 2016-07-28T10:16:23+00:00 urn:sha1:aadf3175ccecb5faf7673d725a0d109cc6adb9cf 2016-07-28T03:26:00+00:00 Mihai Moldovan ïonic@ionic.de 2016-07-03T23:52:43+00:00 urn:sha1:64a83d1e08fd8224a065d6e3548be6323127d4df Maybe needs special strictness handling as well. 2016-07-28T03:26:00+00:00 Mihai Moldovan ïonic@ionic.de 2016-07-03T23:52:06+00:00 urn:sha1:5ec7e48ac70fc88b1285e3615f7651dad1247c37 Maybe needs special strictness handling as well. 2016-07-28T03:26:00+00:00 Mihai Moldovan ïonic@ionic.de 2016-07-09T03:28:27+00:00 urn:sha1:e61c8c85cc11dad063da23fb2f1d031c574166f5 Don't implicitly call the checking function in the init function (and throw away the checking functions result...) Instead, explicitly use the checking function after the init function in other parts of the code and throw away the checking functions return value selectively or actually use it while reconnecting. This is totally different behavior compared to the original one. Hopefully it doesn't cause any problems (i.e., hopefully there was no good reason for never using the checking functions return value, but an oversight.) 2016-07-28T03:26:00+00:00 Mihai Moldovan ïonic@ionic.de 2016-06-29T02:13:03+00:00 urn:sha1:6618271493f86109103a2ade74912d34172ba569 Recognized values: - Strict means that the number of internal and external pixmap formats must match exactly and every internal pixmap format must be available in the external pixmap format array. - Safe means that the number of pixmap formats might diverge, but all internal pixmap formats must also be included in the external pixmap formats array. This is recommended, because it allows clients with more pixmap formats to still connect, but not lose functionality. - Risky means that the internal pixmap formats array is allowed to be smaller than the external pixmap formats array, but at least one pixmap format must be included in both. This is potentially unsafe. - Bypass or higher means that all of these checks are essentially deactivated. This is a very bad idea. Note that the default ReconnectTolerance value is still Strict. Also, the return value of this function is currently not used or passed through to other functions at all. An upcoming commit will change this behavior and actually enable the checks. 2016-07-28T03:26:00+00:00 Mihai Moldovan ïonic@ionic.de 2016-06-28T23:54:17+00:00 urn:sha1:bb9b50bfcf9c656367b7a9b6b5c73fea6c21a718 Recognized values: - Strict means that the number of old and new depths must match exactly and every old depth value must be available in the new depth array. - Safe means that the number of depths might diverge, but all former depth must also be included in the new depth array. This is recommended, because it allows clients with more depths to still connect, but not lose functionality. - Risky means that the new depths array is allowed to be smaller than the old depths array, but at least one depth value must be included in both. This is potentially unsafe. - Bypass or higher means that all of these checks are essentially deactivated. This is a very bad idea. Note that the default ReconnectTolerance value is still Strict.