This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce) Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release. Thanks, Jeremy http://static.macosforge.org/xquartz/downloads/X11-2.3.1_beta2.pkg
Jeremy Huddleston wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release.
There is something wrong with the emulation for button 3. On my MacBookPro (trackpad), button 2 is now OK, even re-allowing the ctrl-alt-click=ctrl-button2 drop-down menu in sterm. But cmd-click, which should be button 3, now does nothing. With xev I see that cmd-click produces a ButtonPress event with "state 0x10, button 3". I think the "state" is wrong, it should be "0x0". Otherwise it is interpreted as "cmd-button3" instead of just "button3", and "cmd-button3" is not associated with any action. I did not change any preference except activating the 3-button mouse emulation and follow system keyboard layout. Here are the defaults: costabel% defaults read org.x.X11 { "cache_fonts" = 1; depth = -1; "done_xinit_check" = 1; "enable_fake_buttons" = 1; "enable_key_equivalents" = 1; "enable_system_beep" = 0; "no_auth" = 0; "nolisten_tcp" = 1; "sync_keymap" = 1; "wm_click_through" = 0; "wm_ffm" = 0; "wm_focus_on_new_window" = 1; } -- Martin
On Aug 15, 2008, at 00:01, Martin Costabel wrote:
With xev I see that cmd-click produces a ButtonPress event with "state 0x10, button 3". I think the "state" is wrong, it should be "0x0". Otherwise it is interpreted as "cmd-button3" instead of just "button3", and "cmd-button3" is not associated with any action.
Well, you're holding down command... so this is what makes sense to me... How would you suggest to emulate cmd-button3 or alt-button2? If we do one, we have no way of doing the other. I think I'm going to solve this by expanding the available options to the 'fake_button2' and 'fake_button3' defaults options, so you can also do 'lalt', 'ralt', 'rcommand', 'lcommand', 'lshift', and 'rshift'. That way, you can have lcommand be the emulation modifier and hold both to do a command-click... this is going to be a tad tricky to implement though... --Jeremy
+ Jeremy Huddleston <jeremyhu@freedesktop.org>:
On Aug 15, 2008, at 00:01, Martin Costabel wrote:
With xev I see that cmd-click produces a ButtonPress event with "state 0x10, button 3". I think the "state" is wrong, it should be "0x0". Otherwise it is interpreted as "cmd-button3" instead of just "button3", and "cmd-button3" is not associated with any action.
Well, you're holding down command... so this is what makes sense to me...
How would you suggest to emulate cmd-button3 or alt-button2? If we do one, we have no way of doing the other.
In my insufficiently humble opinion, this whole "emulate three button mouse" business is a horrible hack. There is no way to do it right; at most, it is an emergency measure to get you through when you're stuck doing X11 with a single button mouse. Serious users of X11 just need to get a three (or more) button mouse. Personally, I use SideTrack on my laptop, which lets me click buttons 2 and 3 (but not drag them) using the trackpad. I can recommend it. I seem never to miss the ability to drag buttons 2 and 3; the only place I can think of is those xterm menus. (If I cared enough, I could remap them to button 1 with suitable modifiers.) Given what I said above, it doesn't seem to be worthwhile spending a huge amount of energy getting this right (it can't be done). But as an emergency solution, I think it is better that the emulated buttons not show up with the modifier set, since that is going to be what users need more frequently. So they can't get the other; too bad, but if something can't be done in software then it can't be done in software. So quit agonizing over it. - Harald
Jeremy Huddleston wrote:
On Aug 15, 2008, at 00:01, Martin Costabel wrote:
With xev I see that cmd-click produces a ButtonPress event with "state 0x10, button 3". I think the "state" is wrong, it should be "0x0". Otherwise it is interpreted as "cmd-button3" instead of just "button3", and "cmd-button3" is not associated with any action.
Well, you're holding down command... so this is what makes sense to me...
How would you suggest to emulate cmd-button3 or alt-button2? If we do one, we have no way of doing the other.
Look at the emulation of button2 via alt-click: If I press alt+some key, I get a KeyPress event with "state 0x2000", but alt+click gives a ButtonPress event with "state 0x0". This is as it should be. For cmd+some key, I get "state 0x10", and cmd+click gives "state 0x10", too, which is wrong. In all previous versions of Apple's or xquartz's X11 up to and including xquartz-2.3.0, it was "state 0x0". I don't care about cmd+mouse button. It is clear that one has to compromise somewhere with the emulation, but the basic function "button 3" needs to be there. It is not only ctrl-button3 that doesn't work, but also basic things that are bound to button 3 like extended selection. I also don't care about lectures on the evils of mouse button emulation. Whoever doesn't like it can always switch it off. There is nothing "emergency" about it, it has worked OK for many years. I don't understand why it should change. -- Martin
+ Martin Costabel <costabel@wanadoo.fr>:
I also don't care about lectures on the evils of mouse button emulation. Whoever doesn't like it can always switch it off. There is nothing "emergency" about it, it has worked OK for many years. I don't understand why it should change.
I must not have expressed myself clearly. While I still do stand by the "emergency" label, I am not against emergency measures - far from it, I am in favour of such. While there is no way to do this right there is a way that is least wrong, and that is as you say, don't let the modifier used for emulation be expressed in the state. I think it should be implemented that way and then left alone. My little diatribe was directed against any attempts at making this emulation mode do everything you can do with a three button mouse, which is just plain impossible - unless someone can come up with something much too clever for me to imagine, in which case it is likely too clever for the poor user as well. - Harald
On Aug 15, 2008, at 05:34, Martin Costabel wrote:
Look at the emulation of button2 via alt-click: If I press alt+some key, I get a KeyPress event with "state 0x2000", but alt+click gives a ButtonPress event with "state 0x0". This is as it should be.
You should not have state 0x2000 with alt. You should have 0x8, and there's no reason the states should be different. I'm not treating the two any differently. Do you have a special ~/.Xmodmap (run 'xmodmap' at the terminal and tell me what it says)? What's your OSX keyboard layout?
For cmd+some key, I get "state 0x10", and cmd+click gives "state 0x10", too, which is wrong. In all previous versions of Apple's or xquartz's X11 up to and including xquartz-2.3.0, it was "state 0x0".
It is correct that up to and including 2.3.0 it was state 0x0, but all those versions had a bug which I'm trying to address, the emulated button click was always a "modifier-release, down, up, modifier press" on the mouse-down. There was no way to "hold" button2 or button3. Yes, those did "release" the modifier, but my reason for not doing this in the beta I just released was that it was more "correct" with respect to the hardware state, was easier to code, and the other way was just as wrong in my mind. As you read in my earlier post, I want to change that so the default is to reset the modifiers, but you have to understand it's not a trivial problem. Consider: cmd-down button1-down # emulated as (cmd-up, button3-down, cmd-down) a-down # this should be cmd-a since command is down a-up button1-up # emulated as (cmd-up, button3-down, cmd-down) versus cmd-down button1-down # emulated as (cmd-up, button3-down, cmd-down) cmd-up a-down # this should be a since command is down a-up button1-up # needs to be emulated as button3-down without cmd-up/ cmd-down This gets even more complicated in the logic once we add in the possibility that l/r modifiers can be differentiated between... so just give me a little while to figure out a clean way to do this. In the mean time, I'm more concerned about why your alt
Jeremy Huddleston wrote:
On Aug 15, 2008, at 05:34, Martin Costabel wrote:
Look at the emulation of button2 via alt-click: If I press alt+some key, I get a KeyPress event with "state 0x2000", but alt+click gives a ButtonPress event with "state 0x0". This is as it should be.
You should not have state 0x2000 with alt. You should have 0x8, and there's no reason the states should be different. I'm not treating the two any differently.
Do you have a special ~/.Xmodmap (run 'xmodmap' at the terminal and tell me what it says)? What's your OSX keyboard layout?
I have a "US international" keyboard (that's the one with "~`" to the left of "z", and a superfluous "±§" key to the left of "1" where "~`" should be,). The "mouse button" is the trackpad button. "Click" means pressing this button. There is no ~/.Xmodmap. xmodmap says: costabel% xmodmap xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x40), Shift_R (0x44) lock Caps_Lock (0x41) control Control_L (0x43), Control_R (0x46) mod1 Mode_switch (0x42), Mode_switch (0x45) mod2 Meta_L (0x3f), Meta_R (0x47) mod3 mod4 mod5 To reiterate what I see with xev: The "alt" key gives status 0x2000 with other keys, for example: alt-a gives "state 0x2000, keycode 8 (keysym 0xe5, aring)", ctl-alt-a gives "state 0x2004, keycode 8 (keysym 0x61, a)" It gives "status 0x0" with mouse click, thus alt-click gives "state 0x0, button 2", and ctl-alt-click gives "state 0x4, button 2" This is the same in xquartz-2.3.0 and 2.3.1beta2 and, as far as I can tell, in all previous Leopard X11 versions. The only "novelty" in xquartz-2.3.0 was that it introduced a spurious ButtonRelease event when the button was not yet released. The "cmd" key gives status 0x10, for example: cmd-a gives "state 0x10, keycode 8 (keysym 0x61, a)", ctl-cmd-a gives "state 0x14, keycode 8 (keysym 0x61, a)". In previous versions of X11, up to xquartz-2.3.0, cmd-click gives "status 0x0, button 3", and ctl-cmd-click gives "state 0x4, button 3". In 2.3.1beta2, cmd-click gives "status 0x10, button 3", and ctl-cmd-click gives "state 0x14 button 3".
For cmd+some key, I get "state 0x10", and cmd+click gives "state 0x10", too, which is wrong. In all previous versions of Apple's or xquartz's X11 up to and including xquartz-2.3.0, it was "state 0x0".
It is correct that up to and including 2.3.0 it was state 0x0, but all those versions had a bug which I'm trying to address, the emulated button click was always a "modifier-release, down, up, modifier press" on the mouse-down. There was no way to "hold" button2 or button3. Yes,
No. This was the case *only* in 2.3.0, not in previous versions, up to 2.2.3. In Apple's X11 with "X.Org X Server 1.4.2-apple5", for example, I see the "modifier release, down" part on mouse down, but the "up, modifier press" part not before mouse up. I think this is how it has always been. The side effect in the old way is, of course, that if you press alt-click-a, you get "a" and not "alt-a = å". But who would do this anyway? -- Martin
On Aug 15, 2008, at 14:21, Martin Costabel wrote:
The "mouse button" is the trackpad button. "Click" means pressing this button. There is no ~/.Xmodmap. xmodmap says:
Ah. *I* had a ~/.Xmodmap which I forgot about: ! This one switches both alt keys to be alt: keycode 66 = Alt_L keycode 69 = Alt_R clear mod1 add mod1 = Alt_L Alt_R That was why you were seeing 0x2000 for alt instead of 0x8 If you look closely, you'll also notice the lack of Mode_switch being released, yet the state doesn't reflect it as down. It looks like in X11 Mode_switch is just never sent with mouse-clicks for some reason, so that's why you weren't seeing it. I wonder why that is...
The side effect in the old way is, of course, that if you press alt-click-a, you get "a" and not "alt-a = å". But who would do this anyway?
Well now with 1.4.2-apple9, you should be getting "å" --Jeremy
Hi Jeremy Thanks for making progress on the 3-button mouse emulation. As Martin said, "ctrl-alt-click" = "ctrl-button2" - that's great! "ctrl-cmd-click", however, does not produce "ctrl-button3" as it should. This is just to confirm Martin's observation (ppc powerbook G4). -John On Fri, Aug 15, 2008 at 12:01 AM, Martin Costabel <costabel@wanadoo.fr> wrote:
Jeremy Huddleston wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release.
There is something wrong with the emulation for button 3. On my MacBookPro (trackpad), button 2 is now OK, even re-allowing the ctrl-alt-click=ctrl-button2 drop-down menu in sterm. But cmd-click, which should be button 3, now does nothing.
With xev I see that cmd-click produces a ButtonPress event with "state 0x10, button 3". I think the "state" is wrong, it should be "0x0". Otherwise it is interpreted as "cmd-button3" instead of just "button3", and "cmd-button3" is not associated with any action.
I did not change any preference except activating the 3-button mouse emulation and follow system keyboard layout. Here are the defaults:
costabel% defaults read org.x.X11 { "cache_fonts" = 1; depth = -1; "done_xinit_check" = 1; "enable_fake_buttons" = 1; "enable_key_equivalents" = 1; "enable_system_beep" = 0; "no_auth" = 0; "nolisten_tcp" = 1; "sync_keymap" = 1; "wm_click_through" = 0; "wm_ffm" = 0; "wm_focus_on_new_window" = 1; }
-- Martin
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Aug 15, 2008, at 03:55, John Koren wrote:
Hi Jeremy
Thanks for making progress on the 3-button mouse emulation.
As Martin said,
"ctrl-alt-click" = "ctrl-button2" - that's great!
Actually, it's ctrl-alt-button2 (0x20c) state: 0x200 - button2 0x400 - button3 0x004 - control 0x008 - alt 0x010 - command
"ctrl-cmd-click", however, does not produce "ctrl-button3" as it should.
It's ctrl-cmd-button3 (0x414) There is no inconsistency.
Jeremy, I think what he was trying to say with 'click' is 'button1'. Remember, we're emulating here so we do not have a 'button2' or 'button3'. Thus, with emulate 3-button mouse on: "ctrl-alt-button1" should produce "ctrl-button2" which works. "ctrl-cmd-button1" should produce "ctrl-button3" and doesn't. Anyway, that's my interpretation of the discussion unless I've gotten confused somewhere along the way. Merle On Aug 15, 2008, at 2:06 PM, Jeremy Huddleston wrote:
On Aug 15, 2008, at 03:55, John Koren wrote:
Hi Jeremy
Thanks for making progress on the 3-button mouse emulation.
As Martin said,
"ctrl-alt-click" = "ctrl-button2" - that's great!
Actually, it's ctrl-alt-button2 (0x20c)
state: 0x200 - button2 0x400 - button3 0x004 - control 0x008 - alt 0x010 - command
"ctrl-cmd-click", however, does not produce "ctrl-button3" as it should.
It's ctrl-cmd-button3 (0x414)
There is no inconsistency._______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Merle Reinhart wrote:
Jeremy,
I think what he was trying to say with 'click' is 'button1'. Remember, we're emulating here so we do not have a 'button2' or 'button3'.
Yes, thanks for clarifying. I was using traditional Apple-speak where you didn't have mouse buttons, you simply clicked. -- Martin
On Aug 15, 2008, at 11:19, Merle Reinhart wrote:
Jeremy,
I think what he was trying to say with 'click' is 'button1'. Remember, we're emulating here so we do not have a 'button2' or 'button3'.
Thus, with emulate 3-button mouse on: "ctrl-alt-button1" should produce "ctrl-button2" which works.
This is what I'm trying to get at. In beta2, it SHOULDN'T be producing ctrl-button2. It should be producing ctrl-alt-button2. It does on my system. I'm not debating whether it should be ctrl-alt or ctrl. I have been working these past few hours to make it that way and should have a build for you to try in a few... but I'm really confused why you're seeing ctrl-button2 and not ctrl-alt-button2.
On Aug 14, 2008, at 2:57 PM, Jeremy Huddleston wrote:
stuck modifier keys (atleast all the ones I could reproduce)
The weird caps-lock behaviour I mentioned in a previous email is still there. Other than that I've been unable to reproduce any stuck modifier keys yet, so this is a huge improvement, thanks. Jamie
Can you please create a new bug report for this at http://xquartz.macosforge.org , so I don't need to sift through old emails to make sure I know all the bugs. Thanks, Jeremy On Aug 15, 2008, at 07:13, Jamie Kennea wrote:
On Aug 14, 2008, at 2:57 PM, Jeremy Huddleston wrote:
stuck modifier keys (atleast all the ones I could reproduce)
The weird caps-lock behaviour I mentioned in a previous email is still there. Other than that I've been unable to reproduce any stuck modifier keys yet, so this is a huge improvement, thanks.
Jamie _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Aug 15, 2008, at 2:24 PM, Jeremy Huddleston wrote:
Can you please create a new bug report for this at http://xquartz.macosforge.org , so I don't need to sift through old emails to make sure I know all the bugs.
Yeah, sorry about that. I've submitted a bug report. Jamie
I just installed X11-2.3-1_beta2.pgk and found that X11 crashes hard when debugging an X11 application. Specifically, I bring the app up under gdb, set a breakpoint, continue once the break is hit, and then click a dialog button (PyQt based). The X11 server crashes immediately. Attached is a gzipped tar file containing the CrashReporter log file for X11 and the .X11_stout_CrashHistory.plist file from ~/Library/Logs/ CrashReporter/ Reverting back to X11-2.3.0.pkg makes the problem go away. Definitely a show stopper for our development activities. Anything else I can provide to track this one down? -Mike On Aug 14, 2008, at 2:57 PM, Jeremy Huddleston wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release.
Thanks, Jeremy
http://static.macosforge.org/xquartz/downloads/X11-2.3.1_beta2.pkg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
FWIW, Looks like I'm now getting the crash with X11-2.3.0.pkg. I don't know if reinstalling X11-2.3.0.pkg put everything back to the way it was prior to X11-2.3.1_beta2.pgk or if I was just always lucky before today. -Mike On Aug 18, 2008, at 9:40 AM, Mike Krogh wrote:
I just installed X11-2.3-1_beta2.pgk and found that X11 crashes hard when debugging an X11 application. Specifically, I bring the app up under gdb, set a breakpoint, continue once the break is hit, and then click a dialog button (PyQt based). The X11 server crashes immediately.
Attached is a gzipped tar file containing the CrashReporter log file for X11 and the .X11_stout_CrashHistory.plist file from ~/Library/ Logs/CrashReporter/
Reverting back to X11-2.3.0.pkg makes the problem go away. Definitely a show stopper for our development activities.
Anything else I can provide to track this one down?
-Mike
<x11_crash_logs.tgz>
On Aug 14, 2008, at 2:57 PM, Jeremy Huddleston wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release.
Thanks, Jeremy
http://static.macosforge.org/xquartz/downloads/X11-2.3.1_beta2.pkg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Yeah, I doubt that this problem was introduced with 2.3.1. I didn't go anywhere near that area of the codebase. MaybeDeliverEventsToClient is deep inside the shared code with the other DDXs (used by linux, etc). Looking at it, I can see where a crash could occur if bogus arguments were given to it, and that would reveal a bug in the caller... so can you: Tell me how to reproduce this without using your specific code (ie: generalized test case). If you can provide me with a tarball of your code and step-by-step how to compile it to trigger the bug, that would be ok too. or... Provide me with a core dump from X11 when it hits this crash. On Aug 18, 2008, at 07:03, Mike Krogh wrote:
FWIW, Looks like I'm now getting the crash with X11-2.3.0.pkg. I don't know if reinstalling X11-2.3.0.pkg put everything back to the way it was prior to X11-2.3.1_beta2.pgk or if I was just always lucky before today.
-Mike
On Aug 18, 2008, at 9:40 AM, Mike Krogh wrote:
I just installed X11-2.3-1_beta2.pgk and found that X11 crashes hard when debugging an X11 application. Specifically, I bring the app up under gdb, set a breakpoint, continue once the break is hit, and then click a dialog button (PyQt based). The X11 server crashes immediately.
Attached is a gzipped tar file containing the CrashReporter log file for X11 and the .X11_stout_CrashHistory.plist file from ~/Library/ Logs/CrashReporter/
Reverting back to X11-2.3.0.pkg makes the problem go away. Definitely a show stopper for our development activities.
Anything else I can provide to track this one down?
-Mike
<x11_crash_logs.tgz>
On Aug 14, 2008, at 2:57 PM, Jeremy Huddleston wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
Please give it a whirl. I think this now tackles most of the major issues that surfaced after the 2.3.0 release.
Thanks, Jeremy
http://static.macosforge.org/xquartz/downloads/X11-2.3.1_beta2.pkg
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Thu, 14 Aug 2008, Jeremy Huddleston - jeremyhu@apple.com wrote:
This release fixes: the first-client-not-connecting bug I added in beta1 3-button mouse emulation stuck modifier keys (atleast all the ones I could reproduce)
I can confirm that these three items behave well on PPC and Intel now. I don't have any sort of odd-ball keyboard so I do not get any of the console messages with debug info, so I cannot help with that. Thank you, mzs
participants (9)
-
Harald Hanche-Olsen
-
Jamie Kennea
-
Jeremy Huddleston
-
Jeremy Huddleston
-
John Koren
-
Martin Costabel
-
Merle Reinhart
-
Mike Krogh
-
xquartz-dev.5.mzs＠spamgourmet.com