Eccentric keyboard

Hi,

I have been given a keyboard by a friend. It is marked as a Trust keyboard, aimed at old-school gamers (so W, A, S, D and cursors are heavy duty rubber keys – Chuckie Egg anyone? ;-) ). Apparently this keyboard supports up to eight key rollover.
This was to replace a functional AZERTY keyboard as I got sick of trying to find special (programming) characters on the AZERTY layout.

When in the desktop and not in an editor, frequently the keyboard acts incorrectly – for example Ctrl-Shift held and clicking something will run it instead of opening it (I never could remember if it was Ctrl or Shift, so I just used to hold both). Conversely, closing a window would pin it to the backdrop.

When in Zap, Sh^C is used to start a compile. This process would freeze until I then press another key, such as one of the cursors. I guess RISC OS might still be thinking Ctrl or something is held?

Has anybody experienced this, and if so, is there a fix? Maybe a USBQuirk setting to slow down the data rate or somesuch?

Here’s the USB info:

*USBDevices

No. Bus Dev Class Description
  1   1   1  9/ 0 EHCI root hub
  2   1   2  9/ 0 Standard Microsystems SMSC9514 USB 4 port hub
  3   1   3  0/ 0 Logitech USB-PS/2 Optical Mouse
  4   1   4  0/ 0 KB USB Keyboard
  5   1   5 FF/ 0 Standard Microsystems SMSC9512/9514 Ethernet device
  6   1   6  0/ 0 USBest Technology USB Mass Storage Device
  7   2   1  9/ 0 MUSBMHDRC root hub
  8   1   7  0/ 0 USBest Technology USB Mass Storage Device

*USBDevInfo 4
USB release     : 0110
Device class    : 00
Device subclass : 00
Device protocol : 00
Max packet size : 08
Vendor ID       : 04D9
Product ID      : A055
Device ID       : 0020
.# of configs   : 1
Manufacturer    : 'KB'
Product         : 'USB Keyboard'
Serial number   : ''

*USBConfInfo 4
Current config  : 1

.# of interfaces: 2
Config value    : 1
Name            : ''
Attributes      : Bus powered
                  Remote Wakeup
Maximum power   : 100mA

Interface 0.0 class 3.1:1 ''
1 HID110 descriptors,  Country 0
    Type 22, length 75
 1 IN  Interrupt 8 bytes 10 frames

Interface 1.0 class 3.0:0 ''
1 HID110 descriptors,  Country 0
    Type 22, length 108
 2 IN  Interrupt 8 bytes 10 frames

Thanks,

Rick.

Nobody?

Nobody had a keyboard where the modifiers (ctrl [and|or] shift) got messed up? [on a Beagle xM]
No quirk settings to try?

Okay then, any thoughts as to stuff I might do to resolve this? [I would prefer to fix the software, not “buy another keyboard” as this issue might end up affecting newbies, I guess it depends upon what is actually happening…]

Following on, it looks as if this keyboard does not work with Linux either.

The actual symptoms under RISC OS (from the little I’ve actually used it), one or both of the modifier keys (Ctrl + Shift) seems to get ‘stuck’ (holding a key to open an application folder doesn’t work; and at other times double-clicking a runnable file loads it into Edit/Zap), and needs an additional alphanumeric keypress to ‘clear’.
Ditto, doing Ctrl+Shift+C to start a compile from Zap appears to freeze the machine until I press an alphanumeric on the keyboard at which point the compile runs (it is as if RISC OS is waiting for me to stop pressing down the Ctrl+Shift+C or somesuch).

I’ve also noticed that my MoreKeys (uses Ctrl+Alt+key) can be a bit erratic.

This is the keyboard (on Maplin’s site). My friend got it because the orange keys reminded him of his Beeb (!). I, personally, suspect the “special gaming features” (anti-ghosting 8-key-simultanteous) is playing up with standard keyboard drivers.

I have found a message describing some of the issues and the resolution, but this stuff is gibberish to me – perhaps somebody more au fait with keyboard USB would understand it?

Message: http://www.spinics.net/lists/linux-usb/msg62270.html

Briefly:

The keyboard is pretty standard, with a boot interface and a report interface. The report interface has two problems:
- as you noted, the device presents 2^15 consumer usages, much larger than the HID_MAX_USAGES=12288 limit
- no LED usage block is presented, preventing any use of the num/caps/scroll LEDs in report mode
I tried making a test module (code below) to make the keyboard work. It does the following:
- provides a fixed report descriptor, correcting the 2^15 consumer usages problem
- adds an LED usage block into the report descriptor, then redirects LED change events to the boot interface.

Hope this helps…somebody. ;-)

I’ve poked the keyboard drivers in the past (to fix a similar problem with the TouchBook trackpad, which wasn’t obeying the HID spec), so I could probably have a shot at this. Shame that Linux code is GPL’d; I guess patching the consumer usage count is easy enough for me to do myself, but working out how to fix the LEDs without copying the Linux patch and without having a keyboard to test with could be a bit tricky! (unless by some freak chance the LEDs are working for you?)

Sorry for the delay in getting back to you.

Actually, the LEDs are working! Indeed, the only problem I am having is that modifier keys seem to get lost/messed up.

Therefore, Linux— RISCOS++ ;-)

Hi guys,
I’m hijacking this keyboard thread because my french keyboard mostly works (when the territory/country is set in !Configure) except a few keys (including circumflex accent, dollar and above all, BACKSPACE!). I use the DEL key in the meantime. Anyone knows who’s in charge of dealing with keyboards support in RISC OS 5 ? Thanks

The way RISC OS intends the France keyboard layout to work is shown in the DrawFile here

Do the same buttons do anything when you choose a different keyboard layout in !Configure?

@ben: “File version number is too high” from Draw 1.19
Artworks 2.75 shows an empty document
And F3 doesn’t do anything anywhere :(

Ah, there seems to be a bug in our CVS viewer – the file appears to have gone through a Latin1 → UTF8 filter (meant for text files, and that’s a binary file). I’ll give the webmaster a prod to see it it can be fixed!

In the meantime, you should be able to read it if you download a source archive – for example this one

The file is inside the directory castle.RiscOS.Sources.Internat.IntKey.Layouts.

Upon investigation, the layout of my keyboard was the same as the one in the CVS… After testing of a WinXP PC, my keyboard had those keys completely dead (beyond repair). So RISC OS wasn’t at fault, sorry guys ;(