Bug#311199: the patch is not likely to correct this problem (311199)
clone 311199 -1 retitle -1 Improper mouse events handling in preview window submitter -1 Reinhard Fössmeier i...@ais-sanmarino.org thanks Hi, The problem addressed by the patch was an environment (hardware? software?) that delivered GTK mouse events with an extra bit (0x2000) set. This caused ALL processing of mouse events to fail. In the present bug the left and right border can be tracked, only the bottom border has problems. This does not look like the problem fixed by my patch. Let's make a dedicated bug out of this. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#311199: the patch is not likely to correct this problem (311199)
AIS, Informofico i...@ais-sanmarino.org wrote: Hi, let me know when the fix goes from candidate to actually fixes the problem :) As the author of the patch I regret to say that it is not likely to fix this problem. Yeah. Besides removing magic values and replacing them with proper definitions, it doesn't do much. The problem addressed by the patch was an environment (hardware? software?) that delivered GTK mouse events with an extra bit (0x2000) set. This caused ALL processing of mouse events to fail. In the I'd really like to understand why this happened. The events were filtered by the lock masks (numlock etc) that you removed, so I'd really like to know what's happening on your end that doesn't happen everywhere else. (and I'd also need to look at the code to understand why the masks are here in the first place) JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#311199: the patch is not likely to correct this problem (311199)
Hello, Gladly I will do my best to explain the patch for xsane. You (JB) write that it doesn't do much but the problem was (as I pointed out in the Ubuntu bug discussion in Launchpad) that the GdkEventMotion.state value originally was masked (AND-ed) with values such as GDK_Num_Lock (0xff7f) or GDK_Caps_Lock (0xffe5). These values are */not/* bit masks, they are enumerated values for key codes. So it makes no sense to use them for bitwise operations. That they worked certainly was not pure coincidence but maybe a result of trial and error. The problem on my platform (Ubuntu 10.04 on a fairly new notebook computer with a second screen) was that GTK delivered the mouse events with the *0x2000* bit set. (This bit is not defined in gdktypes.h.) On my computer, when I try to mark a scan rectangle in the xsane preview window this bit is always set. And it was not filtered by the strange GDK key codes. It could not be; they all have the 0xf000 nibble set. They just are not bit masks. What I did in my patch was masking away all bits except those xsane is interested it: the three first mouse buttons. So instead of masking the state bit vector with key codes I mask it with the combination of (GDK_BUTTON1_MASK | GDK_BUTTON2_MASK | GDK_BUTTON3_MASK) = *0x700*. That is the essential change. You are right, the other three lines are just cosmetics (desirable though). Interestingly, the gdk/gdktypes.h header file says in a comment: GDK_BUTTON5_MASK = 1 12, /* The next few modifiers are* used by XKB*, so we skip to the end. * Bits 15 - 25 are currently unused. Bit 29 is used internally. */ The 0x2000 bit that caused me (and probably others) trouble is (1 13). So it belongs to those used by XKB (X keyboard specification). I just looked up this specification; it says Bits 13 and 14 are interpreted as a two-bit unsigned numeric value and report the state keyboard group. I humbly admit that I do not understand what the state keyboard group is but to me it seems a good idea to mask these bits when we are not interested in the keyboard state. And since xsane is interested only in the first three mouse buttons it seems reasonable to mask everything else. That is what bit masks are used for. Each bit counts for itself. Maybe gdktypes.h ought to define a bit mask to filter those two bits used by XKB. At present it does not, it defines only single bits, and my patch combines such bits to do what is needed. I suppose it was the original author's idea to ignore any pressed or locked SHIFT, CTRL, ALT etc modifiers. My patch does this. And it ignores those bits used by XKB, which the original code did not. Please feel free to contact me for further questions. RF (Aisano)
Bug#311199: the patch is not likely to correct this problem (311199)
AIS, Informofico i...@ais-sanmarino.org wrote: Hi, Gladly I will do my best to explain the patch for xsane. You (JB) write that it doesn't do much but the problem was (as I pointed out in the Ubuntu bug discussion in Launchpad) that the GdkEventMotion.state value originally was masked (AND-ed) with values such as GDK_Num_Lock (0xff7f) or GDK_Caps_Lock (0xffe5). These values are */not/* bit masks, they are enumerated values for key codes. So it makes no sense to use them for bitwise operations. That they worked certainly was not pure coincidence but maybe a result of trial and error. Thank you very much for the research and explanations behind your patch, it's crystal clear and very appreciated! I'll apply the patch in the next revision, won't take long. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#311199: the patch is not likely to correct this problem (311199)
Julien BLACHE a écrit: let me know when the fix goes from candidate to actually fixes the problem :) As the author of the patch I regret to say that it is not likely to fix this problem. The problem addressed by the patch was an environment (hardware? software?) that delivered GTK mouse events with an extra bit (0x2000) set. This caused ALL processing of mouse events to fail. In the present bug the left and right border can be tracked, only the bottom border has problems. This does not look like the problem fixed by my patch. Still I think the patch does nothing wrong and fixes a potentially unpleasant problem. Regards, Reinhard Fössmeier (Aisano) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
