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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/04/14 05:31:59 Log message: 22. Fix a bug in XKB group adjustment (Ivan Pascal, reported Bugzilla #1566). Modified files: xc/programs/Xserver/xkb/: xkbUtils.c Revision ChangesPath 3.19 +3 -3 xc/programs/Xserver/xkb/xkbUtils.c ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/04/14 05:32:49 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3489+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
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: [I18n] Revision of keysymdef.h
Markus, Over the years, a number of problems have piled up with X11/keysymdef.h, which I have set out to sort out. I would like to add small changes into the XKB (iso9995) section of that file. First of all I don't like the keysym XK_ISO_Group_Shift is an alias for Mode_switch #define XK_ISO_Group_Shift 0xFF7E /* Alias for mode_switch */ Mode_switch in the core protocol controls some (unnamed) modifier, whereas in XKB group shift means some another action. Actually, now Mode_switch in XKB does both, i.e. sets a modifier and shifts an XKB group. But I know tasks where it would be better to separate these actions. And the second change. XKB has 4 'xkb groups' but keysymdef.h defines only keysyms for switching to the First_Group, Last_Group (and also Next_Group, Prev_Group). Some people want to use in their keymaps keysyms that are able to switch directly to the one of possible 4 groups. Also there is only one keysym that according to its name is purposed for group latching (XK_ISO_Group_Latch). Therefore it would be useful to complete this set with keysyms like: XK_ISO_First_Group_Latch XK_ISO_Second_Group XK_ISO_Second_Group_Latch XK_ISO_Second_Group_Lock XK_ISO_Third_Group XK_ISO_Third_Group_Latch XK_ISO_Third_Group_Lock XK_ISO_Forth_Group XK_ISO_Forth_Group_Latch XK_ISO_Forth_Group_Lock There is a gap in codes from 0xfe10 to 0xfe1f and I think it could be used for these keysyms. And just a question. What do you think about a bunch of keysyms from XKeysymDB for internet and multimedia keys (such as XF86AudioPlay, XF86AudioLowerVolume, XF86Mail, XF86HomePage, etc)? Are not they worth including into keysymdef.h ? -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/25 06:23:26 Log message: 139. Fixes and updates for XKB keymaps: - Replace Latvian keymap with new one (Bugzilla #1415, Dmitry Golubev). - Add geometry description for two variants of ABNT2 keyboard (Bugzilla #1387, busmanus). Modified files: xc/programs/xkbcomp/geometry/: pc xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xfree86.xml xc/programs/xkbcomp/symbols/pc/: lv Revision ChangesPath 3.17 +167 -5xc/programs/xkbcomp/geometry/pc 3.84 +4 -2 xc/programs/xkbcomp/rules/xfree86 3.84 +4 -2 xc/programs/xkbcomp/rules/xfree86.lst 1.27 +41 -15xc/programs/xkbcomp/rules/xfree86.xml 1.4 +99 -24xc/programs/xkbcomp/symbols/pc/lv ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/19 06:53:47 Log message: 137. Fixes and updates for XKB keymaps: - Update Serbian keymap with new variant (Bugzilla #1176, Zvezdan Petkovic). - Add Genius KB-12e model to inet keymap (Ricardo Cruz). - Update ABNT2 geometry file and change Brasilian keymap to avoid ABNT2 spcific keycodes section (Bugzilla #1387, busmanus). - Add 'Classical Latin' keymap (Bugzilla #1393, busmanus). Modified files: xc/programs/xkbcomp/geometry/: pc xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xc/programs/xkbcomp/symbols/: Imakefile br inet xc/programs/xkbcomp/symbols/pc/: Imakefile br sr yu Added files: xc/programs/xkbcomp/symbols/: lat xc/programs/xkbcomp/symbols/pc/: lat Revision ChangesPath 3.16 +5 -5 xc/programs/xkbcomp/geometry/pc 3.30 +10 -16xc/programs/xkbcomp/keycodes/xfree86 3.83 +2 -4 xc/programs/xkbcomp/rules/xfree86 3.83 +2 -1 xc/programs/xkbcomp/rules/xfree86.lst 3.63 +2 -2 xc/programs/xkbcomp/symbols/Imakefile 1.6 +2 -3 xc/programs/xkbcomp/symbols/br 1.40 +20 -1 xc/programs/xkbcomp/symbols/inet 1.17 +2 -2 xc/programs/xkbcomp/symbols/pc/Imakefile 1.6 +2 -2 xc/programs/xkbcomp/symbols/pc/br 1.4 +13 -1 xc/programs/xkbcomp/symbols/pc/sr 1.6 +12 -1 xc/programs/xkbcomp/symbols/pc/yu ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/19 06:55:07 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3281+7 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] Switching directly through multiple keyboards
Hi, Hi. This keyboard stuff is all very confusing to me. Is there a single, coherent, easy to understand (for hard headed understanders like me) document which explains it from first principles? I'm afraid with such conditions (single, easy and from first principles) you hardly find something. XKB principles are described in two docs XKBproto.ps and XKBlib.ps. You can find them through ftpsearch. For XKB configuration files syntax see my pascal.tsu.ru/en/xkb/ . -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] some misuse in XLC_LOCALE file
Hi, You can get some information through MSDN Thanks. But as you describes later, in theory any application is free to use any other symbols map obtained from any other source. That's what I want. Yes. And such approach doesn't require any changes in existent design but just additional API. My idea may be controversial, but I think it worth a try. I think both approaches don't contradict. It would be good if by default an application loads keymaps from a centralized store buf if anyone (programmer or user) wants a keymaps from other source he can easy do it. (The default behavior could be triggered too.) I will do some programming work to see if it is practical. OK. I wish you success. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] some misuse in XLC_LOCALE file
Hi, As to the idea of rewrite the xlib using iconv, is there a real working plan, or is it just an idea? I would say there are some thoughts what and how can be done but no one line of code yet. Fist of all, I would like to keep existent i18n modules for a fallback (anyway they are separate loadable modules and can coexist with new iconv-based module). It means the changes in other Xlib's code should be as less as possible. The thing is that Xlib's converters differs from iconv and can't be just replaced but we need to wrap iconv calls into Xlib's converters. The Xlib's converters operate with impersonal WideChar, MultiByte, etc. which meaning depends on the current locale whereas iconv operates with exact encoding names. But MultiByte everywhere in Xlib means 'encoding_name' which can be obatined from a locale name or some simple table like locale.dir and used at the converter creation. For WideChar we can take UCS2 or UCS4. Thus it is a simplest problem. The second problem is the CompoundText conversion. Standard iconv doesn't support even iso2022 for all charsets. But actually we have three cases for non-Unicode encodings. The non-standard encodings (charsets) is the simplest case. Their strings are being packed into 'extended segments' without any changes but we need to know a multibyte length or a complete esc-sequence for them. The second case is the set of standard single-byte encodings that are covered with one (strictly speaking - two) charset. They doesn't need any changes in strings but require a table of designators (esc-sequences). And the third case is CJK encodings that are represented in CTEXT with a few different charsets. But fortunately for them iconv has iso2022* encoding that is almost the same as CTEXT an can be easy converted (or rather corrected) to/from CTEXT. But the worst case is the conversion from Unicode to CTEXT. The same Unicode codepoint often can be coverted into many different charsets but will such CTEXT be accepted by Unicode-unaware application depends on the locale used in the application. It isn't CJK problem only. For example Russians still use four different charsets for the same alphabet (the ISO standard for cyrillic isn't widely used in Russia except commercial Unixes, in free Unixes the Cyrillic standard is 'koi8' come from Soviet Union standards, but there also is 'microsoft codepage 1251' that is often used in Unixes too). Therefore for this case we need some ordered list of 'preffered charsets' (or encodings that can be converted into CTEXT) that should be configurable for a separate locale. Thus anyway we need some 'locale object' that is not the same as XLCD but should keep 'encoding_name', en esc-sequence for non-standard encodings, the name of iso2022* iconv code for locales that need it and the list of preffered charsets for UTF-8 locales. What I wnat to do with the conversion part is to make related functioms get rid of XLCD binding. It's easy to achieve either by using iconv or by reusing code from lcCT.c and lcUTF8.c. I don't see how lcCT.c and lcUTF8.c could help here. The lcCT.c functions are very oriented to existent XLCD data and it has unplesant restriction. It is able to convert CTEXT to multibyte only if charset used in CTEXT presents in the current locale XLCD. If there are two application using Cyrillic but on of them uses 'koi8' whereas the another one uses 'microsoft-cp1251' for lcCT it means they are talking on absolutely different languages. The lcUTF8.c module actually is iconv but with reduced set of supported encodings. From CTEXT conversion has no problem. To CTEXT conversion need charset selection, which can be solve by either always use ISO10646-1 I don't think it is a way. If an application is Unicode-aware it should use UTF8_STRING for an inter-client communication. If some application doesn't know UTF8_STRING it is more likely it doesn't accept ISO10646 encapsulated into CTEXT. or read preffered charset from localeDB without trigger XLCD object constructed. Right. But somewhere we have to have such preffered charsets list per locale. Input related part is most complicated part. merely considering XIM part, protocol, imdkit and client side library all should be enhanced. But this make things out of control. Changing client side library only and cheating IM server at some point may be a temporary resolution. Maybe IIIMF should became mainstream, but I think more research should be done on this point. Agree. In fact, I want more here. I think three kind of input methods, namely keyboard mapping, composing and IM server, should have a common point to manage. A consistent switch method among different input methods should be offered, like Windows does. I never use complex input methods in Windows. Where can I read about them or what I have to install on Windows box to see this 'consistent switch method'? I noticed the recent discussion on composing method in this maillist.
Re: [I18n] Switching directly through multiple keyboards
Hi,
To express it more factually, is there a way to assign, let's say
SHIFT+SHIFT to a greek polytonic kbd, SHIFT+ALT to sanscrit, SHIFT+META
to phonetics, etc.
Look inside keysymdef.h for possible symbol names which might produce
desired behavior. You can notice that it's possible to switch
directly to either first or last group, but not to a specific number.
But note that the meaning of those keysyms is not hardcoded somewhere.
There are 'interpret' records (in xkb/compat/* files) where those keysyms
are tied with 'xkb actions'. But all possible actions are not limited with
keysyms mentioned in the interpret records.
For the 'direct switch' one can use actions:
LockGroup(group=1);
LockGroup(group=2);
LockGroup(group=3);
LockGroup(group=4);
How to do it? There are tree ways.
1. One can redefine interpretations for some existent but unused keysyms.
The first two actions are already bound to ISO_First_Group, ISO_Last_Group.
And for two other actions we could take unused ISO_First_Group_Lock,
ISO_Last_Group_Lock and write 'interpret' records for them into
xkb/compat/iso9995 (using interpret records for ISO_{First|Last}_Group
as an example).
2. If such spoiling of existent keysyms is unwanted we can even define own
keysyms. It can be done in X11R6/lib/X11/XKesysmDB. Find there unused codes
and names and write new lines for any kesysm name you want (e.g. LockGroup3,
LockGroup4). Of course, the next step is the same as in the previous variant -
one shoud write 'interpret' records for these new keysyms.
3. Actually it is not necessary to tie actions with keysyms. Any action can
be specified directly for a key in any xkb/symbols/* file.
For example:
key LALT {[ Alt_L, NoSymbol ],
actions[group1] = [ NoAction(), LockGroup(group=3) ] };
But the last method has some 'side effects'.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/05/08 00:27:43 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3253+13 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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: [I18n] Mode_switch woes
Hi, In XFree 4.3.0 most of keymaps were changed to allow their combining into one multi-layout keymap. But us_intl map was changed later. Therefore its behavior depends on have you 'pure' 4.3.0 or some version with additional patches. Could you run setxkbmap us_intl -print and send its output? (Note that i had to modify Alt_R (0x71) to map it to mod3 Mode_switch.) What keysyms were there before your changes? When i type Alt_R apostrophe, an apostrophe should be typed, but in actuality nothing happens. You can try to use ISO_Level3_Shift keysym instead of Mode_switch. But as I said it depends on later patches. Why won't Mode_switch work? On my desktop, which runs XFree86 4.2, i have the opposite behavior. Only the most common non-ASCII characters will be inserted. (For example, e circumflex but not c circumflex.) You mean you can combine dead_circumflex with e but the sequence dead_circumflex and c produces nothing. Is it right? The thing is that 'compose rules' in X Window are not a part of keyboard map but a separate file which choice depends on the current locale. The symbol ccircumflex can be composed in iso8859-3 and UTF-8 locales. If the locale in your XFree 4.3 is one of UTF-8 ones but in your desktop the locale is C (default) or some other but neither iso8859-3 nor UTF-8 you get such difference. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] My patch for having Right Control Key work fine in Canada (ca keyboard)
(in french, sorry) But with good pictures. :) And keyboard definitions : http://externe.net/clavier-normalise/cn-test.gz http://externe.net/clavier-normalise/cn.gz http://externe.net/clavier-normalise/cn-latin1.txt They are complete keyboard maps in xkb format (except the last one). Excelent! I would like to include it in XFree's xkb stuff with minor changes (mainly remove the keys that are common for all keymaps). I already wrote to clavieratexterne.net. Many thanks. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[XFree86] Xkb failures
Hi, Generally, I use the following configuration (or sometimes its XF86Config equivalent, but that only on some machines I installed and had no problems with) for most (PC104) keyboards I work with: setxkbmap -keycodes 'xfree86' -types 'complete' -compat 'complete+leds(scroll)' -symbols 'us(pc104)+altwin(meta_win)+altwin(meta_alt)+il+group(shift_toggle)' -geometry 'pc(pc104)' BTW you could get the similar keymap with a simpler command setxkbmap us,il -model pc104 -option grp:shift_toggle,grp_led:scroll,altwin:meta_win,altwin:meta_alt Why can't setxkbmap give some more insightful diagnostics (why did it fail, where?) The thing is that setxkbmap itself doesn't load keymap but sends all names to the Xserver. The server in its own turn runs an exteranal program xkbcomp which 'compiles' the keymap from source files and writes the map in a binary form into a special file that is then read by Xserver. Since xkbcomp parses the source files it writes to stderr messages if something is wrong in input files. But those message don't reach setxkbmap and it only can say a 'common' result of loading, i.e. was is successful or not. Any idea what the problem is? Why is the behaviour so random between different hosts? In XFree86 4.3.0 and later you can easy connect setxkbmap and xkbcomp directly. Run setxkbmap . -print | xkbcomp - and see xkbcomp's error messages. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/04/03 05:43:43 Log message: 55. Fixes and updates for XKB keyboard maps: - Add nodeadkeys variant to gb keymap (Philip Clayton). - Rename microsoftprose keyboard model to microsoftprousb because it is not Swedish specific but common USB variant (Bugzilla #1155, Alex Holland) - Fix wrong brokenbar keysym in de_CH keymap (Bugzilla #1255, Adrian Fiechter) - Add German Dvorak keymap (Bugzilla #1280, Andreas Rüden) - Add Sorbian keymap (Bugzilla #1304, Edi Werner) - Update Hindi/Devanagari keymap (Bugzilla #1317, David Holl) Modified files: xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xc/programs/xkbcomp/symbols/: de_CH dev gb inet xc/programs/xkbcomp/symbols/pc/: Imakefile dev dvorak gb Added files: xc/programs/xkbcomp/symbols/pc/: hsb Revision ChangesPath 3.81 +2 -2 xc/programs/xkbcomp/rules/xfree86 3.82 +3 -2 xc/programs/xkbcomp/rules/xfree86.lst 3.7 +2 -2 xc/programs/xkbcomp/symbols/de_CH 1.2 +64 -62xc/programs/xkbcomp/symbols/dev 3.8 +7 -2 xc/programs/xkbcomp/symbols/gb 1.39 +19 -13xc/programs/xkbcomp/symbols/inet 1.16 +2 -2 xc/programs/xkbcomp/symbols/pc/Imakefile 1.3 +63 -54xc/programs/xkbcomp/symbols/pc/dev 1.7 +77 -1 xc/programs/xkbcomp/symbols/pc/dvorak 1.8 +14 -2 xc/programs/xkbcomp/symbols/pc/gb ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/04/03 05:44:26 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3205+11 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] Re: Alt + CHTN for arrow key movement, XKB?
Hi,
Sorry for the delay. This task appeared more complex than I thought.
Ahmad Baitalmal ahmad at baitalmal.com writes:
So I think I'm even closer,
I ran xev to see what I'm getting.
It seems to be sending Up when I hit Alt+C which is perfect, but the state is
modified to 0x8 whick means that the Alt key is pressed (right?). So what's
being sent is really Alt-Up.
Yes. This Alt modifier 'spoils' the combination.
So ho do I cancel that Alt and just send Up?
There is a way to do that. XKB allows to tie so called 'actions' to a key
besides keysym. And there is a special action RedirectKey that allows to
emulate any other key event with needed modifiers.
In the keymap you can specifiy in addition to keysyms an actions list:
key AB03 { type=ALT_ALPHABETIC,
[ c,C, Up ],
actions[Group1]= [ . ] };
(Note, there should be comma after the keysyms list.)
Since first two cells in the list (corresponed to c, C keysyms cells) don't need
an action you have to fill them with 'NoAction()' word.
And the action for third cell can look like
Redirect(key=UP, clearmods=Alt)
Note, the 'key' there is not a keysym but a keycode name because the action is
processed on the server side and emulates a press of another physycal key.
But unfortunately this feature is still buggy.
First of all XKB doesn't understand UP there probably because this name is
too short (it understands DOWN or, say, END well). I'll fix it bug but
now I can offer a workaround only. Add to the xkb/keycodes/xfree86 file
(somewhere at the end of the first section) the line
alias UPAR = UP;
(just another name for the UP physical key)
and use this name in the redirect action
actions[Group1]= [NoAction(),NoAction(), Redirect(key=UPAR, clearmods=Alt)]};
But the second bug is worse. Any RedirectKey action causes a server crash in
XFree up to 4.3.0 version. It was fixed in May 2003 (after 4.3.0 release)
and you can use this feature only if your Xserver is based on some
intermediate releases issued after this month.
And if you will try this action don't forget to add
virtual_modifiers Alt;
into your xkb/symbols/* file.
Also, I will need Shift+Alt-C to send Shift-Up, where can I do that?
It's simplier. Add into new type description an additional line for Shift+Alt
combination:
type ALT_ALPHABETIC {
modifiers = Shift+Lock+Alt;
map[Alt+Shift] = Level3;
...
};
Since it leads to the same level and the same Redirect action the combination
Shift+Alt-C emulates the same UP key with Shift but without Alt.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] My patch for having Right Control Key work fine in Canada (ca keyboard)
Hi, I'm using ca keyboard, and was tired that this right control key was mapped to some 5th modulator key that's seems completely useless... The 'ca' keymap is overloaded with symbols. There are up to 5 symbols per key there and the additional modifier is needed to access fifth symbols. So I patched /etc/X11/xkb/symbols/ca, with the following patch of my own, and it works perfectly fine. I think many people would appreciate this to be the default. I'm going to make some additional variants of 'ca' keymap. Among Microsoft's keyboard layouts there are three variants of Canadian keyboard - French, French (Legacy) and Multilingual. Two first use only AltGr modifier and the last only really needs an additional modifier that is RightCtrl too. I hope many people would be satisfied if thay could choose simpler French Canadian keymap. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
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: [I18n] questions about convert functions
Hi,
For the second question, cs* are used for CTEXT encoding, fs* are used
for font rendering, these definitions can be different.
This doesn't convince me.
Nothing wrong there. The cs* sets are used for conversion from CTEXT as well
as to CTEXT. When a convertion module converts some multibyte (or wide char)
string into CTEXT or codes that can be used for rendering it tries charsets
in the order they are numbered.
You can see that in the zh_TW.big5 locale the charset 'cs1' completely
overlaps two next ones. The codes that fall into cs1 range are multibytes
with the first byte 0xa1-0xf9 (the second byte value doesn't matter here),
whereas cs2 covers multibutes with the first byte in the range 0xa1-0xc7 and
the cs3 charset deals with multibytes where the first byte is one from
0xc9-0xf9. Thus the cs2 and cs3 charsets in the multibyte point of view are
subsets of cs1. And when the converter module prepares multibytes for
rendering (converts them into glyph indexes) it never comes to cs2 and cs3
and the corresponded fs*'s are unneeded.
Those two additional charsets are useful for opposite conversion (from CTEXT)
only.
Considering a process running under zh_TW.big5 locale, when get a CTEXT
element(with ESC sequence indicates BIG5-E0/E1 charset) through certain
ICC method, it will convert to CharSet before use it.
Not exactly. When an application gets a CTEXT segment the segment already
match one of CharSet record. Before use it the application converts it
into multibyte string.
But the element will convert to cs2 or cs3(no way to cs1), which has no
corresponding fs* definition. How it supposed to be correctly rendered?
Xlib doesn't render CTEXT string directly. You should call one of
X{mb|wc|utf8}Draw* function and feed it with multibyte, wide char or utf8
string. But as I said above such string will always be converted into cs1 and
never into cs2/cs3 charsets. (Frankly speaking the wc_encoding values are
actually wrong in that locale description. And if one tries to convert CTEXT
into WC directly and then draw that WC string it will fail, really. But it's
a bug. With MB or UTF8 strings it should not happen.)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
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: [I18n] French (AZERTY) + greek polytonic keyboard
Hi, Danilo Segan [EMAIL PROTECTED] dixit : With XFree86 4.3, multigroup layouts have been, sort of, abandoned -- you should probably create separate groups for each, and combine them using setxkbmap, xkbcomp features. Thank you, Danilo. If I answered before your post I would say the same. Yep, I tried to set up that thing using ? include ? features. It failed. I couldn't figure out why, though. So I decided to merge both groups into a multigroup description. But I still can split them quite easily. Well. Let try to fix it together. What did you do? And what problems or error messages you got? There's always bugzilla.xfree86.org, where you could probably file a RFE if you want to see this in some next version of XFree86. I've no clue whether it may interest XFree86 developers... You could try. In a worst case your offer would be rejected. :) But actually it would not happen. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/20 07:15:56 Log message: Update XKB registry file rules/xfree86.xml (Sergey Oudaltsov), reflects CHANGELOG 759. Modified files: xc/programs/xkbcomp/rules/: xfree86.xml Revision ChangesPath 1.25 +25 -1 xc/programs/xkbcomp/rules/xfree86.xml ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/17 07:04:16 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3104+5 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/17 06:59:37 Log message: 759. Updates for XKB keyboard maps: - Add Tibetan/Dzongkha keyboard layout (Bugzilla #1082, Gregory Mokhin) - Add three new Internet/multimedia keyboard descriptions (Bugzilla #1088, Radics Laszlo) Modified files: xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xc/programs/xkbcomp/symbols/: inet xc/programs/xkbcomp/symbols/pc/: Imakefile Added files: xc/programs/xkbcomp/symbols/pc/: dz Revision ChangesPath 3.80 +4 -4 xc/programs/xkbcomp/rules/xfree86 3.81 +5 -1 xc/programs/xkbcomp/rules/xfree86.lst 1.38 +89 -1 xc/programs/xkbcomp/symbols/inet 1.15 +2 -2 xc/programs/xkbcomp/symbols/pc/Imakefile ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/09 06:46:07 Log message: 751. Fix some rules in en_US.UTF-8 Compose file (Bugzilla #1071, Matthew Fischer). Modified files: xc/nls/Compose/: en_US.UTF-8 Revision ChangesPath 1.12 +4 -4 xc/nls/Compose/en_US.UTF-8 ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/09 06:59:18 Log message: 752. Update XKB registry file rules/xfree86.xml (Sergey Oudaltsov). Modified files: xc/programs/xkbcomp/rules/: xfree86.lst xfree86.xml Revision ChangesPath 3.80 +3 -3 xc/programs/xkbcomp/rules/xfree86.lst 1.24 +410 -9xc/programs/xkbcomp/rules/xfree86.xml ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/06 05:14:06 Log message: 734. Update Compose file for en_US.UTF-8 locale (Bugzilla #1053, Matthew Fischer) and fix wrong comment signs there (Ivan Pascal). Modified files: xc/nls/Compose/: en_US.UTF-8 Revision ChangesPath 1.11 +259 -233 xc/nls/Compose/en_US.UTF-8 ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/06 05:35:35 Log message: 735. Add xkb keymap for Microsoft Mutimedia Keyboard keys (Bugzilla #1052, Jacques Legare). Modified files: xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xc/programs/xkbcomp/symbols/: inet Revision ChangesPath 3.78 +2 -2 xc/programs/xkbcomp/rules/xfree86 3.78 +2 -1 xc/programs/xkbcomp/rules/xfree86.lst 1.36 +44 -1 xc/programs/xkbcomp/symbols/inet ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/06 05:49:29 Log message: 736. Fix memory double freeing at XIM destroying in imLcIm.c (Ivan Pascal, reported: Bugzilla #1015). Modified files: xc/lib/X11/: imLcIm.c Revision ChangesPath 1.13 +3 -1 xc/lib/X11/imLcIm.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/06 05:56:30 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3081+7 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/30 05:26:26 Log message: 710. Fixes and updates for XKB keyboard maps: - Fix Armenian phonetic keymap (Bugzilla #1016, Ani). - Fix rules for Brasilian ABNT2 keyboard (Ricardo Y. Igarashi). - Add Shift+CapsLock group switcher (Ivan Pascal, see Bugzilla #1025). - Update rules/xfree86.lst with missing descriptions (Ivan Pascal). Modified files: xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xc/programs/xkbcomp/symbols/: group xc/programs/xkbcomp/symbols/pc/: am Revision ChangesPath 3.76 +4 -3 xc/programs/xkbcomp/rules/xfree86 3.77 +7 -2 xc/programs/xkbcomp/rules/xfree86.lst 3.9 +8 -1 xc/programs/xkbcomp/symbols/group 1.5 +8 -7 xc/programs/xkbcomp/symbols/pc/am ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/30 05:31:18 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3059+6 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/22 06:59:07 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3045+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/18 06:11:05 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3039+8 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/18 06:14:39 Log message: 667. Fixes and updates for XKB keyboard maps: - Add to 'us' keymap backslash key that can be rewritten in other layouts (Bugzilla #976, Børre Gaup). - Fix some keys in Georgian latin keymap (Bugzilla #985, Vano Beridze). - Add Korean keymap (Jungshik Shin). - Add French variant of 'dvorak' keymap (Josselin Mouette). - Fix wrong key type in the 'keymap without special keys' (Ivan Pascal). Modified files: xc/programs/xkbcomp/: expr.c xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/xkbcomp/rules/: xfree86.lst xfree86.xml xc/programs/xkbcomp/symbols/: dvorak ge_la srvr_ctrl xc/programs/xkbcomp/symbols/pc/: dvorak ge_la us Revision ChangesPath 3.8 +2 -1 xc/programs/xkbcomp/expr.c 3.29 +6 -1 xc/programs/xkbcomp/keycodes/xfree86 3.76 +2 -1 xc/programs/xkbcomp/rules/xfree86.lst 1.22 +13 -0 xc/programs/xkbcomp/rules/xfree86.xml 3.11 +113 -1xc/programs/xkbcomp/symbols/dvorak 1.2 +5 -5 xc/programs/xkbcomp/symbols/ge_la 1.4 +3 -1 xc/programs/xkbcomp/symbols/srvr_ctrl 1.4 +68 -1 xc/programs/xkbcomp/symbols/pc/dvorak 1.3 +5 -5 xc/programs/xkbcomp/symbols/pc/ge_la 1.7 +4 -1 xc/programs/xkbcomp/symbols/pc/us ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] Changes for xkb/symbos/pc/br
Hi, OK, I have noted that the maps are different, and I suppose they are in accordance with what you wrote in The XKB internals (I should confess I couldn't understand this text very well...). I guess. Even in Russian (the language the text was origianly written) it is quite complicated. And my poor English translation doesn't make it clearer. If you pointed me exactly sentences or paragraphs that are unclear for you I could rework them somehow. I would like to try the new maps in pc directory; all I need is to change the XF86Config from: Option XkbLayout br to: Option XkbLayout pc/br No. Those XkbModel, XkbLayout, XkbOption are another abstraction level and they are being mapped to files names using XkbRules. The rules file in 4.3.0 is also rewritten and maps layout names to 'pc/[layout name]'. (Since you have XFree 4.3.0 you can check it running setxkbmap program with '-print' option.) On the contrary to make the server get the keymap file from symbols directory is a bit tricky. If you want to use such old file you need to add the layout name into the list of 'old layouts' in xkb/rules/xfree86 file. And I am still using 4.3.0 (I have just downloaded the Xetc.tgz of 4.4 beta); do these maps work on 4.3.0? They appeared in XFree86 4.3.0. :) BTW, the Japanese map is missing in the pc directory... I left some maps unconverted for different reasons. Frankly speaking I don't remember why the Japanese map is one of them (probably because it has a separate rule in the rules file). On the other hand nobody complained. :) I will add such keymap some day. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Changes for xkb/symbos/pc/br
Hi, One question: the use of pc/[language code] will be the standard in XFree86 4.4? Yes. If you are talking about [language code] for keyboard map name nothing is changed there yet. There were proposals discussed here for new keyboard maps that implied name changes of some maps but that work still isn't complete. If you mean the 'pc' directory for XKB symbols maps it's right too. You see that the maps in symbols/pc differ from ones in symbols directory. The maps were rewritten to allow combining them easy in one multi_layout keymap. But existent maps were left for compatibility and as a fallback for the case of possible issues with new maps. Thus 'old' maps are kept in symbols directory and new maps are in symbols/pc. (The name 'pc' was chosen because other vendor keyboard maps have own directories and it would be right to place in the symbols itself only pieces that are common for all maps.) BTW. I added us(intl) submap (i.e. a variant of US keymap) making it similar to MS Windows US International keymap as much as possible. If one complain on us_intl map you can suggest to try this new one. :) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/09 05:49:21 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3030+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/09 05:51:34 Log message: 661. Update Brazilian keyboard map (Ricardo Y. Igarashi). Modified files: xc/programs/xkbcomp/symbols/pc/: br Revision ChangesPath 1.4 +4 -1 xc/programs/xkbcomp/symbols/pc/br ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/05 05:14:48 Log message: update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3020+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/05 05:17:55 Log message: 651. Update XKB registry file rules/xfree86.xml (Sergey Oudaltsov). Modified files: xc/programs/xkbcomp/rules/: xfree86.xml Revision ChangesPath 1.21 +2183 -364 xc/programs/xkbcomp/rules/xfree86.xml ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/03 06:09:09 Log message: 646. Fix for XKB map 'altwin' to avoid one keysym to more than one modifier mapping (Ivan Pascal). Modified files: xc/programs/xkbcomp/symbols/: altwin Revision ChangesPath 1.5 +3 -3 xc/programs/xkbcomp/symbols/altwin ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/02 05:13:08 Log message: 633. Fixes for XKB keyboard maps: - fix Meta, Super, Hyper keysyms interpretation - fix typo in rules/xfree86.xml (Ivan Pascal). Modified files: xc/programs/xkbcomp/compat/: misc xc/programs/xkbcomp/rules/: xfree86.xml Revision ChangesPath 1.5 +4 -4 xc/programs/xkbcomp/compat/misc 1.20 +1 -1 xc/programs/xkbcomp/rules/xfree86.xml ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] UTF8 related font selection is broken multibyte encoding disagreement with libc
Hi, The original i18n part of Xlib is very iso-2022 oriented and lately added Unicode support doesn't fit its design well. It assumes that in every locale the whole range of mutibyte codes can be divided to some non-overlaped charsets (strictly speaking it usualy deals with GL/GR halfs of charsets) and there is only one way of such division. Each charset is fully covered with one font (in the fonts encoding meaning). The list of those charsets and the scheme of 'mb/wc codes range to particular charsets' division is described in the locale description file. Therefore the task of XCreateFontSet is to find one font for each charset and the task of the drawing routine at a single char drawing is to find what charset this mb/wc code match, convert the code to the glyph index and draw it using the font prepared by XCreateFontSet. Even if XCreateFontSet can find more than one fonts for some charset, only first one is used because there is no information why one of fonts is better than others for a single char. But with UTF-8 locales this scheme doesn't work because * Unicode (iso-10646) encoded font overlaps with any iso-2022 based font * in UTF-8 locale a single mb char can be converted into more than one iso-2022 charset. To solve this problem somehow the UTF-* module uses a list of 'preferred charsets'. One such list is builtin in Xlib (it is used in Xutf8* routines) and also the module makes an additional list gathering charsets from the locale description file in the order thy are mentioned in this file. The 'supreset' iso-10646 can be used in this list too. If it is the first one in the list all other charsets are never tried. Problem 1 ... The Xmb routines never use any other fonts but the iso10646-1 helvetica that does not contain all characters, because fonts are selected based on first matching character set and iso10646 seems to be preferred. Now many UTF-8 locales actually share one description file. Therefore this common file is rather a template than a proper locale description file. In this file iso-10646 encoding stands as the first one and all other charsets are left there as examples of charsets that can be used there. If you want the iso-10646 font is used as a 'last resort' you need to change the order of fs's in the locale description file (XLC_LOCALE). Studying the Xlib source code, apparnetly Xmb in UTF8 locale selects fonts by the order of fonts in the fontset, that does not match the order of fonts in the request pattern to XCreateFontSet. Shouldn't the pattern matter? Shouldn't the glyphs actually implemented in a font matter, in particular in case of iso10646 fonts? The thing is that the fontset creation and the string drawing are relatively independed. The font creation procedire uses the base_font_name_list (the pattern) for the font finding only and doesn't store it for any other usage. The string drawing routine gets 'preferred charsets' list from the locale description but not from the base_font_name_list. I would not like to change that because * the pattern may doesn't have any order information (it can be something like -adobe-helvetica-*) or this information can be incomplete. Hence is isn't clear how to merge the orders got from the pattern and from the locale description. * some locales (ja_JP, ko_KR, zh_TW, etc.) already have own description files where the 'preferred order' is already defined. If apllications begin to ignore that order and use the order from the pattern it will be considered as unexpected and unwanted behavior. Example 2. Same as above, Xutf8 routines. These routines seem to prefer iso8859-1 encoding and indeed a fixed-width font with that encoding is in the fontset. But the user wanted helvetica! It can be a bug. But I don't know all conditions. Can you give some example code or just tell what pattern and what locale were used in that case. It seems Xutf8 routines select fonts from the fontset by a fixed list of encodings, filtered by the locale. Yes. Again, font select based on character set guess is wrong. May be. Example 3. Same as above, remove iso10646-1 helvetica from system. Situtation is reversed. Xmb routines use a fixed-width font, Xutf8 routines helvetica. Give more details, please. At least the pattern and the locale under which it happens. Problem 2 All the drawing routines also have the problem of stopping processing the string when an encoding is selected for which there is no font in the fontset, even if some font with other encoding might implement the wanted glyph. Yes. As I tried to explain it's the i18n module design. In iso-2022 based scheme it is impossible that in a single locale some font with other encoding might implement the wanted glyph. Once again, font selection should be based on the available fonts, not the first matching encoding and there's no need to skip the rest of the string even if a font can't be found. It requires deeper
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: [I18n] KeySyms 5 to 8, multiple character sequences
Hi, From what you say ... I can forget KeySyms above 4 ... as the XLookupString does not allow to access them ... Yes. The XLOCALEDIR is also a problem ... I would need to replace the whole set of locales Why? You need to copy the locales you really use. I don't think you use all of over 50 locales that XFree has. ... would it work with XFree86 3.3.6 at all ? Yes. ... it should, however, work with standalone XTerminals, shouldn't it ? Yes. The whole compose processing works on the client side machine and doesn't depend on the Xserver you use. What remains then is the XKB ... I must say that I looked at it ... and it seems to be really complicated ... does it also work with XFree86 3.3.x ? Yes. ... I can forget standalone XTerminals, can't I ? Yes, unfortunately. To me, it seems that (as in the case of XLOCALEDIR) I would need to define my own whole set of keyboards ... again ... I could not find any simple solution to merge my own set of definitions with these that were loaded when the Xserver was started ... Maybe a solution for you could be an utility that allow to reload xmodmap maps quickly when you are working. In such case you use a few four-columns maps but can switch among them quickly using hotkeys. And if such switcher uses the core protocol (what xmodmap does) it works even with Xterminals. I'd suggest you to try xruskb ( ftp://ftp.yars.free.net/pub/software/unix/X11/ ) It does the things I'm talking about. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] KeySyms 5 to 8, multiple character sequences
Hi,
The XFree86 is 4.2.0 on a Linux/i386 machine ...
The first question is the following : (as far as I know) a key may
generate up to eight KeySyms ... the first four elements of the list are
You are deceived, there can be up to 256 keysyms for one key. :)
But...
split into two groups of KeySyms and are accessible as : Key /
Shift-Key / Mode_switch-Key / Shift-Mode_switch-Key ...
How can I access KeySyms 5 to 8 ?
(I can easily assign them using xmodmap, but I have found no
key-combination which would allow me to access them later ...)
Actually the server sends to an application a keycode (row number in the xmodmap
table) and a set of modifiers. And the application itself should decide what
column should be chosen for such set of modifiers. Most of applications use
the Xlib's function XLookupString that performes that choosing. But according
to the core protocol specification it interprets only part of modifiers (Shift,
Mode_switch, CapsLock, NumLock) and can choose one column among first four ones.
But XFree86 has XKB (X Keyboard extension) that allows to use more columns.
Using XKB (it is switched on by default) you can design own rules ('key types'
in XKB terms) that take in account any subset of modifiers and define what
column match each combination of modifiers from that subset. On the other hand
XKB tables have more complex structure. All keysyms for one key are divided
to 'groups' (up to four) and 'levels' (up to 64) inside the groups. Groups
and levels can be switched independly. For more details see
http://pascal.tsu.ru/en/xkb/
The second question is the following : the LANG and XLOCALEDIR decide
which multiple character sequences are working ... they are defined in the
appropriate Compose file ... and are accessible with help of the so
called Multi_key ...
How can I add/define my own multiple character sequences (merging and/or
replacing the original ones) ?
Note here that I do NOT want to modify the original Compose file ...
With your last condition there is no way (unless you make own locale dirs
tree and set XLOCALEDIR pointing to it).
But in the current XFree it is possible. I wrote in this mail-list about
improvements made for Compose files and you can find that message in archives.
But you guess you need the latest beta version of XFree or wait 4.4.0 release.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/31 06:32:05 Log message: 540. Improve xkbcomp's key types auto-recognition (Ivan Pascal). Modified files: xc/programs/xkbcomp/: symbols.c xc/programs/xkbcomp/symbols/: us xc/programs/xkbcomp/symbols/pc/: us Revision ChangesPath 3.16 +43 -10xc/programs/xkbcomp/symbols.c 3.15 +2 -2 xc/programs/xkbcomp/symbols/us 1.6 +2 -2 xc/programs/xkbcomp/symbols/pc/us ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] redefining keys
Hi, I have got a notebook with a trackpad and 2 mouse buttons. The middle button is emulated. I find it very inconvenient to press these 2 buttons at once. But I have got the 2 windows buttons I have never used with linux. Is it feasible to redefine the combination of pressing the windows key (reported as Super_L by xev) and mouse button 1 as mouse button 2 and let's say Super_L+Shift (or ALT)+mouse button 1 as mouse button3? XKB allows emulate mouse button events by keyboard keys. But there is not simple way to use keys as modifiers for real mouse buttons. There are special keysyms such as Pointer_Button1, Pointer_Button2, etc. which can be assigned to any keyboard key. Also the keyboard should be switched to 'mouse keys mode'. In this mode these keysyms prodice mouse buttons events. Further I want the Menu button (reported as Menu by xev) to behave like an ALT key. I have noticed Alt_L reports only one keypress/keyrelease event pair if pressed for a longer period but Menu generates a lot of them. How to change that? IIRC the keyboard driver automaticaly cancels autorepeat if a key has keysym that is a modifier (Alt_*, Shift_*, Control_*) independly on wht physical key it is. You can assign Alt_L keysym to the key you want ant test it. (You can use xmodmap for such experiments.) Anyway if such canceling doesn't work you can disable an autorepeat explicitly in a keyboard map. Can that all be achieved configuring xkb? Yes. But you need to edit keyboard maps manualy (or use xmodmap). The XKB options in XF86Config allow to choose some set of keymap pieces already prepared. If your wishes are unusual (they are) there are not corresponded predefined submaps in XKB configure files and you need to write all changes into those files yourself. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/25 06:25:12 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2903+7 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/14 06:36:31 Log message: 500. Add 'inet' keymaps for two Logitec keyboard models (Bugzilla #762, Eric Mountain; Bugzilla #766, Chris Hornbaker) and cleanup Logitec keymaps (Ivan Pascal). Modified files: xc/programs/xkbcomp/rules/: xfree86 xfree86.lst xfree86.xml xc/programs/xkbcomp/symbols/: inet Revision ChangesPath 3.75 +3 -3 xc/programs/xkbcomp/rules/xfree86 3.74 +5 -11 xc/programs/xkbcomp/rules/xfree86.lst 1.18 +8 -48 xc/programs/xkbcomp/rules/xfree86.xml 1.34 +127 -211 xc/programs/xkbcomp/symbols/inet ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/14 06:38:57 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2883+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/14 06:41:20 Log message: fix typo Modified files: xc/programs/xkbcomp/symbols/: inet Revision ChangesPath 1.35 +3 -3 xc/programs/xkbcomp/symbols/inet ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/13 04:32:27 Log message: 499. Add missing SetScreenSaverTimer() to ProcSetScreenSaver (Ivan Pascal). Modified files: xc/programs/Xserver/dix/: dispatch.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.31 +3 -1 xc/programs/Xserver/dix/dispatch.c 3.2882+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
[I18n] Inet keys for Logitech keyboards.
Hello,
This proposal has no relation to i18n but since most of keyboard mapping issues
we discuss here I chose this list.
It happened that we have in Bugzilla two additions for the inet file (multimedia
and internet keys mapping) and both for Logitech models. Note that we already
have 15 maps for Logitech keyboards an it is a bigest group among all inet
keymaps.
Therefore I decided to look at those map closely and try to figure out how many
actually different keymaps exist among Logitech models. I made a summary table
for keysyms used in those maps and keycodes that can be different for different
Logitech models. The results are:
Fortunately there is a group of common keys, the keys that have the same
keycode-keysym mapping in all models. They are keys such as XF86Standby,
XF86Mail, XF86Search.
There are two (and only two) different mappings for Audio keys. Also there
are at least two type of mapping for keys such as XF86Shop, XF86VendorHome,
XF86Favorites.
One model we have and both maps proposed in Bugzilla have 'Extended Function
keys'. And some models have a wheel and related buttons.
Some keys are maped to different keysyms in different models but meaning of
such keysyms seems to me very similar. Examples:
* Most of models have the key I5F - XF86Standby but in one model it has
keysym XF86PowerOff.
* There is a key that in some models is mapped to XF86Shop keysym but in
one model the keysym is XF86Market.
* Some models have keysym XF86VendorHome but in some others the key with
the same keycode has keysym XF86iTouch.
When I had replaced such keysyms with more often used ones and moved 'common'
and 'audio' parts into separate submaps I found that some model maps are
almost identical. For example
Logitech Cordless Desktop Pro
// common part
key I66 { [ XF86Go] };
key I21 { [ XF86VendorHome] };
Logitech Cordless Desktop Pro (alternate option2)
// common part
key I66 { [ XF86Start ] };
Logitech Internet Keyboard
// common part
key I66 { [ XF86Go] };
And another example:
Logitech Cordless Desktop Optical
// common part
key I66 { [ XF86Favorites ] };
key I16 { [ XF86WheelButton ] };
key I69 { [ XF86Go] };
key I6A { [ XF86Back ] };
Logitech Cordless Freedom/Desktop Navigator
// common part
key I66 { [ XF86Favorites ] };
key UP{ [ XF86ScrollUp ] };
key DOWN { [ XF86ScrollDown] };
key I16 { [ XF86ScrollClick ] };
key I69 { [ XF86Forward ] };
key I6A { [ XF86Back ] };
(I think XF86WheelButton and XF86ScrollClick actually mean the same button
and XF86Go with XF86Forward are different names for the same key.)
And now I am going to merge some maps and reduce their quantity. I realize
it can confuse users who have already configured their soft with such keysyms.
But it makes life easer for those who buy Logitech keyboard and need to choose
appropriate model name from our list.
According to Logitech site they currently offer (or at least support) more
than 20 models and I suppose there also are some old models. We just can't
maintain a complete set of keymaps for all model names they invent. I think
it would be better to describe those models according to their appearance.
Something like
Internet
Internet, with wheel
Internet, with wheel, with extended function keys
Any objections?
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 04:44:00 Log message: 496. Added USB keyboard support for Solaris/x86 platform (Bugzilla #352, Daniel Rock). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: atKeynames.h xc/programs/Xserver/hw/xfree86/os-support/sunos/: sun_kbd.c sun_kbdEv.c Revision ChangesPath 3.2877+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.21 +17 -1 xc/programs/Xserver/hw/xfree86/common/atKeynames.h 1.2 +4 -3 xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_kbd.c 1.6 +252 -2xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_kbdEv.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/09 04:45:27 Log message: 496. Added USB keyboard support for Solaris/x86 platform (Bugzilla #352, Daniel Rock). Modified files: xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/xkbcomp/symbols/sun/: Imakefile Added files: xc/programs/xkbcomp/symbols/sun/: usb Revision ChangesPath 3.26 +20 -4 xc/programs/xkbcomp/keycodes/xfree86 1.6 +2 -2 xc/programs/xkbcomp/symbols/sun/Imakefile ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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: [I18n] us_intl + Russian in 4.3.0
Hi, Sorry. I forgot that us_intl is 'old style' keymap. For such maps you need grp:*_switch options instead of lv3:*_switch. I.e. if you change lv3:lwin_switch to grp:lwin_switch you will get access to extra symbols of us_intl. OK, I did it, but it's almost a same story. I can get a larger number of extended Latin characters, but still no extra symbols available. I nee eurosign, (AltGr+5), copyright (AltGr+c), French quotation marks ( , respectively AltGr+[ and ]), german ss, superscript o, a, 1, 2, 3 and so on. I am not a maintainer of 'us_intl' map itself. It it differs from MS Windows Intl keymap it just means nobody complains of its incompleteness yet. You can write a bugreport on bugs.xfree86.org. I understand the problem better now, but I don't need all those characters and I miss some I use every day. Now I need to insert a special symbol every time I want to put a price in euros, i.e. dozens times per day. Not very convenient. I suggested you to update the xkb stuff from CVS. At least EuroSign presents in the current version (it was added after 4.3.0 release). Because of all those problems with Compose rules, I think there should exist many XkbVariants for different national character assignments. For example, if I want to have my usual US international + Russian setup AND the possibility to use AltGr mode to have all non-Russian cyrillic characters as all Mac users do, I should have the possibility to edit my XF86Config-4 like this: Option XkbLayout us,ru Option XkbVariant (withdeadkeys+eurointernational),(winkeys+fullcyrillic) Option XkbOptions grp:alt_shift_toggle,lv3_AltGr,compose:menu Yes. If you (or someone else) think some variant of any existent layout would be useful you can make a report. Even if you have not enough skills to make a patch you can write some description where and what symbols should be added to an existent keymap. BTW I made a 'multi_layout compatible' variant of us_intl map but, of course, it is not more complete than the map you have currently. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/04 03:25:14 Log message: 476. Fixes and updates for XKB keyboard maps: - Add 'United Kingdom w/deadkeys' gb(intl) keymap (Bugzilla #744, Phil Jones). - Add multi_layout compliant 'us_intl' keymap (Ivan Pascal). - Fix 'macintosh' geometry file (Bugzilla #753, Simon Vallet). Modified files: xc/programs/xkbcomp/geometry/: macintosh xc/programs/xkbcomp/rules/: xfree86 xfree86.xml xc/programs/xkbcomp/symbols/: gb xc/programs/xkbcomp/symbols/pc/: Imakefile gb Added files: xc/programs/xkbcomp/symbols/pc/: us_intl Revision ChangesPath 1.4 +60 -41xc/programs/xkbcomp/geometry/macintosh 3.74 +1 -2 xc/programs/xkbcomp/rules/xfree86 1.17 +8 -1 xc/programs/xkbcomp/rules/xfree86.xml 3.6 +37 -1 xc/programs/xkbcomp/symbols/gb 1.13 +2 -2 xc/programs/xkbcomp/symbols/pc/Imakefile 1.6 +33 -1 xc/programs/xkbcomp/symbols/pc/gb ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/04 03:26:03 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2870+6 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] us_intl + Russian in 4.3.0
Hi, OK, I configured as follows: us_intl lv3:lwin_switch,compose:menu So, I use only US_intl Dead keys work, but we still have the problem with c cedilla. I must use Compose+,+c to get it. The problem is that even if I press Compose key I get often the plain vanilla ,. I need to carefully press Compose, wait a second, press , then c. On the other side, AltGr just doesn't work. I get the usual characters, not some extra. Impossible to get eurosign or something like this. Sorry. I forgot that us_intl is 'old style' keymap. For such maps you need grp:*_switch options instead of lv3:*_switch. I.e. if you change lv3:lwin_switch to grp:lwin_switch you will get access to extra symbols of us_intl. BTW a complete (or almost complete) list of possible options and layouts you can find in X11R6/lib/X11/xkb/rules/xfree86.lst . Unfortunately the structure of this file is not suitable for xkb variants. Therefore for variants you need to read xfree86.xml file in the same directory. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/27 06:31:59 Log message: 456. Fixes and updates for XKB keyboard maps: - Update xkb geometry files (Alexander Pohoyda). - Fix German-Romanian maps (Manfred Pohler). - Cleanup Hungarian layout (Bugzilla #730, Egmont Koblinger). Modified files: xc/programs/xkbcomp/geometry/: chicony hp pc xc/programs/xkbcomp/geometry/ibm/: thinkpad xc/programs/xkbcomp/rules/: xfree86.xml xc/programs/xkbcomp/symbols/: de hu hu_qwerty ro xc/programs/xkbcomp/symbols/pc/: de ro Revision ChangesPath 1.2 +3 -1 xc/programs/xkbcomp/geometry/chicony 1.9 +14 -17xc/programs/xkbcomp/geometry/hp 3.15 +2 -1 xc/programs/xkbcomp/geometry/pc 1.4 +11 -17xc/programs/xkbcomp/geometry/ibm/thinkpad 1.16 +28 -101 xc/programs/xkbcomp/rules/xfree86.xml 3.15 +2 -2 xc/programs/xkbcomp/symbols/de 1.8 +21 -163 xc/programs/xkbcomp/symbols/hu 1.2 +1 -1 xc/programs/xkbcomp/symbols/hu_qwerty 3.9 +3 -4 xc/programs/xkbcomp/symbols/ro 1.7 +2 -2 xc/programs/xkbcomp/symbols/pc/de 1.7 +3 -3 xc/programs/xkbcomp/symbols/pc/ro ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/27 06:35:50 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2867+5 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/08 04:22:19 Log message: Reverese the previous patch that cause compiling problems. Modified files: xc/programs/Xserver/xkb/: ddxLoad.c xkbInit.c Revision ChangesPath 3.33 +3 -5 xc/programs/Xserver/xkb/ddxLoad.c 3.30 +9 -14 xc/programs/Xserver/xkb/xkbInit.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/08 06:13:56 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2847+9 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/06 07:06:34 Log message: 424. Improvement of Xlib's keysym compose module: - Allow to figure out a mulibyte string if it is ommited in Compose file. - Add 'include' instruction with some substitutions. - Add a searching of Compose file as a value of XCOMPOSEFILE environment variable and as a $HOME/.XCompose file. (Ivan Pascal). Modified files: xc/lib/X11/: Ximint.h imLcIm.c imLcPrs.c Revision ChangesPath 3.13 +2 -2 xc/lib/X11/Ximint.h 1.12 +39 -13xc/lib/X11/imLcIm.c 1.10 +155 -22 xc/lib/X11/imLcPrs.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/06 07:08:46 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2845+8 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/04 06:56:48 Log message: 420. Fixes and updates for XKB keyboard maps: - Fix unneeded BKSL redefinition in Ukrainian 'winkeys' keyboard map (Andriy Rysin). - Fix some keycodes for jp106 keyboard model (Bugzilla #657, Stephen J. Turnbull). - Update xfree86.xml registry file (Andriy Rysin, Sergey V. Oudaltsov). Modified files: xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/xkbcomp/rules/: xfree86 xfree86.xml xc/programs/xkbcomp/symbols/: ua xc/programs/xkbcomp/symbols/pc/: ua Revision ChangesPath 3.25 +5 -9 xc/programs/xkbcomp/keycodes/xfree86 3.70 +2 -1 xc/programs/xkbcomp/rules/xfree86 1.12 +122 -8xc/programs/xkbcomp/rules/xfree86.xml 1.5 +2 -4 xc/programs/xkbcomp/symbols/ua 1.5 +2 -3 xc/programs/xkbcomp/symbols/pc/ua ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/04 06:58:14 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2842+7 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] Compose files.
Hi, So currently, the Xlib keyboard customization (including compose) all exists on the client side, but the XKB customization (not including compose) exists more on the server side. You want to allow end-users (sitting in front of the Xserver) to be able to configure the compose on the client side. You end up with a similar problem as the Xkb stuff described above, where the client side only has a filename for it's key to the database, but limited ability to send real data. No, those problems are a bit different. First of a client side *has* ability to load a file (as a compiled keymap) into a server. But most important thing is that when one client has chosen right name(s) and sent them to a server and server has found and loaded those files then all clients just get the map from the server independently on where they are running. In this case the server distributes a complete map that is enough for an applications work. But if the server distributes a *name* of Compose file only (and each client has to find and read this file from its local directory tree) there is not guaranty that each client machine has such file. However, Locale Independance sounds like it would be fairly easy to implement and have the added benefit of removing one of the keyboard configuration methods. What do you mean with one of the keyboard configuration methods? I imagine that would reduce the frustration of users. However, I don't totally understand your explaination here: If the result of a compose rule ia a keysym only Xlibhas to convert it to a string according to the current locale in the way used for usual key press/release events. It this case one compose files can be used for different locales and depends on a keybord map only. It seems like you're saying that instead of using a locale, the compose config would be chosen as a result of the keymap chosen. If that's true, that sounds like a great solution to the Locale problem. I didn't mean the compose file will be chosen automaticaly with the keymap choice. I just meant the compose file choice *depends* on keyboard layout choice. And a user will have the same compose rules for different locales (it's quite real situation if one uses C locale for some applications and en_US.UTF-8 for others). Unless per-user customization is really, really pressing, I wouldn't add it outside of the ideal Xkb solution. What do you think? I think I will anyway. :-) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Compose files.
Hi, Vasilis Vasaitis wrote: The second substitution would allow user to add currently used files into own custom Compose file without care where that file is actually placed. No objections here. Just don't forget to add at least another substitution, %%, which produces a literal %, for completeness' sake. Already done. I didn't mention it as an obvious thing. :-) In finally a most doubtfull part: how to specify needed Compose file. Now I made an environment variable XCOMPOSEFILE which value should be a name (with a path) of Compose file. But I realize it is unhandly for users. Any ideas are welcome. Hm, how about simply checking for the presence of ~/.Xcompose and using it instead of the locale dependent file? In that case, this file would have to include the system wide ones instead of the other way round, so perhaps the substitutions you've proposed wouldn't be really needed. I thought about it. But I think it isn't much better than an environment variable. In one case you have to write a string into your profile file (set the variable) and in another case you have to make a file in your home directory and write some lines there. And both cases are unhandly for configuring utilities. :-( Anyway I can implement both. In this case I think the variable should have bigger priority because if one wants to change compose rules for application only (or apply different rules for different applications) it would be easer to use the environment variable for such task. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] Compose files.
Hello, There are some issues related to a symbols composing and Compose files that were mentioned here (and in Bugzilla) during last monthes. The choice of Compose file depends on the current locale and is very unflexible. The files are placed far from other keyboard-related files (many people even can't find them). There is not any way to customize them (e.g. per-user compose file). I'd like to offer some changes in that mechanism that solve at least a part of problems. First of all I should remind that whereas in many systems a composing mechanism (dealing with dead_keys and/or Mylti_key like prefix) is a part of keyboard driver and composing rules are a part of keyboard maps, in X Window it has no relations to XKB and its files. Moreover that composing should work if Xserver and/or Xlib are built without XKB. The most unpleasant consequence is that Xlib use different ways to get Compose files and other keyboard-related data. A keyboard map is kept on a server and Xlib retrives it using XKB protocol (or some core protocol requests) but Compose file is always read localy from client machine filesystem. An ideal solution would be to integrate compose rules into XKB (or core protocols) maps but it needs changes in the protocol or a making new extension. My proposals touch existent files (and compose subsytem) only. Locale independence. In existent files a compose rule consists of two parts. A 'left side' part is a sequence of keysym and a right part (the result of composing) is a pair of a mylti_byte string and a keysym. Both members ot that pair are independed. Each of them can be omited and the compose subsystem doesn't check any matching between them and doesn't figure out any one of them from other. On the one hand it provides a flexibility. The multy_byte string may have no corrsponded keysym and even be some arbitrary string (a word or even a sentence). On the other hand it causes problem when user changes a locale. The string there is exactly what XmbLookupString has to return (without any changes). Hence for non-ASCII symbols it should be different for C and UTF-8 locales. (Hans Deragon wrote here about the problem he faced: when he changed a locale to Unicode one, some sequences appeared changed because Xlib used another Compose file.) It can be fixed easy. If the result of a compose rule ia a keysym only Xlib has to convert it to a string according to the current locale in the way used for usual key press/release events. It this case one compose files can be used for different locales and depends on a keybord map only. Customization. I added to Compose file an 'include' instriction. It allows to compose Compose file :-) from some files and add small corrections that user prefers. E.g. if user has custom Compose file it can look like include system wide file my_own_rules ... Of course, if some rules overlap, Xlib just discards a previous rule and uses latest one. Also I think some substitutions in the included file name could be usefull. A made two ones: %H means the value of HOME variable and %L means the name with full path to a currently used local-depended file (e.g /usr/X11R6/lib/X11/locale/iso8859-1/Compose). The first substitution woild allow to add a per-user preference file into a 'system' Compose file, e.g. system-wide file: common_rules ... include %H/.XCompose If the file doesn't exist Xlib silently ignores such instruction. The second substitution would allow user to add currently used files into own custom Compose file without care where that file is actually placed. In finally a most doubtfull part: how to specify needed Compose file. Now I made an environment variable XCOMPOSEFILE which value should be a name (with a path) of Compose file. But I realize it is unhandly for users. Any ideas are welcome. P.S. All changes I'm talking about are already made and tested. I can commit them in any time. But I'd like to hear suggestions/objections. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/22 06:29:16 Log message: 384. Fix bugs in Xlib's EUC string converters that cause incorrect work of _Xmblen. Fix _Xmblen usage in imCallbk.c when Xlib is built with X_LOCALE (Etsushi Kato). Modified files: xc/lib/X11/: imCallbk.c lcEuc.c Revision ChangesPath 3.9 +5 -1 xc/lib/X11/imCallbk.c 3.13 +18 -20xc/lib/X11/lcEuc.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/22 06:31:11 Log message: 382. Fixes and updates for XKB keyboard maps: - Fix for Uzbek keyboard map (Bugzilla #595, Mashrab Kuvatov). - Fix for the problem with Alt+Tab combinations in some window mangers (Bugzilla #580,616): window chooser menu doesn't disappear after Alt key release (Egbert Eich, Ivan Pascal). Modified files: xc/programs/xkbcomp/symbols/: uz xc/programs/xkbcomp/symbols/pc/: pc uz Revision ChangesPath 1.2 +7 -7 xc/programs/xkbcomp/symbols/uz 1.10 +6 -6 xc/programs/xkbcomp/symbols/pc/pc 1.3 +7 -7 xc/programs/xkbcomp/symbols/pc/uz ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/22 06:32:35 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2815+11 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/22 06:30:26 Log message: 383. Update xev program for print the result of XmbLookupString call (Bugzilla #582, Noah Levitt, Ivan Pascal) Modified files: xc/programs/xev/: xev.c Revision ChangesPath 1.9 +106 -3xc/programs/xev/xev.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [I18n] XIMText-length problem with multibyte chars in X_LOCALE environment
Hi, I checked lcEuc.c and found euc_mbstowcs() is doing wrong about *from_left value. Referencing with stdc_mbstowcs() in lcgenConv.c, I modified euc_mbstowcs() and also euc_wcstombs() in lcEuc.c. With this modification, _Xmblen began to work fine . Good work! I was going to tell you about euc_wcstombs() and ugly *from_left = *to_left there when got your message with a complete fix. :-) So following patches fix XIMText-length problem and also fix _Xmblen() in X_LOCALE defined XFree86 with LANG=ja_JP.eucJP. Please apply to CVS repository. Commited. Thanks. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/11 06:28:24 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2802+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
