New keyboard layout for Pandora

I’d like to gather everyone’s opinions on the idea of introducing one or more new keyboard layouts/handlers, for the Pandora. As I understand it adding new handlers is a fairly straightforward process (just a case of writing an appropriate key mapping file and letting InternationalKeyboard’s keygen utility do the rest), but I’m hesitant to jump in and add a new one because it would result in compatibility issues for any software that tries to make use of the internal low-level key numbers directly, although I guess that practice should be discouraged anyway.

Basically the crux of the issue with the Pandora is that the keyboard layout is relatively non-standard, both as far as Shift is concerned, and due to the use of a FN key to access many of the non-alphanumeric glyphs. There’s a photo of the keymat here to see what I’m talking about. What’s not clearly visible there is the D-pad (the left-hand + of 4 keys), which is typically used for cursor movement, and the A/B/X/Y game buttons (right-hand + of 4 keys) which is used for home/end/page up/page down. There’s also the two analogue nubs which are used for mouse emulation, and the left + right shoulder buttons (not used for keyboard emulation on Linux AFAIK, but I’ve mapped it so that pressing both at once will trigger a Break keypress).

At the moment PandoraKey works around the key mapping issue by handling it all itself. This means it generates fake shift & alt keypress events as required in order to force the keyboard handler to produce the right output for the key the user is pressing; e.g. FN+E should generate an open bracket, and PandoraKey implements this as sending the sequence for Shift+9. This approach has a few drawbacks:

• Handling multiple keypresses is hard, as each key could have conflicting Shift/Alt requirements. At the moment the code limits itself to only one key at a time. Best-case would be for multiple keys to be allowed only as long as Shift/FN aren’t in use
• Since Shift needs to be treated specially, holding Shift by itself doesn’t generate any keypress events.
• The code also requires the user to be using a compatible keyboard layout in order for the faked keypress sequences to have the desired results.

Put all those reasons together and it’s a pretty compelling case for switching over to use a new keyboard layout handler instead.

So that brings us to the topic of how best to implement a new Pandora keyboard handler. As I see it there are (at least) the following issues to tackle:

The FN key

IntKey does support the use of FN keys, but according to the docs, it looks like IntKey’s code for handling it should only be used as a last resort. In particular INKEY won’t report that a FN-translated key is being held, and the FN key can’t be used to generate keypresses of modifier keys – which means caps lock won’t work due to the source key (Shift) being a modifier. So it looks like FN key support will need improving, or PandoraKey will have to handle it itself. Without looking at the keygen sources in detail I’m also not sure whether it supports “sticky FN” (i.e. after pressing & releasing FN the next key pressed will be FN-modified) or FN-lock.

New low-level internal keys

If FN is handled by PandoraKey, we’ll need to generate the appropriate low-level internal key code for any keys pressed while FN is in effect. If we stick with the convention of using low-level keys that have a name/purpose which matches their non-modified usage, we’ll need new key codes for the following:

()!_"´¥:?|$€

Which is a fair list, but not quite as bad as I was expecting. However future keyboards might need more, so perhaps it makes sense to try transitioning away from having a fixed list of low-level internal keys?

The obvious solution I can think of to would be to start using Unicode for the low-level internal keys; for KeyV this is easy enough just by adding a couple of new reason codes to indicate Unicode keypresses, but I’m not sure what could be done with EventV, especially since the comments in Hdr:RISCOS suggest that there are only two event numbers remaining. Maybe we can just EOR unicode numbers with some cunning value, allowing us to use the full UCS4 code page, apart from a small uninteresting section which will effectively be overwritten by the old-style RISC OS codes? E.g. &E000 would map it ontop of the &E000-&F8FF private use area, giving scope for expanding the RISC OS low-level key numbers right up to 6399 if necessary.

The only downside to Unicode is that (AFAIK) it doesn’t cover modifiers, or special keys like F1-F12, Escape, Caps Lock, etc. Nor does it make any distinction between duplicate keys (e.g. numbers on the numpad and numbers on the main keyboard). So RISC OS key codes would still need to be used (and allocated as necessary) for those.

A quick look at the USB HID spec suggests that there aren’t any key codes for specific currencies, so I don’t think there would be much to gain from using USB keycodes instead of Unicode/RISC OS ones.

Special keys

