Key injection to buffer

For a long time I’ve been wanting a simple way to insert a keycode into the buffer. It would avoid a lot of complexity for what would be otherwise trivial tasks. A custom keyboard driver is overkill. Given it is possible to read the buffer, why can’t it be written to?

Will SYS “Wimp_ProcessKey” do what you want?

Or OS_Byte 138

https://www.riscosopen.org/wiki/documentation/show/OS_Byte%20138

As Jeff has pointed out OS_Byte 138 is usually sufficient for user code. If you need to go lower level then use KeyV 2

I didn’t know about Wimp_ProcessKey. Not sure it’d work for what I’d want but maybe.

I thought OS_Byte was generally obsoleted. Mind you, it may do. KeyV 2 is pretty much back to needing a custom driver, which is overkill for simple stuff.

Wimp_ProcessKey can do control and another key e.g Ctrl C etc.

KeyV 2 is pretty much back to needing a custom driver

KeyV doesn’t need a custom driver, you simply call it via OS_CallAVector

If you can get away with OS_Byte calls, that would be the preferred route. There are situations where OS_Byte can’t be used, such as in IRQ code. OS_Byte certainly isn’t obsolete, where there are more modern equivalents for OS_Byte calls, the advise is to use them in preference.

And this is where I die.

#include <stdio.h>
#include <stdint.h>
#include <swis.h>

#define KeyV 0x13

void injectKeyCode(uint32_t key)
{
	_kernel_swi_regs reg;

	reg.r[9] = KeyV; // 0x13
	reg.r[0] = 2; //sending keycode to OS.
	reg.r[1] = key;
	reg.r[15] = 0x0; //I don't know what flags to send.	
}

int main()
{
	injectKeyCode(65); //should be h
	return 0;
}

This is as far as I get using available information. All it does is produce a dialog or text saying “Window manager is currently in use”.

OS_Byte 138 works well for ASCII at least which is nice.

You aren’t calling kernel swi to actually execute the command, and don’t touch R15!

and don’t touch R15!

Yeah, the ‘r’ array is only 10 elements long, so I’m surprised the compiler didn’t warn about it.

I think it’s only a handful of vectors which care about the C/V flags on entry, and KeyV isn’t one of them, so you shouldn’t need to worry about R15 at all.

I thought about this while at work (what I’m supposed to be doing now ;) ) and I think you need to look at the SWI regs definition. I think it only defines something like R0-R8 or R0-R9… so by writing to R15, and C’s infamous lack of bounds checking… you’ll be trashing whatever may be on the stack at that location.

Also, if you’re calling key pressed, shouldn’t that be followed by key released ?
Why not use OS_Byte? Are you trying to fake Ctrl or Shift being pressed?

Now it’s pointed out, I’m shocked at what I did (and didn’t do). A comedy of errors. Also I just discovered Norcroft pings me for r15 but not gcc.

On the bright side, after adding my forgotten _kernel_swi and removing that silly r15, it works. And yes there should have been a key release.

This kind of spun off from me trying to unsuccessfully inject mouse button clicks. It’s so easy to move the cursor around by various means, but so hard to actually use the buttons.

but so hard to actually use the buttons.

Hook into MouseV. Fiddle with the stack to pass on the vector and get called again on the way out (this part is important). Then patch in the mouse buttons you want to fake.

^{^} This sort of finagling was my original complaint.
However, KeyV is letting me use the mouse keycodes.

This sort of finagling

It’s not too hard.

The kernel regularly calls PointerV (sorry, not MouseV!). I think every VSync, but don’t quote me on that.
The call will work its way through the routines hanging on to PointerV until one claims the call. The one that claims the call will be whatever device is the current active mouse driver.

Now, the thing is, the way these vectors work is that you, if you’re on PointerV, will be called before the mouse driver (you’ll want to pass on the call unless you are totally replacing the mouse) but if you pass on the call to the mouse driver, anything you set as the button state will be overwritten by the mouse driver.

Therefore, you need to arrange to get yourself called after the mouse driver has done its thing.

Vectors are passed on by jumping to the address provided in R14, and they are claimed by pulling an address off the stack and jumping there. So if you pop your address on the stack and then pass on the call, when the mouse driver claims the vector, the address it pulls off the stack will be yours. At that point you can then modify the buttons, and then you pull an address off the stack, which will be the original address for the end of the vector handling.

Yes, it’s a bit fiddly, but sometimes you want to modify things before the event, and sometimes afterwards…

Rick, I’ll have to work it out.

Besides a few minor things like not being able to drag scrollbars properly, and no mousewheel I can use the uSynergy client in RISC OS now. Mapping the incoming scancodes to RO scancodes was laborious, but it seems to work pretty well.

I should say that I’m typing this using the mouse and keyboard connected to a linux box, with RISC OS as a client. I’m typing this in NetSurf on RO.

Personally I used OS_Byte 153 to poke characters into the keyboard buffer when I wrote !PollMask…

The following snippet is in BASIC and has been lifted directly out of PollMask.

DEFPROCpoke_kbd(s$)
 LOCAL i%
 FOR i%=1 TO LEN(s$)
  SYS"OS_Byte",153,0,ASC(MID$(s$,i%,1))
 NEXT
ENDPROC