Subject:
Re: Input event insertion from user apps
From:
Morten Rolland ####@####.####
Date:
18 May 2000 13:11:55 -0000
Message-Id: <3923F9F1.BA0F3CEC@screenmedia.no>
Greg Haerr wrote:
> 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.
Returning a scan code is a good idea, but we would also need
a standard way to identify typical keys like arrows, "Home",
function keys etc. in a portable way, like you say.
Originally I thought about doing this by allocating our own
unicode values somewhere far out, but this would not
make it possible to return "for you simple apps, note that
'4' was pressed - and by the way, you sophisticated apps may
want to know that it was '4' on the *numpad*."
This would be possible with the special variable. It could
be achieved with the scan code too - but with a portability
penalty. This is not critical to us, but personally I think
the added complexity is small enough for the applications to
enforce it for greater flexibility.
> : 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.
I agree completely - and I forgot it seems to explain the most
important reason for the existence of this idea:
Backward compatibility (deliver escape sequeces) combined with
a simpler and more portable way for applications to detect
function keys! (Our widget set decodes escape sequences now).
If you feel like the API should take care of this - and not
deliver (recognized) escape sequences, then this is fine by me.
> I'd rather see a cooked/raw mode entry point for this sort of
> thing, and I'm not sure even that makes sense.
Me neither for an API, but maybe someone somewhere has a keyboard
with very strange knobs on it that has conflicting escape
sequences with the keyboard that the keyboard driver thinks it is...
This is far fetched, but if the RAW mode needs to be implemented
for reasons like this, the raw mode can't be turned on globaly.
This is on problem solved with the event tagging I proposed.
We can let the RAW problem rest for now.
> : 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,
Character? You mean mouse move event? The cursor will be either
on or off (for long periodes) depending on wether the input method
is touch or mouse. You don't want a mouse pointer when using touch,
but it is needed for mouse input. I may actually need this function
for, uhm, a hack too... But that is another story.
> that's a completely
> different API function: GrShowCursor(), GrHideCursor().
Yes, but they are not exported by the client API right now, and I
was affraid the GrShow/HideCursor functions would have slightly
different semantics, so the easiest solution seemed to be to define
it through the new functions.
The differing semantics is, I suspect, that GrHideCursor will not
always hide the cursor (because of the reference count thing).
The semantics that I need is for the external "mouse/touch-server"
to be able to command visibility 100% - depending on input
method alone, not depending on other applications.
The implementation calls the Hide/Show functions when the
"visibility" argument changes from the previous one (from inside
the nano-X server).
> 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.)
Yes. We will have to keep state of the mouse buttons *as delivered*
to the applications so that the "synthetic" keyboard event will
contain the correct information.
> 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.
If this means that the GrHideCursor will *always* hide it - then I
will export the Show/Hide functions from client.c and use this
instead. If Hide may not always hide the cursor we may have to
come up with (at least) an alternative API (which may be the
"visible" flag to InjectPointer), and then make it do the right
thing at a later stage (it seems to work for my setup witht the
NULL keyboard driver).
> : 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
Yes. Language/codepage/unicode should probably be handled at this
level as well, with the help of higer-level helper functions, since
the hardware driver knows how to interpret the native driver and
translate into unicode, and then deliver unicode (and decoded function
keys etc.)
> 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.
Yes, but this may be a bigger task, and can be solved later? We will
not need this functionality, I think. I can try to upgrade the tty
driver first, when the API is ready.
> : 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.
I think it is easier for you to do it than me making a tiny patch:
* Create a file microwin/src/version.c that looks similar to:
/* Microwindows project by ... etc. */
const char *microwin_version = "$info: Microwin Version 0.88pre6b $";
And then include this file from e.g. 'srvmain.c' and others:
nano-X server (nanox/srvmain.cas you suggested)
nano-X client library (nanox/client.c)
Microwin libraries
> : #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.
The 'modifiers' was intended for this, wasn't it? I don't mind
putting this info into 'content', though.
> I don't think "content" is a good name, though, too confusing.
> "flags" would be better.
Agreed,
> Not that you care what Win32 does,
Well.... - Since Microwindows is is guided by this in part,
it would be smart to try find a common ground that is both
simple to use from both camps and sufficiently feature rich
since some code will be used by both (Low level keyboard driver).
> 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.
I'm not used to this API, so I think you should guide me when I
do something stupid - but from what I understand there should be some sort
of simple mapping.
OK, how do we proceed from here?
Regards,
Morten Rolland, Screen Media