Brightness up/down, lid close sensor, and the power switch. These could be handled as special cases by PandoraKey, but the sources to the Stork version of the Portable module suggest that Acorn were intending that all the special keys on the Stork keyboard were to be assigned their own low-level internal key codes – see the list here. Some of those codes have now been reused for other things, but from the perspective of keeping PandoraKey simple it probably makes sense for at least the Pandora brightness keys and the power switch to generate KeyV events. There isn’t a lid close sensor listed in the Stork list, so perhaps they were going to special-case that one, or it wasn’t part of the keyboard? (Technically it’s not part of the keyboard on the Pandora, but it is in with all the GPIO-attached gamepad keys, so having PandoraKey detect it is trivial). The power switch isn’t explicitly mentioned in the Stork list either, but it’s usage would be in a similar to the Stock “freeze”, “on”, “off”, etc. keys. Plus a fair few PC keyboards have power buttons on them, so it wouldn’t be too out of place to include it.

Gamepad controls

One way or another I suspect PandoraKey is going to need to contain some code to allow the gamepad keys to be remapped for when playing games. But since they don’t have any modifiers by default, and they’re all GPIO attached instead of using the keyboard matrix, it shouldn’t be hard for PandoraKey to handle this remapping itself, especially since they’ll most likely get used to emulate keyboard keys which already have low-level internal key numbers, or joystick buttons which would go via the seperate Joystick SWIs.

Likewise I’m hoping that it will also be possible to switch the nubs between mouse emulation and joystick emulation; I can imagine this being something that will need to be done using a key press combination, as there aren’t any APIs in place to allow programs to indicate when they’re starting and stopping joystick use. At the moment my best idea for what could control this would be something like FN + Pandora key. Although once we get a touchscreen driver it may not be too bad if switching in and out of joystick mode can’t be done via keyboard alone.

Missing keys

Print Screen, Scroll Lock, Break, Num Lock and Alt-Gr are all keys missing from the Pandora compared to a standard Arc/RiscPC keyboard. Break and Alt-Gr are probably the two most important ones – i.e. ones which can’t be reliant on a FN modifier. As mentioned above I’ve currently got break mapped to a press of both shoulder buttons, leaving the thumbs free to hit Alt or Ctrl as appropriate. But that behaviour isn’t ideal if the gamepad controls/nubs are in gamepad mode, so maybe FN+Pandora to switch in and out of gameing mode isn’t such a bad idea. Alt-Gr I’ve currently got mapped to the Pandora key, although I guess either of the shoulder buttons would also do, and might end up being easier to use. Using the shoulder buttons would also free up the Pandora key for mapping to the Windows key (arguably the shoulder buttons could be used for the Windows keys, but the Pandora key makes more sense due to the labelling)

The remaining three keys could potentially be mapped to FN + gamepad keys? Maybe FN + D-pad left for print screen, FN + D-pad up for scroll lock, and FN + D-pad right for num lock. That should make them relatively easy to hit (since FN is on the bottom right of the keyboard), and the left to right ordering matches the order of the keys on a real keyboard.

It’s worth pointing out that at the moment Print Screen & Scroll Lock are handled by entering a special “FN + Enter” mode, but since those are the only two keys using that mode, and it’s a mode which Linux doesn’t use, I’d prefer to get rid of it if possible to help keep the code clean and provide a more consistent experience.

Just my tuppence…

I think it may be a good thing to move to changing the keyboard handler to a new API that:

• Nominally returns Unicode keypresses (to allow for a wider range of keyboard options, ie kana), not to mention breaking dependence upon the currently defined character set.
• Returns special keys with top bit set (as Unicode is up to 6 bytes and not all of those are defined, hence top bit set (or -ve numbers if you look at it that way) should hold clearly defined keycodes – F12, Esc, Email, Sleep, etc etc.
• Have an API for telling if specific modifier keys Ctrl, Alt… are pressed.

There should be a compatibility layer for “the old way”, but look to phasing that out. We probably ought to start thinking about OS_Key or maybe Territory_Key instead of the unholy mess of OS_Bytes that keyboard handling is scattered through…

There will be a need for low-level keyboard scanning, ie for games and such, on the understanding that the driver returns the keyboard codes and these are liable to change depending on the hardware.

Pfff, to many for me. I hope I understand the most right. It is the same discussion I have with Thomas last year and it is a “programmers problem” ;-). Since one year I use the Pandora (Linux and RISCOS) and I mean it is good usable with the Pandora-Layout. The same (uk) Layout for both is practical (Double click under Linux is right Nub up under RISCOS down ;-)).
The German chars if I need I can use with !Chars. Print Screen & Scroll Lock I not use with the Pandora.
Break via Pandora+L1+R1 is good, Reset via Pandora + On-slider is the same under Linux… it should be enough.
I have tested the Pandora with a german layout. It is not usable… searching, searching, searching. No standard.
I have a A5000 with the original keyboard and a german layout. No problem because my fingers know the right place of the keys… On the Pandora it is only practical to use what you see on the keys.
If Print Screen etc. is needed, a button in !AppDock or what ever is fine…
The special keys e.g. Brightness up/down, lid close sensor, and the power switch would be fine.
If I use the Pandora at home on a table I use a external keyboard/mouse and then I use the german layout and have all the functions.
Certainly I think too short for all the great but I’m only user. ;-)

