[haiku-development] Re: Joystick support
- From: Krzysiek Ćwiertnia <krzysiek.bmkx@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Dec 2009 14:57:42 +0100
2009/12/17 Michael Lotz <mmlr@xxxxxxxx>:
> Just don't waste too much time to implement something for joystick like
> devices. If you eventually go with the framework then it would be easy
> to make BJoystick a client of that and drop any specific protocol you
> implement now.
The more I think of the new framework, the less I feel motivated for
implementing it like I thought at first :)
>> IMHO: As long as application will know what type of input device it
>> is
>> and could choose whether to use it or not, yes. Don't know if it's
>> always appropriate to use mouse as joypad for example.
[...]
> Why would the app care? HID has usage IDs which pretty specifically
> describe the function of an element. They are grouped into collections
> to form logical devices. The app can deduce from that what type of
> control it is and if it is a good choice to use it.
Well, I could have joypad and mouse both plugged in at the same time.
Both devices have axes, both have buttons. Both have usage "Pointer"
in Collection "Physical". How would input server (being a client of
the framework) pick primary pointer device for the desktop usage then?
Without being informed of primary usage of the device?
> The general idea is that there are so many devices out there that have
> very different functionality but all export this information as nice
> HID descriptors. So why should the driver pick out some parts of these
> packages and only relay them to userland? It imposes a data loss by
> fitting a device into a certain category. If you provide the framework
> and let the app decide what info it wants to use and how it just makes
> more sense. It also avoids the need for device vendors (or more likely
> us) to write specific drivers that pick out different info from the
> same devices. Just think about how stupid it would be if you'd have to
> write an extra driver just to make some motion sensor available in a
> device that otherwise is perfectly HID solely because some limited API
> in the OS or the suposedly generic driver doesn't provide the needed
> data fields.
I cannot agree more with you here. Maybe I wasn't precise (and my
english skills are not so good either). I was only stating that the
client should know what type of device it deals with, in order to help
it make a decision.
> You don't really want to poll. The best way to go is usually to setup a
> condition to wait on and then wait. In the case of input you'd pick out
> the data items you are interested in and then wait on them. That's how
> it is implemented in usb_hid. The handlers pick out the keys/buttons/
> axis they are interested in and then block on the report. As soon as
> one comes in they go through the collection of items and check for
> updates. Something similar could be exported to userland. The framework
> could also abstract this internally, so that you'd only send messages
> out for actual changes. The app would then subscribe to some controls
> it is interested in. If it isn't interested in them for a while it
> could always unsubscribe from them.
Ok, that sounds to me like the right approach.
> It's pretty obvious to implement it that way. It's just a bit of work
> to come up with a good design that is efficient and easy for the app
> developer to use. The protocol between the framework and the driver is
> the easiest part really. There needs to be a way to enumerate devices,
> collections of controls inside them that group certain functionality
> and then the individual controls. Then you need a way to start
> listening to events on these controls. Handing out control IDs and then
> being able to start listening by supplying the ID + some BLooper should
> be easy enough.
>
> To reduce duplicated work it'd make sense if the input_server would do
> the state keeping and management and be the one who sends out the event
> messages to the different apps that are listening.
Will give it some thought then. Thanks for your time and help.
Regards,
Krzysiek
Other related posts:
