New user advice

Probably a daft question

Hehe. :-)

Of course. It wouldn’t find a USB number (or report regular keys) otherwise.

For what it’s worth: USB$Device_00_00_00_1C4F_0002_*

For what it’s worth: USB$Device_00_00_00_1C4F_0002_*

And there’s only one endpoint on that device? Surely a man of your talents already knows how to read USB device data without my help!

This probably warrants a new thread on fixing RO’s handing of HID.

Print the data coming from the keyboard USB Device to screen (example code in this post), then plug the KVM in and switch inputs to see what data it’s sending. Once you know what it’s sending its a case of handling it in a keyboard driver.

I don’t think it’s that simple… The problem seems to be that the KVM effectively provides a USB hub which it switches around the different computers, so that the keyboard and mouse are plugged in and then unplugged again whenever the target system is changed.

In this case, your BASIC code happily displays the output from my KVM-attached keyboard, until the target is switched. At this point it says “USB Device not found” and falls over. The time when the Titanium’s USB seems to have issues is when the KVM switches back to the machine: at which point, presumably, RISC OS sees a new USB hub plugged in with a keyboard and mouse attached.

The time when the Titanium’s USB seems to have issues is when the KVM switches back to the machine: at which point, presumably, RISC OS sees a new USB hub plugged in with a keyboard and mouse attached.

Exactly. That is precisely the behaviour my KVM displays. Since my KVM is used only for KM, the V is a separate switch, one can watch when the error occurs on switching away and back to the Titanium.

At this point it says “USB Device not found” and falls over.

Modify it so it repeatedly retries to open the endpoint, we want to see if the KVM sends any data when it reattaches.

Since my KVM is used only for KM, the V is a separate switch, one can watch when the error occurs on switching away and back to the Titanium.

Likewise, and a directly-connected keyboard and mouse allow me to interact with the Titanium when the errors occur.

I’ve been doing some tests just now, and after the desktop is up and running the main issue is an Abort on Data Transfer at &6408 or &63EC in the USBDriver module (RISC OS 5.24), either when the KVM is switched in, or when it is switched away¹. Pre-desktop, there were Data Aborts at &3E8C and &3E90 in the XHCIDriver.

¹ Sometimes it’s one, sometimes the other. After that, the KVM won’t work with the Titanium until it has been rebooted.

there were Data Aborts at &3E8C and &3E90 in the XHCIDriver.

Yes, that is what I see, although that is once the machine is running normally in the desktop and is then switched.

I know that Sprow worked on a solution for at least one of the “interesting” KVM problems – I had one KVM switch that would – if connected to the Titanium board – not allow the Titanium to even boot. I think it was a problem in parsing that completely broken USB device descriptor early in the Ti firmware.

The KVM was in many aspects completely broken so it was not a problem to switch to another one. The good old 8port Belkin PS2-USB-VGA seems to work fine with the Titanium.

I have two other KVM switches which have 4K HDMI video support that I need to test in my ongoing quest for the ideal KVM (where the “ideal” requirement has already been reduced to “not completely unusable”).

Well, Rillian, after all of that…are you convinced? :)

you convinced? :)

Ah, but convinced about what?

• That we’re very passionate about RISC OS?
• That we’re geeks?
• That many of us don’t speak a language known to normal people?
• All of the above?

;-)