Still need to be busy doing other things, but will record some things.

See:

• About These Pages
• X Server Modification Project, Bug 43

Contents

Notes

• Got some additional responses to my email requesting help with digging into the code -- will add additional stuff to the questions and responses on yesterday's page: XsmD20030412

• Also got a follow-up from David Allan re gtkeyboard -- I'll summarize here:
  • Re: enabling SendEvents for KDE applications: "I don't know much about KDE, but from what I have been told by others, it would require a source patch, or at minimum that the packages be configured and compiled differently. I don't think it's dynamically configurable."
  • Re Mozilla: "Mozilla isn't a lost cause, it's just pretty difficult. You need a window manager whose settings don't immediately rob the application you had focus on of keyboard focus, or one that will put keyboard focus in the right widget. I have heard WindowMaker works pretty well."
  • Re modifying the X server: "Well, it's definitely possible to make the change within the X server, but it would likely take a lot of work. Architecturally that might even be the best place to do it if you want the facility to be good for just about any X application, but keep in mind that it likely wouldn't be useful as a default feature (for security reasons) and there are also several different versions of X out there. (Not just XFree86)"
  • Re understanding keysyms, keycodes, key events: "Check out the O'Reilly books on X programming written by Adrian Nye. They are probably the best reference available for this material. (I use mostly volume 1)"

• X.org is apparently still alive, see:
  • X Server Design
  • X Resources
  • Technical X Window System and Motif WWW Sites — "Kenton Lee's list of over 700 X Window System and Motif resources"

• Started kdevelop yesterday, had trouble reading the help and found http://www.kdevelop.org, including Programming Manual (and others) — started reading -- appears that it can work with C as well as C++

• Forgot about dumpkeymap or whatever, and it's hint that something might be in place (maybe only in Next, or Darwin) to handle keyboard macros -- will try writing to the devel@xfree86PLEASENOSPAM.org list. Got a very prompt response from Torrey Lyons, summarizing (or quoting ):

The dumpkeymap utility applies only to Mac OS X and NeXTStep/OpenStep. It is an open source reader for what were previously proprietary system .keymapping files. (I say previously because the format information was open sourced by Apple after they bought NeXT.) If you are not using one of these operating systems, then dumpkeymap is not likely of interest to you. It is included with the XFree86 distribution on Mac OS X because the X server can read and use these files. Note on Mac OS X, the keymapping mechanisms have evolved and the dumpkeymap utility is becoming out of date.

...

This ability did exist at the system level in NeXTStep/OpenStep, but this has nothing to do with the X server. In fact, XDarwin ignores such character sequences when using .keymapping files.

• Writing to broeker@usersPLEASENOSPAM.sourceforge.net to ask whether C scope can deal with the problem of tools that cannot deal with functions called through function pointers, "leaving an incomplete call tree." (Matthieu Herrb)

