Re: Failed to compile keymap using ptxdist
On Fri, Nov 18, 2011 at 02:09:17PM +0530, Wingston Sharon wrote: I'm using the pengutronix ptxdist BSP for the mini2440 and i wanted to set up an xwindow system. but got this error.. when trying to start Xorg.. i have enabled anxkeymap entry in menuconfig but i cant find a keymap entry in eithermenuconfig or kernelconfig.doing a ptxdist clean xorg and then ptxdist go doesnt help either.. asin ptxdist says that theres nothing to be done for world. (==) Logfile: /var/log/Xorg.0.log, Time: Thu Oct 2 23:41:35 2008(==) Using config file: /etc/X11/xorg.conf(==) Using system config directory/usr/lib/X11/xorg.conf.dsh: /usr/bin/xkbcomp: not found(EE) Error compiling keymap (server-0)(EE) XKB: Couldn't compile Sounds like you need to install xkbcomp. keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be amissing or incorrect setup of x. Fatal server error: Failed to activate core devices.-doing a little more digging around i came across the xorg -configureoption.. this though gives me this little gem of knowledge.. root@mini2440:~ Xorg -configure X.Org X Server 1.9.3Release Date: 2010-12-13X Protocol Version 11, Revision 0Build Operating System:Linux- PtxdistCurrent Operating System: Linux mini2440 3.1.1-ptx-2011.11.0 #0 PREEMPT Fri NovlKernel command line: console=ttySAC0,115200 mini2440=6tbc ip=192.168.1.2:192.16)Build Date: 18 November 2011 11:37:52AM Current version of pixman: 0.21.2 Before reporting problems, check http://www.pengutronix.de/software/ptxl to make sure that you have the latest version.Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: /var/log/Xorg.0.log, Time: Thu Oct 2 23:53:52 2008List ofvideo drivers: dummy v4l fbdev No devices to configure. Configuration failed. ---i gues my device is fbdev.. but i'm stumped how i would be able to getit to configure the xorg.config file.[Wilson Wingston Sharon] -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Failed to compile keymap using ptxdist
On Mon, Nov 21, 2011 at 01:43:05PM +0530, Wingston Sharon wrote: thing is i cant find xkbcomp in menuconfig or kernelconfig.. i searched through.. is there an easy way to identify where the packages menu entry would be? [Wilson Wingston Sharon] Sorry, I don't know pengutronix ptxdist BSP. Best ask at ptxdist.org. On Mon, Nov 21, 2011 at 1:30 PM, Dirk Wallenstein hals...@t-online.de wrote: On Fri, Nov 18, 2011 at 02:09:17PM +0530, Wingston Sharon wrote: I'm using the pengutronix ptxdist BSP for the mini2440 and i wanted to set up an xwindow system. but got this error.. when trying to start Xorg.. i have enabled anxkeymap entry in menuconfig but i cant find a keymap entry in eithermenuconfig or kernelconfig.doing a ptxdist clean xorg and then ptxdist go doesnt help either.. asin ptxdist says that theres nothing to be done for world. (==) Logfile: /var/log/Xorg.0.log, Time: Thu Oct 2 23:41:35 2008(==) Using config file: /etc/X11/xorg.conf(==) Using system config directory/usr/lib/X11/xorg.conf.dsh: /usr/bin/xkbcomp: not found(EE) Error compiling keymap (server-0)(EE) XKB: Couldn't compile Sounds like you need to install xkbcomp. keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be amissing or incorrect setup of x. Fatal server error: Failed to activate core devices.-doing a little more digging around i came across the xorg -configureoption.. this though gives me this little gem of knowledge.. root@mini2440:~ Xorg -configure X.Org X Server 1.9.3Release Date: 2010-12-13X Protocol Version 11, Revision 0Build Operating System:Linux- PtxdistCurrent Operating System: Linux mini2440 3.1.1-ptx-2011.11.0 #0 PREEMPT Fri NovlKernel command line: console=ttySAC0,115200 mini2440=6tbc ip=192.168.1.2:192.16)Build Date: 18 November 2011 11:37:52AM Current version of pixman: 0.21.2 Before reporting problems, check http://www.pengutronix.de/software/ptxl to make sure that you have the latest version.Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: /var/log/Xorg.0.log, Time: Thu Oct 2 23:53:52 2008List ofvideo drivers: dummy v4l fbdev No devices to configure. Configuration failed. ---i gues my device is fbdev.. but i'm stumped how i would be able to getit to configure the xorg.config file.[Wilson Wingston Sharon] -- Cheers, Dirk -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to include setxkbmap in Xorg.conf directly ?
On Sun, Jun 12, 2011 at 09:13:00AM +0800, Aaron Lewis wrote: Hi I put setxkbmap -option ctrl:nocaps,terminate:ctrl_alt_bksp in ~/.xinitrc and do startx each time i start my machine , However , when USB keyboard plugged in , keyboard options won't be set on it , i had to run that command again. Any solutions ? Many thanks for any of your responses. Hi, http://who-t.blogspot.com/2011/03/custom-input-device-configuration-in.html -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 09:33:43AM +0300, Dotan Cohen wrote:
On Mon, May 9, 2011 at 01:46, Marty Jack marty...@comcast.net wrote:
Look in /usr/share/X11/keysymdef.h at line 128 or thereabouts. If you
don't have that include file, install the X development headers. This will
help you find what the right spelling and capitalization are for anything
you are interested in. Keysyms are case sensitive, even though most things
in the keyboard definition are not case sensitive. I think Escape would
work if you had it spelled with a capital E.
Thanks! The keysymdef.h file is exactly what I had needed as a
reference. Before that I was scouring google looking for examples!
The setup for the modifier keys is in /usr/share/X11/xkb/symbols/pc at line
39 where it assigns the Shift meaning to Shift_L and Shift_R the left and
right shift keys. Shift_L and Shift_R are assigned to keycodes right above
there to be whatever the keycodes LFSH and RTSH are on your keyboard
model. The Caps Lock assignment is there as well.
This looks like an issue, as I need to change the modifier keys based
on keyboard layout. I tried to add a new section to ~/symbols/pc like
this, but either I am calling it wrong or I wrote it wrong:
partial modifier_keys
xkb_symbols noah {
key AE05 { [ escape ] };
key AB05 { [ backspace, caps_Lock ] };
key AB06 { [ Super_L, Super_R ] };
key LCTL { [ Control_L ] };
key LWIN { [ Alt_L ] };
key LALT { [ Shift_L] };
};
Then in ~/symbols/us I added new section which calls it like this:
partial alphanumeric_keys
xkb_symbols noah {
name[Group1]= USA - Noah Ergonomic;
include pc(noah)
key TLDE { [ 5, percent ] };
key AE01 { [ 4, dollar ] };
key AE02 { [ 3, numbersign ] };
...snip key definitions...
};
However, the modifier keys are not changing as I had intended. What
have I done wrong?
To change modifiers you have to edit the modifier_map entries, too.
They look something like this:
modifier_map Mod1 { LALT };
modifier_map Shift { LFSH };
modifier_map Control { LCTL };
modifier_map Lock { CAPS };
For example, replace the last line with:
modifier_map Lock { AB05 };
--
Cheers,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 11:42:37AM +0300, Dotan Cohen wrote:
On Mon, May 9, 2011 at 11:15, Dirk Wallenstein hals...@t-online.de wrote:
To change modifiers you have to edit the modifier_map entries, too.
They look something like this:
modifier_map Mod1 { LALT };
modifier_map Shift { LFSH };
modifier_map Control { LCTL };
modifier_map Lock { CAPS };
For example, replace the last line with:
modifier_map Lock { AB05 };
Thanks, Dirk. Is AB05 called a keycode? I will use that term for
purpose of discussion below, please tell me the correct term if it's
not!
It's a symbolic name and equals a keycode. They are assigned in the
keycode section, and everywhere else these symbolic names are used
instead of numbers.
I'm having a hard time figuring out what the keycodes of the bottom
keyboard row are. For instance, what is the keycode currently assigned
to L_Alt? Where would I find that? I need them for all the modifier
keys. I tried looking in the remaining files in ~/symbols but I can't
find that info.
As long as you are testing I would recommend working with a complete
keymap. You can save the current map in a file with:
xkbcomp $DISPLAY keymap.xkb
and load it after editing with:
xkbcomp keymap.xkb $DISPLAY
At the top of the file is the keycode section where symbolic names are
assigned to keycodes. You can easily exchange keys there.
Find out keycodes by executing 'xev' and translate them to symbolic
names to find the configuration for it. For example:
key AB06 { [ Super_L, Super_R ] };
key LCTL { [ Control_L ] };
key AB05 { [ 5 ] };
Inside the brackets are keysyms. They can be translated to strings,
like '5' in the case of the keysym XK_5, or they are tied to vmods like
in the case of Super_L. A modifier_map entry would connect such a vmod
to a real modifier and thereby activate it.
--
Cheers,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 02:56:03PM +0300, Dotan Cohen wrote:
I seem to have a problem with the modifier keys affecting other
layouts. For instance, in ~/symbols/pc I have added these lines to the
bottom:
partial modifier_keys
xkb_symbols noah {
modifier_map Lock { AB05 };
};
However, now the B key is Caps Lock in the standard US keyboard layout
as well! How can I restrict this change only to the Noah variant?
Would I be better off making Noah not a variant of US but rather it's
own separate layout?
Do you include the noah symbols from somewhere else?
Isn't it simply this?:
xkb_symbols noah {
include us
modifier_map Lock { AB05 };
};
--
Cheers,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 05:56:42PM +0300, Dotan Cohen wrote:
On Mon, May 9, 2011 at 17:26, Dirk Wallenstein hals...@t-online.de wrote:
On Mon, May 09, 2011 at 02:56:03PM +0300, Dotan Cohen wrote:
I seem to have a problem with the modifier keys affecting other
layouts. For instance, in ~/symbols/pc I have added these lines to the
bottom:
partial modifier_keys
xkb_symbols noah {
modifier_map Lock { AB05 };
};
However, now the B key is Caps Lock in the standard US keyboard layout
as well! How can I restrict this change only to the Noah variant?
Would I be better off making Noah not a variant of US but rather it's
own separate layout?
Do you include the noah symbols from somewhere else?
Isn't it simply this?:
xkb_symbols noah {
include us
modifier_map Lock { AB05 };
};
I'm sorry, I'm not sure that I follow you. From where else should I
have included the noah symbols? This is what I have done (the
unshown parts of the files have not been touched):
✈demios:~$ tail /usr/share/X11/xkb/symbols/us -n 68
xkb_symbols noah {
name[Group1]= USA - Noah Ergonomic;
include pc(noah)
key TLDE { [ 5, percent ] };
key AE01 { [ 4, dollar ] };
key AE02 { [ 3, numbersign ] };
key AE03 { [ 2, at ] };
key AE04 { [ 1, exclam ] };
key AE05 { [ Escape ] };
key AE06 { [ grave, asciitilde ] };
key AE07 { [ minus, underscore ] };
key AE08 { [ equal, plus] };
key AE09 { [ 6, asciicircum ] };
key AE10 { [ 7, ampersand ] };
key AE11 { [ 8, asterisk] };
key AE12 { [ 9, parenleft ] };
key BKSP { [ 0, parenright ] };
key TAB { [ q, Q ] };
key AD01 { [ w, W ] };
key AD02 { [ e, E ] };
key AD03 { [ r, R ] };
key AD04 { [ t, T ] };
key AD05 { [ Tab, Tab ] };
key AD06 { [ bracketleft, braceleft ] };
key AD07 { [ bracketright, braceright ] };
key AD08 { [ y, Y ] };
key AD09 { [ u, U ] };
key AD10 { [ i, I ] };
key AD11 { [ o, O ] };
key AD12 { [ p, P ] };
key BKSL { [ slash, question] };
key CAPS { [ a, A ] };
key AC01 { [ s, S ] };
key AC02 { [ d, D ] };
key AC03 { [ f, F ] };
key AC04 { [ g, G ] };
key AC05 { [ Return ] };
key AC06 { [ apostrophe,quotedbl] };
key AC07 { [ Return ] };
key AC08 { [ h, H ] };
key AC09 { [ j, J ] };
key AC10 { [ k, K ] };
key AC11 { [ l, L ] };
key RTRN { [ semicolon, colon ] };
key LFSH { [ z, Z ] };
key AB01 { [ x, X ] };
key AB02 { [ c, C ] };
key AB03 { [ v, V ] };
key AB04 { [ b, B ] };
key AB05 { [ Backspace, Caps_Lock ] };
key AB06 { [ Super_L, Super_R ] };//test these
key AB07 { [ backslash, bar ] };
key AB08 { [ n, N ] };
key AB09 { [ m, M ] };
key AB10 { [ comma, less] };
key RTSH { [ period,greater ] };
key LCTL { [ Control_L ] };
key LWIN { [ Alt_L ] };
key LALT { [ Shift_L] };
key SPCE { [ space ] };
key RALT { [ Shift_R] };
key RWIN { [ Alt_R ] };//test this
key RCTL { [ Control_R ] };
};
✈demios:~$
✈demios:~$ tail /usr/share/X11/xkb/symbols/pc -n 4
partial modifier_keys
xkb_symbols noah {
modifier_map Lock { AB05 };
};
✈demios:~$
I have some holes concerning how a final keymap gets assembled, I'm
afraid. Are you aware of the registration in the *.dir files and such?
Maybe add hints to the us additions:
partial alphanumeric_keys modifier_keys
If that doesn't help I would recommend the xkeyboard-config mailing
list:
http://listserv.bat.ru/xkb/List.html
--
Cheers,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 06:28:25PM +0300, Dotan Cohen wrote: On Mon, May 9, 2011 at 18:19, Dirk Wallenstein hals...@t-online.de wrote: I have some holes concerning how a final keymap gets assembled, I'm afraid. Are you aware of the registration in the *.dir files and such? Maybe add hints to the us additions: partial alphanumeric_keys modifier_keys Thanks, I'm not aware of the registration files but this project is the first that I've ever played with custom keyboard layouts. I'll google it and see what I can come up with. Should've said this a long time ago: http://www.x.org/wiki/XKB -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Changing non-printing keys in keyboard layout
On Mon, May 09, 2011 at 05:36:41PM +0200, Dirk Wallenstein wrote: On Mon, May 09, 2011 at 06:28:25PM +0300, Dotan Cohen wrote: On Mon, May 9, 2011 at 18:19, Dirk Wallenstein hals...@t-online.de wrote: I have some holes concerning how a final keymap gets assembled, I'm afraid. Are you aware of the registration in the *.dir files and such? Maybe add hints to the us additions: partial alphanumeric_keys modifier_keys Thanks, I'm not aware of the registration files but this project is the first that I've ever played with custom keyboard layouts. I'll google it and see what I can come up with. Should've said this a long time ago: http://www.x.org/wiki/XKB Note also that it is possible to install whole keymap in the 'keymap' subdirectory of the xkb config. Maybe that's an option, too. -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Keymapping hal/fdi
On Sun, Apr 24, 2011 at 10:48:02AM +0100, David Woodfall wrote: On (02:25 24/04/11), David Woodfall d...@dawoodfall.net put forth the proposition: Hi, I've have a usr9600 usb phone, which is an extra keyboard. I have setup a 20-phone.fdi for it and set layout etc. Now I'm trying to map keys 1-0 to keypad 1-0 but I'm having problems with that. lshal shows the mapping but it looks like the hex codes are the wrong ones. I got the codes with xev. This is the mapping section: append key=input.keymap.data type=strlist0030:KP0/append ... append key=input.keymap.data type=strlist0039:KP9/append Is xev the right tool to get these codes? Any ideas why this isn't working? Cheers Dave -- Don't look back, the lemmings are gaining on you. Not having any luck with this so I tried the old xorg.conf way: Section InputDevice Identifier Keyboard1 Driver evdev Option XkbModel pc105 Option Device /dev/input/by-id/usb-Yealink_Network_Technology_Ltd. _VOIP_USB_Phone-event-if03 Option event_key_remap 10=87, 11=88, 12=89, 13=83, 14=84, 15=85,16=79, 17=80, 18=81, 19=90 Option XkbLayout us Option XkbRules xorg EndSection This also doesn't work. I got the event_key_remap option by googling. I couldn't really find anything else on this. It's a pit xmodmap doesn't support multiple devices. xkbcomp can since 1.2.1, and switching keys is easy: Get the keymap: xkbcomp -i deviceid $DISPLAY keymap.xkb Edit keymap.xkb: Exchange the keycodes at the top. For example switch: KP3 = 89; AE03 = 12; Install the keymap: xkbcomp -i deviceid keymap.xkb $DISPLAY -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Dvorak-Qwerty Keyborad Layout
On Sun, Apr 10, 2011 at 12:15:56PM +0200, Thomas Berger wrote: Hi, I'm using the US Dvorak keyboard layout with X.Org X Server 1.9.0. The problem I have is that control-key and alt-key keys are also mapped, so that ctrl-c becomes ctrl-i, etc. Is there a way to have the Dvorak keyboard layout, but if one presses control or alt it uses the Qwerty keyboard layout? This layout is available by default on Mac OSX. The reasons for such a layout is that the common copy/paste hotkeys X, C, and V remain on the left hand, and so can be used while the right hand is on the mouse. Regarding this issue I found the following workarounds, which did not work as expected: [1]http://ubuntuforums.org/showthread.php?t=774773 [2]http://code.google.com/p/dvorak-qwerty/ [3]http://forums.gentoo.org/viewtopic-p-4660238.html?sid=e2605ed35a9188 210eeb03f07d615279 Can such a Dvorak-Qwerty layout be implement/configured in xorg? No, that can't be done with an XKB configuration. The solution would be that shortcuts on the client side could be defined in terms of keys and not keysyms. For example in KDE there is the system-settings dialog Standard Keyboard Shortcuts -- so there appears to be desktop wide abstraction for it. If it would be possible to to assign a shortcut to a key and not the keysym (eg 'c' for crtl-c) it would be possible to have those shortcuts independent of which layout you use. -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xkb: how to map symbol Meta to key Alt
On Mon, Mar 21, 2011 at 03:41:50PM +0100, Maciej Pilichowski wrote: On Monday 21 March 2011 09:51:12 Dirk Wallenstein wrote: Thank you for your response. Btw. I am subscriber, no need to CC. Hm, I hope I did understand correctly. You want to use the Alt key to generate characters and not use any of the desktop functionality tied to it. That's right. If clients interpret Alt and Meta alike, you have to use another way. It didn't happen in years. Do you have a national layout available that produces all the chars you want with ISO_Level3_Shift (aka AltGr)? With ISO_Level3_Shift, yes. With AltGr -- no. This is the whole point, to get rid of it. If so you can simply put that modifier onto the Alt key. I am exactly asking for this -- how to do it? The approach in your initial mail was right -- edit the keysym table of the key and add a modifier_map entry. The only thing that confuses me is that you want to have Meta instead of ISO_Level3_Shift there. Note that Alt/Meta and AltGr/ISO_Level3_Shift are two different concepts. If you start xev and press the key on the right side, what is displayed as keysym? If it shows ISO_Level3_Shift please try it with that keysym. Three remarks: a) I would prefer modify keycode table file (previously xfree86) because this way, all layouts would see alt-key as meta. You can only exchange keys there, not copy a configuration to another key. b) the reason for my odd request is this: being forced to press right Alt-key only to get national characters is so weird for me, that I decided to use both Alt-keys to produce those characters. But Alt (symbol) is hardcoded in X11 to get accelerators. Because of that I have to move that symbol somewhere else. The perfect place is CapsLock. So now, I would have Alt-symbol on CapsLock-key, and Meta-symbol on both Alt-keys. So I would have symmetric keyboard, 100% functionality and much more productive layout, I used it for years, and it proved its quality. No wonder, I would like to still use it in openSUSE 11.4. I think what you want does exist as a setxkbmap option. If you use one of the major desktops please try to configure it there. In KDE for example, I guess it's: systemsettings - hardware - Input - Keyboard - Advanced Key to choose third level : Any Alt c) I learned how to make a dump of the layout to take a peek how X11 sees my layout. Both Alt-key entries were divided for Group1 and Group2. Group1 looks like from X11 original symbol file (pc) and Group2 is coming from me. So it looks like I am only able to add symbols, not redefine keys -- despite they fact I used replace keyword in definition. But if I could alter keycodes (see (a)), this would solve this problem. Kind regards, -- Cheers, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xkb: how to map symbol Meta to key Alt
On Sat, Mar 19, 2011 at 10:46:37PM +0100, Maciej Pilichowski wrote:
Hello,
How to map symbol Meta to key Alt?
My previous mappings:
-
In opensuse 11.1 I simply edited xfree86 keycodes files, and put for
keycodes AltL/AltR scancodes MetaL/MetaR. It worked without any
problems with X11.
Now:
I have opensuse 11.4 and editing xfree86 simply does not work (it is
completely strange for me, because this file is mentioned in the
config files). I put the same table as for 11.1 and Alt was still
Alt.
So I tried to edit symbols file, but no matter what I try, no success.
In all cases, xev reports (when pressing Alt) that Meta key was
pressed, however X11 still recognizes Alt as Alt -- for example when
running Firefox, I press Alt+F and File menu opens, or I press
Alt+Tab, and I get windows list.
Since I have my entire layout defined for national characters as
Meta+key, I can also check if I get national characters (óąłäö,
etc.) -- I don't get them.
Hm, I hope I did understand correctly. You want to use the Alt key to
generate characters and not use any of the desktop functionality tied to
it. If clients interpret Alt and Meta alike, you have to use another
way. Do you have a national layout available that produces all the chars
you want with ISO_Level3_Shift (aka AltGr)? If so you can simply put that
modifier onto the Alt key.
My tries:
key LALT { [ Meta_L ] }; // (*)
modifier_map Mod3 { LALT, RALT };
or
key LALT { [ Meta_L, Meta_L ] };
modifier_map Mod3 { LALT, RALT };
or
key LALT { type[Group1] = ONE_LEVEL,
symbols[Group1] = [ Meta_L ] };
modifier_map Mod3 { LALT, RALT };
I also tried to add replace before key, over and over same results
(as you can see, I am/was pretty despair ;-) ).
So how to do it with xkb? I could do it with xmodmap, but I prefer
xkb -- after switching layout xmodmap is killed.
Thank you in advance for help.
Kind regards,
(*) the entries are doubled, for right Meta/Alt.
--
Cheers,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: local xkb layouts
On Wed, Jan 05, 2011 at 06:25:46PM +0100, Stefan Witzel wrote:
Am 05.01.2011 16:32, schrieb Dirk Wallenstein:
On Wed, Jan 05, 2011 at 02:41:16PM +0100, Stefan Witzel wrote:
is it possible to extend the system-wide xkb layout database by
user-specific files. And if not: why is that?
I ran into this problem because I want a german
deadgraveacutecircum-layout in which grave acute and circumflex are
dead but tilde is not. But on systems where I am not administrator I
cannot install this. And even on systems where I am administrator I
would have to renew my changes after every upgrade.
Would the right way to do it be to use the standard layout (with dead
tilde) and then use a .Xmodmap? Every time I tried that I got strange
effects when switching between multiple xkb layouts.
Thanks in advance for any help!
If you know how to edit XKB keymaps and only need one specific
keymap for yourself, I would suggest to simply load the wanted keymap
with xkbcomp at startup. I do that in the KDE autostart folder.
This sounds like a good idea but apparently I got something wrong. I
created a file my_keymap which looks as follows:
xkb_keymap de {
xkb_keycodes{ include xfree86 };
xkb_types { include default };
xkb_compatibility { include default };
xkb_symbols
{
include pc(pc105)+de(basic)
name[Group1]=Germany - Dead grave acute circumfex;
key AD12 { [ plus, asterisk, asciitilde,
dead_macron ] };
key BKSL { [numbersign, apostrophe,grave,
grave ] };
};
xkb_geometry{ include pc(pc102) };
};
When I now do xkbcomp my_keymap :0.0 the X server crashes. I also
tried to put the symbols in a separate symbols file (so as to add them
to the existing symbols rather than replacing those), but I could not
get him to find that file. I admit that I do not really understand the
entire mechanism but I didn't find much documentation of it either.
Oh, sorry for my brevity. The easiest way to tweak a keymap is to get
the full keymap, tweak it, and load it again.
$ xkbcomp $DISPLAY my-keymap.xkb
... edit my-keymap.xkb
$ xkbcomp my-keymap.xkb $DISPLAY
Docs are here:
http://www.x.org/wiki/XKB
There is a tabular display of key-types here:
http://sourceforge.net/tracker/download.php?group_id=286545atid=1214224file_id=361450aid=2945171
--
Greetings,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: local xkb layouts
On Wed, Jan 05, 2011 at 02:41:16PM +0100, Stefan Witzel wrote: Hello, is it possible to extend the system-wide xkb layout database by user-specific files. And if not: why is that? I ran into this problem because I want a german deadgraveacutecircum-layout in which grave acute and circumflex are dead but tilde is not. But on systems where I am not administrator I cannot install this. And even on systems where I am administrator I would have to renew my changes after every upgrade. Would the right way to do it be to use the standard layout (with dead tilde) and then use a .Xmodmap? Every time I tried that I got strange effects when switching between multiple xkb layouts. Thanks in advance for any help! If you know how to edit XKB keymaps and only need one specific keymap for yourself, I would suggest to simply load the wanted keymap with xkbcomp at startup. I do that in the KDE autostart folder. -- Greetings, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] x-jhbuild 0.3
X-JHBuild-0.3 # X-JHBuild is a framework for building and working with X.org modules. It makes use of JHBuild and is specialized for working with modules that use Git as VCS. http://sourceforge.net/projects/x-jhbuild/ http://www.x.org/wiki/XjhBuild Navigation Convenience: === The navigation function has now support for command line completion, and can clone a repository when it does not exist. It is possible to configure aliases for modules, but only the navigation function knows about them currently. Configuration Convenience: == Forks, Clones, Personal Trees: -- It is now possible to select a fork of a main module by means of a simple configuration option. For example to use ~vignatti/xorg-server in the place of xorg-server, all that is required is this configuration snippet: [module.xorg-server] fork = vignatti/xorg-server There is always only one repository of one kind (xorg-server in this example) in the set of active modules. All distributed subcommands, with a few exceptions, act only on the active modules, in terms of the main module id. The advantage is that you can use the main module-ids everywhere and just inject a different repository by making a small change to the configuration. Aware of forks are the navigation function, and the status plug-in when used with the new option '--forks'. There is the fork management plug-in 'fork-man' which can display information about forks in a way similar to 'modinfo', as well as download inactive modules. You can, for example, easily iterate over all paths of inactive, checked-out repositories. There is now a moduleset (xjh-forks.modules) with a large set of fork definitions. This is the default moduleset now. New Configuration Options: -- There are new configuration options that allow to make modifications to the dependencies of a module, specify tags, and pick only some of the modules to work with (like a reverse skip setting). The need to edit a moduleset has been largely reduced by this. For example the xkbcommon.modules moduleset is now obsolete and the same can be accomplished with this configuration section: [module.xorg-server] fork = krh/xorg-server branch = xkbcommon deps-add = libxkbcommon Likewise the wayland.modules moduleset is obsolete and can be replaced by this configuration: [buildconfig] modules = wayland modules-filter = kbproto dri2proto libxkbcommon libdrm mesa cairo wayland [module.cairo] autogenargs = --enable-gl [module.mesa] autogenargs = --enable-gl --enable-gles2 The moduleset repository at [1] contains further example configurations. To have module specific configuration in one section and not spread out across diverse subsections of 'buildconfig', there is the new top-level configuration section 'module' which is a container for subsections that apply to one particular module each. The buildconfig subsections that apply to commit selection and module specific build configuration moved into this section and the old sections have been deprecated. The affected sections are branches, module-[c]makeargs, and module-autogenargs, as well as the augmentation versions of those sections. Benefits: - Overall these changes will make overriding a module in a moduleset a rare exception. Fork and revision selection, as well as build configuration can now exclusively be done in the configuration without burying it in a swath of dependency graph descriptions. Modulesets can now be a stable and persistent description of repositories. In particular, hiding checked out repositories when combining modulesets should never be necessary. Smaller Changes: - It is now possible to recognize unspecified options in a multi-type configuration section. This is useful if every specified value overrides a default that is determined by other means. There is the special string representation 'unspecified' for such cases. - The patched JHBuild that is being used here, has its own repository now [2] and is referenced by a new submodule. - There can be configuration templates in the directory '~/.x-jhbuild/config-templates' that will be used as repository configuration when specified as argument to the '-c' option of 'init'. - Configuration files in the token and template directories can have an optional '.xjhrc' suffix. Dirk Wallenstein (20): init: Add support for configuration templates repogroup: Abstract handling of xjh-dir file locations Remove patch that modifies JHBuild defaults JHBuild update moduletraits: Fix cmake trait generation configsection: Recognize unspecified options in multi-type sections prompt: Extract function that finds the repogroup root repogroup: Move filename definitions into repogroup.py cwdmodule: make get_cwd_repo_root_dir() public gitaccess
Re: Easy way to bisect xorg-xserver?
On Wed, Jul 07, 2010 at 04:23:22PM +0200, Clemens Eisserer wrote: Hi, I would like to do some bisecting to find a regression that was introduced somewhere between 1.6 and 1.7. I tried but for me as a non-developer its quite hard to get the right versions of the right libraries, and I gave up after a few hours. Is there a script which can download and build the appropriate libraries requiered for a certain version of the x-server? JHBuild has a sticky_date option, by which you can skip back to a previous point in time across several modules. It is possible to pass that switch to the 'build' subcommand [1]. [1] http://library.gnome.org/devel/jhbuild/2.30/command-reference.html.en#command-reference-build -- Greetings, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How can I add a custom xkb layout
On Mon, Jul 05, 2010 at 11:13:29PM +0400, czark...@gmail.com wrote:
Hello!
I'm using X.Org X Server 1.6.5. I tried to add a custom XKB layout for serbian
on US keyboard. So, I've added the following to /etc/X11/xkb/symbols/us:
// Serbian charecters added as third level symbols to US keyboard layout.
partial alphanumeric_keys
xkb_symbols serbian {
name[Group1]= USA - Serbian;
include us(basic)
include level3(ralt_switch)
key TLDE { [ grave, asciitilde ] };
key AE06 { [ 6, dead_caron, asciicircum, asciicircum ] };
key AC09 { [ l, L, U1C9, U1C8 ] };
key AB06 { [ n, N, U1CC, U1CB ] };
key AB01 { [ z, Z, U1C6, U1C5 ] };
key AD03 { [ e, E, EuroSign, cent ] };
key AC03 { [ d, D, dstroke, Dstroke ] };
key AC11 { [ dead_acute, quotedbl, apostrophe, U315 ] };
key SPCE { [ space, space, nobreakspace, nobreakspace ] };
};
At the same time I've added following to the /etc/X11/xkb/rules/xorg.lst:
serbian us: Serbian on US keyboard
And to the /etc/X11/xkb/rules/xorg.xml (to the us layout):
variant
configItem
nameserbian/name
descriptionUS keyboard with Serbian support/description
/configItem
/variant
After restarting X I've got:
% setxkbmap -layout us -variant serbian -v 10
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Warning! Multiple definitions of layout variant
Using command line, ignoring X server
Applied rules from xorg:
model: pc105
layout: us
variant:serbian
options:grp:caps_toggle
Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete+ledcaps(group_lock)
symbols:pc/pc(pc105)+pc/us(serbian)+group(caps_toggle)+group(caps_toggle)
geometry: pc(pc105)
Error loading new keyboard description
I'm sure I've done something wrong, but I can't get what exactly. Anyone
knows?
I reproduced your steps and it works.
The translation to the symbols component is flawed. An xkeyboard-config
update could fix that.
--
Greetings,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Emulating a one-handed keyboard?
On Thu, May 27, 2010 at 04:41:00PM +0200, Florian Echtler wrote: Hello everyone, I came across this demo for a mirrored keyboard layout today: http://www.half-qwerty.com/demo/ Would it be possible to create something like this as an X keymap? I suppose the difficult part would be to use a different keymap when space is held down... The only thing currently not possible is to use space to both switch the layout and to produce a space character. That is related to canceling actions and something that certainly would appear in XKB2. If you are willing to type a space with another key, than that is possible now already. For a test, just switch AltGr and the spacebar. -- Greetings, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Emulating a one-handed keyboard?
On Fri, May 28, 2010 at 07:50:22PM +1000, Peter Hutterer wrote: On Fri, May 28, 2010 at 09:23:56AM +0200, Dirk Wallenstein wrote: On Thu, May 27, 2010 at 04:41:00PM +0200, Florian Echtler wrote: Hello everyone, I came across this demo for a mirrored keyboard layout today: http://www.half-qwerty.com/demo/ Would it be possible to create something like this as an X keymap? I suppose the difficult part would be to use a different keymap when space is held down... The only thing currently not possible is to use space to both switch the layout and to produce a space character. That is related to canceling actions and something that certainly would appear in XKB2. I've heard Godot has an implementation of XKB2 ;) Waiting for announcement ;) -- Greetings, Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: C++/Shell Integration
On Sat, May 15, 2010 at 11:41:45PM +0100, Mubarak Aguye wrote: Hi. I was wondering if there is a way of determining the title of the current active window, and its x-y coordinates from within a C++ application, or even a standard Linux shell. For the shell, you could use 'xwininfo'. For C++, you would use XWindowAttributes and Properties. http://www.x.org/docs/X11/xlib.pdf (Chapter 3) http://tronche.com/gui/x/xlib/window-information/ -- Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compose with numeric keypad
On Thu, May 13, 2010 at 09:36:39AM +0200, Andre Majorel wrote: [...] Thank you. All the documentation I found focussed on using an existing input method. Anything on *creating* an input method ? SCIM is very popular and also a development platform for Input Methods. I guess that would be a starting point. http://www.scim-im.org/ -- Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xkb] Map alt+key to arrow
On Mon, May 10, 2010 at 02:11:53AM +0200, Damien R. wrote:
On 05/07/2010 10:37 AM, Dirk Wallenstein wrote:
If you run 'xev' with that keymap installed, do you have
(keysym 0xff51, Left)
in the output when you press alt+key?
Yes, it got it.
And if you try it in a terminal you get the same strange output as if
you press directly Alt+Left?
Exactly, it got the same output (in my case D).
The Alt modifier is heavily used on the client side (menus and such) and
clients seem to often track it themselves, so they don't recognize that
the alt modifier has been 'consumed' in the lookup. It's hard for
clients because alt is a vmod.
Do you mean that clients does not query X to know the status of alt
modifier ? If so, how they check it ?
Some look out for Alt keysyms.
Now, if I do :
key AD08 { type[Group1] = PC_ALT_LEVEL2, [ d, Left ],
actions[Group1] = [ NoAction(), RedirectKey(key=LEFT,
clearmods=Alt)] };
should it work or will client still track alt ?
No. You would have to release the Alt modifier key before the Left
keysym reaches a client.
When I try that, alt+d or d+alt restart the X server.
Maybe, I misunderstand how X and clients work, so
can you give some links or explain ?
http://www.x.org/wiki/XKB
http://en.wikipedia.org/wiki/X_Window_System
http://www.x.org/docs/
I would avoid advanced mappings involving Alt, currently.
It works with AltGr. You can put AltGr on both sides of the space bar if
you have enough keys.
I cannot use AltGr because my keyboard layout uses it to map useful keys.
Thanks,
--
Damien R.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
--
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compose with numeric keypad
On Sat, May 08, 2010 at 08:18:00AM +0200, Andre Majorel wrote: Is there a way to get X to let me compose keystrokes with the numeric keypad ? Preferably not a DOS-type alt-(digit [digit [digit]]) system. More like every sequence of two physical keystrokes producing one logical keystroke. Something that can be used with one hand efficiently. You can do that with input methods. http://en.wikipedia.org/wiki/Input_method Chapter 13 of http://www.x.org/docs/X11/xlib.pdf -- Dirk ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xkb] Map alt+key to arrow
On Thu, May 06, 2010 at 10:54:36PM +0200, Damien R wrote:
Hi,
I want to map alt+key to arrow keys.
For eg, I want to press Alt+d and it will do Left.
I tried :
key AD08 { type[Group1] = PC_ALT_LEVEL2, [ d, Left] };
but it does not work.
How can I do that or can you give me links to doc ?
Thanks,
--
Damien R.
If you run 'xev' with that keymap installed, do you have
(keysym 0xff51, Left)
in the output when you press alt+key?
And if you try it in a terminal you get the same strange output as if
you press directly Alt+Left?
The Alt modifier is heavily used on the client side (menus and such) and
clients seem to often track it themselves, so they don't recognize that
the alt modifier has been 'consumed' in the lookup. It's hard for
clients because alt is a vmod.
I would avoid advanced mappings involving Alt, currently.
It works with AltGr. You can put AltGr on both sides of the space bar if
you have enough keys.
Greetings,
Dirk
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] man: Redirect users from XKeycodeToKeysym to XkbKeycodeToKeysym #25732
XKeycodeToKeysym keeps compatibility with pre-XKB and thus only sees 2 groups with 2 levels each. It wraps the index into the next group. This behavior confuses the unaware user, and therefore this will add a reference to XkbKeycodeToKeysym in the corresponding man paragraph. Another bug had that issue, too. #5349 Signed-off-by: Dirk Wallenstein dirkwallenst...@t-online.de --- man/XStringToKeysym.man |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/man/XStringToKeysym.man b/man/XStringToKeysym.man index 62212db..067765b 100644 --- a/man/XStringToKeysym.man +++ b/man/XStringToKeysym.man @@ -202,6 +202,10 @@ If no symbol is defined, .ZN XKeycodeToKeysym returns .ZN NoSymbol . +.ZN XKeycodeToKeysym +predates the XKB extension. If you want to lookup a KeySym while +using XKB you have to use +.ZN XkbKeycodeToKeysym . .LP If the specified KeySym is not defined for any KeyCode, .ZN XKeysymToKeycode -- 1.6.5.3 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] man: Redirect users from XKeycodeToKeysym to XkbKeycodeToKeysym #25732
This is the duplicate I meant in the other thread. Please ignore this. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
My plans for Duttulm and XKB. I intent to make the next announcement for Duttulm-0.8 unless you are interested in the intermediate versions. There is now a git repository. http://duttulm.git.sourceforge.net/git/gitweb.cgi?p=duttulm/duttulm;a=summary git://duttulm.git.sourceforge.net/gitroot/duttulm/duttulm I will make more use of other sourceforge features (e.g. news for major and minor versions), and I can enable more features if requested (e.g. mailing lists). Duttulm Release Plan 0.2 Completion of the data model for XKB data in Duttulm. 0.[3-8] Completion of each of approximately half a dozen Tweakers (key-type, level-entry-assignment, browser, ...) I will switch programming to the XKB specific parts of the Xserver. 0.9 XKB-Description setting request emittance implementation to actually change keymaps and use Duttulm as a testing device. 1.0 It works. 1.* Add specialized Tweakers. For example Tweakers that facilitate configuration of remote controls. Duttulm-0.1.2 Release Notes === Among bug fixes and source code embellishments this release unlocks the QSP support (sorry for advertising something that is locked, in the previous release notes). Tests are added for two supported pointer types (QSharedPointer and QPointer), in which the parenthood outside of the XML mechanism is verified. There is a demonstration on how to use flags as properties (to get XML attributes like colors=red|blue|magenta), and it is shown how multiple XML-adaption can occur in a single object hierarchy. http://p.sf.net/duttulm/Release-Notes http://p.sf.net/duttulm/Current-Release http://p.sf.net/duttulm/Duttulm-Intro Greetings, Dirk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
On Mon, 07 Dec 2009 20:27:59 +0100 Bernd Steinhauser wrote: Hi, Dirk Wallenstein wrote: I would like to give some examples of what a fully functional and configurable XKB extension could offer. 1.Obviate the need to leave the home row for functionality that is provided by keys right of the main keyboard - - By taking a common pc-105 keyboard and holding down the AltGr/ISO-Level3-Shift modifier , all the alphabetic keys can be equipped with functionality like cursor-cross, insert, delete, home, etc. With the help of XKB's Redirect-Key-Action it would even be possible to have word-wise cursor movement in all text edit fields. All without leaving the home row. Just in case you don't know about it yet, you might want to have a look at Neo: http://www.neo-layout.org It implements some of the things you mentioned. Regards, Bernd Wonderful. In particular Level-4 (Ebene-4) tries to obviate the keys right of the main keyboard. That is certainly a level of interest to a wider audience, I think. Greetings, Dirk. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
I have improved the load/save mechanism of Duttulm in version 0.1.1. It is now possible to have built-in pointer, QPointer, and QSharedPointer to XmlAbleContainerElement as elements in an XML container. Additionally it is possible to have user-defined unsigned int wrappers as container keys, without any inheritance requirement. I have appended a small section regarding that to the introduction and there are release notes. ReleaseNotes : http://sourceforge.net/projects/duttulm/files/Duttulm/0.1.1/duttulm-0.1.1.release.notes.txt/view Version 0.1.1 : http://sourceforge.net/projects/duttulm/files/Duttulm/0.1.1/duttulm-0.1.1.tar.bz2/download Intro 0.1.1 : http://sourceforge.net/projects/duttulm/files/Duttulm/0.1.1/Duttulm.Introduction.0.1.1.pdf/download Greetings, Dirk. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On Sunday 22 November 2009 23:35:29 walt wrote:
I've mapped my CapsLock key to a plain Shift_L key, using your instructions.
Here is the output of xev (note the keycode is 66):
KeyPress event, serial 30, synthetic NO, window 0x201,
root 0x189, subw 0x0, time 35504647, (136,79), root:(140,822),
state 0x0, keycode 66 (keysym 0xffe1, Shift_L), same_screen YES,
XKeysymToKeycode returns keycode: 50
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
That part is wonderful, but pressing the Caps Lock key doesn't create upper
case letters, but pressing the Shift key does.
Here is the line that I changed in the .xkb file:
key CAPS { [ Shift_L ] };
What have I missed?
For modifiers, you have to change the modifier_map entry.
Currently, it will look like this:
modifier_map Lock { CAPS };
Change it to:
modifier_map Shift { CAPS };
If you want to reuse the shift key for other things, you might want to
change or remove the modifier_map entry for your shift key - which
probably looks like:
modifier_map Shift { LFSH };
Greetings, Dirk.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
On Friday 20 November 2009 00:06:47 Peter Hutterer wrote: On Wed, Nov 18, 2009 at 01:26:10PM +0100, Dirk Wallenstein wrote: But honestly, I think it would be a real improvement if users could define their own keymaps with the full range of tools that XKB provides. I skipped the other parts, because your last sentence sums it up perfectly: we need better configuration tools. XKB from a users POV suffers more from the lack of configuration tools, less so from the protoco/implementation. For what you seem to be proposing in this thread, the focus should thus be on the client application to enable flexible (and persistent) custom configuration. Think of an XKB-aware xmodmap, that will be the core of it. I don't think a command-line tool can in any form reasonably and intuitively accomplish that, with all the key types and actions. That's why I wrote Duttulm (http://sourceforge.net/projects/duttulm/). It already has some very important features. It is possible to edit an interactive visual representation of a button device, by which it will be possible to depict information about a keymap in form of key colors (key-type dissemination, behaviors, action types). Also, loading and saving to/from an XML representation is completely abstracted. The current state is described in this pdf: http://sourceforge.net/projects/duttulm/files/Duttulm/0.1/Duttulm.Introduction.pdf/download From now on development can focus on XKB keymap specific parts. I have already put much thought into how to organize the data and how to isolate the effects of possible changes to XKB. Once that application is working, we can re-visit and see what actual deficiencies are in the protocol/implementation. I still think you can can get about 80-90% there without having to touch XKB (the protocol) itself. Yes, I thought about providing the hundred or so default actions as a selection of non-editable actions. The result would be the set of actions available through xmodmap currently, plus configurable key-types and behavior. This would be a perfect moment to re-visit protocol/implementation. I think at that stage it could also serve as a basis for an open discussion about what should or shouldn't be possible. Greetings, Dirk. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
On Wednesday 18 November 2009 04:31:48 Peter Hutterer wrote: much of what you propose is already there. Yes, absolutely. The examples were not so much about lacking functionality but about what should be made available to users more easily. And they are just very rigid examples to outline the potential without going into details about level lookup and such. The messages of mine in this thread actually cover two topics: - reworking parts of XKB to unlock its full potential - making the current or the full potential available to the common user. Reworking parts of XKB - The main topic, besides the client interaction ideas I stated in another message, are XkbActions. There are some real nice things possible with actions and some of them are not accessible. Some of these things, you might be able to do by means of a xkeyboard-config keymap, but even those would be so much easier to apply when using direct configuration. I'm talking about enabling a user to apply user-specific changes, and not about providing millions of people with keymaps. For example the redirect-key-action. Many widget toolkits support char-wise or word-wise selection and movement through a combination of Shift/Control and Left/Right. These could be made accessible on the main keyboard (say through AltGr-U) by simply filling in a XkbRedirectKeyAction structure and putting it on the corresponding level. Actions can't be simply unlocked, though. There are some things that should be improved, mainly in xkbAction.c. For example, the tracking/filtering mechanism could be improved. What happens if single actions are changed? Should that even be possible? Or should a change to an action (or maybe any level) set the device into the default state. Some handlers could be improved and the sync of the keysym and action table could be watched more closely (if not merged because of the memory footprint). Making XKB's potential available to the user Even such things as changing the key type of a key are not that easy to accomplish, without editing keymaps by hand. Not to mention creating your own keytype and accessing it. 2.Shortcuts abound -- Press one key and let the whole keyboard produce keysyms that are not recognized by any application, so that you can be sure, not to interact with the currently active application in an unwanted manner. This now inactive keyboard could be set up, to exclusively interact with the desktop environment. what is the common use-case for this? it seems a bit like a hack around applications that misbehave. also, what client would be the desktop environment? I wanted to say that, if you hold that key you can be sure no key event _reaches_ the application. The client would be the window manager as a switch for key events. what would be the difference to having an additional group that triggers only those shortcut keysyms (XF86Back, XF86Forward, XF86Whatnot)? None. The point of this example together with the example 3 is that I would like to make the functionalities the window managers offer easily available, say, to the 10 fingered office worker. shortcuts for switching applications and desktops is just one example. I, for example, have a usual western keyboard with this huge space-bar and the lack of modifiers at the tips of my pointing fingers. Now, with the need for Shift, Control, Alt and AltGr on each side of the space bar there's no space left for a group switch and so I have all sorts of two-modifier-plus-trigger-key shortcuts to use WM functionality. My next keyboard will be an Asian one, where they have separate keys for the pointing finger in the lowest row. I would like to enable the aforementioned office worker (well, I could use that too, then), to configure these keys as he likes. The gist is that it should not be necessary to edit keymaps manually, and accomplish things that are simply not possible by means or rearranging keysyms. 4.Configure remote controls --- The usual device selection buttons on a remote control could be used to switch between key type levels, so that the other keys produce the key events a particular application takes for the corresponding action. With a simple configuration file format that could be supported by those applications, and a mechanism like inotify, configuration changes in the application could be immediately active in the remote control. The user would at first create a general configuration for the remote control, and after that, would only need to associate the device selection buttons with a particular application. that can be done right now by changing the keymap according to the application? The device selection buttons would be radio buttons. If there are more than 4 of those buttons , you would have to use key-type levels in some form, as the four
Re: May I rework XKB ?
I needed a way to generally demonstrate my programming skills and as there is no such thing as an XKB keymap editor by which you can generally edit an XKB description (key types, actions, radio buttons, ...), I thought that laying the foundation for such an app is the right thing in any case. Of course it would be nice if I could continue to program at Duttulm, and to some extent, a very limited set of device configuration would be possible without changes to XKB itself. In any case the next development steps are strongly related to things that could improve and simplify XKB itself. One of the reasons for the subject line, was to signal that I am willing to take part in anything that can improve XKB (coding, raising awareness, summarizing state). As such please see the following as ideas and not as receivables. - A clearer distinction between the use of modifiers for key type level determination and the use of modifier-attributes (and not virtual modifiers) that influence client side behavior (Alt or ScrollLock would be such attributes). - Making modifier info available to clients. In particular it could be possible to obtain a name for a real-modifier and to obtain modifier attributes. Maybe offer info about which keys hold a particular modifier bit. - An easy way for clients to determine if the key-event is a final one (for example a key event generating a shortcut keysym without an associated string) or a state changing event (actions for modifiers, controls, anything the clients might want to be informed about) - An easy way for clients to determine which modifiers took part in the keysym generation (basically 'state keytype-mods'). This together with the modifier info and the distinction between final- and state-change-events would make shortcut assignment easier on the client side. So, my next steps would be a job application tour to ask if there is any corporate interest in making keymap configuration available through Duttulm. I would love to hear any comments or advices regarding that. Greetings, Dirk. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
On Tuesday 17 November 2009 10:22:07 Nicolas Mailhot wrote: Please do not try to implement such gross hacks. I don't want to make that available through xkeyboard-config but through direct configuration. I use that already. Together with AltGr, I have the cursor cross on IJKL, Home on U End on O, Backspace on H and Delete on N That way you have these functionalities in every text edit box (firefox, OpenOffice, whatever) The redirect-key-action is not possible because setting actions is locked down. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On Tuesday 17 November 2009 09:56:35 walter harms wrote:
xkbcomp -xkm ${DISPLAY} -o keymap.xkm
Warning: Could not load keyboard geometry for :0.0
BadAlloc (insufficient resources for operation)
Resulting keymap file will not describe geometry
xkbprint keymap.xkm keymap.ps
Error: Couldn't read geometry from XKM file keymap.xkm
Exiting
The keymap you get from the $DISPLAY does not contain the geometry, you must
obtain it per setxkbmap/xkbcomp
For example:
setxkbmap -model pc104 -print | xkbcomp -xkm -o keymap.xkm -
Note the '-' at the end.
Feeding keymap.xkm to xkbprint should now work.
By omitting '-model xxx' you get the geometry for the current keymap
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
On Tuesday 17 November 2009 15:26:18 Sergey Udaltsov wrote: In relation to the XKB editor, did you have a look at http://code.google.com/p/keyboardlayouteditor/ ? It is not to bad, indeed No, I wasn't aware of that application. Thanks for pointing to it, but there are several keymap editors in the form of layout assemblers and xmodmap frontends. Sorry that my initial message wasn't clear about what will make Duttulm different. The important thing is that you will be able to edit arbitrary geometries, key types, behaviors and actions. Currently all modifications are made in terms of keysyms. You have a predefined set of actions that you can put onto a level in terms of specifying a keysym that will be translated into an action. Some things are simply not possible currently, and to see what might be possible, I recommend the chapter 16 of XKBLib.pdf. There is a myriad of opportunities for real cool device interactions. Greetings. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On Sunday 15 November 2009 01:01:49 Maciej Piechotka wrote:
Everything is working except AltGr+e/E and AltGr+n/N. What is wrong?
You probably have to change the key types. You can get the current keymap by
executing this command:
$ xkbcomp -xkb ${DISPLAY} -o keymap.xkb
Now edit the resulting file keymap.xkb and find the sections for the keysym
assignment. They might look something like this:
key AD03 {
type[group1]= FOUR_LEVEL_ALPHABETIC,
type[group2]= ONE_LEVEL,
symbols[Group1]= [ e, E, EuroSign, EuroSign ],
symbols[Group2]= [ e ]
};
key AD09 {
type[group1]= FOUR_LEVEL_ALPHABETIC,
type[group2]= FOUR_LEVEL_ALPHABETIC,
symbols[Group1]= [ o, O, End, End ],
symbols[Group2]= [ o, x, y, z ]
};
You have to change the values for the type[groupX] entries. Just take the
values from the keys that work, and fill in the keysyms.
You can install the result by executing the following command:
$ xkbcomp keymap.xkb ${DISPLAY}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On Monday 16 November 2009 19:09:11 walter harms wrote:
any idea why this BadAllocmay show up ? i have plenty of ram,
and the resulting keymap.xkb seems resonable.
xkbcomp -xkb ${DISPLAY} -o keymap.xkb
Warning: Could not load keyboard geometry for :0.0
BadAlloc (insufficient resources for operation)
Resulting keymap file will not describe geometry
By means of the geometry description it is possible to draw a picture of
diverse keyboards. This info is of no value in the server (it only occupies
space) and can be obtained separately. Thus you can ignore those warnings. If
you want to see some of those keyboard pictures you can try `xkbprint`
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: May I rework XKB ?
I would like to give some examples of what a fully functional and configurable XKB extension could offer. 1.Obviate the need to leave the home row for functionality that is provided by keys right of the main keyboard -- By taking a common pc-105 keyboard and holding down the AltGr/ISO-Level3-Shift modifier , all the alphabetic keys can be equipped with functionality like cursor-cross, insert, delete, home, etc. With the help of XKB's Redirect-Key-Action it would even be possible to have word-wise cursor movement in all text edit fields. All without leaving the home row. 2.Shortcuts abound -- Press one key and let the whole keyboard produce keysyms that are not recognized by any application, so that you can be sure, not to interact with the currently active application in an unwanted manner. This now inactive keyboard could be set up, to exclusively interact with the desktop environment. 3.Use a shortcut setup to control the window manager By using a shortcut setup from example 2 and making it accessible by one of the keys in the lowest keyboard row, it would be possible to configure advanced window manager interaction that would not require leaving the home row. Shortcuts for switching applications, switching desktops, packing windows, and common application shortcuts, would have some considerable clearance. It would be possible to lock these shortcuts onto the main window (say with Shift-Return), and with slightly improved support from the window manager, there would be the chance to move the active window in a mouse-keys like behavior or force a particular geometry onto a window (For example: maximize on the left halve of the screen, halve the screen's width and a quarter of the screen's height in the top right corner, etc). 4.Configure remote controls --- The usual device selection buttons on a remote control could be used to switch between key type levels, so that the other keys produce the key events a particular application takes for the corresponding action. With a simple configuration file format that could be supported by those applications, and a mechanism like inotify, configuration changes in the application could be immediately active in the remote control. The user would at first create a general configuration for the remote control, and after that, would only need to associate the device selection buttons with a particular application. 5.Configure a gamepad as a typing device With 7 independently combinable buttons it would be possible to type all characters of the English alphabet and punctuation (6 modifiers and a trigger key), maybe facilitated by an input method. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
