1

Topic: What happens, when I push Shift-Ins?

I represent myself it somehow so: 1) the keyboard controler forms sequence of bytes and tries to transfer it in the central processor, for this purpose causes interruption. 2) interruption processes a kernel and rewrites bytes from the keypad controler through units for operation with USB in operative storage 3) the kernel thrusts these bytes in program XOrg server (why in it? What method thrusts?) 4) program XOrg server defines what window active and thrusts the message in queue of this window 5) the program periodically interrogates queue on x11 protocol (main message loop) 6) the received key pattern is run on  on client side, are caused functions for  contents  from the x-server 7) the received contents are interposed into a control item (editbox for example)

2

Re: What happens, when I push Shift-Ins?

Hello, Ejnstok Fajr, you wrote: > 3) the kernel thrusts these bytes in program XOrg server (why in it? What method thrusts?) it, does not thrust bytes in the program. The kernel creates char device for each input equipment in /dev/input/event##. X.Org, as well as any other process, can open and listen to this device events. https://en.wikipedia.org/wiki/Evdev

3

Re: What happens, when I push Shift-Ins?

Hello, Ejnstok Fajr, you wrote: > I represent myself it somehow so: > 1) the keyboard controler forms sequence of bytes and tries to transfer it in the central processor, > for this purpose causes interruption. > 2) interruption processes a kernel and rewrites bytes from the keypad controler through units for operation with USB in operative storage of the Keypad different happen. If it is connected on PS/2, there the controler cut down  also it is normal with dial-up translation . An output - sequence of events of pressing/otzhatija. Well and interruption, of course, but it on event "the port received ". If it is connected on USB, the basic interface such: the driver includes waiting  from the device; when something changes, comes ; in it of 8 status bit of modifiers (Shift, Alt, Ctrl, Win, all in two variants - left and right) and to 6 codes actually now pushed keys. Further the driver compares with previous  and transforms changes into sequence of events. These events can be given or in a type scancodes (for compatibility, as Set 1 or Translated Set 2), or in a type keycodes (independent from PC values, though as a matter of fact the same). There can be more difficult cases like the keypad on Bluetooth. > 3) the kernel thrusts these bytes in program XOrg server (why in it? What method thrusts?) Xorg it can be connected or directly to the keypad controler, or through so-called event device. In Linux prefer the second way. In places (FreeBSD) still the main the first. The essential difference is not present. In both cases are read hardware-independent keycodes and a pressing/otzhatija sign (it it is possible to look in details, launching xev). The choice to what to be connected, it does on server start. The input equipment thus passively waits, while from it read. > 4) program XOrg server defines what window active and thrusts the message in queue of this window Yes. Though there there are singularities with interception/updating of messages. On an output messages of type KeyPress, KeyRelease turn out. In each message keycode it is the key code, and state it is a mask of the active modifiers.  from keycode do still the keysym - one more dial-up of the codes. > 5) the program periodically interrogates queue on x11 protocol (main message loop) > 6) the received key pattern is run on  on client side, > are caused functions for  contents  from x-server EF> 7) the received contents are interposed into a control item (editbox for example) At all points - yes. Thus there are singularities - for example, actually Shift+Ins is defined at level keysym, and here if text entering is supposed, it is necessary to call XmbLookupString () which calls, in particular, translation on XKB, working off Ctrl and so forth.