Bug 166973

Created attachment 78623 [details]
Debug  data for bug 166973

We'll handle it there.

*** This bug has been marked as a duplicate of 148155 ***

different issue than bug #148155

Marcus, do we have a chance to handle cases like this with that simple "xmodmap" call from comment #8 ? Is there any generic command that can be called to cover them all? Or should that rather be handled inside "xmodmap"?

I thought this has been fixed in xmodmap ?
Matthias ?

Appearantly Yast does not invoke xmodmap (or not correctly).

If I do a 'xmodmap -e "pointer = 3 2 1"' on a console during installation, it works as expected and swaps left and right mouse pointer.

Also if I click multiple times with the right button, and let yast switch left and right buttons (click on 'yes'), the next time it should ask whether it should switch back (because it already has switched to 3 2 1), but it asks the same question again.

That's exactly what happens:

void YQUI::maybeLeftHandedUser()
{
    if ( _askedForLeftHandedMouse )
	return;


    QString message =
	_( "You clicked the right mouse button "
	   "where a left-click was expected."
	   "\n"
	   "Switch left and right mouse buttons?"
	   );
    int button = QMessageBox::question( 0,
					// Popup dialog caption
					_( "Unexpected Click" ),
					message,
					QMessageBox::Yes | QMessageBox::Default,
					QMessageBox::No,
					QMessageBox::Cancel | QMessageBox::Escape );

    if ( button == 0 )	// Yes
    {

	const char * command = 
	    _leftHandedMouse ?
	    "xmodmap -e \"pointer = 1 2 3\"":	// switch back to right-handed mouse
	    "xmodmap -e \"pointer = 3 2 1\"";	// switch to left-handed mouse

	_leftHandedMouse	 = ! _leftHandedMouse; 	// might be set repeatedly!
	_askedForLeftHandedMouse = false;	// give the user a chance to switch back
	y2milestone( "Switching mouse buttons: %s", command );
	
	system( command );
    }
    else if ( button == 1 )	// No
    {
	_askedForLeftHandedMouse = true;
    }
}

Sorry to jump in, don't think it is needed, but anyway:

> That's exactly what happens:

It is indeed written in the code.  The same code excerpt was put in bug
report 148155 as well (and I saw the code excerpt before I opened this bug report).  Anyway, the code looks right,  but unfortenately the functionality
does not looks like to work.  It's a real pity, as it is a great feature
to nice and implemented in nice way!

Do you mean with "That's exactly what happens":
1) the user mouse buttons are swapped during installation
2) the code tells us it works like that