One part of the equation which I’d previously forgotten about: The keyboard numbers which are used to register the driver with RISC OS. I guess we’d want a new keyboard number for the Pandora (and anything else which isn’t based around the standard PC-AT layout). I’ll admit that I don’t know what RISC OS does with the keyboard type; does it just ignore it? Since the keyboard type is related to the availability and usage of the low-level key numbers, it would make sense if InternationalKeyboard (or whatever else registers layout handlers) used different layouts for each keyboard type. E.g. one layout for UK PC-AT, and one layout for UK Pandora.

Nominally returns Unicode keypresses (to allow for a wider range of keyboard options, ie kana), not to mention breaking dependence upon the currently defined character set.

The keyboard handlers that InternationalKeyboard/keygen generates already allow Unicode character codes to be generated in response to key presses. But AFAIK it will only do so if the system alphabet is set to UTF-8, and there are currently a few barriers to making UTF-8 the default (see here and here for some discussion about that).

The issue I’m interested in is whether it makes sense to transition the “low-level internal key numbers” (which are what the keyboard handler receives from the keyboard driver) away from the fixed list we’re currently using and towards something more flexible, so that we don’t have to keep extending the list each time new keys are required. Since the keyboard handler internally operates in Unicode, using Unicode for the low-level keys could help reduce the amount of work it needs to do, and make it better at coping with keyboards which it previously didn’t know about.

(Note that low-level internal key numbers shouldn’t be confused with the keyboard scan codes that INKEY, etc. uses!)

(Double click under Linux is right Nub up under RISCOS down ;-))

Hmm, I didn’t realise I had it the wrong way round :) I’ll remember to fix it.

If I use the Pandora at home on a table I use a external keyboard/mouse and then I use the german layout and have all the functions.

That’s another problem that needs solving – Ideally the keyboard layout should be a per-keyboard thing instead of a global setting. If the KeyV key pressed & released reason codes could indicate the keyboard number then the keyboard handler could then use the appropriate layout for that keyboard, allowing you to plug in as many different styles of keyboard as you want without RISC OS getting confused (although the choice of UK, German, etc. layout would still need switching manually). It looks like this will need some tweaks to the kernel, so that it stores key up/down states on a per-keyboard number basis instead of using one global table

Lots of replies, firstly to Jeffrey. Apologies for the staggering length of this post.

it would result in compatibility issues for any software that tries to make use of the internal low-level key numbers directly, although I guess that practice should be discouraged anyway.

In the absence of ubiquitous DeepKeys-like functionality it can be unavoidable for programs with lots of hotkeys or for games, for example.

At the moment PandoraKey works around the key mapping issue by handling it all itself. This means it generates fake shift & alt keypress events as required in order to force the keyboard handler to produce the right output for the key the user is pressing

