Bug 1583

The mouse button swap is REALLY frustrating. :-) I know this worked in the past, so tagging the report as a regression.

Another glitch: When I connect and the remote user's screen saver is active, the screen saver seems relentless in continuing to run. Mouse movements do not disable the remote screen saver. That is, the screen saver momentarily disappears and within a second thereafter starts running again.

I'm bumping this report to Major because of the "long" list. I'm almost tempted to bump to Critical but I don't know how many Trinity users use krdc. I haven't added the report to the R14.0.0 ehterpad road map, but I think after R14.0.0 is officially released I'll bump this to Critical to receive attention for R14.0.1. I use krdc often enough for these problems to be a nuisance but not enough to be a show stopper. :-)

Regarding the swapped mouse buttons, I connected an R14 system to a 3.5.13.0 system. The mouse button behaved correctly. So the problem was introduced in R14.

Can anyone check 3.5.13.2 for the existence of this bug?

I compiled TQt3 without -glibmainloop (defaulting to TQt3 internal main event loop). With respect to this report, I notice some significant differences:

1) The session opens immediately with no delays.

2) There were no kcrashes on the remote system when terminating the session.

3) The recompiled TQt3 did not resolve the screen saver problem that occurs when connecting to a system where the monitor is in DPMS power down mode. When only the screen saver is running and the monitor has not yet powered down to DPMS, then the screen saver behaves fine once the krdc session starts.

Recompiling did not resolved the swapped mouse buttons. :-)

There are really two programs in play here, krfb and krdc, and it is hard to know which one is causing which problem(s).  Can you do the following and post the results of each?

1.) Run your test battery with the server running 3.5.13.2 and the client running R14.
1.) Run your test battery with the server running R14 and the client running 3.5.13.2.

This will help me isolate if the connection delay is a krdc problem or a krfb problem, among other things.

Thanks!

I don't have 3.5.13.2 installed anywhere. I'm trying to resolve that. Currently I only have 3.5.13.0 and 3.5.10 for testing and both are on VMs.

I don't know that we need 3.5.13.2, other than to bisect when the bugs were introduced. That said, I am convinced the problems are caused by -glibmainloop.

Observation: Two of the problems described here are related to -glibmainloop. On two systems I installed a package set where I built TQt3 without -glibmainloop. On a third system I have a previous package set where TQt3 was built with -glibmainloop.

Connection speed:

* Between the two systems without -glibmainloop, the connection is immediate.

* When the local system is without -glibmainloop and the remote system is with -glibmainloop, the connection is slow as originally described.

* When the local system is with -glibmainloop and the remote system is without -glibmainloop, the connection is immediate.

The kcrashes:

* Disappear when both the local and remote system is running without -glibmainloop.

* When the the local system is without -glibmainloop and the remote is with -glibmainloop, the kcrashes still occur on the remote system.

* When the the local system is with -glibmainloop and the remote is without -glibmainloop, the kcrashes disappear on the remote system.

These observations indicate a problem with -glibmainloop. The observations imply the problem is with krfb rather than krdc.

Reminder: the kcrashes contain no backtraces.

I am backing away from my observation in comment 4 because the remote system is a VM and mice don't function exactly the same in a VM as in real hardware. I am going to work toward copying my 3.5.10 and 3.5.13.0 systems to real hardware, but that will take time.

I'm updating the bug report summary to krdc/krfb issues. :-)