I can you tell you that 1) in my situation/setup is unfortenately not true :(

How to continue, is it possible to debug?

Hm - when I do that on my machine, I get those log lines in y2log:

2006-04-28 14:28:13 <1> snell(8519) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
2006-04-28 14:28:24 <1> snell(8519) [qt-ui] YQUI_x11.cc(maybeLeftHandedUser):571 Switching mouse buttons: xmodmap -e "pointer = 3 2 1"
2006-04-28 14:28:48 <1> snell(8519) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
2006-04-28 14:28:51 <1> snell(8519) [qt-ui] YQUI_x11.cc(maybeLeftHandedUser):571 Switching mouse buttons: xmodmap -e "pointer = 1 2 3"


In your logs I always only see

2006-04-16 21:20:21 <1> 192.168.4.97(3638) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected

but _never_ a log line with "Switching mouse buttons" or "xmodmap".

The only explanation I have for that is that you didn't click on the "Yes" button. As you can see from the code snippet in comment #7, if you click "Yes" (button #0) you will always get that "Switching mouse buttons" log line. The log level of both messages is the same (milestone, level 1), so it cannot be a side effect of different log levels.

Please try it in "HelloWorld.ycp" (will attach). 
Start it (as a normal user) with 

    y2base HellWorld.ycp qt

Please watch the y2log (tail -f ~/.y2log).

If your mouse buttons get switched, you might want to switch them back immediately.

The sequence is:

- Click with the right mouse button on the "OK" button

- Watch the popup asking you to open

- Click "Yes" in that popup 
  !!! you still need to do that with the OLD primary mouse button, the mouse 
     buttons are still unchanged at this point!!!

- Watch the messages in ~/.y2log - you should now see 
  "YQUI_x11.cc(maybeLeftHandedUser):571 Switching mouse buttons: xmodmap..."

The change takes effect immediately when you see that message. It affects your complete X desktop. You can check with your desktop's menus.

- Don't forget to switch back before you hit the "OK" button:

- Click the "OK" button with the OLD primary mouse button. 
  This will now be recognized as the right mouse button.

- Click "Yes" again in the popup. Remember to use the NEW primary mouse button for that click.

Alternatively, you can type in any xterm / konsole window:

   xmodmap -e "pointer = 1 2 3"

or
   xmodmap -e "pointer = 3 2 1"


What happens when you try all this?

Created attachment 80802 [details]
HelloWorld.ycp

Start with

/usr/lib/YaST2/bin/y2base HelloWorld.ycp qt

This is what happens:
- launch: /usr/lib/YaST2/bin/y2base HelloWorld.ycp qt
- there is a widget telling me "Hello, World" [OK}
- I click [OK}
- It now stops....
- mouse buttons still the same :(

I tried the procedure with all 3 connected mice, there is no difference...

Below an strace after I clicked [OK}:
read(10, "\0", 1)                       = 1
write(13, "*", 1)                       = 1
read(10, "\0", 1)                       = 1
ioctl(8, FIONREAD, [0])                 = 0
write(9, "\0", 1)                       = 1
futex(0x80f2b54, FUTEX_WAKE, 1)         = 1
futex(0x80f2b74, FUTEX_WAKE, 1)         = 1
ioctl(8, FIONREAD, [0])                 = 0
write(9, "\0", 1)                       = 1
futex(0x80f2b54, FUTEX_WAKE, 1)         = 1
futex(0x80f2b74, FUTEX_WAKE, 1)         = 1
write(13, "*", 1)                       = 1
futex(0xb5335be8, FUTEX_WAIT, 22409, NULL) = 0
close(12)                               = 0
close(13)                               = 0
close(10)                               = 0
close(11)                               = 0
uname({sys="Linux", node="medion101", ...}) = 0
stat64("/home/richard/.y2log", {st_mode=S_IFREG|0644, st_size=72128, ...}) = 0
open("/home/richard/.y2log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 10
fstat64(10, {st_mode=S_IFREG|0644, st_size=72128, ...}) = 0
mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb4acc000
fstat64(10, {st_mode=S_IFREG|0644, st_size=72128, ...}) = 0
_llseek(10, 72128, [72128], SEEK_SET)   = 0
time(NULL)                              = 1146405664
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
write(10, "2006-04-30 16:01:04 <1> medion10"..., 104) = 104
close(10)                               = 0
munmap(0xb4acc000, 32768)               = 0
uname({sys="Linux", node="medion101", ...}) = 0
stat64("/home/richard/.y2log", {st_mode=S_IFREG|0644, st_size=72232, ...}) = 0
open("/home/richard/.y2log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 10
fstat64(10, {st_mode=S_IFREG|0644, st_size=72232, ...}) = 0
mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb4acc000
fstat64(10, {st_mode=S_IFREG|0644, st_size=72232, ...}) = 0
_llseek(10, 72232, [72232], SEEK_SET)   = 0
time(NULL)                              = 1146405665
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
write(10, "2006-04-30 16:01:05 <1> medion10"..., 112) = 112
close(10)                               = 0
munmap(0xb4acc000, 32768)               = 0
exit_group(0)                           = ?
Process 22408 detached

Uh - of course it stops if you click that "OK" button. It's only a "Hello, world" program. It's simply _over_ after you click the "OK" button with the left mouse button. ;-)

But what happens when you use the other mouse button? After you get the "do you want to switch the mouse buttons" popup?

Ah, you're right.  Okay now I did:

1) /usr/lib/YaST2/bin/y2base HelloWorld.ycp qt
2) click RMB in "OK" window
3) The "yes", "no", "cancel button pops up
4) I press LMB on "yes"
5) go back to step 2)....

In case I press RMB in step 4, the "OK" window stops....

