Re: modifiers problems with xlibs 4.3.0.dfsg.1-5

2004-07-08 Thread Branden Robinson
Sebastien,

Thanks for starting a thread on this.  X Strike Force, let's see what we
can do about it.  :)

Mr. Pascal,

I recently backported your change from XFree86 CVS last year:
   172. Add workaround for problems that arise when in multi-layout map
different modifier keysyms share the same key (Ivan Pascal).

to Debian's packages of XFree86 4.3.0, and promptly got bug reports exactly
the same as XFree86 Bugzilla #580.

Mailing list subscribers,

Please read upstream XFree86 bug report about this:
http://bugs.xfree86.org/show_bug.cgi?id=580

On Sun, Jun 20, 2004 at 05:05:56PM +0200, Sebastien Bacher wrote:
> The new xlibs package (4.3.0.dfsg.1-5) seems to have some modifier'
> problems that breaks alt+tab with metacity for example.
> 
> I've attached the xev output for an "alt+tab" action in a "xinit /usr/
> bin/X11/xev -- :1 vt8 > /tmp/xev.out" to the mail.
> 
> After talking with Brandon

With whom?  :)

> on IRC I've tried to revert some changes to compat/misc (patch
> xlibs-modifier.patch attached to the mail).
> 
> This patch fix the problem on one of my boxes, but has some weird
> effects : if you keep a key pressed xev doesn't stop to display "pressed
> - released - pressed ..."  events instead of displaying one "pressed".
> 
> Then I've tried to replace xkb/symbols/pc/pc with the xlibs -4
> version ... it fixes the "multi-events problem" but my breaks shift/
> altgr/... combinated actions. 
> 
> Does somebody has an idea of what is exactly broken in xlibs 4.3.0.
> dfsg.1-5 ? Let me know if you need more details of the problems ...

I have attached the upstream changeset that caused this problem.

Unfortunately, I don't think just reverting it is the right solution.  Ivan
Pascal is trying to solve a real problem.  We can't just assign certain
modifiers to certain keys on a "base" symbols file like
symbols/pc/pc(basic), because that really screws up people who need to use
multi-level layouts.  Not every layout is going to use the exact same keys
for the exact same modifiers, especially when crazy stuff like Compose,
AltGr, ISO_Lock and so forth gets involved.

Reverting is bad because:
* We'd break compatibility with XFree86 4.4.0;
* We'd break compatibility with X.Org.

At the same time, I suspect the fix in XFree86 #580 is a kludge, because
perhaps not everyone using the pc/pc(basic) symbol map will actually want
Mod1 on .

Furthermore, we know that people *still* can't use Alt_R+Tab to cycle
windows, and people whose window managers use the left and/or right Windows
keys together with tab are seeing the same problem.

I'm pretty sure Ivan Pascal is regarded as one of the very few experts on
this subject.  Unless he thinks it was a bad call to move to the "fake key"
approach, I think we're best advised to help him figure out how to
implement a solution that will stick.

I have a few questions:

* Is it possible to non-destructively update a modifier mapping?  I.e., if
  we have:

// xc/programs/xkbcomp/symbols/pc/pc

partial hidden alphanumeric_keys modifier_keys
xkb_symbols "basic" {
/// snip
modifier_map Mod1   { Alt_L };
}

default
xkb_symbols "pc104" {
modifier_map Mod1   { Meta_L };
}

And I'm using "pc/pc(104)" for my symbols, is Mod1 on *both* Alt_L and
Meta_L, or just on Meta_L?

I'm wondering if what we need are modifier_add and modifier_del keywords.

E.g.,

modifier_add Mod1 { Meta_L };

...would map the Mod1 modifier key to Meta_L, *without changing any
existing mappings of Mod1 to any other keys*.  If Mod1 is already mapped to
Meta_L, this directive would be ignored, but not cause an error.

modifier_del Mod1 { Alt_L };

...would remove any existing mapping of Mod1 to Alt_L.  If Mod1 is not
already mapped to Alt_L, this directive would be ignored, and not cause an
error.

To support Ivan Pascal's approach, I think we're going to need the above
functionality, especially if people are going to keep playing around with
special symbols files like "altwin", "compose", "ctrl".

Maybe what I suggest is already possible, just using a different syntax?

Furthermore, are window managers using bad code to detect press and release
events for modifier keys?  Maybe window managers need to be changed as well
to be smarter about this.

Mr. Pascal, can you help Debian understand this problem?