• Revisiting the three options I see (intercepting keyboard events between the keyboard and xserver, in the xserver, or between the x server and the client) to note some pros and cons of each. (Talking about which is easiest would be silly at this time -- whichever one I learn enough about to be able to do will be the easiest for me -- learning enough about all three to make the optimal choice might be more than I want to do.)
  • Between keyboard and x server: Might be the most device / OS dependent, (so I might focus on doing this only for the 8086 familiy of computers, at least as a start), requires little or no knowledge of X (maybe), maybe even the documentation I have on 8086 machines and such things as BIOS event handlers might be applicable (nah, probably not). Fairly low cycles but not the least because each keypress generates multiple events (keydown, keyup, .... — up to six if I understand correctly — thus I'd have to generate up to six events for each character that I want to "simulate"). I've not really gone looking for information about how the keyboard is handled before it gets to the x server -- not sure where to seek such information, but there might be more people with that knowledge than with intimate knowledge of keyboard handling in X. (I'm thinking of the "hook an interrupt" type solutions that used to be possible in dos / Windows -- I would think there would be some similar possibility in Linux.)
  • Within the x server: requires a lot of knowledge of the x server, and a lot of potential for causing problems. But, would / could be device / OS independent, and involve a minimum of processing cycles (I'm assuming I could find the place where keyboard events are generated and deal only with keyboard events, not mouse or whatever other events exist.) (Of course, maybe I'll get tangled up in the Linux kernel -- that would probably not be good (well, not convenient for me) for a number of reasons.)
  • Between the x server and x client: Another choice that requires less knowledge of how the internals of the X server work, but I may have to "stand" somewhere and pass all events in both directions between the x server and x clients, so I suspect it may require the most CPU cycles (even if I need six events per character for the "before the x server" solution).

• I want to think about where I could get the information I need on the "before the X server" approach -- I guess the X server documentation must address this, but there must be other places. I had started to learn something about the X client to X server communication (sockets, pipes, and TCPIP), but never got as far as exact addresses or something similar.

• Just to refresh my memory, and in case it jogs anybody else's memory or thoughts, the dos / Windows (did it work in Windows) "hook an interrupt" thingie went something like this. There was an interrupt generated when a keyboard event occurred, and there was a table of interrupt handler addresses. To hook an interrupt, you replaced the interrupt handler address for the interrupt you were interested in with the address for your "own" interrupt handler, but saved the original interrupt address. Then, as the last step of your interrupt handler, you gave control to the original interrupt handler. Does Linux handle the keyboard on an interrupt driven approach, or some sort of scan? Can I (my program) get access to the interrupt handler table?

Re below: Just a reminder that one of the links below mentioned that keyboard interrupts (or keypresses, or whatever) are typically moved to a keyboard buffer by the first (keyboard) interrupt handler -- that could be a better place to intercept and replace keypresses (or whatever). (Was that only for dos/Windows??)

• Did a Google search on ["Keyboard interrupt" address Linux handler] and got some promising hits re the "hook the interrupt" approach:
  • Adeos project post -- these guys seem to have some code that might be directly applicable
  • CS 134c Final Project -- some other useful information -- they (he) scans the keyboard input port (but perhaps only useful for PS/2?)
  • Input and Output: CIS 450:­ Computer Organization and Architecture; Copyright 2003; Tim Bower; as Google HTML — has some snippets of the keyboard handling code (PS/2) in the Linux kernel (2.4, IIUC), from /usr/src/linux/drivers/char/pc keyb.c.
  • signal System Call — signals get into the act also (SIGINT, for example)
  • Signals might be exactly what I'm looking for (or maybe not) -- that page is part of The Linux Kernel; DRAFT, Version 0.1-10(30) (1996, 1997); David A Rusling — the entire thing might be worth reading (or browsing)
  • Signals
  • nobanner.c — might have some useful code
  • UQLX — includes this little tidbit (and other stuff related to successfully grabbing the keyboard: "Best cure is do NOT use XKB. Despite what many national-howtos say Xkb is completely optional and only wastes resources. To disable it,add following lines in `/etc/XF86Config'
    XkbDisable
    =RightAlt ModeShift=" and this "ICCM compliant wm's (those that don't grab events from clients) should be preferred where possible."
  • 17.4 Hardware Interrupts — I should have known / remembered this, but, at some point there is a hardware interrupt from the keyboard (on any 8086 based, "PC clone", which should be accessible whatever operating system is being used (well, maybe, unless the Linux kernel grabs that and no one else can get access to it)) — not that I even want to consider such a thing, just an Ahha moment that I wanted to remember:

17.4.3 The Keyboard Interrupt (INT 9)
The keyboard microcontroller on the PC's motherboard generates two interrupts on each keystroke - one when you press a key and one when you release it. This is on IRQ 1 on the master PIC. The BIOS responds to this interrupt by reading the keyboard's scan code, converting this to an ASCII character, and storing the scan and ASCII codes away in the system type ahead buffer.

By default, this interrupt is always enabled. If you disable this interrupt, the system will not be able to respond to any keystrokes, including ctrl-alt-del. Therefore, your programs should always reenable this interrupt if they ever disable it.

• • signal — "SIGINT: Keyboard interrupt. Generated by CTRL-C" — oops, I may be barking up the wrong tree with re signals — this is not the keyboard interrupt I want
  • COS 318 : Operating system — some class assignments for a "mythical" operating sytem, but links to some resources that could be useful, including what may be a useful paper on "An Introduction to Programming With Threads" by Andrew D. Birrell
  • The Linux Kernel: Signals & Interrupts — even though I don't think signals are what I'm looking for, this looks like a pretty good (and quick) presentation
  • Interrupts and Handlers Part 1 — at the very least, this distinguishes between signals and software interrupts, also looks like a good tutorial on writing an interrupt handler — could I build my keyboard macro thingie as an interrupt handler? Maybe, but I think it would be a bad idea &mdash, a long replacement string (when I press <ctrl><alt><shift>b to enter the Bible into a text file) could interfere with some other possibly important process

It's probably past time to stop collecting these links, and, anyway, time for a break.

Contributors

• () RandyKramer - 13 Apr 2003
• If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.

Page Ratings