Log file below:
===============  start HelloWorld ============
2006-05-09 23:13:51 <1> medion101(19204) [liby2] genericfrontend.cc(main):200 Launched YaST2 component 'y2base' 'HelloWorld.ycp' 'qt'
2006-05-09 23:13:51 <1> medion101(19204) [wfm] Y2CCWFM.cc(createInLevel):153 Parsing finished
2006-05-09 23:13:51 <1> medion101(19204) [wfm] Y2WFMComponent.cc(SetLanguage):501 GET encoding for nl_NL.UTF-8:  UTF-8
2006-05-09 23:13:51 <1> medion101(19204) [liby2] genericfrontend.cc(main):484 YAST_IS_RUNNING is yes
2006-05-09 23:13:52 <2> medion101(19204) [qt-ui] YQUI_x11.cc(loadPredefinedQtTranslations):421 Can't load translations for predefined Qt dialogs from /usr/lib/qt3/translations/qt_nl.qm
2006-05-09 23:13:52 <1> medion101(19204) [qt-ui] YQUI_core.cc(processCommandLineArgs):240 Qt argument: qt
2006-05-09 23:13:52 <1> medion101(19204) [qt-ui] YQUI_core.cc(calcDefaultSize):350 Default size: 895x675
2006-05-09 23:13:52 <1> medion101(19204) [qt-ui] YQUI_core.cc(YQUI):210 Forcing /usr/lib/qt3/lib/libqt-mt.so.3 open successful
2006-05-09 23:13:53 <1> medion101(19204) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
=============== 
2006-05-09 23:14:12 <1> medion101(19204) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
2006-05-09 23:14:20 <1> medion101(19204) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
2006-05-09 23:14:25 <1> medion101(19204) [qt-ui] YQGenericButton.cc(eventFilter):184 Right click on button detected
2006-05-09 23:14:32 <1> medion101(19204) [wfm] WFMSubAgent.cc(~WFMSubAgent):41 Deleting SubAgent: 0 scr
2006-05-09 23:14:32 <1> medion101(19204) [liby2] genericfrontend.cc(main):499 Finished YaST2 component 'y2base'


I tried with my 3 different (usb) mouse, but all have the same effect...

I still don't understand what goes wrong on your machine. It works perfectly in all environments I could test so far.

The first log line is there - as expected:

    "Right click on button detected"

But the one that should appear when the command is executed is missing:

    "Switching mouse buttons: xmodmap ..."

You can see the code that is executed in comment #7 : If the "yes" button in that popup is activated (button #0 - see also http://doc.trolltech.com/3.3/qmessagebox.html#question), there will be a log message - unconditionally. The code is straightforward.

This message is missing in your logs - in the first logs as from comment #1 as well as in the log from comment #13. To me this can only mean that the "Yes" button click never arrived.

This can be a user problem in that popup dialog (likely) or a very strange, very subtle bug deep in the Qt libs in your system (very unlikely).

Stefan,

tried it again to prevent a user problem...:

I do:
- kcontrol set mouse to right handed
- /usr/lib/YaST2/bin/y2base HelloWorld.ycp qt
- popup with "hello World [OK]"
- press RMB
- Window with "You clicked the right mouse button" [Yes] [No] {cancel]
- press LMB on [Yes]: back to Hello, World

- Start over
- press MMB on [Yes]: nothing

- Start over
- press RMB on [Yes]: nothing

This to prevent an user error.  Do you see a user error?
There is just no xmodmap call :(

Is it possible to provide code like "print button > logfile"
After this line:
        );
    int button = QMessageBox::question( 0,
                                        // Popup dialog caption
                                        _( "Unexpected Click" ),
                                        message,
                                        QMessageBox::Yes |
QMessageBox::Default,
                                        QMessageBox::No,
                                        QMessageBox::Cancel |
QMessageBox::Escape );

HERE add: print button to log file (if at all possible)???

    if ( button == 0 )  // Yes

Uh - that logging is there. It's the y2milestone() call in the code above. This is a pretty high-priority logging (level "milestone"), i.e. if you see anything in the logs, that milestone logging will be there, too.

Now also happens for me

See bug #222505 for explanation

*** This bug has been marked as a duplicate of bug 222505 ***