Yeah, that’s not good. You definitely need to write a keyboard handler (InternationalKeyboard replacement). I wrote one for the MMK Keyboard, it’s not horrific (certainly not now you can start with one from ROOL. I didn’t :-[ ).

If FN is handled by PandoraKey, we’ll need to generate the appropriate low-level internal key code for any keys pressed while FN is in effect. If we stick with the convention of using low-level keys that have a name/purpose which matches their non-modified usage, we’ll need new key codes for the following:

I really wouldn’t do that. It’s pretty easy to map the Pandora buttons to existing internal key numbers and do all the handling in InternationalKeyboard (for Pandora). (Aside: It is sometimes thought that INKEY numbers are limited to 7bits by the OS_Byte calls, but in fact that interface merely disallows bit7 – higher numbers are possible).

In other words, the internal key numbers used by PandoraKey would be the usual for A-Z, 0-9, Backspace, Left shift, comma and full stop, space and enter. Start and select are left alt and ctrl, and the logo key is &68 (“Left Logo”). Both sets of cursor keys are straightforward.

So that just leaves the shoulder buttons, which I’d have used &6D and &6E for (“Rewind” and “Forward”) – It’s the job of IK to translate these to INKEYs and key codes.

(Edit: Actually, some mix of the two is probably the best plan – FN does generate an internal key number, but FN-P also emits an F12 internal key number transition).

The obvious solution I can think of to would be to start using Unicode for the low-level internal keys

No no no. Unicode is about the encoding of the meaning of glyphs. It is nothing to do with physical keypresses. The MMK had a rotary knob which could be used for many things including controlling volume. This was mapped by the MMK_PS2 module to internal keys &74 and &75 which I deliberately ambiguated as “Less” and “More”. What Unicodes are they? Or more succinctly, this mouse has seven buttons on it, what are the Unicodes?

No, Unicodes are very clearly defined both in meaning and scope, and you are trying to bind them to physical buttons much too early.

I’m not sure what could be done with EventV, especially since the comments in Hdr:RISCOS suggest that there are only two event numbers remaining.

Well this kind of thing is one of the reasons I wrote VectorExtend, so we can have as many vectors as we like, but that’s another story.

sources to the Stork version of the Portable module suggest that Acorn were intending that all the special keys on the Stork keyboard were to be assigned their own low-level internal key codes

Yes. That’s what internal key numbers are. These are the buttons that got pressed – what happens next is up to whatever is hanging on KeyV, including (but not only) InternationalKeyboard (indirectly). I don’t take those Stork mappings as gospel – it was never released. Various multimedia keyboards were though, and I think we all standardised on the following (I certainly did):

• &68 Left Logo
• &69 Right Logo
• &6A Menu (key)
• &6B Play
• &6C Stop
• &6D Rewind
• &6E Forward
• &6F Eject
• &73 None (mute)
• &74 Less (volume down)
• &75 More (volume up)
• &76 Power
• &77 Sleep
• &78 Wake
• &79 Help
• &7A Web (favourites)
• &7B List
• &7C Link
• &7D Find (search)

at least the Pandora brightness keys and the power switch to generate KeyV events

Indeed. All the physical buttons on the device should be allocated an appropriate internal key number. Actual actions are then carried out by modules listening to KeyV/Event.

Likewise I’m hoping that it will also be possible to switch the nubs between mouse emulation and joystick emulation; I can imagine this being something that will need to be done using a key press combination, as there aren’t any APIs in place to allow programs to indicate when they’re starting and stopping joystick use. At the moment my best idea for what could control this would be something like FN + Pandora key.

This would be a module, looking out for the right enable/disable key combination on KeyV and filtering out appropriate internal key numbers when enabled.

MMK shipped with a number of such module including a few for controlling volume. As well as the simple ‘system volume’ there were a number for controlling various types of CD drive, including their internal volume. (And emulating skip to next/previous track on drives that only supported absolute seek was a challenge).

Print Screen, Scroll Lock, Break, Num Lock and Alt-Gr are all keys missing from the Pandora compared to a standard Arc/RiscPC keyboard.

Indeed, much as őöóåąãçėøôō are missing from my keyboard, and yet I managed to type them. In this case through the use of dead keys (the MMK driver has 16 dead keys – that’s 16 different types of accent) but the CTRL+num approach is another way. That Logo key is rather unused – you could use it as a modifier (when used as a modifier, IYSWIM), so Logo-P is Print Screen.

(Incidentally, the twin requirements of having to deal with any selected alphabet AND the desire to handle dead-keys for accents appears contradictory – how can you generate the right keycode for an accented character if you don’t recognise the alphabet. Because of that I introduced reason code 256 for Service &43 (International) to allow Alphabet modules to supply the necessary mapping tables. It did hard spaces too. However, all of that is better done through the later Unicode reason code, probably.)

However, there’s a difference between being able to operate the machine and being able to press every key some other machine had. Why would you want to press PrintScreen? You can’t on a Windows-hosted RISC OS emulator for example.

I’ll answer my own question with this: I wrote a series of “keyboard handlers” for the Beeb and Archimedes which allowed “Talkers” (think Stephen Hawking’s distinctive DECTalk-based talker) to directly control a computer, including pressing any key. This allowed someone limited to head and eye movement only to play Chocks Away for example. But do you think you’d need similar keyboard capability on the Pandora without additional code (ie a compatibility module)?

The keyboard handlers that InternationalKeyboard/keygen generates already allow Unicode character codes to be generated in response to key presses. But AFAIK it will only do so if the system alphabet is set to UTF-8

Indeed. And they have to generate different codes if the alphabet is set to something else.

The issue I’m interested in is whether it makes sense to transition the “low-level internal key numbers” (which are what the keyboard handler receives from the keyboard driver) away from the fixed list we’re currently using and towards something more flexible, so that we don’t have to keep extending the list each time new keys are required

Internal key numbers are internal. They changed between the Beebs and the Arc (hence INKEYs and LLIKNs) and can change again on the Pandora. Some INKEYs are faked for compatibility (see 72 for example). Ultimately, whether Fn is handled pre- or post- EventV is a matter of taste. Before might allow some degree of compatibility with games that read internal key numbers (INKEYs or LLIKNs), but after works too.

If the KeyV key pressed & released reason codes could indicate the keyboard number then the keyboard handler could then use the appropriate layout for that keyboard

Right now one can support multiple keyboards with different layouts by careful switching of the layout type on KeyV as required (and the Event has the driver ID, ugg). However, there’s no way to detect a single key on a particular keyboard. However, one could maintain a ‘current keyboard number’ by a similar additional reason code for KeyV (let’s not extend Event any further).

And Rick wrote:

Nominally returns Unicode keypresses (to allow for a wider range of keyboard options, ie kana), not to mention breaking dependence upon the currently defined character set.

If Alphabet is set to UTF8, that’s what you’d expect InternationalKeyboard to deliver. However, if it’s set to MacRoman, you wouldn’t!

Returns special keys with top bit set

Hang on, no. There’s some confusion here between character codes and key codes. The WIMP conflates these for convenience (which is why UCS32 cannot be returned by the Wimp_Poll KeyPress message).

I’m not quite sure what you mean by “the keyboard driver” as the functionality is split between a number of systems. The device driver quizzes the hardware and issues internal key number transitions. InternationalKeyboard interprets them and pushes codes into the keyboard buffer. The Wimp reads the keyboard buffer, remaps certain codes, and emits Wimp keypress codes through Wimp_Poll.

There are defined interfaces in a number of places there and you have to be pretty careful.

DeepKeys (amongst other things) extends the keyboard buffer to be word-wide instead of byte-wide. This allows one to insert &12345 into the keyboard buffer. The Wimp reads this, sees that it is not one of the encoded ‘special’ keys so passes it unmolested through Wimp_Poll to the application. However, the intention of this mechanism was to support virtual ‘special’ keys – an application friendly representation of additional inputs afforded by USB devices (such as a ‘Scan’ button on a USB scanner).

It can’t be used to deliver UCS32 through the Wimp (though could be so-used in a stand-alone application not using the Wimp) but there’s no point as UTF8 can be passed by the normal mechanisms.

Unicode is up to 6 bytes and not all of those are defined, hence top bit set (or -ve numbers if you look at it that way) should hold clearly defined keycodes – F12, Esc, Email, Sleep, etc etc.

If one were to define a new Wimp message, one could do such a thing. There’s no point talking about “the keyboard driver” doing that though, as it is putting things into the keyboard buffer (amongst other things) and as described it already encodes your example keys in a much simpler 8-bit way.

Have an API for telling if specific modifier keys Ctrl, Alt… are pressed.

At what level? You can use OS_Byte to read them, you can use KeyV to track them, you can use DeepKeys to deliver them through the Wimp_Poll keypress message. What further interface do you see a need for?

A replacement for the OS_Byte calls would be nice, but only because OS_Byte’s parameters are limited to 8 bits ¹ – its results aren’t (little known fact).

There will be a need for low-level keyboard scanning, ie for games and such, on the understanding that the driver returns the keyboard codes and these are liable to change depending on the hardware.

Isn’t that the very low-level calls you suggest should be phased out?

¹ OS_Byte is a highly misleading name. All calls to OS_Byte go down the ByteV vector, claimants of which can do whatever they like, including treating the ‘OS_Byte number’ R0 as a word (as VProtect does, for example) or its parameters R1 & R2. The kernel clamps R0 to a byte before decoding it, so an unimplemented ‘high’ R0 would cause some other OS_Byte to be executed, though that’s easily avoided (ByteExtend anyone?). Importantly though, OS_Byte has always returned word-sized results in R1 & R2, and can respond to word-sized parameters, contextually.

If Alphabet is set to UTF8, that’s what you’d expect InternationalKeyboard to deliver. However, if it’s set to MacRoman, you wouldn’t!

Which assumes a dependence upon Alphabet choices. Shouldn’t we look, as part of the wider picture, to transition to having UTF by default, with system alphabets for legacy software?

Hang on, no. There’s some confusion here between character codes and key codes.

I would say it depends upon how far down into the firmware you’re looking. I notice you mention the Wimp several times. I was thinking lower than that. But it is an interesting question as to how much the internal keyboard mapping is exposed; and at what point best to handle mappings and “wide” conversions (ie all of the stuff outside of the standard system character set).

It can’t be used to deliver UCS32 through the Wimp

No, the Wimp needs to either:

• Recognise via Wimp_Initialise version or flags that it is a “compatible” program that can receive Unicode and extended mouse events.
  or:
• Fake it using the existing API (even if this means all the destination program sees is a pile of “?” – that’s exactly how it looks and feels on WinXP as well!).
  While software like DeepKeys and hacks such as multiple keypress events serve their purpose; aren’t we getting into the day and age when eyebrows are going to raise if everything comes with an implicit 0-255 limitation on it? The Wimp ought to cope with Unicode stuff by itself in a sane manner.

A replacement for the OS_Byte calls would be nice, but only because OS_Byte’s parameters are limited to 8 bits – its results aren’t (little known fact).

A replacement to OS_Byte would be nice so you don’t have to keep looking at StrongHelp or the PRM to remember which call does what. ;-)

