Re: Auto-repeat with evdev 2.2.0
Confirming this issue with xf86-input-evdev-2.2.0 and xorg-server-1.5.3-r3 on Gentoo linux ~x86. I used to have xf86-input-evdev-2.1.3 before. I haven't tested the patch - yet. M. Peter Hutterer wrote: On Mon, Mar 09, 2009 at 10:15:50PM -0400, Marty Jack wrote: Dropping evdev 2.2.0 onto a system that was running 2.1.3 caused auto-repeat to stop working. The keyboard is a run of the mill keyboard connected via a PS/2 connector. HAL is not installed. Restoring 2.1.3 restored auto-repeat. xset q reported the same auto-repeat settings under both drivers. Anyone else experience this? Regression or something changed in what configuration is needed? If it might be a configuration problem, what should I be looking at? That's probably a result of --- commit ece72ce9e97adae23b1932dc1334f63669196d56 Author: Sascha Hlusiak saschahlus...@arcor.de AuthorDate: Mon Dec 8 12:27:34 2008 +0100 Filter all repeated keys from kernel, because we do softrepeat in server Discard all repeated events that come from the device. The server will handle per-key autorepeat in software. --- and you need the following xserver commit --- commit bbf811514d3cdf84790bad5b852942a4e636902b Author: Sascha Hlusiak saschahlus...@arcor.de AuthorDate: Mon Dec 8 12:24:39 2008 +0100 ddxCtrls.c: XkbDDXUsesSoftRepeat always returns 1 now We'd like to do soft repeat in the server for all keys. Remove obscure check, that'd prevent the server from autorepeating when delay is set to exactly 660ms and rate is set to exactly 25 (interval=40). - (ff9b55d8cbc19e0e31a91034e332058acd967cd1 in the 1.6 branch) What server version are you running? 1.5? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: a pledge for updating/enhancing xsm
Dennis Heuer wrote: On Tue, 10 Mar 2009 09:45:24 +0100 Martin MOKREJŠ mmokr...@ribosome.natur.cuni.cz wrote: How about fvwm2? ;-) m. actually, i don't get the clever point you make 8-( i ask for enhancements in xsm and you target me to a window manager. but openbox behaves fine. it also could override xsm's window placement somehow if defined in its rc-script. however, this is a hack and not the solution!? please take my pledge serious. Sorry then, I did not get your point. I thought your were looking for a simple window manager. :( M. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type
Hi Peter,
thanks for excellent explanations. More below.
Peter Hutterer wrote:
(**) Option xkb_rules evdev
(**) AT Translated Set 2 keyboard: xkb_rules: evdev
(**) Option xkb_model evdev
(**) AT Translated Set 2 keyboard: xkb_model: evdev
(**) Option xkb_layout us,cz
(**) AT Translated Set 2 keyboard: xkb_layout: us,cz
(**) Option xkb_variant ,qwerty
(**) AT Translated Set 2 keyboard: xkb_variant: ,qwerty
(**) Option xkb_options
grp:alt_shift_togglegrp_led:scrollcaps:shift_nocancel
(**) AT Translated Set 2 keyboard: xkb_options:
grp:alt_shift_togglegrp_led:scrollcaps:shift_nocancel
this last line is wrong, see below.
xkb_keymap {
xkb_keycodes evdev+aliases(qwerty) {
[...]
xkb_types complete {
[...]
xkb_compatibility complete {
[...]
xkb_symbols pc+us+cz(qwerty):2+inet(evdev) {
[...]
this is what actually is loaded in the server. You see how all your options
are missing? This is because of a wrong setup (fdi file below).
Until one know how it should look like it is not that clear.
Now I see what had to be there:
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: /dev/input/event4
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type:
KEYBOARD)
(**) Option xkb_rules evdev
(**) Option xkb_model pc105
(**) Option xkb_layout us,cz
(**) Option xkb_variant ,qwerty
(**) Option xkb_options
grp:alt_shift_toggle,grp_led:scroll,caps:shift_nocancel
key LFSH { [ Shift_L ] };
key RTSH { [ Shift_R ] };
key LALT { [ Alt_L, Meta_L ] };
key RALT {
type[group2]= ONE_LEVEL,
symbols[Group1]= [ Alt_R, Meta_R ],
symbols[Group2]= [ ISO_Level3_Shift ]
};
here's the details why it doesn't work, the Alt/Shift keys dont have the
required ISO_Next_Group, ISO_Prev_Group they should have, hence group
switching doesn't work.
So here is what I have now compared to the former/broken:
# xkbcomp :0 -xkb out.xkb3
# diff -u -w out.xkb out.xkb3
--- out.xkb 2009-02-12 17:54:32.0 +0100
+++ root/out.xkb3 2009-02-23 16:56:36.0 +0100
@@ -291,7 +291,7 @@
alias LatM = AB07;
};
-xkb_types complete {
+xkb_types complete+caps(shift_nocancel) {
virtual_modifiers
NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;
@@ -309,6 +309,7 @@
modifiers= Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
level_name[Level1]= Base;
level_name[Level2]= Caps;
};
@@ -489,10 +490,11 @@
modifiers= Shift+Lock+LevelThree;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
map[LevelThree]= Level3;
map[Shift+LevelThree]= Level4;
map[Lock+LevelThree]= Level4;
-map[Shift+Lock+LevelThree]= Level3;
+map[Shift+Lock+LevelThree]= Level4;
level_name[Level1]= Base;
level_name[Level2]= Shift;
level_name[Level3]= Alt Base;
@@ -502,6 +504,7 @@
modifiers= Shift+Lock+LevelThree;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
map[LevelThree]= Level3;
map[Shift+LevelThree]= Level4;
map[Lock+LevelThree]= Level3;
@@ -582,7 +585,7 @@
};
};
-xkb_compatibility complete {
+xkb_compatibility complete+ledscroll(group_lock) {
virtual_modifiers
NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;
@@ -1048,8 +1051,7 @@
modifiers= NumLock;
};
indicator Scroll Lock {
-whichModState= locked;
-modifiers= ScrollLock;
+groups= 0xfe;
};
indicator Shift Lock {
!allowExplicit;
@@ -1066,7 +1068,7 @@
};
};
-xkb_symbols pc+us+cz(qwerty):2+inet(evdev) {
+xkb_symbols pc+us+cz(qwerty):2+inet(evdev)+group(alt_shift_toggle) {
name[group1]=USA;
name[group2]=Czechia - qwerty;
@@ -1278,7 +1280,10 @@
symbols[Group1]= [ grave, asciitilde ],
symbols[Group2]= [ semicolon, dead_abovering, grave,
asciitilde ]
};
-key LFSH { [ Shift_L ] };
+key LFSH {
+type= PC_ALT_LEVEL2,
+symbols[Group1]= [ Shift_L, ISO_Prev_Group ]
+};
key BKSL {
type[group2]= FOUR_LEVEL,
symbols[Group1]= [ backslash, bar ],
@@ -1341,12 +1346,15 @@
symbols[Group1]= [ slash,question ],
symbols[Group2]= [ minus, underscore,asterisk,
dead_abovedot ]
};
-key RTSH { [ Shift_R ] };
+key RTSH {
Re: [Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type
Martin MOKREJŠ wrote: Forgot to add that the [alt]+[shift] switch works with the setup I have now. Only I suspect that [shift]+twice pressing [=] on the US keyboard layout followed by pressing [u] should generate ů instead of ˇu. But, the character is anyway mapped over the [;] character of US layout. Is there a way to get a graphical layout of the expected buttons from my installation and some reference layout (gif/jpg/ps or X11 live app)? I see xvkbd but it does not change its output if I switch between the keyboard layouts: $ xvkbd xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly $ Thanks Martin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type
Dan Nicholson wrote: On Sat, Feb 21, 2009 at 11:15 AM, Martin MOKREJŠ mmokr...@ribosome.natur.cuni.cz wrote: I don't know the internals of xorg server, so ... I am puzzled why the /usr/bin/xkbcomp is being called twice, as logged in Xorg.0.log. I even cannot find the file to existing for teh currently running instance: The server pipes xkb source data to xkbcomp, which outputs a compile .xkm file. The server then loads the file and destroys it. It happens twice because once is the keymap for the core keyboard, and once is the keymap for the device. Hopefully one day this interaction can suck less, but my guess is that your bug lies elsewhere in XKB. Thanks Dan, actually it seems it is called always when I go a console mode from X or while returning (ctrl+alt+F[0-6] or alt+F7). After a while I see it simply multiple times. Probably the problem is with my keyboard map then. Lets see who else can speak up. ;-) -- Martin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
