Subject:
Re: Input event insertion from user apps
From:
"Greg Haerr" ####@####.####
Date:
17 May 2000 06:19:05 -0000
Message-Id: <090301bfbfc7$e392a960$15320cd0@gregh>
: The essense of this patch is important to us, at least.
I like the idea of the patch. I have a few issues, although
I haven't looked much at the implementation yet.
: The following variables are now defined in the GR_EVENT_KEYSTROKE
: event structure (others with same semantic as before not listed):
:
: GR_UNICODE uch; /* 32-bit Unicode keystroke */
: unsigned int special; /* Special keys */
: GR_CHAR ch; /* 8-bit keystroke */
: unsigned char content; /* What variables are valid */
Having both uch and ch probably is a good idea,
basically it allows both multiple encodings to be
returned, as you mention, letting the applications
program worry about whether it wants unicode
or not.
I'm a little worried about the "special" element though -
I think encoding function keys into a 16-bit keystroke
(using 0-255 as the local code page value and values
above 255 as our special function keys etc) would be
better, and then using the "special" value renamed as
"scancode" which returned system-dependent information
would be better.
:
: GR_KEYSTROKE_CONTENT_8BIT_PROPER
: GR_KEYSTROKE_CONTENT_8BIT_CTRLSEQ
: GR_KEYSTROKE_CONTENT_UNICODE_PROPER
: GR_KEYSTROKE_CONTENT_UNICODE_CTRLSEQ
: GR_KEYSTROKE_CONTENT_SPECIAL
I'm not sure I like the difference between xxx_PROPER
and xxx_CTRLSEQ. The underlying lower layer should
decode function key sequences and either deliver them
as a single "function key" or, if timeout or invalid sequence,
just spit them thru as normal PROPER characters. This
lets the lower layer completely control the decoding
of "sequences" into function keys, according to local
machine characteristics, like X Windows or console
/etc/termcap, for example.
: The reason for distinguishing between control and proper
: characters would be for the benefit of applications: Some
: applications like terminal emulators may want to get the
: data from the keyboard "as is", e.g. does not care if they
: are proper or control sequences, while other applications
: may want nano-X to decode function keys for them, while yet
: others may only be interested in proper 8-bit keys.
I'd rather see a cooked/raw mode entry point for this sort of
thing, and I'm not sure even that makes sense.
: void GrInjectPointerEvent(MWCOORD x, MWCOORD y,
: int button, int visible);
: void GrInjectKeyboardEvent(GR_UNICODE uch, GR_CHAR ch, int modif,
: int special, unsigned char content);
:
: The "visible" flag to GrInjectPointerEvent indicates if the pointer
: should be visible or not; make it visible when pointer is mouse,
: don't show it for touch screens.
Remove the visible parameter. We don't want to turn the
cursor on and off on a per-character basis, that's a completely
different API function: GrShowCursor(), GrHideCursor().
Also, the GrInjectKeyboardEvent may have to change slightly
based on the final API, but I like the idea. (Basically it should
handle the same parameters as the low-level kbd driver passes
up to the engine layer.)
:
: I'm not sure if I have implemented the "visible" functionality
: correctly, though; it works for me with the NULL-kbd driver, but
: it seems to use a reference count system that I don't understand.
: Is this for applications to decide visibility?
Yes, the reference count stuff is badly written right now, I think
I've fixed it for Microwindows. But basically, you shouldn't
have to know the count, you just call the Hide/Show functions,
and the system does the right thing.
:
: Also, the linux console escape sequences are not decoded like I
: describe in this mail, as I want to hear your opinions first.
: I have a fully working standalone program that implements the
: escape sequence detection for all keys on my Linux system that
: I can port as a followup to this first effort to redefine the
: API if I get the GA.
I'd like to see this code stuck in the drivers/kbd_tty.c for instance,
and a separate implementation in drivers/kbd_x11.c
: NOTE: One thing to keep in mind is the modifiers and the
: KEY_UP event which seems to me is not used now for the
: tty driver.
It is important that we have knowledge of separate key
down and key ups, and also handle the pressing of shift,
alt, and ctrl keys during normal operation, even of the Linux
console.
: PPS: The nano-X binary and shared library should have some sort
: identification string that is recognised by 'ident' and produce
: the proper nano-X version.
You should add them. Add ident to srvmain.c, I think.
:
: PPPS: When a client first connects to the nano-X server, the
: client should tell the server what version it is, and the
: server should make a quick compare or table lookup and report
: if the two versions are compatible, so the client can give
: errors or warnings as appropriate. I have had a little too
: many versions lying around, each one designed for a different
: purpose.... Not the average situation I guess but nice all the
: same. Anyway, this is for later.
Yes, good idea. Perhaps we should mod the protocol
now, before it's too late.
: #define GR_SPECIAL_KEY_F1 1
: #define GR_SPECIAL_KEY_F2 2
: #define GR_SPECIAL_KEY_F3 3
[snip]
We may want to renumber these things, and we may want
more function keys, and definitely need to handle the business
of whether a control, shift, or alt is pressed at the time that the
key is pressed. This info can be passed back in content.
I don't think "content" is a good name, though, too confusing.
"flags" would be better.
Not that you care what Win32 does, I have nonetheless
pasted in the return values for keyup and keydown messages.
It would be nice to be somewhat close to this. If we added
an additional nUnicodeValue, and stored the 8-bit value
as well as the "virtual" function key stuff in nVirtKey, and
stored all the content flags in lKeyData, we would basically
be there.
Win32:
WM_KEYDOWN
nVirtKey = (int) wParam; // virtual-key code
lKeyData = lParam; // key data
The WM_KEYDOWN message is posted to the window with the keyboard focus when a
nonsystem key is pressed. A nonsystem key is a key that is pressed when the ALT
key is not pressed.
Parameters
nVirtKey
Value of wParam. Specifies the virtual-key code of the nonsystem key.
lKeyData
Value of lParam. Specifies the repeat count, scan code, extended-key flag,
context code, previous key-state flag, and transition-state flag, as shown in
the following table:
Value Description
0-15 Specifies the repeat count. The value is the number of times the keystroke
is repeated as a result of the user holding down the key.
16-23 Specifies the scan code. The value depends on the original equipment
manufacturer (OEM).
24 Specifies whether the key is an extended key, such as the right-hand ALT and
CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if
it is an extended key; otherwise, it is 0.
25-28 Reserved; do not use.
29 Specifies the context code. The value is always 0 for a WM_KEYDOWN message.
30 Specifies the previous key state. The value is 1 if the key is down before
the message is sent, or it is 0 if the key is up.
31 Specifies the transition state. The value is always 0 for a WM_KEYDOWN
message.
Regards,
Greg