-- 
G. Branden Robinson|The basic test of freedom is
Debian GNU/Linux   |perhaps less in what we are free to
[EMAIL PROTECTED] |do than in what we are free not to
http://people.debian.org/~branden/ |do.  -- Eric Hoffer
From: Ivan Pascal <[EMAIL PROTECTED]>
To: cvs-commit@xfree86.org
Subject: CVS Update: xc (branch: trunk)
Date: Thu, 15 May 2003 06:32:01 -0700 (PDT)
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Status: No, hits=0.6 required=6.0
tests=SPAM_PHRASE_00_01
version=2.41

CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED]  03/05/15 06:32:01

Log message:
 

modifiers problems with xlibs 4.3.0.dfsg.1-5

2004-06-20 Thread Sebastien Bacher
Hi,

The new xlibs package (4.3.0.dfsg.1-5) seems to have some modifier'
problems that breaks alt+tab with metacity for example.

I've attached the xev output for an "alt+tab" action in a "xinit /usr/
bin/X11/xev -- :1 vt8 > /tmp/xev.out" to the mail.

After talking with Brandon on IRC I've tried to revert some changes to
compat/misc (patch xlibs-modifier.patch attached to the mail).

This patch fix the problem on one of my boxes, but has some weird
effects : if you keep a key pressed xev doesn't stop to display "pressed
- released - pressed ..."  events instead of displaying one "pressed".

Then I've tried to replace xkb/symbols/pc/pc with the xlibs -4
version ... it fixes the "multi-events problem" but my breaks shift/
altgr/... combinated actions. 


Does somebody has an idea of what is exactly broken in xlibs 4.3.0.
dfsg.1-5 ? Let me know if you need more details of the problems ...



Thanks,

Sebastien Bacher



Outer window is 0x41, inner window is 0x42

PropertyNotify event, serial 8, synthetic NO, window 0x41,
atom 0x27 (WM_NAME), time 4534, state PropertyNewValue

PropertyNotify event, serial 9, synthetic NO, window 0x41,
atom 0x22 (WM_COMMAND), time 4534, state PropertyNewValue

PropertyNotify event, serial 10, synthetic NO, window 0x41,
atom 0x28 (WM_NORMAL_HINTS), time 4534, state PropertyNewValue

CreateNotify event, serial 11, synthetic NO, window 0x41,
parent 0x41, window 0x42, (10,10), width 50, height 50
border_width 4, override NO

MapNotify event, serial 12, synthetic NO, window 0x41,
event 0x41, window 0x42, override NO

MapNotify event, serial 13, synthetic NO, window 0x41,
event 0x41, window 0x41, override NO

VisibilityNotify event, serial 13, synthetic NO, window 0x41,
state VisibilityUnobscured

Expose event, serial 13, synthetic NO, window 0x41,
(0,0), width 178, height 10, count 3

Expose event, serial 13, synthetic NO, window 0x41,
(0,10), width 10, height 58, count 2

Expose event, serial 13, synthetic NO, window 0x41,
(68,10), width 110, height 58, count 1

Expose event, serial 13, synthetic NO, window 0x41,
(0,68), width 178, height 110, count 0

EnterNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5280, (174,54), root:(176,56),
mode NotifyNormal, detail NotifyAncestor, same_screen YES,
focus YES, state 0

KeymapNotify event, serial 16, synthetic NO, window 0x0,
keys:  63  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5280, (158,42), root:(160,44),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5296, (146,32), root:(148,34),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5296, (134,22), root:(136,24),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5312, (124,14), root:(126,16),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5312, (114,6), root:(116,8),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5328, (112,5), root:(114,7),
state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 5328, (110,4), root:(112,6),
state 0x0, is_hint 0, same_screen YES

KeyPress event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 7878, (110,4), root:(112,6),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:  ""

KeyRelease event, serial 16, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 7878, (110,4), root:(112,6),
state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:  ""

KeyPress event, serial 21, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 8132, (110,4), root:(112,6),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:  ""

KeyPress event, serial 21, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 8993, (110,4), root:(112,6),
state 0x40, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:  ""

KeyPress event, serial 21, synthetic NO, window 0x41,
root 0x3f, subw 0x0, time 9918, (110,4), root:(112,6),
state 0x48, keycode 23 (keysym 0xff09, Tab), same_screen YES,
XLookupString gives 1 bytes:  " "

KeyRelease event, serial 21, synthetic NO, window 0x41,