BeOS Joystick Framework

Article contributed by ModeenF on Mon, 2008-08-11 13:53

This article are more of a compliment to ITO Takayuki’s “BeOS Joystick Driver ” so reading ITO’s article before this one are advisable.

I’m not a article writing person (not even in Swedish) but as I’m the 3:d that tries to implement the Joysticks framework in Haiku I think that it would be good to have something for the 4:th person to read if I drop this :)

When I started to look over the Joystick framework I thought that this would not be that hard, boy was I fooled :) , lol I don’t even know how to talk to hardware. Anyway after some testing (trial and error style) I think I have found some additional information about the Joystick framework, but first I would like to describe how I think the frame work works.

The BJoystick class in talks to a joystick published at dev/joystick/”portname”/”joystick name” this way both the generic gameport and ITO’s usb_joy works as they publish as separate devices.
usb_joy = dev/joysticks/usb/0 (for the first)
usb_joy = dev/joysticks/usb/1 (Second and so on)
gameport = dev/joysticks/gameport/201
emuxkigameport = dev/joysticks/ emuxkigameport /et18

emuxkigameport are a driver that was donated to Haiku that make’s gamport on a SB Live and Audigy soundcard work. I tried to add it to emuxki but then the sound was interfered when I moved the joystick. This driver uses the generic gameport.

So how does this work? You could say we have two ways of talking to Joystick’s, through usb_joy and emuxkigameport. First you must have a copy of a joystick description file in config/settings/joystick/”portname”/”joystick name”. I think that this need to be a copy of a description file as the Joystick Preference app does changes to the file so a link are not to recommend.

First usb_joy, when BJoystick sends a ioct (I haven’t tested but I think I have figured that one out right?) to the driver the usb_joy does everything by itself, collecting usb information and reading joystick description file from /settings/joystick/”portname”/”joystick name”.

How does the emuxkigameport work then? BJoystick sends the same information as with usb_joy but in this case the emuxkigameport forwared the ioct to a driver called generic gameport located under drivers/generic this one loads the file in config/settings/joystick/”portname”/”joystick name” with this file it knows what module to load and loads this module but it must be a joystick description file in this location or you will only be allowed to used the joystick in standard mode (same if the module don’t exist to your joystick).

Using BeOS Joystick Framework in Haiku. Yes this works but not usb_joy as it crashes the system.
You need to copy, Joystick preference app, etc/joysticks, media/joy, generic/gamport and Haiku’s emuxkigameport. I have only tested stickit and BeOS R5 joystick preference and not any games.

So what now? I will continue but perhaps focus on the usb_joy driver and figure out what’s wrong with this driver. I would like to have some help to determent if it would be a good idée to use modules in a USB drive to handle the difference in different joystick’s or does those difference not exist in a USB world?

If you like to read more about Joysticks in BeOS here are some links.


Re: BeOS Joystick Framework

Hi Frederik

While I certainly find it commendable that you invest time to investigate how this was all supposed to work in BeOS, I don't really see why we should stick to such an obviously strange design. As you pointed out, the BJoystick does itself communicate with the drivers so there is a protocol between the two. Additionally there are multiple drivers that apparently handle things differently. This is ugly to say the least.

The usb_joy is an absolute no go from my side. It completely duplicates the HID parsing and handling present in usb_hid. That's not how it should work. Instead, the USB joystick should just be a normal USB HID device (it is after all just a normal USB HID device) added to the usb_hid driver and therefore publish an entry as "/dev/input/joystick/usbX" as do all the other HID devices. Then the protocol should be between the input_server and the driver as for all other input devices. This means the input_server would handle the joystick as an input device and the usb_hid driver (or a generic gameport based joystick driver for that matter) should communicate with the input_server only. BJoystick should then just be an accessor to the input_server data.

I understand that you are trying to reimplement the BeOS solution under Haiku, but this is one of the cases where we IMHO have the chance to correct a flawed design decision. Leaving the BJoystick class as a wrapper to a new design, we can keep binary compatibility from an application side of things.

Please don't take this as a discouragement, it is just meant to show you how this could be made into a better design that will be easier to maintain for the long term.


Re: BeOS Joystick Framework

No problem and I haven’t forgotten our last discussion and I was hoping for your comments :)

I have begun to look on the usb_hid you suggested , tried to make a joystick part but without luck. I didn’t try that hard and my expertise are more application and UI layout than back side usb/hardware programming but I’ll continue trying. :)

Doesn’t the input_server need to be change to handle joystick?

I also found that Dano/Zeta have a GameInput class (don’t remember exact), I think that Be was about to abandon BJoystick for games.

Found some linux links is some one wants to read more :)

Re: BeOS Joystick Framework

what I would like to see is support for the same type of motion control technology that's on the wii. A standard for such controllers would result in all kinds of new games and controllers and not just the ones that have a deal with Nintendo (or Microsoft or Sony if they decide to copy)

Re: BeOS Joystick Framework

arielb wrote:

what I would like to see is support for the same type of motion control technology that's on the wii. A standard for such controllers would result in all kinds of new games and controllers and not just the ones that have a deal with Nintendo (or Microsoft or Sony if they decide to copy)

The Wii remote is just a Bluetooth HID, and (IIRC) the motion-sensitivity data shows up as additional axes. Since the Bluetooth HID profile is a wrapper around the USB HID protocol, it ends up being relatively easy to do (tools exist for Windows and Linux to let you use the Wiimote as a game controller, I don't have a link but they're relatively easy to Google). All we would need to use the Wiimote would be a working USB stack with HID support and a working Bluetooth stack. According to Wikipedia (, the Playstation3 controllers do the same thing.

Re: BeOS Joystick Framework

Hi, maybe you can have a look at that's a cross platform input (and output, think force feedback etc) library used for game programming. I think the mac implementation uses HID to communicate with the devices (not sure the mac version is complete though as i only used it on linux and windows)

Hope this helps,

Re: BeOS Joystick Framework

Then is posible psx1 pad in haiku?

Re: BeOS Joystick Framework

If I plug a USB joystick, it takes out my USB Mouse :P

Re: BeOS Joystick Framework

some though:

BJoystick should have some software-layer to give ability to simulate keyboard using joystick. This could solve a problem with apps / games / emus that dont have joystick implementation.