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 x

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

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 bef

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. --

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 me

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 se

Re: Xkb

Hi, > Here is some code: > > --- > Bool changeGroup(int increment) { > if (GroupCount <= 1) return False; > XkbLockGroup(dsp, deviceID, (CurrentGroupXKBNo + GroupCount + increment) % > GroupCount); > return True; > } > --- There is nothing wrong here. But it is too less to understand the

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. Prob

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

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

Re: atkbd.c: unknown key released - XFree86 shouldn't access hardware directly

Mike A. Harris wrote: > I'm still curious why the lnx_io.c code is getting used instead > of the newer lnx_kbd.c code which is based on the former and > seems that it was intended to replace it. Was this a work in > progress perhaps that didn't quite get finished, so the old code > was left in

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

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 regressio

Re: documentation of the format of files in xkb/symbols?

Hi, > > You'll find some documentation here: > > 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/g

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

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

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

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 mi

Re: Screen blank seems to have broken (regression)

Hello, > I notice that if I do > > xset s 1 > xset s 1000 > xset s 1 > > The screen blanker is broken. I think this worked about a month > ago. Did anyone mess with code related to that recently? It's my fault. I rewrote ScreenSaverTimeout processing using Xserver's timeout facility (

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 do

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 key

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 ev

Re: incompatible XkbdModel

Hi, Chris Hornbaker wrote: > and then I made a new entry in /etc/X11/xkb/symbols/inet based of the > logicdn, but that just doesn't want to work. Good. You went right way. But you also need to add the name of this entry into the list of 'inet entries' $inetkbds in /etc/X11/xkb/rules/xfree

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 check

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

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 ProcessInputEven

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

Re: Wrong order of a timeouts processing in WaitForSomething.

> Around 20 o'clock on Sep 20, Ivan Pascal wrote: > > > The solution is obvious. WaitForSomething should not run any callbacks before > > the Select but just check timers and if there are expired timers call select > > with a zero timeout. > > One more iss

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 t

Wrong order of a timeouts processing in WaitForSomething.

Hello, Trying to solve the problem reported in Bugzilla #301 I found that the root of the problem is an order of timeout processing in WaitForSomething subroutine. The reported problem is that under some conditions Xserver duplicates key press events. For example if one run setxkbmap program

Re: CapsLock behaviour and Turkish keyboard

Owen Taylor wrote: > On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: > > Now Turkish keyboard users just have to set XkbOption "caps:shift". > > With that option Xlib doesn't use 'internal capitalization' but CapsLock > > key acts as 'locking Sh

Re: CapsLock behaviour and Turkish keyboard

Owen Taylor wrote: > On Tue, 2003-08-05 at 14:32, Ivan Pascal wrote: ... > > I risk to seem impolite but did you try this option before making such > > assertion? If you tried you would notice that it is not true. > > I had the made the assumption that caps:shift did the

Re: patch for sun type6 keyboard support from debian patches

> This is a patch to add sun type6 keyboard support. It comed from the patches > debian puts on the 4.3.0 source before building the packages. I think this > type of info should be passed to the XFree86 core so that everyone who uses > XFree86 can take advantage of this. Commited. Thanks. >ty

Re: CapsLock behaviour and Turkish keyboard

Hi, > Well, I used to like that behaviour of "typewriter capslock" (with shift > key removing the caps lock, and the capslock affecting all keys and > being a shift lock in fact) Unfortunately I can't imagine how to make such mode ("affects all keys" but "Shift cancels Caps" ) in XKB. > I test

Re: CapsLock behaviour and Turkish keyboard

Hi, > Well, I described how it worked on mechanical typewriters; just having > a ShiftLock is enough. (OTOH it is a long time since I last used > a mechanical typewriter, and since I discovered the CapsLock on > computers (allowing to have uppercase of ccedilla for example), I like > this better

Re: CapsLock behaviour and Turkish keyboard

Pablo Saratxaga wrote: > On Wed, Aug 06, 2003 at 01:31:45AM +0700, Ivan Pascal wrote: > > The name was misleading I thought it was the system where capslock > is similar to shift lock (how is that mode named then?) There is not such option now. In my opinion it is inconvenient beca

Re: CapsLock behaviour and Turkish keyboard

Hi, > I see keyboard topics are being discussed right now... > there is long standing problem with the CapsLock and turkish keyboard > that would be nice to have fixed. Yes. There *was* such problem and it was discussed year ago. :-) (I don't remember but I was sure you took part in that discus

Re: Change of behavior of shift+ (without numlock)

David Dawes wrote: > On Mon, Aug 04, 2003 at 03:10:02PM +0200, Egbert Eich wrote: > >Bugzilla 558 requests to change the behavoir of shift+ > >This requests sounds reasonable so I would like to find out if > >somebody has a strong opinion on this issue. > >If not I will commit the supplied fi

Re: linux 2.6 atkbd ==> xkb

Hi, > >> What I cannot find is *where* those fake scancodes are generated > >> and how they are mapped to 0x81-0x84 > > Ivan> xc/programs/Xserver/hw/xfree86/common/xf86Events.c > Ivan> xf86PostKbdEvent() subroutine > > Ok. From that it looks like I need e0/01 thru e0/04, but as far as I

Re: linux 2.6 atkbd ==> xkb

Hello, > As per xc/programs/Xserver/hw/xfree86/common/atKeynames.h: > > /* > * Fake 'scancodes' in the following ranges are generated for 2-byte > * codes not handled elsewhere. These correspond to most extended keys > * on so-called "Internet" keyboards: > * > * 0x79-0x93 > *

Re: [PATCH] btc9001ah keybaord symbols

Hello, > I'm using btc9001ah keyboard and found out that > current CVS doesn't support this model! > > Here is its description: I commited your description but without commented lines. We can add them later when the keycodes will be emulated correctly. -- Ivan U. Pascal | e-mail:

Re: iBook us-keyboard problem

Hi, > The linux-ppc kernel has an option (CONFIG_MAC_ADBKEYCODES) to use the "old" > ADB-style keycodes. I imagine setting this option to "no" uses the conversion > you're talking about. For the record, the scancodes I see (from showkey -s) > are as follows: > > KeyPad Equals : 0x5c 0xdc >

Re: iBook us-keyboard problem

Hi, > OK, after some more resarch, I have some idea of what's going on. It seems > that the X server gets the scan codes from the kernel, then passes these scan > codes to the X client. xlib has some nice functions to then convert these > scan codes into keycodes, then into keysyms. (Correct

Re: KeyBoard BUG on sparc/sparc64 in 4.3.0 too.

Balint Cristian wrote: > Regard to that one BUG with the mention that it persist in 4.3.0 too > and any CVS too: > > By Rene: > http://marc.theaimsgroup.com/?l=xfree86&m=104526841725691&w=2 > > By mysef: > http://marc.theaimsgroup.com/?l=xfree86&m=104385693307371&w=2 > > I send more deBug: > ht

Re: [XFree86] [XFree86(TM) Bug Report] bad keyboard types in logicdn and es

David Dawes wrote: > I'm not sure if the best solution is to add the definition to > the pc/es map (and all others where the default keyboard has this key), > or change rules/xfree86 so that all of the "inetkbds" definitions are > based on "pc105" instead of "pc104" (the key is the only differenc

Re: VT switching is broken

y map. This fixes > side-effects (loss of auto-repeat and mousekeys functionality) of > the way this was implemented previously (#5610, Ivan Pascal). Actually this patch isn't a reason of the bug. The bug itself appeared when new actions for VT switching was added to a k

Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS

Hi, > Err, I think is just found another problem, forgive me if it is a known > problem (and I missed some email about it), but for example: > > % setxkbmap -model pc104 -layout us_intl > or > % setxkbmap -model abnt2 -layout br > => Scroll_Lock leds works They are 'old layouts'. > % set

Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS

Hi, A short introduction: Any key in XKB can have keysyms, xkb actions, a virtual modifier(s) and some flags describing a key behavior such as 'repeat', 'locking' and so on. A core protocol knows about keysyms only. If one changes a keysym binding using the core protocol it can happen tha

Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS

> > On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: > > >/*-+ on the numeric keypad won't repeat in current CVS. Other > > >keys on the keypad do repeat, including numbers when numlock is > > >turned on. /*-+ on the normal part of the keyboard do repeat. > > > > > >Tried "xset r

Re: A bug in xset and a fix for it

David Dawes wrote: > >That in turn uses _XReply() to fill in a xkbGetKbdByNameReply struct, and > >either that call fails, or the "reported" field of the struct is set to > >zero. (line 142 in XKBGetByName.c) > > Does the xset call actually change the repeat rate when this happens > (with your fix

Re: TerminateServer Keycode combination broken ...

Hi, Stefan Dirsch wrote: > > The "TerminateServer" keycode combination > > key { > type="CTRL+ALT", > symbols[Group1]= [ BackSpace, Terminate_Server ] > }; > > is missing for nearly all keyboard symbol tables. Currently (CVS version > from today) it is only includ

Re: xkb bug in XFree 4.2.99.3

Hello, > I am trying RedHat's latest beta which includes XFree 4.2.99.3 and there > is a bug in the xkb code. I cannot configure a proper French Canadian > keyboard. When specifying "ca_enhanced" in the XF86Config file, some > keys on the keyboard are not mapped properly. I should apologize