(In reply to comment #8)
> I don't have 3.5.13.2 installed anywhere. I'm trying to resolve that. Currently
> I only have 3.5.13.0 and 3.5.10 for testing and both are on VMs.
> 
> I don't know that we need 3.5.13.2, other than to bisect when the bugs were
> introduced. That said, I am convinced the problems are caused by -glibmainloop.

You are correct; testing without -glibmainloop is sufficient as long as all the problems are resolved this way.

The mouse problem puzzles me as there were no changes to the mouse handling code in krfb, which is where the problem was localized through your testing.  In fact, there were almost no changes to krfb at all between 3.5.13.x and R14 HEAD.

Are we going to resolve issues when building with -glibmainloop? Or must we continue building without?

Is there an explanation why -glibmainloop is preferred? What usability differences do we notice?

The mouse problem confuses me too. I compared sources to previous versions and saw nothing obvious. I have the mouse configured for left-hand use on all affected systems. I would think mouse clicks would be seamless.

(In reply to comment #10)
> Are we going to resolve issues when building with -glibmainloop? Or must we
> continue building without?

Yes, we must resolve issues when building with -glibmainloop.  I had thought they were all fixed until this report showed otherwise.

> Is there an explanation why -glibmainloop is preferred? What usability
> differences do we notice?

-glibmainloop is needed to interact with any of the GTK/glib libraries.  Qt4 has had this feature for some time, and IIRC our GTK3 theme engine support depends on it as well.  There was some discussion on the mailing lists regarding this feature before it was committed (end of 2011 IIRC).

> The mouse problem confuses me too. I compared sources to previous versions and
> saw nothing obvious. I have the mouse configured for left-hand use on all
> affected systems. I would think mouse clicks would be seamless.

So would I!  All other system program versions (X11, etc.) were the same when you compared 3.5.13.0 to R14, correct?

I'll watch for event loop patches. Let me know how to help.

> All other system program versions (X11, etc.) were the same when
> you compared 3.5.13.0 to R14, correct?
Too long ago to remember. :-( On my main system I have been using git almost since we migrated from svn. I did not migrate my HTPC from 3.5.10 to git for a long time. During that period often I connected to the HTPC using krdc and there were no mouse issues. The connection would have been local machine: git, remote machine: 3.5.10. I have been using left-handed mice for more than 20 years and that would have been and has always been the same for all systems.

I will provide more information when I get some VMs copied to real hardware and hopefully get a 3.5.13.2 system installed.

This is interesting. The problem seems rooted in krfb not recognizing a local Left-Hand mouse (local with respect to where krfb is running).

Local krdc: Right-Hand mouse
Remote krfb: Right-Hand mouse
Mouse buttons work as expected for local krdc user.

Local krdc: Right-Hand mouse
Remote krfb: Left-Hand mouse
Buttons are reversed, must operate local krdc mouse as Left-Hand mouse.
Looks like a single negative.

Local krdc: Left-Hand mouse
Remote krfb: Right-Hand mouse
Mouse buttons work as expected for local krdc user.

Local krdc: Left-Hand mouse
Remote krfb: Left-Hand mouse
Buttons are reversed, must operate local krdc mouse as Right-Hand mouse.
Looks like a double negative.

Same results when using KDE4 against Trinity or against KDE4, both krdc/krfb.

I am certain I never saw this problem until originally reported. I am uncertain about the combination of the two desktops before I first noticed the problem. I believe the remote (krfb) machine was 3.5.10 (my HTPC, which I did not update for a long time), but I don't remember which desktop I was running on my local office (krdc) machine. Could have been 3.5.10, 3.5.12, or 3.5.13 or very early R14.

I tested three computers with krdc and krfb. The desktops are 3.5.10, 3.5.13.0, R14 with glib main loop and R14 with tqt3 main loop. I am unable to test 3.5.10 vs. 3.5.13.0 (same machine, multi-boot).

The results varied with no repeatable consistency.

With most combinations the authentication dialog took a long time to disappear. The exception was with 3.5.10, either on the krdc or krfb side.

Most combinations I saw a kcrash on the krfb remote desktop.

Another data point is that under 3.5.12 I see krfb crash unpredictably on session termination.

Created attachment 1663 [details]
krfb backtrace

In my tests, regardless of the desktop version, the kcrash does not contain a useful backtrace. That said, during my testing today I was using krdc on a 3.5.10 system and krfb on an R14 system running gmainloop. The 3.5.10 desktop locked up. I used Ctrl-Alt-Backspace to terminate the locked session. Oddly, at that moment the krfb kcrash had a backtrace. I don't know whether the backtrace is useful. This is the only backtrace I've seen with these intermittent and unpredicatble kcrashes.

Just a guess.

krdc/vnc/kvncview.cpp KVncView::mouseEvent sends buttonMask values.

KVncView::mouseEvent:

if ( (e->type() == TQEvent::MouseButtonPress)
  if ( e->button() & Qt::LeftButton )
    m_buttonMask |= 0x01;
  if ( e->button() & Qt::MidButton )
    m_buttonMask |= 0x02;
  if ( e->button() & Qt::RightButton )
    m_buttonMask |= 0x04;

if ( e->type() == TQEvent::MouseButtonRelease )
  if ( e->button() & Qt::LeftButton )
    m_buttonMask &= 0xfe;
  if ( e->button() & Qt::MidButton )
    m_buttonMask &= 0xfd;
  if ( e->button() & Qt::RightButton )
    m_buttonMask &= 0xfb;

krfb (libvncserver/main.cc defaultPtrAddEvent ?) does not adjust the buttonMask code for a Left-Hand mouse.

krfb/libvncserver should note when the value of kcminputrc/[Mouse]MouseButtonMapping == LeftHanded and swap the buttonMask values for LeftButton and RighButton.

Or something to that effect.

The crashes should be fixed in GIT hash 8dd4535.  I had missed one block of direct pthread calls when I tried to fix krfb in April of this year, and also failed to actually *terminate* the threads when their associated functions were complete.

Please let me know if this resolves any of the latency problem or not, or if the crash is still present on your system (it is gone here).

Thanks!

>The crashes should be fixed in GIT hash 8dd4535.
Does the patch presume TQt3 is built with glibmainloop or is that irrelevant?

April? Ah, the time line has continuity. In April we resolved bug 1403. In that report I traced the problem to Nov-Dec. Nov-Dec 2012 seems about that long since I remember krdc/krfb "just working." :-)

I still can't account with certainty why I had no mouse button problems back in those days.

First report. I rebuilt tdenetwork with the pathc. I'm still using TQt3 without glibmainloop. The authentication dialog disappears quickly and there is no krfb kcrash when closing the krdc session.

No change in the mouse buttons and I still need to test with rebuilding TQt3 with glibmainloop.

Machines updated with TQt3/glibmainloop. Overall everything responds much better.

With respect to the original problems filed, only the mouse button issue remains. For me I would like to see the problem resolved. I realize many if not most people do not experience the problem because only 7% of people are left-handed and with computers, the majority of them still use a right-hand mouse.

For anyone helping with the mouse button problem, please refer to comment 13 and comment 17.

Oops, not out of the woods yet.

I rebuilt tdenetwork after rebuilding tqt3 with glibmainloop. Most of the time the Authenticating dialog remains on screen for about 30-40 seconds. Most of the time, but not repeatable. Curiously, I can make the Authenticating dialog disappear immediately by bumping the mouse pointer while the pointer is hovering over the dialog. I tested this with three different systems.

Created attachment 1669 [details]
Use current X11 mouse button mappings to decide which mouse button to emulate

Can you see if the attached patch fixes the problem on your systems?  My test setup sends the correct button mask to the rfb server without needing any remapping, so I need additional testing to confirm that this patch actually works. ;-)

Comment on attachment 1663 [details]
krfb backtrace

Since krfb no longer crashes this backtrace should be obsolete.

I will test.

>Can you see if the attached patch fixes the problem on your systems?  My test
>setup sends the correct button mask to the rfb server without needing any
>remapping, so I need additional testing to confirm that this patch actually
>works.
That bothers me. Also because I can't find any online complaints about this problem. Also because I don't recall the problem until some time before filing the original report. Could there be something fundamentally wrong or improperly configured on my system? Should we be looking elsewhere?

Patch test: same results as reported in comment 13.

(In reply to comment #27)
> Patch test: same results as reported in comment 13.

OK, this doesn't make any sense.  At this point I am starting to suspect something is not working properly in your Xorg server on the remote system; does x11vnc suffer from the same problem?

I have never used x11vnc, but I will try another vnc method.

In the mean time, regarding the krdc screen not updating immediately, I noticed all afternoon with my testing that the krdc screen seems tied to mouse events. As long as I keep moving the mouse pointer the krdc screen updates immediately almost as fast as the krfb screen.

I just spent time fiddling with my xorg.conf file, which I need because I use the proprietary nvidia drivers. No difference in the results. I will explore more in that area.

Created attachment 1670 [details]
Same as before but with debugging

OK, try this patch.  It will log both the remote button number (i.e. the button number that krdc sends) and the local button number (i.e. the button number that is passed from krfb to the local X11 server).  It also logs the local X11 server button mapping on startup.

You should see the debugging output in ~/.xsession_errors , attach a copy of that output to this report please.

Thanks!

I'll test the updated patch.

I _am_ confused. I get the same exact results with two systems running KDE4 krdc/krfb.

(In reply to comment #32)
> I'll test the updated patch.
> 
> I _am_ confused. I get the same exact results with two systems running KDE4
> krdc/krfb.

In that case do we want to unflag this as a regression (as the regression part of this report appears to be fixed) and lower the priority?

Both mice are three button devices.

===================================
Local krdc: Right-Hand mouse
Remote krfb: Right-Hand mouse

Started krdc and connected to krfb.

At krfb:

[krfb] [DEBUG] Pointer mapping: 1 2 3 4 5

At krdc, pressed left button (click button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1

At krdc, pressed right-button (popup menu button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3

===================================
Local krdc: Right-Hand mouse
Remote krfb: Left-Hand mouse

Started krdc and connected to krfb.

At krfb:

[krfb] [DEBUG] Pointer mapping: 3 2 1 4 5

At krdc, pressed left button (click button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1

At krdc, pressed right button (popup menu button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3

===================================
Local krdc: Left-Hand mouse
Remote krfb: Right-Hand mouse

Started krdc and connected to krfb.

At krfb:

[krfb] [DEBUG] Pointer mapping: 1 2 3 4 5

At krdc, pressed right button (click button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 1

At krdc, pressed left button (popup menu button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 3

===================================
Local krdc: Left-Hand mouse
Remote krfb: Left-Hand mouse

Started krdc and connected to krfb.

At krfb:

[krfb] [DEBUG] Pointer mapping: 3 2 1 4 5

At krdc, pressed right button (click button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 3
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 1
[krfb] [DEBUG] PointerEvent::exec() using local button 3

At krdc, pressed left button (popup menu button).

At krfb:

[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 1
[krfb] [DEBUG] Entering PointerEvent::exec()
[krfb] [DEBUG] PointerEvent::exec() remote requested button 3
[krfb] [DEBUG] PointerEvent::exec() using local button 1

===================================

Seems the debugging messages confirm my post in comment 13. krfb incorrectly interprets the locally configured left-hand mouse and swaps the buttons.

I rebuilt tqt3/tdenetwork with the latest patches as of this morning. As reported in bug 1703, sessions are now very responsive.

The full screen toolbar now looks the same as the KDE 3 days. Interesting.

Regarding whether the mouse issue is a regression, yes, to me that is correct. The buttons worked at one time although I cannot say whether that was with 3.5.10 or earlier versions of TDE.

I won't holler if we remove this report from the R14.0.0 etherpad road map, but the mouse problem remains for me and is still a regression and I want to keep the report status as is.

(In reply to comment #35)
> I rebuilt tqt3/tdenetwork with the latest patches as of this morning. As
> reported in bug 1703, sessions are now very responsive.

Great!

> The full screen toolbar now looks the same as the KDE 3 days. Interesting.

I did that in a separate patch (e5524391) as I had enough of hovering over the tiny little buttons waiting for a tooltip to see what was what.

> Regarding whether the mouse issue is a regression, yes, to me that is correct.
> The buttons worked at one time although I cannot say whether that was with
> 3.5.10 or earlier versions of TDE.

Well, the buttons work correctly here (3.5.13.2 client, R14 server), and you can reproduce the mouse problem in KDE4 on your end, so I strongly suspect this is an X11 problem on your end.  What version of X11 are you using on your remote system(s)?

> I won't holler if we remove this report from the R14.0.0 etherpad road map, but
> the mouse problem remains for me and is still a regression and I want to keep
> the report status as is.

OK.  I changed the title to be more descriptive however.

Part of what is so puzzling about this is that according to the debug output the patch I provided correctly swapped the mouse buttons to match your remote system configuration.  Why this didn't change the behavior is currently beyond me!

>so I strongly suspect this is an X11 problem on your end.
I'm beating my head as to what to test. The two primary test beds are a system with proprietary nvidia and the other with Intel. Same results from either direction. I doubt the drivers are the problem. I tested on my old PI and PII systems. Same results. I tried fresh profiles. That I see the same results with KDE4 does seem like a clue of something more fundamental, but that could be red herring because KDE4 and Trinity share common roots (despite the differences between Qt3/4).

>What version of X11 are you using on your remote system(s)?
All main systems here are Slackware 14.0. Xorg 1.12.4. I created a 3.5.10 and a 3.5.13.0 system but see the same results either direction. Nobody is more confused than me!

My systems are 1.12.4 as well.  I don't get it.

I am going to perform some testing with older distros. I know the problem did not exist until some time before I filed this report. I don't know exactly when the breakage occurred. I'm hoping with the older distros the mouse buttons again function as expected. That should provide some kind of baseline or starting point.

This will require several days before I can provide further information.

This went faster than I expected. On two spare hard drives I installed Slackware 12.2 that came with KDE 3.5.10. I used that release because that is what I used when I first built my HTPC several years ago --- and krdc/krfb sessions worked then. That was before I got involved with Trinity.

I installed the hard drives into two systems. Removable hard drive bays are nice. :-)

Left-handed mice on both systems works as expected both ways on both systems. Did not matter which one was krdc or krfb. Very snappy.

Next I tested my current installs: Slackware 14.0 with R14. I used one R14 system as krdc and the krfb as one of the Slackware 12.2/KDE 3.5.10 systems. Left-handed mice worked as expected. I then rebooted both computers to swap desktops on each. Same satisfactory results.

Bottom line: krfb in KDE 3.5.10 on Slackware 12.2 does nothing strange to the mice buttons.

Next I tested using the 12.2/3.5.10 systems as krdc and the 14.0/R14 systems as krfb. Things went snaky that way. Sometimes the mouse buttons worked, other times they swapped. More strange, the R14 desktops got hosed. The next time I restarted the R14 desktops I had to reconfigure the mouse buttons and NumLock on. I don't know what happened there, but I saw that with both R14 systems. Somehow 3.5.10 krdc does not like R14 krfb whereas R14 krdc and 3.5.10 krfb get along fine.

I'm somewhat relieved I'm not going senile. At least I remember correctly that once upon a time the mouse buttons worked.. :-)

Next test, I'll install Slackware 13.1 with my own KDE 3.5.10 packages, which I used for a while. I also had built 3.5.13.0 packages for 13.1,but I never used 3.5.13.0, instead moving from 3.5.10 to R14. Yet I'll try the 3.5.13.0 packages too.

In the mean time I'd appreciate from anybody a pick list of ideas to consider what might be going on. Wild guesses included. :-)

(In reply to comment #40)
> Next I tested my current installs: Slackware 14.0 with R14. I used one R14
> system as krdc and the krfb as one of the Slackware 12.2/KDE 3.5.10 systems.
> Left-handed mice worked as expected. I then rebooted both computers to swap
> desktops on each. Same satisfactory results.
> 
> Bottom line: krfb in KDE 3.5.10 on Slackware 12.2 does nothing strange to the
> mice buttons.
> 
> Next I tested using the 12.2/3.5.10 systems as krdc and the 14.0/R14 systems as
> krfb.

Any way to try R14 on 12.2 to rule out something changing in the base system rather than TDE itself?

That would be a good test. 12.2 is a tad old. I don't know whether R14 will compile without fits. I need only the core packages and tdenetwork, but that might still be a challenge. Conversely, any build failures should be reported to the project because 12.2 has not reached end of life. I did build 3.5.12 on 12.2. I don't believe I ever built 3.5.13 on 12.2, only 13.1.

That is another idea. I could install the 3.5.12 packages on 12.2.

Preliminary tests with an image of a Slackware 13.1 install with my own 3.5.10 packages did not go well. Same results as what started this mess.

Next I'll try a stock 13.1 install because I customize my systems like crazy. There is the possibility my 13.1 image is too customized. A stock install would indicated soething awry with my customizations.

I can also test krdc/krfb from the stock KDE 4.1 from 13.1. Who knows.

First I'll try 3.5.12 as those packages are already premade for 12.2.

Interesting. After installing TDE 3.5.12 on Slackware 12.2, the left-hand mouse buttons functioned as expected. I tested both ways on both 3.5.12 systems and accessed the 3.5.12 systems (krfb) from R14 systems (krdc). No problems.

My suspicions at this point:

* OS, kernel, etc.
* X
* TQt3 (3.5.12 used the original Qt3 3.3.8b)
* My own customizations

None of this explains why I see the same problems with KDE 4.10.5 on Slackware 14.0.

I'm now attempting to build R14 on 12.2.

This has beat me.

I am unable to build R14 on 12.2. I don't think R14 is involved. Would have been nice to build on 12.2 to verify with certainty, especially since 3.5.10 and 3.5.12 behaved perfectly.

I installed Slackware 14 on two extra hard drives with no system customizations. KDE 4.8.5 has the same problem. I installed Slackware 13.1 on the hard drives with no system customizations. KDE 4.4.3 has the same problem. I installed tightvnc on my existing Slackware 14.0 systems and again saw the mouse buttons fail.

I don't believe hardware is the culprit because I've tested this across three very different systems and each has a different mouse, video, etc.

I'm clueless.

I just remembered the problem exists with my VirtualVox VMs too. I have to leave the VM mouse buttons configured as right-hand to function transparently with my host left-hand mouse.

The data you have presented strongly points to a problem in Slackware 13 or higher.  I don't think this is a regression in TDE at this time, though it sounds like it is a regression in some as-of-yet unidentified system component.  I'd like to remove the regression tag if possible from this report, downgrade the priority, set it to Slackware specific, and remove from the R14 Etherpad.

Bug report updated. I had already removed the report from the etherpad after our last conversation.

This problem is hugely frustrating because the mouse buttons work differently between the host and guest desktops.

I really want to get R14 installed on 12.2 but tdelibs won't compile. Keeps trying to build TDEHWLIB components (12.2 is HAL based). Slackware 12.2 is not EOL and Trinity should be required to build on that release just as older Debian versions are still supported. If I could install R14 on 12.2 I would have a bisect point that I could offer the distro maintainers.

That makes sense.  Is there a bug report for the Slackware 12.2 build failure?

bug 1741

Interesting test results:

Two Slackware 14.0 systems.

Test1:

I started Xfce on both systems. I configured left-hand mouse buttons in both. I used TightVNC to connect both systems. No mouse button problems.

Test2:

I started Xfce at the remote system running TightVNC. I connected to that system using TightVNC from within R14 konsole. No mouse button problems.

Test3:

I started Xfce at the remote system running TightVNC. I connected to that system using R14 krdc. No mouse button problems.

Those three tests tend to imply the button swap problem is not the underlying Slackware 14.0 OS (but says nothing about how Xfce or TightVNC are coded to handle left-hand mouse buttons).

===============================

At the remote system, when the default system desktop xinitrc is KDE4 or R14, the mouse buttons swap. Even when connecting from a local machine with TightVNC.

Because of the common roots of KDE4 and R14 (despite the differences in TQt3/Qt4), is there a common flaw in the basic krfb engine? A corner case that I see but not others?

I don't compile KDE4 or Xfce packages. I use the upstream Slackware repositories. I compile only R14. Perhaps there is a compilation corner case at my end with R14 (tqt3? tdelibs? tdenetwork?). Perhaps there is a configuration problem at my end that I am unaware, although I see the same problems with a fresh profile.

That nobody is reporting these problems in the Slackware community --- few Trinity users but heavy on KDE4 and Xfce usage, and that nobody is reporting these problems with R14, I wonder what might be the true root cause.

I suspect something awry with krfb but why only on my system?

BTW, TightVNC is not a palatable solution. TightVNC provides an ALTERNATE desktop to a krdc user but does not provide direct access to the remote user's CURRENT desktop. That is the reason TightVNC uses :1 rather than :0. TightVNC only provides remote access, not direct control of a user's desktop. :-)

I notice the following fix in the TightVNC 2.0.3 change log:

"In systems with swapped left and right mouse buttons, remote mouse events will be adjusted accordingly. As a result, the remote mouse should work just like the local one."

That fix is for version 2.0.3. I tested with 1.3.10. So despite me not seeing any button problems, apparently the TightVNC developers have noticed swapped button issues. That is, the problem might not be unique to krfb.

I tested with some live cds: slax and fedora. I used KDE4 as krdc and TDE as krfb. Same results: left-hand mouse buttons don't work.

I found this related KDE bug report:

https://bugs.kde.org/show_bug.cgi?id=211346

The bug report was written against KDE 4.2.4 --- a very early version of KDE4 in their porting of KDE3.

Why no problem with KDE 3.5.10 or TDE 3.5.12 on Slackware 12.2? My guess is something changed in X since the 12.2 days (xorg server 1.4.2). The TDE/KDE4 krdc or krfb algorithms have not been updated to accomodate those changes. As I see the same problems starting with Slackware 13.0, which contains xorg server 1.6.3, my guess is the change occured in X between those two versions.

I tested connecting to a remote TDE system using Remmina. I connected without problems but the reversed mouse buttons still existed at the remote TDE system. Seems then the problem is krfb rather than krdc.

Using Remmina to connect to a remote desktop not running TDE results in normal mouse button behavior. My local system was running TDE while the remote system was running LMDE and the Mate desktop providing desktop sharing through vino.

To summarize this long discussion:

In comment 34 I mentioned for the first time the problem is krfb and not krdc.

In comment 40 I tested KDE 3.5.10 on Slackware 12.2 on the krfb side. No mouse button swapping. Using 3.5.10 at the krdc side and TDE on the krfb resulted in button swapping.

Reminder: building R14 on Slackware 13.1 or previous is not possible, so no testing is possible.

In comment 43 I tested 3.5.12 on Slackware 12.2. No button swapping.

In comment 52 I tested slax and fedora at krdc and TDE at krfb. The buttons swapped.

In comment 54 I again affirmed the problem is krfb and not krdc.

I cannot replicate the problem with remmina or other desktop environments.

I am unable to test connecting TDE krdc to a non TDE remote desktop: refer to bug 2180. Connecting TDE with remmina to a remote non TDE results in no button swapping.

Conclusion: TDE krfb is at the root of the button swapping problem. Other elements might contribute or there might be more than one bug masking another, or something in R14 history unmasked an inherent bug from KDE3, but krfb is at the root of the problem. Resolving bug 2180 will help provide further details.

I tested this with R14 on Fedora 21. Same swapped buttons. The problem is not the OS. As I have tested enough to indicate the problem is with krfb and not krdc, I changed the bug report summary.

I reworked a large chunk of krfb to use the latest upstream libvncserver in multiple commits ending with GIT hash 710a9c7 (tdenetwork).  As a result, krfb should now look and act like a modern VNC server.

Can you test and see if this bug is still valid?

Thanks!

It looks like a candidate for inclusion in the bug 2246? Or it will be considered as a new feature and belongs to the bug 2247?

(In reply to Slávek Banko from comment #59)
> It looks like a candidate for inclusion in the bug 2246? Or it will be
> considered as a new feature and belongs to the bug 2247?

Let's see if the fix works before adding this report to a meta bug; I don't want to commit to fixing something that I can't reasonably repair in time. :-)

In any case Bug 2246 would be appropriate as this is merely a bug fix (albeit a large one) and not a new feature.

Tim

I rebuilt tdenetwork only. The swapped buttons still exist.

I see the following cmake warning in the build log:

CMake Warning at libtdevnc/CMakeLists.txt:70 (message):
  *** The libjpeg library you are building against is not libjpeg-turbo.
  Performance will be reduced.  You can obtain libjpeg-turbo from:
  https://sourceforge.net/projects/libjpeg-turbo/files/ ***

(In reply to Darrell from comment #61)
> I rebuilt tdenetwork only. The swapped buttons still exist.

Thank you for the report.  It looks like the fault might lie within the upstream libvncserver library; I'll need to see what I can do to get this reported.

> I see the following cmake warning in the build log:
> 
> CMake Warning at libtdevnc/CMakeLists.txt:70 (message):
>   *** The libjpeg library you are building against is not libjpeg-turbo.
>   Performance will be reduced.  You can obtain libjpeg-turbo from:
>   https://sourceforge.net/projects/libjpeg-turbo/files/ ***

Don't worry about it; the old krfb didn't support libjpeg-turbo but the new one does.  If you want faster compression performance (i.e. less load on the server running krfb) install libjpeg-turbo and recompile tdenetwork. :-)

>It looks like the fault might lie within the upstream libvncserver library;
>I'll need to see what I can do to get this reported.
Remmina does not have the swap problem. Either those developers work around an upstream bug or there is a fundamental flaw in the kde/tde lineage that causes the swap. I lean toward the latter because as mentioned in previous comments, I experience the same problem in kde4.

While I can test using remmina locally to connect to a remote tde/krdc system, I cannot locally test using tde/krfb to a remote non tde system because of bug 2180. If that bug was resolved then that would help narrow the focus for this bug report.

Although not hampering troubleshooting, bug 2023 is a nuisance because I have to always ssh into the remote system to stop the screen saver. Otherwise the vnc connection is continually interrupted by the screen saver.

Testing with the latest TDE GIT (using the new libvncclient) on local and remote Slackware 14.1 systems.

The buttons remain reversed.

Today I ran some simple tests.

The remote VNC server system (the system to be viewed) is Slackware 14.1 with a TDE git build set from June 13. The local client system is Fedora 21 with MATE 1.10 using Remmina as the viewing client. Just a reminder, I use left-handed mouse buttons in all of my systems and desktops. Hence, the origin of this bug report.

At the remote system I disabled the TDE Internet Daemon to the disable VNC server (is there another way to disable VNC?).

At the remote system I installed x11vnc and tigervnc.

At the remote system I started x11vnc. As viewed from the client, the remote mouse buttons are swapped. Likewise when using the tigervnc x0vncserver command.

At the remote system I exited TDE and started X with MATE 1.8. I started with x11vnc. No swapped mouse buttons. Same results with tigervnc x0vncserver command.

At the remote system I exited MATE and started Xfce. I started with x11vnc. No swapped mouse buttons. Same results with tigervnc x0vncserver command.

When using TDE krdc to connect to a remote system running MATE 1.10 using vino-server as the VNC server, I see normal mouse buttons.

Conclusion: I do not experience the swapped mouse buttons bug when the remote desktop is MATE or Xfce. I experience the bug only when using TDE on a remote system, even when using a vnc server other than krfb.

Because I was not using krfb as a VNC server, the problem seems unrelated to krdc or krfb but caused by something fundamental with how TDE (tqt3? tdelibs?) handles mouse events.

I found a work-around to this annoying issue. I long have used x11vnc and have since added the '-buttonmap 13-31' parameter.

Curiously, this bug affects KDE 5. I suspect libvncserver because both TDE and KDE depend on that library package. As mentioned in previous comments, there was a time when this problem did not exist. A common dividing point seems to be adopting libvncserver.