Re: Fetching symbols information with XKBlib
Hello, But I can't find a way to ask about current symbols. I just want to receive short description like 'ru' or 'en' (or any other information which may be used to identify current symbols) - is there a way to get it ? You can fetch names of groups that are symbolic names specified in xkb/symbols/* files like name[Group1] = Russian; The function for getting these names is XkbGetNames(dpy, XkbGroupNamesMask, xkb); where 'xkb' is a pointer (XkbDescrPtr) to some structure 'XKB Description'. You have to allocate this decription structure with XkbAllocKeyboard(void) before XkbGetNames call. If XkbGetName is completed successfully the names will appear in the array of Atoms xkb-names-groups[] -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Small fix for XKB.
New patch (attached) is more correct and should not harm something. Looks OK to me. Is it needed for the second XkbAdjustGroup() call too? Yes. I did'n forget but tried to imagine when a negative value can appear there. (The bug reason is that the 'state' structure there keeps all fields as an unsigned char but actually some of them sometime represent negative values.) But after some thinking I suppose there are such cases. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Small fix for XKB.
Hello, I apologise for my slowness but I'd like to add small patch to Xserver XKB code. The thing is that the bug was already fixed long ago but then came back. The problem was reported in Bugzilla #1566. After some questions I found the symptoms are wellknown for me and I had fixed the bug before 4.1.0. Therefore I thought the reporter somehow got XFree based on some old release or some Xorg's server where the patch was applied later. But when I got similar complains in e-mail I decided to check sources and found out that my patch was reverted completely becouse of compilation warnings (signed-unsigned assignment without explicit cast). Of course it's my fault that the fix causes warnings but the reverting caused the bug came back. New patch (attached) is more correct and should not harm something. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia --- xc/programs/Xserver/xkb/xkbUtils.c.orig 28 Mar 2005 02:51:13 - 3.18 +++ xc/programs/Xserver/xkb/xkbUtils.c 6 Apr 2005 12:32:41 - @@ -746,7 +746,7 @@ grp= state-locked_group; if (grp=ctrls-num_groups) - state-locked_group= XkbAdjustGroup(grp,ctrls); + state-locked_group= XkbAdjustGroup(XkbCharToInt(grp),ctrls); grp= state-locked_group+state-base_group+state-latched_group; if (grp=ctrls-num_groups)
Re: What happened to the fonts?
Marc Aurele La France wrote: OK. This makes some sense to me. But should something like this be done to all affected locates? Yes. The same problem exists for all other locales (at least for 'iso8859 like' one-byte encodings). I made changes for all such locales and commited them. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
Marc Aurele La France wrote:
I don't know enough about this stuff to answer. Perhaps someone else will,
and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html.
In the meantime I've backed out the change that's causing this.
I investigated this issue.
In one of next messages Barry Scott mentioned
I recall I was seeing code behind XutfTextExtents fail to
return any info without the patch - I think it was Xutf8TextExtents.
Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8
locale. And it is a real issue. These functions don't work without changes
he proposed. But after such changes Xmb* output functions don't work.
Obviously, there is some difference in the interpretation of XLC_LOCALE data
between these two families (Xutf8* and Xmb*).
The traditional iso2022 based font system requires that any input string
be separated into portions where all chars belong to one charset.
Corresponded converters cut out such portions from a text, label them with
charset name and pass to the next procedure that finds an appropriate font
for this portion drawing.
XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records
describe rules for distinguishing chars of different charsets and chaset names
suitable for each type of chars. The 'fontset' records just defines pairs
'charset name' - 'font encoding name' that tell what font should be used
for each charset (the string labeled with this chaset name).
What we see in iso8859-15 locale file (and in many other one-byte encoding
locales)?
There are two codeset records
cs0 { sideGL:Default
..
ct_encoding ISO8859-15:GL; ISO8859-1:GL }
cs1 { sideGR:Default
..
ct_encoding ISO8859-15:GR }
and two fontset records
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL
} }
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR } }
The second records in both pairs is the simplest case. The codeset record says
that all 'right side' chars (codes 127) belongs to the right side of
ISO8859-15 charset and the fontset record says that the text portion labeled
with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15
encoded font.
The first fontset record is simple too. It says that 'ISO8859-1 left side'
labeled string can be writen with ISO8859-15 encoded font.
But the first codeset record is more complex. It contains two charset names
for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and
Xmb* functions use different names from this pair. (I know why, and can
explain. But here I omit those details.)
Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter
labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as
'ISO8859-15:GL'.
And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15'
the second step procedure successfuly finds appropriate font for 'mb' converter
output string but can do nothing for 'utf8' converter output. And after Barry's
changes we got a reverse situation: the first fontset record became
'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter
output has appropriate font but there is nothing useful for the 'mb' converter
results.
The worst thing is that there is significant difference in these converters
internals and if even we force the 'utf8' converter to choose ISO8859-1
charset we will not get the the behavior similar to 'mb' converters one.
In this case the 'utf8' converter makes the 'right side' chars labeled with
ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate
chaset-font pair among fontset records.
I would suggest a simple workaround: instead of changing the first fontset
record add a similar one but with another charset name. I.e. the fontset
section of XLC_LOCALE will look like:
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL }}
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR }}
fs2 { charset { nameISO8859-15:GL }
font{ primary ISO8859-15:GL }}
In such case the first record would satisfy Xmb* functions and the third record
would make Xutf8* functions happy.
(Of course, I tested this solution. It works.)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: finding all windows belonging to an application
Yes, I see the pattern you mention in XID. Appears that the most significant two bytes identify client and the least sig two bytes identify window. This should solve my problem. Thanks very much. Actually Xserver may divide XID to these two parts in any bit position. When an application setups a connection Xserver in the reply sends resource-id-mask where ones mark the part of XID that the application may use for resource IDs and zeros mark the common 'connection number' part. Xlib saves this mask in the Display structure. In XFree86's implementation of Xlib it is dpy-resource_mask. In my box its value is 0x1f (more than two bytes). Also the X11 protocol specification says that three most significant bits (of whole XID) can't be used. Unfortunately, the Display structure is opaque for an application and can vary in dependence on Xlib implementation vendor. And there is no standard Xlib call that return this mask. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: KP_Separator in the abnt2 keyboard
Hi, Sorry for such long delay. The abnt2 keyboard has a comma and a dot in the keypad. The dot is generating the KP_Decimal keysym but the comma is generating the comma keysym. This make both comas use the same keysym. It appears to me that the KP_Separator should be generated. Probably you are right. We told about it before your mail with Ricardo Y. Igarashi (the author of that keymap). But he didn't insist on immediate changes. :) Since you think it is a real problem I change it now. Thanks for the report. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VT switching / XKB problem
Hi,
In 4.3.0 days I made a change to the native keyboard driver that would
differentiate between Alt+Ctrl+SPECIAL and Alt+Ctrl+Shift+SPECIAL, where
SPECIAL is one of the VT screen switch, zap, or mode change keys. I
submitted a small patch (Bugzilla #1298) that cathes a new case where
this was being missed, but that code is only ever used if XKB is
disabled. When using XKB mode, the problem still exists (that is,
holding down shift while using one of the special key sequences still
acts on that sequence).
I am XKB-impaired, and don't know if this is a problem in the keyboard
definition or in XKB itself. I have several applications that want to
use Alt+Ctrl+Shift+Fx, and the only way I can currently do that is to
disable XKB. Can anyone who 'gets' XKB take a look at this? Many thanks
in advance.
The thing is that in XFree before 4.3.0 such key combinations were processed
inside the keyboard driver. But in 4.3.0 special keysyms were introduced that
cause a switching to VTs.
Therefore the code in driver that deals with those combinations stais idle and
the effect you see is caused by the mecahism that selects keysym in dependence
on modifiers.
In previous keymaps keys F1-F12 had one keysym only and that keysym was being
chosen independly on any modifiers. But in present maps such keys have two
keysyms: [ F1, XF86_Switch_VT_1 ] and note that the second column here doesn't
mean a 'Shift state' as for most other keys. Since the second field should be
chosen when Alt and Control modifiers are pressed those keys belong to special
type named CTRL+ALT. You can find the description of this type in
xkb/types/pc. It looks like
type CTRL+ALT {
modifiers = Control+Alt;
map[Control+Alt] = Level2;
...
};
The first line inside the description specifies what modifiers should be
considered for a field (level) selection. The next string is a rule that means
if both Control and Alt are pressed choose the second level. Since all other
combinations (none modifiers and Control or Alt alone) are not mentioned there
it means the first level shold be chosen (as a default choice).
But since Shift modifier is not mentioned among the modifiers that should be
considered XKB ignores it completely for such keys. I.e. it catchs the
Control+Alt pair bit doesn't distinguish it from Control+Alt+something.
What can be done. The obvious solution is to add Shift to the list of
modifiers. If we change firest string to
modifiers = Control+Alt+Shift;
but don't add any additional 'mapping rule' all combinations like Control+Shift,
Alt+Shift and 'Shift alone' will lead to the default first field with keysym F1.
But there is one bad thing there. XKB by default 'comsumes' all modifiers
mentioned in the 'key type'. It means that after calling X*LookuppString
(it is needed for mapping key event to keysym) the Shift modifer as well as
Control and Alt is removed from the modifiers set and it looks like one have
pressed F* key without modifiers. For preventing such consuming we need
to add some additional rules to the type description, like
preserv[Shift] = Shift;
preserv[Control+Alt+Shift] = Shift;
etc
But there is a simpler way. :)
You can just choose the 'old style' keymap without new special keysyms. There
is (in XFree 4.4.0) a special XkbOption srvrkeys:none (none 'server keys'
in a keymap) that simply removes new kesyms and changes the type of F1 keys
to simple two level (with the same keysym in both levels) type.
If this option is specified in XF86Config file the server at the start should
detect that special keysms are absent in the keymap and swith on an internal
(in the driver) processing of such combinations. But for sure you can switch
it explicitly in XF86Config, see the ServerFlags option (not a keyboard option!)
Option HandleSpecialKeys Always
in man XF86Config.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: howto get the XkbLayout with the C language
Hi, I've just tried to get the XkbLayout in my program, but It doesn't work for me at this moment. I caught the event, when the user changes the keyboard layout. But I cannot get the layout symbolic name as is in my XF86Config like us or cz or de or whatever I have there in the Option XkbLayout us,cz line. How can I programm it? I programm it in the C language. All strings from Xkb* options are stored in the root window property _XKB_RULES_NAMES. You can get them as a usual window property or use the function XkbRF_GetNamesProp (see X11/extensions/XKBrules.h) from libxkbfile. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
David Dawes wrote: Where does the LED state get resynced with the DDX? The only place that I see the LED state synced with the DDX is at init time. If I disable XKB, 'xset q' doesn't report changes to the real LED state. Yes. But I think it's rather a bug. Note that by deafult (without XLeds option in the config file) all LEDs are protected from changes by applications and the core protocol doesn't provide any way to get real LEDs state. Thus the XGetKeyboardControl request just reflects attempts (unsuccessful with deafult settings) of some applications to change the LEDs state. Those tests work OK for me now if I disable XKB. I don't think it is unreasonable to do the core protocol tests with XKB disabled. I agree. It would be good to add such suggestion into xsuite README. BTW, the fix for this regression is very simple. We just have to remove one line in dix/devices.c where the LEDs mask field of the keyboard controls structure is being reloaded with the actual LEDs state. The tests will be passed with success. But there will not be any way (in the core protocol) to know the real state of LEDs. It is being loaded with the XKB's LED state, isn't it? It is. Without XKB Xserver doesn't keep real LED state. On the other hand the test itself could be changed. One way is to make it XKB-aware and make it set the needed flag (that turns the XLookupString behavior to the 'core protocol like' one). Another way is don't use the Shift modifier (that can be 'eaten' under some circumstance) there. All other modifiers (except Caps) would be interpreted equaly in both (with/without XKB) cases. That sounds reasonable to me. It would also be nice to add some XKB tests to the test suite. I agree. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
Hello,
Mark Vojkovich wrote:
On Mon, 19 Jan 2004, David Dawes wrote:
Tests for XChangeKeyboardControl
Test 9: FAIL
Test 10: FAIL
That has been showing up for a while. It should be followed up.
That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - ...the state of that leds is changed, if possible..
XGetKeyboardControl - ...each bit set to 1 in led_mask indicates an LED that
is lit (Note if possible and an LED that is lit.)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
BTW, the fix for this regression is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
Tests for XRebindKeysym
Test 1: FAIL
The XRebindKeysym failure goes away if XKB is disabled.
Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: documentation of the format of files in xkb/symbols?
Hi,
You'll find some documentation here: http://pascal.tsu.ru/en/xkb/
i haven't the information i need on that page. i may have overread it or
something, but i still ask myself what certain keywords mean when
reading the files in .../xkb/symbols/pc
http://pascal.tsu.ru/en/xkb/garam-symbols.html
What is unclear there ?
my new keymap is now located at /usr/X11R6/lib/X11/symbols/pc/null and
the file looks like that
default xkb_symbols basic {
};
but when loading that keymap, the keys like 0123..9 and TAB,Enter etc.
still work. it's surely due to some implicit inheritance, but how do i
avoid that? how can i create a totally empty keymap?
I guess you specify this map using XkbLayout option (or -layout as setxkbmap
argument). You had read http://pascal.tsu.ru/en/xkb/setup.html inattentively.
The layout name is not a file name but some word that XKB translates to
file name(s) using XkbRules. And the default rule converts a single word
in the layout name into the pair of file names e.g. ps/pc(105)+pc/null.
You can check it running setxkbmap -print command.
If you want only that file alone is used as a symbols map you should specify
that it is XkbSymbols but not XkbLayout
Option XkbSymbols pc/null
But then you will face another problem. XKB (the server part) doesn't like
the symbols map that is empty completely. I'd suggest you to add at least
one key definition there that does nothing. For example
default xkb_symbols basic {
key TLDE { [NoSymbol] };
};
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: problem using dead keys
Hi, everything was ok, except that it appears to be ignoring the Option XkbOptions grp:lwin_switch Try lv3:lwin_switch instead. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: usb keyboard
I'd like to add some support to X for my usb keyboard's extra multimedia keys (if it's not already there). It sends some keycodes to the linux kernel that can't be passed via the kernel's raw mode. From my research, it seems to me that the solution is to give X the ability to use the new linux input event interface (please correct me if I'm wrong). I'd like to add some support to do this, but I'm not quite sure where to start. Where would the best place be to add code for this capability? Any suggestions? Does such functionality already exist? http://people.debian.org/~warp/evdev/ -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xkb/xlib problem key states
I'd like to add a special hotkey feature to the icewm window manager: If the user holds down a (function) key for a configurable amount of seconds a program will be executed. Now my problem is how to query the key states in xlib. My first attempt was using XGrabKey and calculating the time between KeyPress and KeyRelease events but this did not work because of two problems: . Autorepeat must not be set (bad thing) You can disable autorepeat per key. See man XChangeKeyboardControl Can anyone tell me how to query the real state of a specific key (Pressed/Released?) with xlib ? man XQueryKeymap -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [linux-usb-devel] USB keycodes Logitech Cordless Desktop Optical: (Was USB Multimedia Keyboards. Some keys do not produce keyevents)
I was under the impression that the kernel would/should at least always see the raw scancode (where this is not a value between 0 and 255), whether or not it could do something with it, and that X didn't use linux's keyboard driver anyway, it interpreted the scancodes itself. You are mixing the linux keyboard driver and the raw keycodes emulator. The 'traditional' (without USB) keyboard driver does some steps: - reads raw scan-codes from a hardware keyboard, - converts two-byte scan-codes to one-byte 'middle raw' keycodes (this mapping can be changed using setkeycodes) - maps keycodes to symbols (characters) There are some 'forks' from those steps and any application can request what data (from what step) it wants. The keyboard driver can give out codes from any of steps mentioned above: - raw scan-codes (that the driver has read from tha hardware) - middle raw keycodes - characters. The Xserver usually requests codes from lowest level, i.e. raw scan-codes (although it can also use middle raw keycodes). In this case we can say that the Xserver doesn't use linux's keyboard driver because all next steps of the linux's driver don't work there. But note that even in this case the Xserver doesn't read scan-codes from the hardware directly. Anyway it reads the data from linux's driver but actually uses only small part of this driver. | linux's keyboard driver *| keyboard reading, scan- to key- codes conv., keycodes to symbols conv. \ \-- X's keyboard driver Since an USB keyboard produces another scan codes (and uses a different protocol) its codes can't be read by PC keyboard driver directly. Therefore there is special sub-driver that reads USB codes from the USB keyboard and converts them to PC's scan-codes and passes those codes to the PC keyborad driver as if they were read from the PC keyboard. |*** linux's keyboard driver ** ... PC keyboard reading, scan- to key- codes conv., ... / \ |*** sub-driver *| /\-- X's keyboard driver USB kbd--reading, PC's scan-codes emul./ In this case X's keyboard driver anyway interracts with linux's driver and if the USB sub-driver doesn't emulates PC's raw scan-codes (with a warning or silently) for some keys, it passes nothing to PC's driver and the X's driver gets nothing too. Is it clear? -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: USB Multimedia Keyboards. Some keys do not produce keyevents.
Hi, If that module doesn't know how to emulate a scn-code for some key it prints this message (note it is not Xserver's message but kernels one) and passes nothing. In such case there is nothing to read for Xserver and you don't see any events in xev. However, showkey -s does show the scan codes, so is the kernel not passing it along anyway? Maybe I'm not understanding the whole process, but I thought that it still passes the scan code on if it doesn't know what to do with it. It is strange. As far as I know 'showkeys -s' uses the way of getting scan-codes the same as Xserver uses. I have not such keyboard and can't test it. Could you give an example of such keys? What codes showkeys shows? Do you confirm that for the same key showkeys outputs some code without any kernel messages but xev shows nothing and the kernel message you wrote about appears somewhere? -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Button press emulation
Hi, hi all, I'm working on a virtual keyboard for disabled people and I have some problems with button press emulation. I use XTestFakeButtonEvent to simulate button press events. Every virtual key has a keysym and using XKeysymToKeycode I translate virtual key Keysyms into keycodes. I have some problems with key modifiers. I'm using and italian keyboard and some keys use the AltGR modifier that is mapped as Mod5. XGetKeyboardMapping function returns 4 keysyms per keydef corresponding to Shift, Lock, Control and Mod1 modifiers. Have you ever read X protocol specification? According to the core protocol the keysyms XGetKeyboardMapping returns match states: none modifiers Shift the modifier bound to the key with Mode_switch keysym (Mode_switch modifier) 'Mode_switch modifier' + Shift Unfortunately in XKB (X KeyBoard extension) environment this dependence becomes more complex. Each key can have a separate rule for mapping a modifiers combination to the column number. In simplest case you can just find what key has Mode_switch keysym (it is AltGr usualy) and find what modifier is bound to that key (Mod5 in your case). Thus in your case the columns in XGetKeyboardMapping result are none Shift Mod5 Mod5+Shift -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: USB Multimedia Keyboards. Some keys do not produce keyevents.
Hello, I have project called lineak http://lineak.sourceforge.net which is a user configurable daemon to run commands when a user presses a multimedia key on their keyboard. However, some people who have USB keyboards, have a problem that some keys do not get keycodes, or generate events. In fact, xev and the like just ignore them. Under Linux, errors get written to the messages file about unknow keys, eg. Kernel: keyboard.c: can't emulate rawmode for keycode xxx The keyboard driver was initially designed for AT keyboard and its scan-codes. The module that deals with devices that generates different scan-codes (such as USB HID) emulates AT's scan codes and passes them to the 'common' driver where those codes can be read by Xserver or converted to character codes (if the driver operates in console mode). If that module doesn't know how to emulate a scn-code for some key it prints this message (note it is not Xserver's message but kernels one) and passes nothing. In such case there is nothing to read for Xserver and you don't see any events in xev. I've contacted the linux keyboard driver developer but he mentioned that this is an X problem. So, here I am. X's problem is that it gets nothing from the kernel keyboard driver. :) How it can be fixed in the Xserver? How should we proceed with addressing this problem? It seems the easiest thing would be to make X configurable with regards to which scancodes get mapped to which keycodes. Would this be possible or even desirable? Xserver recognizes lot of scan-codes and although their mapping to X's keycodes is not configurable it is not a problem. The problem is that Xserver has nothing for mapping. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Keith Packard wrote:
Yes, it looks like you're correct -- every example I could find would
ensure that pending device input was marked in checkForInput. There are
some odd examples of this however, which are somewhat instructive to
examine:
a) The original A/UX server had checkForInput marked from the SIGIO
handler and read device events in ProcessInputEvents.
If WaitForSomething returns after the checkForInput check allowing
ProcessInputEvents be executed before the timers check, this case changes
nothing. It doesn't matter when the events reading was done, before the
ProcessInputEvents or during its execution.
BTW I forgot to mention one other advantage of checkForInput. It reflects
the events queued from SIGIO handlers but the devicesReadable check misses
such events.
b) Many old servers never set checkForInput. The default values
point at two different values, so ProcessInput events would be
called each time around the Dispatch loop.
Unfortunately, if we assume that some events can be queued from SIGIO handlers
this case is hopeless completely.
With conditions:
- timers should not be processed if there are input events queued but not
processed by ProcessInputEvents,
- checkForInput can't be used because it always true and with such check
the timers will never be processed,
- devicesReadable check doesn't reflect input events queued in SIGIO handlers
and can't be used because it doesn't fulfil the first condition
the problem becomes unsolvable.
Is it possible to check changes in the file descriptors set instead of just
the fact that some timer was processed?
That would only be necessary if performance across timer execution were a
critical factor -- essentially what we're forcing by returning 0 is
another call to select, which will do all of the file descriptor checking
necessary. It seems simpler to let the existing code handle this case.
OK. I made the next (and hope it's final) version.
In both branches (after the select) the subroutine returns if at least one
time is expired.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
--- xc/programs/Xserver/os/WaitFor.c.orig Wed Sep 17 17:24:12 2003
+++ xc/programs/Xserver/os/WaitFor.cWed Sep 24 19:15:53 2003
@@ -131,17 +131,12 @@
* pClientsReady is an array to store ready client-index values into.
*/
-static INT32 timeTilFrob = 0; /* while screen saving */
-
int
WaitForSomething(int *pClientsReady)
{
int i;
struct timeval waittime, *wt;
INT32 timeout = 0;
-#ifdef DPMSExtension
-INT32 standbyTimeout = 0, suspendTimeout = 0, offTimeout = 0;
-#endif
fd_set clientsReadable;
fd_set clientsWritable;
int curclient;
@@ -188,138 +183,17 @@
else
{
#endif
-#ifdef DPMSExtension
- if (ScreenSaverTime 0 || DPMSEnabled || timers)
-#else
- if (ScreenSaverTime 0 || timers)
-#endif
- now = GetTimeInMillis();
- wt = NULL;
+wt = NULL;
if (timers)
- {
- while (timers (int) (timers-expires - now) = 0)
- DoTimer(timers, now, timers);
- if (timers)
- {
- timeout = timers-expires - now;
- waittime.tv_sec = timeout / MILLI_PER_SECOND;
- waittime.tv_usec = (timeout % MILLI_PER_SECOND) *
- (100 / MILLI_PER_SECOND);
- wt = waittime;
- }
- }
- if (ScreenSaverTime 0
-#ifdef DPMSExtension
- || (DPMSEnabled
-(DPMSStandbyTime 0 || DPMSSuspendTime 0 || DPMSOffTime 0))
-#endif
- ) {
-#ifdef DPMSExtension
- if (ScreenSaverTime 0)
-#endif
- timeout = (ScreenSaverTime -
- (now - lastDeviceEventTime.milliseconds));
-#ifdef DPMSExtension
- if (DPMSStandbyTime 0)
- standbyTimeout = (DPMSStandbyTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSSuspendTime 0)
- suspendTimeout = (DPMSSuspendTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSOffTime 0)
- offTimeout = (DPMSOffTime -
- (now - lastDeviceEventTime.milliseconds));
-#endif /* DPMSExtension */
-
- if (
- timeout = 0
-#ifdef DPMSExtension
- ScreenSaverTime 0
-#endif /* DPMSExtension */
- ) {
- INT32 timeSinceSave;
-
- timeSinceSave = -timeout;
- if (timeSinceSave = timeTilFrob timeTilFrob = 0)
- {
- ResetOsBuffers(); /* not ideal, but better than nothing */
- SaveScreens(SCREEN_SAVER_ON, ScreenSaverActive);
-#ifdef DPMSExtension
- if
Re: Wrong order of a timeouts processing in WaitForSomething.
Egbert Eich wrote:
The XKB code could call ProcessInputEvents just above the check for a
pending repeat key; that would ensure that any input queued either in the
X server or the kernel would get processed before repeat status was
checked.
Hm, doesn't ProcessInputEvents() only process the events already in
the queue on the server? From looking at the code it doesn't seem
to do a read() to obtain events that have not been read from the
kernel - but that's what we'd need.
Right. ProcessInputEvents doesn't read events from the kernel.
Such check in the autorepeat callback function might make sense only being used
with a SIGIO driven input.
In any case, the current spot isn't sufficient as the timers
will never be executed if the server is constantly receiving application
input, so at least that needs to be fixed.
One could move the timer handlers past the end of the
if (i = 0) { } else { } statements. However with input queued
(ie when the mouse is constantly moved) the timers don't get
called either.
Can the mouse movement really make such frequent stream of events?
BTW for timers that need the devices input checked first (screensaver, DPMS,
keys autorepeat) it is not a problem. Anyway they do something useful when
input evens absent some time. But for other timers it can be important.
If such danger really exists it argues for a making two kinds of timers and
distinguishing them.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Around 21 o'clock on Sep 22, Ivan Pascal wrote: Also I added a flag for timers TimerNeedsCheckInput. The timers without this flag are processed before the select all others are delaied until the second timers check. (The second check doesn't distinguish those timers.) I think that's overkill; the simple expediency of returning 0 from WaitForSomething after a timer has been processed will make sure that any effects of the timer are reflected at every scheduling stage. WakeupHandler(i, (pointer)LastSelectMask); +ProcessInputEvents(); Calling ProcessInputEvents from WaitForSomething is not appropriate; input events are already processed by dispatch at the appropriate time. I agree. It was a silly kludge. Instead of attempting to patch the code to kludge things into working, let's try to nail down precisely how things should work and then rewrite the code to match that. Here's a short list of 'requirements': Thank you. Offering my patch I want to hear an opinion of those who know well how this loop works. 1) DoTimer called only when all pending input processed. a) After select b) After checkForInput tested Agree. c) After devicesReadable is checked But here I don't understand why this check is needed. If the select returns some readable devices fd's they all should be read in Wakeup handlers immediately after the select and this reading should be reflected in checkForInput. Moreover it can happen that a driver reads events from the kernel but doesn't put any events into the servers queue (for example the keyboard driver that processes VT- or VMode-swithing internally). 2) DoTimer called even if server swamped with client input a) Must check timers even when select returns positive Agree. 3) DoTimer effects on file descriptors respected (not that any known instances exist) a) Return 0 after any timers processed Is it possible to check changes in the file descriptors set instead of just the fact that some timer was processed? I imagine something like: save AllSockets do timers if XFD_ANYSET in (saved_AllSockets XOR AllSockets) return 0; Or what do you mean? Also I think it is not necessary to return in the branch 'the select returned 0' because in this case there are not any action with sockets and WaitForSomething returns in loop back to the select. 4) Minimal system calls in normal case a) Call GetTimeInMillis() as few times as possible b) Don't call ProcessInputEvents from WaitForSomething Agree. The next version of the patch attached (WaitFor.c only). I didn't make the 'return after the timers processing' but just put a comment where I think it should be done. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Hello, Egbert Eich wrote: One use for timeouts is to handle external network events, such as font server reconnect or XDMCP messages. In those cases, the timeout routine can modify which sockets will be needed in the select mask, hence the desire for the timeout routine to execute before the select (and various BlockHandler) routines are invoked. When the timeout routine fires only after select returns, the server will go through a complete scheduling interval before the BlockHandler is invoked. So what would be the way out? I suppose one could use a wakeup handler instead. This however would only work if the wakeup handler for keyboard input was called before the xkb timer handler. The latencies of other handlers that are called before the xkb handler could also cause the timer to expire with the key release unnoticed. The only way to ensure that a possible release event is detected is to read the keyboard in the xkb callback handler to check for pending release events. However I'm afraid xkb simply doesn't work that way. Another solution may be a a SIGIO driven keyboard input. Except the solution I offered I considered as possible solutions: - a check for input directly in the autorepeat timer callback function, - a using of additional wakeup handler, - a using SIGIO driven input, - an additional flag for timers to distinguish them in the first check in WaitForSomething. 1. Check for input in the callback function. I don't like it because it works on the level that is far from an interface with a kernel. In our case a release event is not even read from a kernel driver hence the callback routine should somehow start this reading. But it deals with a dix level device structure _DeviceIntRec. That structure has a pointer to an input device driver but the driver itself is opaque for this level. Moreover in the case of a built-in keyboard driver the DeviceIntRecord even has not such pointer and so has not any hooks to initiate a reading. Also we need to be sure that a file to the kernel driver is in NONBLOCK mode. In most cases it is but I'm not sure it is always. And finaly, the state when unneeded events are generated happens very seldom but to avoid it the callback routine has to call a read syscall every time. 2. An additional wakeup handler. Frankly speaking I didn't consider it deeply because it seemed to me unnecessary complex. What happens if there are not real key events and the autorepeat event is really wanted? The timer check before the select doesn't emit an event but only puts a task for a wakeup handler that will be executed after the select. But since the timer is already expired, WaitForSomething thinks this timeout already consumed and makes the select wait until a next timeout expire or any other event happens. It is incorrect too. Therefore in this way we need: change a timeout figuring out, add a wakeup handler itself (and we need to be sure it stands in queue after input devices reading), insert a ProcessInputEvents() somewhere between handlers processing and so on. And anyway WaitForSomething has to be changed. 3. SIGIO driven input. It is almost ideal. Frankly speaking I didn't guess how to solve the problem that a SIGIO handler only reads input devices but doesn't do a complete event processing. But now after reading replays to my message I see that it is quite simple. The callback routine can call ProcessInputEvents. It is much simpler than to make a driver read events from a kernel and doesn't consume much time if a queue is empty. But there is another issue. As far as I understand not all target platforms now support SIGIO input. Therefore it will be a solution for Linux and BSD only. Is not it? 4. Distinguishing the timers that can be processed before the select and the timers that should not. Although nobody mentioned it I still think it could be a solution. I mean we can add additional flag to a timer (or more if it is needed). BTW a subroutine TimerSet already has a 'flags' argument but doesn't save it for a future use. On the other hand it means we don't need to change all TimeSet calls but only those that really need to be checked after an input devices reading. The first timers check in WaitForSomething should check this flag in a timer and skip such timers. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
I made new version of the patch.
The issue Keith pointed is fixed.
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check. (The second check doesn't distinguish those timers.)
Also I found another issue. The thing is that the procedure xf86Wakeup that
reads input devices processes only one device in a turn because, as it is said
in comments, it Must break [loop] here because more than one device may share
the same file descriptor. Now the built-in keyboard driver is called
separately before the loop and all works well. But if a keyboard is served
by a module driver and there are more than one devices with 'ready for reading'
events there is not guaranty that all input devices events will be read before
the timers checking.
I made a separate patch for xf86Wakeup (in a separate attachment).
Please review.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
--- xc/programs/Xserver/os/WaitFor.c.orig Wed Sep 17 17:24:12 2003
+++ xc/programs/Xserver/os/WaitFor.cMon Sep 22 19:34:55 2003
@@ -109,6 +109,7 @@
CARD32 expires;
OsTimerCallbackcallback;
pointerarg;
+intflags;
};
static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
@@ -131,17 +132,12 @@
* pClientsReady is an array to store ready client-index values into.
*/
-static INT32 timeTilFrob = 0; /* while screen saving */
-
int
WaitForSomething(int *pClientsReady)
{
int i;
struct timeval waittime, *wt;
INT32 timeout = 0;
-#ifdef DPMSExtension
-INT32 standbyTimeout = 0, suspendTimeout = 0, offTimeout = 0;
-#endif
fd_set clientsReadable;
fd_set clientsWritable;
int curclient;
@@ -188,138 +184,37 @@
else
{
#endif
-#ifdef DPMSExtension
- if (ScreenSaverTime 0 || DPMSEnabled || timers)
-#else
- if (ScreenSaverTime 0 || timers)
-#endif
- now = GetTimeInMillis();
- wt = NULL;
+wt = NULL;
if (timers)
- {
- while (timers (int) (timers-expires - now) = 0)
- DoTimer(timers, now, timers);
- if (timers)
- {
- timeout = timers-expires - now;
- waittime.tv_sec = timeout / MILLI_PER_SECOND;
- waittime.tv_usec = (timeout % MILLI_PER_SECOND) *
- (100 / MILLI_PER_SECOND);
- wt = waittime;
- }
- }
- if (ScreenSaverTime 0
-#ifdef DPMSExtension
- || (DPMSEnabled
-(DPMSStandbyTime 0 || DPMSSuspendTime 0 || DPMSOffTime 0))
-#endif
- ) {
-#ifdef DPMSExtension
- if (ScreenSaverTime 0)
-#endif
- timeout = (ScreenSaverTime -
- (now - lastDeviceEventTime.milliseconds));
-#ifdef DPMSExtension
- if (DPMSStandbyTime 0)
- standbyTimeout = (DPMSStandbyTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSSuspendTime 0)
- suspendTimeout = (DPMSSuspendTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSOffTime 0)
- offTimeout = (DPMSOffTime -
- (now - lastDeviceEventTime.milliseconds));
-#endif /* DPMSExtension */
-
- if (
- timeout = 0
-#ifdef DPMSExtension
- ScreenSaverTime 0
-#endif /* DPMSExtension */
- ) {
- INT32 timeSinceSave;
-
- timeSinceSave = -timeout;
- if (timeSinceSave = timeTilFrob timeTilFrob = 0)
- {
- ResetOsBuffers(); /* not ideal, but better than nothing */
- SaveScreens(SCREEN_SAVER_ON, ScreenSaverActive);
-#ifdef DPMSExtension
- if (ScreenSaverInterval 0
- DPMSPowerLevel == DPMSModeOn)
-#else
- if (ScreenSaverInterval)
-#endif /* DPMSExtension */
- /* round up to the next ScreenSaverInterval */
- timeTilFrob = ScreenSaverInterval *
- ((timeSinceSave + ScreenSaverInterval) /
- ScreenSaverInterval);
- else
- timeTilFrob = -1;
- }
- timeout = timeTilFrob - timeSinceSave;
- }
- else
- {
- if (ScreenSaverTime 0 timeout ScreenSaverTime)
- timeout = ScreenSaverTime;
- timeTilFrob = 0;
- }
-#ifdef DPMSExtension
- if (DPMSEnabled)
- {
- if (standbyTimeout 0
-(timeout = 0 || timeout
Re: CapsLock behaviour and Turkish keyboard
Hi,
Well, I used to like that behaviour of typewriter capslock (with shift
key removing the caps lock, and the capslock affecting all keys and
being a shift lock in fact)
Unfortunately I can't imagine how to make such mode (affects all keys but
Shift cancels Caps ) in XKB.
I tested it and it seems to work correctly with caps:shift
(setxkbdmap fr -options caps:shift) ?
Yes, it works! And it's a big surprise to me.
Of course now I understand why it happens but I didn't guess until you wrote
about it. :-)
Let me explain.
1) Xlib converts a keycode to a keysym in two steps.
At the first step it chooses a cell in a keyboard map table according to
the state of modifiers and gets a keysym. And the second step is that if
Lock modifier is set Xlib tries to convert the keysym to uppercase one using
an internal table.
2) For the cell choosing it uses rules called 'key type'. Such rule describes
what modifiers should be taken in account and what combiantion of modifiers
match each shift level. (Note that the modifers can be not Shift only but also
Control, Alt, etc.).
Each key can have own type (refer to own rule) and if there are more than one
'xkb group' in a keybaord map the key can have different types for different
groups.
3) The first step subroutine can remove some modifiers ('consume' in XKB terms)
if they are used for the sell selection. Otherwise it would be imposible to
cancel temporary a Lock modifier action. Thus if we want the Shift cancels
Caps mode we have to specify in the type description that if Shift is pressed,
Lock modifier should be removed (or hidden) and the second step will leave the
keysym unchaged.
4) xkbcomp program itself tries recognize what key is alphabetic and what key
is not and assign them different types (rules). The algorithm is simple,
if the keysym in the first level is some lowercase letter and the keysym in
the second level is some uppercase one it is an alphabetic key (note: the
program doesn't check any matching between them). Otherwise xkbcomp thinks
it is a 'non-alphabetic key with two levels'.
Also one can explicitly specify the key type in a keyboard map.
Now we can understand the results of your experiments.
The key [ccedilla 9] was not recognized as an alphabetic key because the second
symbol isn't an uppercase letter.
On the other hand the rule for 'simple two level' keys is:
if Shift is set choose the second level, otherwise choose the first one.
But (what I didn't guess) the rule says nothing about the consuming of Lock
modifier. And if Lock is set the second step converts ccedilla to uppercase
Ccedilla. If Shift is also set the first step chooses '9' and the second step
does nothing.
Actually there is not a difference between the 'two level' type and the
'alphabetic' type in caps:internal mode except Lock+Shift case.
'Alphabetic-internal' rule chooses first level when there is not any modifiers
set and the second level when Shift is active. If Lock (without Shift) is set
it chooses the first level keysym but allow second step to make it uppercase
one (using internal table !).
But the case Lock+Shift is processed differently. 'Two level' rule chooses
the second level symbol but 'alphabetic-internal' rule still gets the first
level keysym but consume Lock modifiers and prevents the capitalization at
the secont step.
Thus you see that the 'alphabetic-internal' rule *never* chooses the second
level if Lock is set but only pass it to or hide it from the second step.
The rule 'alphabetic' in caps:shift mode differ from both mentioned rules.
It *always* consume Lock and leave the second step idle. On the other hand
it use Lock for choosing the second level and returns to the first level
when Shift is added to Lock.
And what is exactly the difference between the caps:shift and the currently
default behaviour?
In caps:shift mode if Lock modifier is set Xlib gets from keyboard map
a keysym from the second shift level the same as is chosen when Shift modifier
is set.
?? You said that such behaviour is no more present.
No, I said that CapsLock key doesn't control Shift modifier (saying 'modifiers'
I don't mean keys themselvs but bit flags that the keys set).
The CapsLock key always set Lock modifier. But in this mode Lock and Shift
modifiers (flags) cause the same action at a level choosing.
But since CapsLock key doesn't lock Shift modifier but Lock modifier
it allows to distinguish cases CapsLock is active and CapsLock is active and
Shift key is pressed. Also it allows only part of keys (alphabetical ones)
be affected by CapsLock.
So, it is not the second shift level that is chosen; but
- if the second shift level is alphabetic, it is chosen;
- if not, the first shift level is uppercased.
is that right?
Not exactly, but it looks like that. :-)
As I tried to explain above, if the second shift level is alphabetic (and
uppercase) the 'alphabetic' rule is applied and in caps:shift mode
it means that the
Re: CapsLock behaviour and Turkish keyboard
Hi,
Well, I described how it worked on mechanical typewriters; just having
a ShiftLock is enough. (OTOH it is a long time since I last used
a mechanical typewriter, and since I discovered the CapsLock on
computers (allowing to have uppercase of ccedilla for example), I like
this better. On typewritters the Shift Lock was useful to type
lots of numbers (on French and Belgian keyboars, digits are on second
shift position); but on computers there is the numeric keyopad...)
Well, I can make an option (what about caps:lockshift name) that shifts
ALL keys but it can't be canceled with Shift key pressing.
Probably ConvertCase procedure doesn't know how to convert it to uppercase.
Where is the list of internal case pairs ?
There is XConvertCase subroutine in xc/lib/X11/KeyBind.c but deals with keysym
ranges and you need to figure out falls a paticular keysym into some range
or not.
I wrote a test program that prints keysyms for all keys in a map for all
combinations of Lock and Shift. And than I ran it for all layouts in both
modes and compared the results.
There are few differences (in 'tr' for example) and in all cases caps:shift
produces more reasonable result.
Could I get that program somewhere?
It's a very simple program (I attached it). It just prints all keysyms of the
current keyboard map. Therefore I ran it from a batch file like
setxkbmap al
maptest al.map
setxkbmap be
maptest be.map
...
and then compare files with 'diff'.
So, if that is the only reason not to make caps:shift the default, then
it may be dismissed. (and the Canadian keyboard map should be fixed to
have either [ eth, ETH ] or [ eth, dstroke ] )
OK.
Mmmh; I don't see any difference in behaviour at all between caps:shift
and caps:internal !
Even for 'tr' and 'az' keyboard ?!
('az' uses the same idotles/I and i/Iabovedot pairs as 'tr')
Also I found a difference for [oe, OE] key in 'fr-latin9' map. But it rater
a bug in XConvertCase and I think it's already fixed in the current sources
(I tested it under 4.3.0).
But I see a difference between old (in /xkb/ ) and new (in .../xkb/pc/ )
keymaps.
Old ones behave as in your description of caps:internal; new ones
behaves as in your description of caps:shift
I tested with [ a, Greek_OMEGA ], when the keyboard is listed as old
one; then CapsLock gives A; when it is listed as new layout, then
CapsLock gives Greek_OMEGA.
Hmm. Don't know. Can you tell about all conditions?
What caps mode you tested with? What keymap do you mean? There is not such
key in existent maps. Did you write it yourself? If so, don't you forget
to copy the file into both directories (xkb/symbols for old layouts and
xkb/symbols/pc for new ones)?
In my tests (a wrote such key description myself) it always is recognized
as 'two level' (it seems like a bug in xkbcomp; probaly it doesn't recognizes
Greek keysyms as letters at all) and always gives 'A'.
(So, the solution for the Turkish keyboard problems would be to use
only new layout ones; it solves my problem, but I wonder how I don't
see any difference when using -option caps:shift or -option caps:internal)
BTW. Do you know that xkbcomp 'summarizes' new options with already set ones?
If you run it once as setxkbmap layout -option caps:shift, to replace
the mode you have to run it second time as
setxkbmap layout -option -option caps:shift
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
#include X11/Xlib.h
#include X11/Xlibint.h
XKeyEvent ev;
Display *dpy;
main(argc, argv)
int argc;
char **argv;
{
KeyCode keycode;
KeySym keysym;
int GroupMask, max, min;
dpy = XOpenDisplay(0);
if(!dpy) { printf(Can't open display\n); exit(0);};
ev.type = KeyPress;
ev.display = dpy;
ev.state = 0;
ev.keycode = 0;
XDisplayKeycodes(dpy, min, max);
for(keycode = min; keycode max; keycode++) {
ev.keycode = keycode;
printf (%3d : , keycode);
ev.state = 0;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
ev.state = ShiftMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
ev.state = LockMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
ev.state = ShiftMask | LockMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
/* New layouts */
GroupMask = Mod5Mask;
/* Old layouts*/
/* GroupMask = 113; */
ev.state = GroupMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
ev.state = GroupMask | ShiftMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
ev.state = GroupMask | LockMask;
XLookupString(ev, NULL, 0, keysym, NULL);
printf (%s , XKeysymToString(keysym));
Re: CapsLock behaviour and Turkish keyboard
Pablo Saratxaga wrote:
On Wed, Aug 06, 2003 at 01:31:45AM +0700, Ivan Pascal wrote:
The name was misleading I thought it was the system where capslock
is similar to shift lock (how is that mode named then?)
There is not such option now. In my opinion it is inconvenient because such
key affects all keys (including numpad) and can't be canceled with Shift key
(the behaviour that usualy expected). Nobody requested such option yet.
And why isn't caps:shift made the default? It doesn't seem to change
anything for other layouts (after some quick tests).
Well. When I two years ago suggested such behavior for CapsLock *you* argued
against it. :-)
:I suggested to change Lock modifier behavior (XKB allows it) to make it
: simply choose keysym from second column as Shift do.
:
: But that behaviour won't be welcome in all cases, for example on French and
: Balgian keyboards there is:
:
:key AE09 {[ccedilla, 9 ]
:
: CapsLock allows to type a Ccedilla; changing CapsLock behaviour will make
: it impossible.
( http://marc.theaimsgroup.com/?l=xfree-i18nm=99365248027276w=2 )
I realize that make it default and my suggestion change the behavior
completely are different things. But if we change the defaults now ...
1) most of user will not notice any differences but
2) French or Belgian keyboard users will be surprised unpleasantly.
And what is exactly the difference between the caps:shift and the currently
default behaviour?
In caps:shift mode if Lock modifier is set Xlib gets from keyboard map
a keysym from the second shift level the same as is chosen when Shift modifier
is set. But since CapsLock key doesn't lock Shift modifier but Lock modifier
it allows to distinguish cases CapsLock is active and CapsLock is active and
Shift key is pressed. Also it allows only part of keys (alphabetical ones)
be affected by CapsLock.
In caps:internal mode (the default) Xlib gets a keysym from the first level
(or 'column' in core protocol terms) but then converts it to another keysym
using a builtin table.
Note also that /usr/X11R6/lib/X11/xkb/README.enhancing is outdated, it
doesn't talk about caps:shift
This README was not written as a reference book for all options.
Such description can be found in xkb/rules/xfree86.lst or xfree86.xml file.
And those files are mentioned in the README.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Change of behavior of shift+numpad arrow keys (without numlock)
David Dawes wrote: On Mon, Aug 04, 2003 at 03:10:02PM +0200, Egbert Eich wrote: Bugzilla 558 requests to change the behavoir of shift+numpad arrow keys This requests sounds reasonable so I would like to find out if somebody has a strong opinion on this issue. If not I will commit the supplied fix. Since X has been documented to work this way for a long time, it would be better to make the behaviour configurable than to just change it. I agree completely. It's easy to make new XkbOption that switch on the behaviour of numpad keys exactly as in MS Windows. Egbert, I'd like to ask you don't apply the patch from the bugreport. I am going to make this option (something like numpad:no_shift or numpad:microsoft) soon. Any suggestions about an option name are welcome. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Hi, I see keyboard topics are being discussed right now... there is long standing problem with the CapsLock and turkish keyboard that would be nice to have fixed. Yes. There *was* such problem and it was discussed year ago. :-) (I don't remember but I was sure you took part in that discussion.) Now Turkish keyboard users just have to set XkbOption caps:shift. With that option Xlib doesn't use 'internal capitalization' but CapsLock key acts as 'locking Shift' (but can be canceled by Shift key). It solves the problem. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: linux 2.6 atkbd == xkb
Hello, As per xc/programs/Xserver/hw/xfree86/common/atKeynames.h: /* * Fake 'scancodes' in the following ranges are generated for 2-byte * codes not handled elsewhere. These correspond to most extended keys * on so-called Internet keyboards: * * 0x79-0x93 * 0x96-0xa1 * 0xa3-0xac * 0xb1-0xb4 * 0xba-0xbd * 0xc2 * 0xcc-0xd2 * 0xd6-0xf7 */ What I cannot find is *where* those fake scancodes are generated and how they are mapped to 0x81-0x84 xc/programs/Xserver/hw/xfree86/common/xf86Events.c xf86PostKbdEvent() subroutine P.S. I currently use: Option XkbModel pc105 but AFAICT the only way to turn on a named section in xkb/symbols/inet is to use Option XkbModel named_option How do I get both us(pc105) and inet(inspiron)? Simply use the second way. If the model name is the same as one of inet file sections name, XKB uses us(pc105) map and _adds_ inet(model_name) to it. (I mean XFree86 4.3.0. In previous versions it uses us(pc104). ) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] btc9001ah keybaord symbols
Hello, I'm using btc9001ah keyboard and found out that current CVS doesn't support this model! Here is its description: I commited your description but without commented lines. We can add them later when the keycodes will be emulated correctly. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
Hi, The linux-ppc kernel has an option (CONFIG_MAC_ADBKEYCODES) to use the old ADB-style keycodes. I imagine setting this option to no uses the conversion you're talking about. For the record, the scancodes I see (from showkey -s) are as follows: KeyPad Equals : 0x5c 0xdc Left Arrow : 0xe0 0x4b 0xe0 0xcb Wow! It is exactly what I told about. I didn't say what Xserver's driver does with one-byte codes. Actually it does: - converts 0xe0 xx sequences to some one byte code - and then adds 8 to every code, including one-byte scan-codes and codes (one-byte too) got from the sequences covertion. Therefore 0x5c code after that becomes 5c+8 = 0x64 hex or 100 dec. And the Left arrow sequence at the first step is converted to 0x5c too and after adding 8 becomes 100 (dec). For the source-fix option, I think that the change should be in the Xserver, because it's not a problem in the PPC-specific keycode conversion. In the Xserver source, where are these keycodes generated? I think it's in xc/programs/Xserver/hw/xfree86/os-support/linux/ but I can't really tell which file. No. Since the server's driver deals with hardware scan-codes, this part isn't a Linux-specific. See xc/programs/Xserver/hw/xfree86/common/xf86Events.c xf86PostKbdEvent(unsigned key) procedure. There always is. :) Are these medium-raw codes the ones shown with showkey -m? Hmm. I have not a Linux box here but and I searched 'man showkey' in Internet. If I understand it right, showkey -k (or --keycodes) shows medium-raw codes. Note that the console drivers second level generates different keycodes for your two keys. I think what you mean here is that the console drivers' third level generates different keycodes, because I see different charcters on the console when I type (i.e. in bash). Though the showkey -m also shows different results from showkey -k. I meant since you see different characters (codes from the third level) for these two keys, it means the keys medium-raw codes (codes from the second level) are different too. :) Ah. I wondered if X would be able to use the console keycodes. The answer seems to be 'yes.' What's interesting is that in X with the medium-raw codes enabled, most of the keys still work fine (a-z, 1-0, tab, keypad = even). However some of the 'strange' keys aren't mapped properly. Namely all the arrow keys and the right alt... things like that. But it should be possible to change that, it seems. But it'll take some time. Yes it's what I meant saying 'shifted'. A main (and maybe only one) difference between 'raw' and 'medium-raw' codes is that 'extended scan-codes' are replaced with one-byte codes. Thus all keys that produce 'ordinar scan-codes' have the same value of 'raw' and 'medium-raw' codes. Only keys that generate 'extended scan-codes' have differnt values. Take any documentation about PC keyboard scan-codes and you will see all that 'strange' keys are those which produce extended scan-codes. I'd appriciate it if you could tell me in which (set of) files these raw scancodes are converted to XFree scancodes. I already mentioned that function: xf86PostKbdEvent(unsigned key) in Xserver/hw/xfree86/common/xf86Events.c -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
Hi, OK, after some more resarch, I have some idea of what's going on. It seems that the X server gets the scan codes from the kernel, then passes these scan codes to the X client. xlib has some nice functions to then convert these scan codes into keycodes, then into keysyms. (Correct me if I'm wrong here.) You are wrong, really. In fact the first step the scan-codes-keycodes convertion is done in the server itself. The server sends to an application keycodes and xlib converts them into keysyms (does the second step only). The second convertion is very flexible because Xlib gets all needed data from external tables usually called 'a keboard map'. Note all these maps contain only keycode-keysym matches. But tables for scan-code-keycode convertion are builtin into the server code. Regarding your case... A usual PC keyboard produces two kind of scan codes. Some keys emit simple one-byte codes but there are keys that produce two-byte sequences (extended scancodes). Most of keyboard drivers (including a 'system' Linux driver and an Xserver's one) convert two byte sequences into a one byte code. Unfortunately, different drivers do it in own way. The Left key you mentioned emits a sequence that the Xserver's driver converts to keycode 100. But if some other key produces such one-byte code (or rather the one-byte code which is converted to 100 by the Xserver driver) an application will get the same keycode from both keys. I don't know what scan-codes your iBook keybord produces. But I think a some part of Linux code converts them trying emulate PC keyboard codes. Thus this part of driver generates usual two-byte sequence for the Left key and some one byte code for your extra key. The problem is that the second part of system driver which gets scan-codes and converts them to one byte generates for Left key a code differnt from the 'equals' key code. Therefore console application can distinquish them. But the Xservers driver, as I said, do it in own way and its keycodes for these two keys are the same. On of solutions could be to change a source code of Xserver's keyboard driver or a code of Linux driver which emulates PC scan-codes. But there is another way. The thing is the system driver has at least three levels (I mean a usual PC keyboard driver and don't consider mac-PC codes conversion). The first one just gets scan-code from hardware and can give such 'raw codes' to any interested application. The second one is that which converts raw scan-codes to some intermediate one-byte codes. Such 'middle raw' codes also can be taken by an application. And the third level converts these 'keycodes' into symbols according to a keyboard map. Note that the console drivers second level generates different keycodes for your two keys. Xserver's driver normally gets codes from the first level of the system driver (i.e. raw scan-codes). But it's possible to make them get 'middle raw' one-byte codes. In this case the codes of two keys you are talking about will be different. But on the other hand in such case many of keycodes can become 'shifted' and you will need to make a new keyboard map. To switch Xservers driver to getting 'middle raw' codes add into XF86Config (keyboard section) the option Option CustomKeycodes on -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: KeyBoard BUG on sparc/sparc64 in 4.3.0 too.
Balint Cristian wrote: Regard to that one BUG with the mention that it persist in 4.3.0 too and any CVS too: By Rene: http://marc.theaimsgroup.com/?l=xfree86m=104526841725691w=2 By mysef: http://marc.theaimsgroup.com/?l=xfree86m=104385693307371w=2 I send more deBug: http://marc.theaimsgroup.com/?l=xfree86m=104385720707941w=2 The reason of this bug is a change : 656. Make SysRq generate the same keycode as PrtScrn, and Break the same : keycode as Pause (#A.1160, Owen Taylor). which added into an xf86PostKbdEvent procedure a code : /* : * PC keyboards generate separate key codes for : * Alt+Print and Control+Pause but in the X keyboard model : * they need to get the same key code as the base key on the same : * physical keyboard key. : */ : if (scanCode == KEY_SysReqest) : scanCode = KEY_Print; : else if (scanCode == KEY_Break) : scanCode = KEY_Pause; But for a Sun's type5 keyboard it means something like if (code == 'letter L') code = 'letter B' if (code == 'comma')code = 'letter V' A simple fix for this issue could be a moving this code to the part of xf86PostKbdEvent which is being executed for PC keyboards only. --- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.orig Tue Mar 4 18:34:31 2003 +++ xc/programs/Xserver/hw/xfree86/common/xf86Events.cTue Mar 4 18:41:45 2003 @@ -531,6 +531,17 @@ } /* + * PC keyboards generate separate key codes for + * Alt+Print and Control+Pause but in the X keyboard model + * they need to get the same key code as the base key on the same + * physical keyboard key. + */ + if (scanCode == KEY_SysReqest) +scanCode = KEY_Print; + else if (scanCode == KEY_Break) +scanCode = KEY_Pause; + + /* * and now get some special keysequences */ @@ -819,17 +830,6 @@ #ifdef XKB } #endif - - /* - * PC keyboards generate separate key codes for - * Alt+Print and Control+Pause but in the X keyboard model - * they need to get the same key code as the base key on the same - * physical keyboard key. - */ - if (scanCode == KEY_SysReqest) -scanCode = KEY_Print; - else if (scanCode == KEY_Break) -scanCode = KEY_Pause; /* * Now map the scancodes to real X-keycodes ... -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Hi, Err, I think is just found another problem, forgive me if it is a known problem (and I missed some email about it), but for example: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works They are 'old layouts'. % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work They are new ones. These are the settings I normally use, Scroll_Lock is of no use for me under X, but this maybe be a problem. The thing is new layouts have three-four levels and need a modifier bit for switching to those levels. But all real modifiers are already used: Lock, Shift, Control - according their names, and unnamed ones (Mod1-Mod5) are Alt, Meta, NumLock, ScrollLock and one for a Mode_Switch emulation for compatibility with the core protocol. Thus for the new ThirdLevel modifier I had to sacrifice one of them. The ScrollLock modifier seems me most unused and now this bit is used as the ThirdLevel modifier (of course the ScrollLock key still prodice a corresponded keysym). But the ScrollLock indicator still configured to show state of modifier bound to the ScrollLock keysym. I think if complaints will come I'll make an option that maps the ScrollLock virtual modifier to some real one. Otherwise we can use the indicator for something else. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click Both problems are side-effects of an adding 'special key sequences' such as Ctrl+Alt+Keypad +, Ctrl+Alt+Keypad -, etc. (You see only keys that have a special action are affected.) Tommorow I will write an explaination and will try to offer a workaround for both problems. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A bug in xset and a fix for it
David Dawes wrote: That in turn uses _XReply() to fill in a xkbGetKbdByNameReply struct, and either that call fails, or the reported field of the struct is set to zero. (line 142 in XKBGetByName.c) Does the xset call actually change the repeat rate when this happens (with your fix)? Also, do you need to do anything special to reproduce this? A check for a NULL return value from XkbGetKeyboard() should be added (and I'll do that), but I'm wondering what ignoring it might be covering up. It may seem strange but there really is a big difference between an XkbGetKeyboard call and a pair XkbAllocKeyboard - XkbGetControls calls. Since the XkbGetKeyboard call actually use an XkbGetKeyboardByName it does its task in a long indirect way: - converts all server internal structures into an .xkb file format - calls an xkbcomp and passes this text to its input - the xkbcomp writes the result as an .xkm file - the server reads and parses this file - and finally sends the result of parsing to the client In the same time the XkbGetControls just delivers contents of needed structures to the client. Thus you see there can be many reasons why the XkbGetKeyboard fails but the XkbGetControls works well. And I think the right way here isn't to check a NULL result but to get rid of the XkbGetKeyboard and use the XkbAllocKeyboard (which allocates a 'base' structure for all elements of an xkb description) and some call(s) which delivers only parts of a complete xkb description that are really needed for an application. (Unless one really needs a complete description). Regardless on does the XkbGetKeyboard fail or not it is 'too expensive' in case one wants to change a couple of flags/values in XKB server structures. Of course there still is a question why the XkbGetKeyboard (one of its steps) fails. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xkb bug in XFree 4.2.99.3
Hello, I am trying RedHat's latest beta which includes XFree 4.2.99.3 and there is a bug in the xkb code. I cannot configure a proper French Canadian keyboard. When specifying ca_enhanced in the XF86Config file, some keys on the keyboard are not mapped properly. I should apologize I missed this layout in a new xkb rules file. Thus what you got isn't a 'ca_enhanced' layout but a 'pre_XKB' keyboard map. The fix is very simple. Find the rules file (/usr/X11R6/lib/X11/xkb/rules/xfree86 or /etc/X11/xkb/rules/xfree86) and add the layout name (ca_enhanced) to the end of string ! $oldlayouts = az bs ca fr_CH de_CH hu lt_std vn mn -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: TerminateServer Keycode combination broken ...
Hi,
Stefan Dirsch wrote:
The TerminateServer keycode combination
key BKSP {
type=CTRL+ALT,
symbols[Group1]= [ BackSpace, Terminate_Server ]
};
is missing for nearly all keyboard symbol tables. Currently (CVS version
from today) it is only included for
czsk
dvorak
jp
srvr_ctrl
tel
us
us_group2
us_group3
vn
Even more. Keys such as Return, Escape, arrow keys, function keys and
some other also are missing for nearly all symbol files.
The thing is all those files are _partial_ keyboard symbol maps and must
never be used alone.
If you run a setxkbmap with a high verbose level
xkbcomp layout name -v 10
you will see something like :
...
Trying to build keymap using the following components:
...
symbols:pc/pc(pc104)+pc/de
or for some layouts you can get something like:
...
symbols:en_US(pc104)+ca
Thus you see a complete keyboard map is a combination of at least two files
(actually more files are involved in the composition becouse each of files
listed in the setxkbmap output can have an 'include' instruction which adds
some other files to the final map).
Also you can get a shapshot of the current keymap using an xkbcomp keyboard
compiler in a 'decompiler mode':
xkbcomp $DISPALY filename
and search the terminate key in the complete map.
and therefore only works for these.
If you specify (in the XF86Config file or as setxkbcomp arguments) them
as an XkbSymbols value it really doesn't work like Return, Escape and many
other keys that in this case don't work too.
But if you specify them as xkb layout names it should work.
Any plans to change this for 4.3 final release?
No plans, I think.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