Isn’t that the very low-level calls you suggest should be phased out?

Annoying dichotomy, but I don’t imagine games programmers who want to bash the keyboard directly would be too thrilled if the reply was “nope, can’t do that”. You know what games programmers are like, they’ll do it anyway using whatever method works, and stuff will start to come unstuck down the line…

I’m not sure what could be done with EventV, especially since the comments in Hdr:RISCOS suggest that there are only two event numbers remaining.

The first thing – does somebody at ROOL have access to the complete secret-work-in-progress list? I can see gaping holes in the list given in that header file.

If so, are all of the allocated codes likely to be current and active? Nothing could be recycled?

Example off the top of my head: if there is an event for the Aleph1 80386 podule co-pro that isn’t present on the x86 RiscPC co-pro; well, RISC OS 5 is unlikely to work pre-RiscPC and it is unlikely a user will want to use a podule co-pro when better direct plug-in co-pro cards are available; thus if something like this existed, it could be a candidate for repurposing.

Likewise, can we have a show of hands of anybody that uses Econet on a machine capable of running RISC OS 5? [and me, I’m a fan of Econet; it hurts to write that, but seriously… three events for a networking system that no-way-no-how is going to be supported in current hardware?!? I’m actually surprised that Econet isn’t in The Attic!]

Thirdly… or is it fourthly? Anyway – why the limitation of Event calls? Something restricting it to five bits? Is this fixable, or is it spaghetti noodle code that is best left well alone?

