Since my last post I’ve been continually trying different distros at home trying to resolve my synergy glitching problem. The symptom is simply that the mouse freezes on my T42 for a few seconds and then comes good. I use my old Thinkpad 600x as the synergy master, the T42 is to the right of it as a synergy client, then my core 2 desktop machine and then my mac mini. Only the T42 seems to glitch and its only started happening since I started trying different distros on the T42. I had been using an older build of Arch linux with no glitching on the T42. This was using a custom 2.6.17 kernel. Slackware 12.0 with stock kernel does the glitch from time to time, Debian Etch with stock 2.6.18 kernel also does it. And more recently as a test, I installed a 2nd copy of Archlinux using the latest 2007-08-2 build and used the 2.6.22-ARCH kernel that it comes with. That now glitches too.

I had started to think that the problem was some clash between newer versions of Xorg and synergy, but the fact that the new install of Arch had the glitching problem disproved that (it seems to have the same Xorg as my older build of Arch).

Some time today I must have changed something on this new Arch build and I rebooted and now synergy virtually didn’t work at all. I could see that it was connecting to the master and if I moved the mouse very slowly I could see the mouse move every few secs. Very painful and completely unusable. I tried to reverse the small number of changes I’d made during the day, but several reboots later and it still was pretty hopeless. Rebooting back into the old Arch had everything working fine.

Now, one of the things with the newer kernels is that kernel scheduling has changed a lot so I wondered whether syenrgy was getting pushed down the priority list and not getting enough CPU time (admitedly there are no CPU hungry tasks on the T42 as I’ve been testing this). Obviously synergy needs to be reasonably high priority in order to not drop key and mouse events. So I tried doing a renice of the synergyc process:

sudo renice -18 <pid>

Amazingly that restored sanity and my mouse zooms around like it should. Totally bizarre. I obviously have some more testing to do, but it looks like a working solution. I’ve found the most recent linux kernels generally annoying … and hence thats why I kept on using that old 2.6.17 kernel. It’s quite sad if  my priority change is the correct fix.

I’ve changed my .xinitrc so that it starts synergyc as follows:

nice -n -5 synergyc -n t42 10.11.12.13

So that raises the priority by 5 over normal.

…. a few days later …

Well, that renice’ing fix only seems to work for a specific combination of distro’s. I switched my T42 back to Slackware 12.0 and the glitch is back seemingly regardless of the kernel I use or the niceness of the synergyc process. So given that I’m a tad frustrated by all this, I’ve made the T42 the synergy master, and the Thinkpad 600x is now a client. Consequently, there is now no glitching on the T42. So far there doesn’t seem to be any glitching on anything else either.