Hootswitch, a (work-in-progress) Apple Desktop Bus switch

Andy

Well-known member
One way that might work would be to allow switching control over ADB to the Hootswitch. You could have an INIT on the mac that watches the mouse position and when it reaches the side of the screen sends a "switch next" or "switch previous" message to the Hootswitch. That would kind of emulate passing the mouse from screen to screen and bypassing tracking absolute positioning altogether.
 

CircuitBored

Well-known member
Great responses to my ponderings all around - thanks everyone. I think what we're ultimately all dreaming of is a KVM that can integrate with a program like Synergy. I'd sure love to clear that secondary ADB keyboard off my desk...
 

Arbee

Well-known member
As for the absolute positioning thing, I've already been dipping my toes into Mac application development (nothing specific to drivers yet). I've been pondering how hard it would be to write a generic absolute-positioning driver, something that I could deploy here for WiFi control and tashtari/others could potentially use elsewhere with other custom ADB projects. There is an open source Qemu virtio driver implementing a tablet that might provide an existing structure to build on: https://github.com/elliotnunn/classicvirtio

Curious if @Arbee or others with emulator dev experience could chime in with how applicable they think that code would be to a real-device driver?

You could definitely use that driver as the basis for what you want to do.
 

LaPorta

Well-known member
Maybe I’m just a simplified idiot…but isn’t the easiest way to switch things an actual switch on the box, or even a remote switch?
 

saybur

Well-known member
It's definitely the easiest way, but unfortunately the design of ADB makes things a bit more complicated:
  • Devices get reset during computer startup. If you don't participate in that process the device will likely not work with the computer properly.
  • ADB devices all have a changeable bus address. This follows a semi-random routine during reset. If all you have attached is a keyboard and mouse they generally remain at a default, predictable bus address, but if you have more than one device of a given type their locations on the bus can be random and switching will not be reliable.
  • There were apparently issues with mechanical switches losing the mouse and needing a separate program (ADB Renewer) that had to be launched from the keyboard.
The idea with the software-switch approach is to fix these problems by virtualizing the communication: even if a Mac is not the selected computer on startup, Hootswitch is pretending all the devices are there and handles all the required steps. If you switch away from a computer in the middle of a communication session, it looks to the computer like all you did was take your hands off the keyboard/mouse - they'll continue to respond to required messages if needed.

Basically, you can kind of get away with mechanical switches for very simple setups, but it was still quirky.
 

Arbee

Well-known member
Right, ADB enumerates the ADB devices once at power on and once more around SecondaryInit time (where 7.5.0 and later clear the initial Welcome banner and the boot thermometer appears). That's the major reason you can't hot-plug ADB devices.
 

saybur

Well-known member
Huh, that's interesting, I wasn't seeing a second enumeration while monitoring the bus via sigrok, at least with my IIci running 7.5.5. It generated a reset early on, enumerated, then started the usual Talk querying. Is the enumeration behavior ROM dependent? I could just have been missing it, I honestly was paying more attention to the particulars of the messages rather than the reset timing.

It would be nice if there was a second later pulse, the SE on 6.0.8 has a problem with Hootswitch where ADB reset is really early: if you try to power the devices up at the same time Hootswich will not have finished setup by the time the pulse comes in. Easy enough to get around by having a separate power source, but it's on my list of things to (eventually) fix.
 

superjer2000

Well-known member
It's definitely the easiest way, but unfortunately the design of ADB makes things a bit more complicated:
I think @LaPorta was just suggesting buttons on Hootswitch instead of a complex switching model (ie moving a cursor from machine a to b) - At least that is what I was thinking. Until I watched the video I wasn't sure how switching worked but it looks like you can change at the device or with a key combination.

Hootswitch looks awesome! I currently use a 4 port metal case type dial switch (probably for svideo) which is a pain as if I have the wrong machine selected and power on I need to hard power it down as I'm pretty sure switching while powered on is dangerous for ADB devices. This would solve that! Looking forward to watching this progress!!
 

saybur

Well-known member
I think @LaPorta was just suggesting buttons on Hootswitch instead of a complex switching model (ie moving a cursor from machine a to b) - At least that is what I was thinking. Until I watched the video I wasn't sure how switching worked but it looks like you can change at the device or with a key combination.
Ah, that makes sense. The button / key combo will be the default approach for sure. In general, even if 'fancy' features get added I really want to make sure this thing operates as a basic KVM-style switch without any user configuration: at some point I'll need to add a 'hoot.ini' type feature to set WiFi/Bluetooth/etc settings but that will not be required if all you want is something to replace the kind of equipment you're describing.

Thanks too for the nice comment :)
 

Torbar

Well-known member
do you happen to have the compiled uf2 file you can post? I don't have a linux machine setup currently so if you have one that'd save me a bit of time
 

Torbar

Well-known member
Got both the PCBs and the components this afternoon, built one, and it seems to work well. Don't have extra ADB cables handy(in the basement...somewhere) but hoping to find them this weekend and really test it out.

Awesome work!
 

saybur

Well-known member
Most excellent! If you end up testing more over the weekend I'd love to hear how it goes. Congrats on the new device and thanks for building one! 🥳
 

saybur

Well-known member
Haha yes, it is much easier by comparison! This time around I chose parts stocked by JLCPCB and included the CPL needed to have them do the annoying SMD work for you. I think I put mine together in about 15 minutes or so, everything is through-hole including the Pico unless you want to use the castellations on those.

For hardware, if you want to be really adventurous I have a version 2024b prototype up on Github (https://github.com/saybur/hootswitch/tree/hw-2024b) but I have not manufactured it yet. Most of the changes are minor but I'm reluctant to recommend anyone try something totally untested, more just FYI that it's there and aims to correct the errata for 2024a in the main branch. I'll hopefully have 2024b shipped back here in the next week or so and can make sure it works.
 
Top