I stay with the hardware. Is too complicated for me. ;-) If my docking station is ready for the Pandora, I’ll come back with my desire for an automatic detection of an external keyboard, mouse, network and video / sound under RISCOS;-)

why the limitation of Event calls? Something restricting it to five bits? Is this fixable, or is it spaghetti noodle code that is best left well alone?

It’s Beeb stuff. Way, way back, you didn’t want to run code unnecessarily. In particular, you didn’t want to issue Events for which there were no interested handlers. Now Event is just another vector, but its reason codes are special – events are only actually sent down EventV if that event is ‘enabled’, and there’s only a few bytes dedicated to remembering which events are enabled (by OSBytes 13 & 14). Guess how many bytes?!

Now one could increase the number of counter bytes, but that would mean reorganising zero page (which shouldn’t be done lightly, I’m looking at you, ROLtd) or one could accept that only the first 32 event numbers have enable counts… but the concept is outdated anyway. We’re really not saving anything by avoiding issuing those events, we can spare a few cycles (and there’s other things we could make more efficient).

And no, one shouldn’t be repurposing old Econet calls either.

I would say it depends upon how far down into the firmware you’re looking. I notice you mention the Wimp several times. I was thinking lower than that.

Doesn’t matter – it’s all holistic. The Wimp sets up the keyboard to encode ‘special’ keys (cursors, Fns etc) in a particular way (via OSBytes 4, 221-228 and 238). As that’s what the Wimp does, and it’s ubiquitous, everything else expects those values too.

I’m still trying to understand what problem needs to be solved here. It seems to me that all the existing mechanisms can cope perfectly well with the Pandora keyboard.

The ability to plug in multiple USB keyboards simultaneously (and have them do different things) is an interesting one, and analogous to the problem of plugging in multiple mice and being able to do useful things with them (I designed but did not complete the Channels module for that kind of thing). But that’s not the problem that needs to be solved here, is it?

I’m looking at you, ROLtd

ROL – Hmmm, I think the lights are on, doors are open, but no one is home.

Or did you mean ROOL ?

I’m looking at you, ROLtd

ROL – Hmmm, I think the lights are on, doors are open, but no one is home.

Or did you mean ROOL ?

ROL I’d assume. AFAIK ROOL don’t have any plans to reorganize zero page, apart from my work towards getting rid of it entirely.

The ability to plug in multiple USB keyboards simultaneously (and have them do different things) is an interesting one, and analogous to the problem of plugging in multiple mice and being able to do useful things with them (I designed but did not complete the Channels module for that kind of thing). But that’s not the problem that needs to be solved here, is it?

It’s not a problem that needs to be solved here, but it is a problem that will become more prevalent once the Pandora keyboard has its own layout handler. Although I suspect it will only be myself and Raik who are inconvenienced by it!

ROL I’d assume.

Indeed. If you’re going to make the EXEC file handle a word instead of a byte, move it, don’t just make it bigger and move everything else along… >:-[

Not that one should be furtling in zero page, unless one knows what one is doing, but there’s no reason to make it harder than it needs to be.

it is a problem that will become more prevalent once the Pandora keyboard has its own layout handler. Although I suspect it will only be myself and Raik who are inconvenienced by it!

Internal key numbers are 32bit, which is quite a lot more than anyone is going to need on a single device. ;-) How about defining the top 16 bits as a keyboard number (optionally)?

ie Under ‘default’ behaviour all keyboards (and existing code in effect) use keyboard number zero and everything goes through the usual IK route. But if you switch a particular device driver to use a keyboard number in the top bits, then IK (and everything else) is going to ignore those transitions as unknown keypresses. A new IK or something like it can deal with those.

The problem is one of configuration – eg if I had an AVID-like keyboard http://farm2.staticflickr.com/1158/1309116127_5cae23c3cd.jpg I could (by some new mechanism) tell its device driver to label its key transitions with some (dynamically?) allocated keyboard ID, map those deep internal key numbers to allocated deep key codes in the keyboard buffer (via DeepKeys) and hence deliver them unambiguously to any application (via Wimp_Poll or OS_ReadC). But if I plugged in a second and wanted that to do different things again, what then? Something analogous to the 221-228 OSBytes, but for whole keyboards?

I dealt with the multiple mouse problem by having mice control physical Channel values, and having things like mouse position, volume, pen pressure etc as virtual Channels, and allowing the user to connect physical to logical Channels by star command or GUI. That’s not going to scale well to keyboard keys!

Progress update:

• I’ve got a new version of PandoraKey that handles the FN key itself but leaves everything else up to the keyboard handler. In the end I found that the easiest way of handling the FN key was to track the FN state of each key individually, this made it easier to deal with rules like the sticky/delayed FN key, and complex key combinations like shift-ctrl-F12
• I’ve got a new InternationalKeyboard layout that works OK. I still need to compare it against a few other layout files to make sure I’ve got everything that’s expected (e.g. dead keys), but all the basics are there and working.
• Since most of the keys are mapped to the standard Arc/PC key numbers, the keyboard is still usable even if the right layout isn’t in use.

Next step is to work out how to properly integrate it into the sources. Since keyboard layout numbers have a 1:1 mapping to country/territory numbers, I think I’ll go down the route of teaching InternaltionalKeyboard to use different sets of layout files depending on which keyboard ID/driver is in use. Apart from some ugliness with the build system to resolve, this should be pretty straightforward.

After that I’ll need to deal with the fact that the system only allows the use of one keyboard layout at a time. Although revising the kernel’s keyboard handling to properly cope with multiple keyboards is desireable, I think I’ll just cheat and go with the easier approach of switching between different keyboard drivers as appropriate. After all, it’s unlikely that you’ll be wanting to be pressing two keys on two different keyboards at exactly the same time.

At the moment the USB drivers will use KeyV to set the keyboard type each time a keyboard is connected. However they don’t do anything when the last keyboard is removed. I could change things to set the keyboard type before each keypress, but that’s a bit too hacky. Instead I suspect I’ll add a new KeyV reason code for when a keyboard is removed; that way the USB driver can issue it once the last keyboard is gone, and PandoraKey can then claim it and reinstate its own keyboard type. (Another approach would be to make USBDriver just restore the previous keyboard type, but that also seems a bit nasty). Since InternationalKeyboard listens out for keyboard type changes on KeyV, these calls will automatically cause it to switch between the PC-AT layouts and the Pandora layout(s). Some extra logic may also be needed in PandoraKey to make sure that it only sets its keyboard type on startup if nothing else has set the keyboard type yet; that should avoid it overriding USBDriver’s settings if a USB keyboard is connected on boot.

Sounds good. Tomorrows ROM ? ;-)

The first thing – does somebody at ROOL have access to the complete secret-work-in-progress list? I can see gaping holes in the list given in that header file.

Yes, with our RISC OS allocations manager hats on, we do. Hdr:RISCOS is a rare header outside the Programmer.HdrSrc component that’s actually managed separately because several categories from the list of Things Requiring Allocations are held in it. It does say so at the top of the header file:

; This header file is autogenerated from the files maintained by the
; RISC OS allocations manager and should not be edited by anyone else.

although the presence of the standard licence header does make it harder to spot.

