Browsing this Thread:
1 Anonymous Users
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
On the "A Week in AROS..." thread nikolaos wrote:
Quote:
Hi and sorry for the late reply... In my mind the new input implementation should be done right the first time. There are many possibilities on how the new input method could be conceived. I'd prefer if common agreement could be met on just how to implement it. Someone might frown upon using the AROS .hidd system, but they are basicly just libraries/devices... Kalamatee wants an event driven system which is in my mind is also desired, but I think SDL also polls the inputs... No big deal there either, just make a input handler that fills the inputs as they come and poll the result from there if not implementing a real event driven system. This could be implemented in the SDL AROS port so it would seem nothing has changed.
Posted on: 2018/4/29 11:26
|
|||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Yes, would be nice if 2 joysticks where detected automatically to different ports. Little lame the need to configure manually through Trident.
Posted on: 2018/4/26 22:16
|
|||
|
www.aspireos.com
|
||||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
I use the lowlevel library through lib Sdl. The lowlevel library has support for only 7 joystick buttons (I guess that limit was from the old Cd32 controller). Even support for 1 more button would be helpful but support for 12 or 16 buttons would cover most joypads, I think.
The lowlevel library forces a choice between digital (d-pad) or analog support. An extended type, on top of the legacy controller types, would ideally support both. As it is now, I have to compile a custom lib Sdl for games that use xy analog. It would be nice to have z-axis and rotation support, but to be honest most Sdl games don't need it. Yes, if I plug in a second joypad, the readings seem to get merged with the input of the first joypad, until I reconfigure Trident. Perhaps there could be a Trident option to load a typical cfg (which would then ask for port, number of buttons, etc). Also regarding input, many Sdl games (and posix apps) expect and use the right-ctrl key. Sometimes it's a pita to find a workaround, especially if the keys are documented. Imo, having distinct left and right ctrl keys would benefit Aros.
Posted on: 2018/4/20 21:55
|
|||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Well... The Poseidon's eventhook system doesn't allow one to claim a device or interface, I thought it could but no. The whole psdEventhook system isn't finished and was left half way done. With Poseidon one can claim the whole device or just one(or more) of it's interfaces. If the humaninput.device would only use the interface for buttons etc. then some other class could use the audio interface. Not sure what the usbaudio.class is capable of at the moment, but that is meant for usb and audio.
Posted on: 2018/4/20 18:18
|
|||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Theres a few problems; A> Theres not propper support for controllers with more than 2 buttons, more than one analogue input, other newer features B> Theres no way to query what is available C> theres no way for devices to automatically assign themselves to a unique port. everything just gets dumped on port 1. D> You _must_ manually configure it all yourself in trident prefs presently. This is really un-user friendly and cryptic for those without prior knowledge. E> Theres no amiga like event-driven way to get feedback from the controllers. It must be polled which is inefficient. Its also far less responsive for gamers.
Posted on: 2018/4/20 15:21
|
|||
|
||||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
I was thinking more the opposite. the usb hid.class would register a "hidd" driver representing the device with humaninput.device, which can be queried to determine what buttons are present etc. humaninput.device can broadcast events when a device is attached or removed, so that listeners can determine when to enumerate what is available to update in their own state. If a driver (lets say a ps4 or xbox controller), exposed an audio device to push sound out of its headphone jack or integrated speaker ... we could expose that attachment via the usb objects hidd also. It would need to privde an ahi device representing the audio output. You would then either be able to choose to send audio via it using AHI - or if a e.g game supported such functionality, it can determine the ahi device for the controller via the enumerated hidd object ... and pump certain sounds specifially for that controller/user Quote:
I would like that the usb hid class just maps the usb hid device to an object format that is generic for AROS to understand and use, and let AROS components manage the enumeration and actual usage/mapping of the functionality.
Posted on: 2018/4/20 15:16
|
|||
|
|
||||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
This is to advanced for me but Joystick, lowlevel port 1 with 2 button controller always worked. The problem been more advanced controllers with more buttons and 2 analogue pads. You can not map buttons or controllers without using the analogue hack is my understanding.
Posted on: 2018/4/20 12:31
|
|||
|
www.aspireos.com
|
||||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
HID.class has had the lowlevel patch in it from day one on our repository. Haven't tried to map anything with the Trident though...
Posted on: 2018/4/20 6:05
|
|||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
We could make a gamepad "stack" that attaches to Poseidon PsdEventHook and goes through a list of supported game controllers and if it has one then claims the device for the "stack".
Common API would there after be used to communicate with the controller. Now everything is in the hid.class but with that we should be able to bypass the hid.class claiming the device.
Posted on: 2018/4/20 6:00
|
|||
|
||||
|
Re: Controller
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
It isnt quite as straight forward as you think to do cleanly/correctly. Quote:
I would prefer a more permanent solution - this sounds too "quick fix"/ hacky. IMHO we need 2 new components to compliment the existing and expose new features. A> We need a new input (like) device that does the same kind of things as the existing input.device. It should be the place drivers register input controllers, and handles forwarding supported events to the existing input.device for legacy support. Lets call it hid.device for the time being. * = we can copy/reuse a lot of the existing input device code for this and addapt it. B> We need a new lowlevel.library that also deals with the new hid.device to communicate with controllers and provides a light weight api for devs to interact with the controllers. Again, it should forward supported events to the existing lowlevel.library for legacy support - but new code should use the new library instead. Lets call it inputdevice.library for now. * = this probably needs a different api to the existing one. So .. The existing implementation has many shortcommings that we need to address in these new components. # Theres no clean way for input devices (other than those that use the existing input.device) to register with the system in a unique way - which is why poseidon devices for instance all map to port 1 until configured manually. The hid.device needs to handle registration and allocate a suitable unique ID to use for each attached device. # Theres no real way to query "what" is attached to the system currently - the library needs to provide a clean way to do this, and to find out the capabilities of any device. Since AROS uses the hidd device API, it should be able to find out the hidd objects available representing the devices, then query those directly. # Existing input is only handled via polling which is not very amigaos like (AmigaOS being event driven). The new library needs to provide a way for listeners (apps using the devices) to register event handlers and pump the events to them. lowlevel.library could register and have the events it needs pumped to it, then expose them for legacy apps using polling. # New controllers have other features integrated (such as sound output, etc) - so it should be able to query the input devices hidd driver and find out what else it supports. [edit] Thinking about it a little more ... # We may be able to proivide both using one implementation, and have just the device but with extra lib functions to its base exposing the "low-level" API for apps to enumerate, etc, the actual devices. This would allow for a smaller footprint overall and negate the need for glue between both. # HumanInput would probably be a better base name if thats what it is meant to represent. Input.device would the the system level input, and HumanInput for real interactive devices used by a user. # We should consider advanced input events that AROS/AmigaOS cant propely handle currently - like multi-touch, when implementing the API's # It would be nice to provide a way for a listener to obtain exclusive access to a device, Instead of only having all events distributed globaly like input device/lowlevel currently do.
Posted on: 2018/4/19 17:36
Edited by Kalamatee on 2018/4/19 18:05:17
Edited by Kalamatee on 2018/4/19 18:06:14 Edited by Kalamatee on 2018/4/19 18:23:13 |
|||
|
|
||||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