It is true that event numbers 0-29 have all been allocated. The allocations system doesn’t really allow for the possibility of them being clawed back, and even if we had the contact details of the original allocators, they probably wouldn’t be valid any more. Don’t be too concerned by the comment about only two remaining: event numbers above 32 have been possible at least as far back as CVS goes (RISC OS 3.6), the only difference is that the events can’t be disabled – not a big issue for RISC OS machines, so events 30 and 31 are probably best reserved for BBC micro enthusiasts, where that facility matters. You might notice that event 32 has been allocated – by yours truly, as it happens (in the days when I made rather than granted the requests!)

You might ask why you’d bother allocating a new event rather than a new vector, if any new events can’t be disabled. The answer is that events, like that other under-utilised interface, upcalls, can be have a handler installed by an application, so you don’t have to write a module to use them (unlike other vectors or service calls). The main difference between events and upcalls is that upcalls are issued synchronously (in other words, as part of handling a SWI that the application called), whereas events can be issued asynchronously (by an interrupt handler) and so, for example, an event handler may only call re-entrant SWIs.

Various multimedia keyboards were though, and I think we all standardised on the following

Regrettably, it doesn’t look like these were coordinated with Acorn/Pace. In the late 1990s, quite a lot of work was done on the keyboard and other subsystems to add support for Japanese, Korean and Taiwanese users, including support for the additional keys used on non-multimedia layouts in those countries, and those key codes clash with yours. There’s also a clash with the mouse scroll wheel, which appears as two keys.

As you may have seen from CVS, I’ve been working offline with Jeffrey to do some key number allocations for Pandora. We’ve basically agreed on a scheme that involves substantially enlarging the numberspace available for additional keys, and since we have Hdr:Keyboard as a centralised reference for keys now, hopefully any such clashes can be avoided in future.

Alt-Gr [is] missing from the Pandora

I think Jeffrey has spotted this in the meantime, but just so the record is set straight in the forum: RISC OS doesn’t treat AltGr any different from Alt, except if you explicitly scan for the right Alt button being held down. In terms of character composition, it’s treated identically to the left Alt key. On Archimedes keyboards, I seem to remember that it was also labelled as Alt. So it’s not top of the list of keys to panic about being missing from the Pandora. Personally, my biggest concern would be how to use keyboard shortcuts that consisted of shift + a function key, since shift is only on the non-FN layer, and the function keys are only on the FN layer…

Alt-Gr [is] missing from the Pandora

I think Jeffrey has spotted this in the meantime

Correct. The current code I’ve got treats the Pandora key as Alt-Gr, but now I know that RISC OS doesn’t treat Alt-Gr any differently from Alt, I’ll be forgetting about Alt-Gr and mapping the Pandora key to one of the Windows keys instead.

Personally, my biggest concern would be how to use keyboard shortcuts that consisted of shift + a function key, since shift is only on the non-FN layer, and the function keys are only on the FN layer…

The new version of PandoraKey tracks the FN state of each key individually, and only decides whether a key is to be FN translated or not on the key down event. So if you hold shift, then hold down FN, then press P, you’ll get Shift-F12, even though FN+Shift = caps lock.

There are a fair few bits I need to do to get everything working with the new wider range of low-level and INKEY key numbers, but hopefully I’ll have the new version of PandoraKey released sometime in the next couple of weeks.

I’m in super-pedant mode today, sorry. These comments for general readership, not BA or the other gurus of course.

Ben said:

You might ask why you’d bother allocating a new event rather than a new vector, if any new events can’t be disabled. The answer is that events, like that other under-utilised interface, upcalls, can be have a handler installed by an application, so you don’t have to write a module to use them (unlike other vectors or service calls).

Firstly, applications can register (“Claim”) handlers for Vectors – that’s what OS_DelinkApplication/OS_RelinkApplication are for. However, as Ben implies, that would only be any use for Vector calls that occur synchronously – specifically, when your application is ‘paged in’ (ie your handlers are “(re)linked”, not “delinked”). For a single tasking program there’s no problem. For a Wimp application one has to Delink before Polling and Relink after.

So the real issue is whether the thing you want to respond to is predictable – if you want to claim SpriteV for your app, you don’t need to do that in a module, but if you want to do so for all apps, you do. SpriteV is, in that sense, synchronous, and new Vectors could also be defined to be so.

VectorExtend massively increases the number of vector numbers and also allows (very nearly) every SWI to be auto-vectored. Both of which make Delink/Relink more useful, in fact (which is why I fixed the bug in Relink too). I should really make an RO5 version.

DebugTools also provides a mechanism for vectorising OS SWIs (it probably still works on RO5; it’s definitely 32-bit safe).

OS SWIs? Pah! Easy! Vectorise all SWIs, even ones where the module hasn’t been loaded yet… ;-p