Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dizzy

Pages: [1] 2
Development (General) / Re: Status of Raspberry Pi native support
« on: January 16, 2019, 09:23:38 PM »
Poseidon is the main USB code, it doesn't know by itself anything about the hardware. Driver code is attached to it. Poseidon takes care of all the preferences, classes and drivers. Drivers only try to satisfie higher level requests from Poseidon or it's classes more specificly.

Every driver has to have a roothub as per usb spec. Roothub represents your hw. Roothub has ports, these are the physical ports that the host controller has (doesn't have to be... You could also implement a virtual port and have virtual devices attach)

hub.class calls your roothub and your driver has to respond to roothub requests. It's all in the usb specs. Poseidon doesn't yeat know anything about usb 3.x requests. Driver also responds to requests to the physical device and conveys messages between the host and device.

Development (General) / Re: Status of Raspberry Pi native support
« on: January 16, 2019, 09:07:32 PM »
Poseidons preference program is called Trident, it's not a coincidence.

For coding a driver you first need to understand Exec signals, messages, iorequests and lists.

For a driver (device normally) there are only a few "functions" DoIO, SendIO etc. The details are in the IO request fields. Take a look at the VUSBHCI driver. There's no hw stuff, only high level code for Poseidon driver and libusb.

VUSBHCI is also much more readable as I've put everything in plain sight in structures. You will recognize usb spec things in it and how things are passed around.

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 15, 2019, 07:42:02 PM »
Dizzy: When can I test :) What fantastic work you are doing :)
I will start my 6 days of work tomorrow morning at 5:30 it might not be until the end of work schedule that I'll continue with it. It's almost all there, just needs some sort of interface for games to attach to. It is also all there but no code in the library.

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 15, 2019, 07:26:10 PM »
I'll start tomorrow renaming things differently, I just don't understand the point... I'll call the arosx.class XUSB.dll and arosx.library XINPUT.dll  ;D
EDIT: Holy shit! I can actually do that!

Development (General) / Re: Status of Raspberry Pi native support
« on: January 15, 2019, 05:42:58 PM »
What is the current status of getting AROS up and running on the Raspberry Pi? I looked into this years ago, and some developer was having trouble getting the USB to work. I've done some bare metal programming for the Pi, and it would be fun to help improve hardware support. Can someone point me to documentation on compiling AROS, how the repository is organized, and driver development?

It's best to develop under Linux. AROS build system can make a cross compiler for your platform. Build system uses metamake, takes a bit to get used to, but it does it's job if not asked too much.

For driver development you should know how Exec works (library and device) and how messages are passed around. Then comes the AROS macros to actually define the LVO's...

There is only host mode support for USB, we have no VID/PID nor code in Poseidon (USB stack) for having it behave as a device. No OTG.

For USB driver development the USB specs are a source of good information... Poseidon drivers can be programmed with that information. There are the working PCIUSB driver (all nicely bundled together OHCI/UHCI/EHCI) and couple not so working examples of my conception (XHCI and somewhat working libusb based hosted implementation VUSBHCI, virtual usb host controller interface)

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 15, 2019, 09:38:50 AM »
@dizzy. kalamatee is complaining about your naming convention "arosx".. he says it should be simply "xinput".
wanna join us on slack?

edit: ah, he wrote you already. nevermind.
I'm not entirely so fond of it either, it comes from the fact that it's for AROS and purely for XInput. I could have called it AROS_XINPUT or something.
Either way, as XInput's internals are closed I think for the reimplementation for XInput controllers it suits just fine. It doesn't even try to pass as XInput, it's different.

The base class arosx.class, which is also a library, doesn't need arosx.conf to build includes, our build system needs it to be in place for building the class/library. Could it use the Poseidon base class conf? Poseidon uses that to call the classes. EVERY SINGLE ONE .conf file is redundant except the base class conf, make a change in there and crash is about to happen. Only the base, version and some library flags are used.

There is no option to pass different .conf file...
Build system also builds the linklib for arosx.library although it has no code, but only needs to build the includes...

On Windows the layer communicating with the XInput device via USB is called XUSB. Should I name the base class to XUSB? XInput does not directly communicate with any controller.

Last night in the bed crying myself to sleep, I tried to justify myself why the other arosx.conf is in the inlude folder. It's sole purpose is to build the includes for the arosx.library... Or so I told myself...

On Apple the call to discover wireless controllers is called startWirelessControllerDiscoveryWithCompletionHandler, I would have prefixed it with "IOS_" or" Apple_" :)
No just kidding, the purpose of "AROSX_" prefixes is to prevent naming conflicts. I think no one is fool enough to name their things in a similar way...
Not much things are exposed to the outside world containing that prefix, the class code is littered with it though... Which is kinda pointless if the point is to prevent naming conflicts as I could name a thing differently if conflict occured and not just name everything with that prefix...

Well... The real truth why things are the way they are is that there is no preliminary planning involved with this... It all just kind of evolved... No real answer to this one I'm afraid... :)

I could have created a single library that talks to Poseidon directly, but then I would have to query it for all the devices. Now they are handed to us by the interface binding mechanism.
Basicly the arosx.class and arosx.library is the same thing. Poseidons arosx.class has in essence two library interfaces, one for Poseidon (arosx.class) and one for the user (arosx.library) then there are the handler tasks dancing in between. It could also be made such that the class code exposes message ports (or a device interface) and some library talks to it via those...

I haven't made up my mind how the arosx.library attaches itself to a controller. arosx.class could call some function "AddController" That way also other than XInput controllers could be bind with the library, but then arosx.library would have to have some more generic name, "gamecontroller.library" or something... I don't foresee that anyone would take on the task to make hid.class controllers attach to anything else than lowlevel.library.

There still could be a third, more generic library that gathers different kinds of controllers, one being the four arosx controllers... Either things bind with arosx.library or arosx.library binds with some other game controller library.
If anyone wants to code such a game controller API then I'm all good with that. I've stated it before that I do not look forward defining any such game controller API.

                      Game or game controller library

For the event based notifications, I'm thinking to imlement these functions:

port = CreateEventPort(controller id)
AttachEventHandler(&Handler, port)
RemoveEventHandler(controller id, port)

Or something... ?

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 14, 2019, 10:09:21 AM »
I've basicly now rewritten the whole thing...  :o

I should have started a bit more object oriented way. Now there is the AROSXClass and it has AROSXClassController which in turn can be XInput gamepad. The arosx.library does nothing at the moment but now it is actually working (can be opened and closed...), it was just a quick copypastemonkeycode from the first thing I found on the AROS tree.

I've looked at a lot of game controller API's and they pretty much just poll the inputs, let's see what the arosx.library will house.

As the arosx.library is part of the arosx.class  (just a different interface exposed to outside world) I'm thinking just to use arosx.class memory as if it belonged to arosx.library. Or pass around messages.
Maybe messaging is better suited... Don't know... For force feedback it might be beneficial to have a queue of ff-commands with duration and instant flush of the queue when needed.

Yesterday I tried to find how the battery information is passed on the USB, but my Windows machine is W7 and it has older xinput. Not sure if it provides such information. I installed vs2017 and got at least one example that polled the inputs and send ff commands to work.

For the Logitech F710 wireless gamepad arosx.class shows that it is wireless and when it goes to sleep mode and when it wakes, not sure if it will work the same with different wireless controllers.

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 13, 2019, 09:58:48 AM »
What about the plugin here.
It is for the PS1 emulator fpse. The emu source code is not available but the plugin source is there to play with.
I be happy to test but must be abi v.0
I'll see about the plugin once I get things going on better with the class. It's a bit early for backporting as the code at the moment doesn't actually do anything usefull.
I've limited the number of gamepads to four now and set the leds to lid according to the gamepad number.

I'll clean up the basic framework of the code so it will change quite a bit. Now the code is mostly just some code snippets here and there...

EDIT: I've cleaned the code a lot now, it should be easier for now to attach other library to it. It needs a bit more streamlining, I'll do a commit after that is done.

I'm not sure if I should provide the arosx_ll.library to substitute the lowlevel.library with hex editor on already compiled games. As Poseidon already patches the lowlevel I'm not sure how my patching would affect it.

EDIT: On HTML5 the gamepad API inhibits the discovery of controllers until one presses a button on the controller. This is to inhibit fingerprinting the machine, I don't think that is needed for us... ?
As the arosx Poseidon class now only setups gamepads, I think if there will ever come support for different kind of XInput controller, say a racing wheel, then I think they will get their own numbering so the four controller limit isn't for all xinput controllers but for controllers of the same kind... don't know...

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 11, 2019, 03:45:28 PM »
Hi. Any hope for an ABIv0 backport?
I don't see any problems for it running on ABIv0, nothing really special about the class in any way. I have not setup any ABIv0 build systems at the moment so I can't provide any test pieces for it.

I'm trying to build the Prototype game for AROS. I had GCC4.6.4 build on my build system, the Prototype code doesn't like it to be that old... I'll check some other games as I haven't got a glue which sort of interface would be most suitable. Event base system would be good, but I think most games just poll the inputs.

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 11, 2019, 12:20:08 AM »
At the moment there is no limit on the number of controllers. They aren't even counted upon. Hence there is no led thingy going on. Home/logo button is not forwarded either, it's not in the Microsoft API.

AROS Software Development / Re: arosx (xinput gamepad usb class)
« on: January 10, 2019, 06:56:46 PM »

Sorry for the slow pace... Had so much other things ahead.

I compiled that Prototype for Linux ( Might be a good candidate for testing the gamepad thingy. Not sure if I'm able to compile it to AROS on the build system.

Here's a link for the arosx.class (i386-AbiV1)

AROS Software Development / arosx (xinput gamepad usb class)
« on: January 10, 2019, 04:44:35 PM »

I've just updated the arosx.class on AbiV1 to show all the input values that the Microsoft game controller API  provides on the interface setting gui.



Now in order for make use of it I'm thinking to expose arosx.library build in to the arosx.class.
API would mostly be a clone from Microsoft game controller API...

Only 4 gamepads and only one opener for the library... Or should it be per gamepad...

If anyone would like to make a better gui for it then I'd be pleased...

Development (General) / Re: SMP Update?
« on: January 10, 2019, 06:22:39 AM »
If one wants program to be multi-threaded then it needs to be coded such a way that the program spawns sub tasks and gives them tasks to do. Most of AROS drivers spawn a handler task so in essence they are multi-threaded...

Even though a thread and a Amiga like task aren't equivalent they serve the same purpose and that is they allow the CPU to execute code. AROS and Amiga program environment are different to those that utilize memory protection e.g. Linux/Windows and how they perceive a thread.

It's up to the Kernel/Exec to schedule tasks among different cores. If one spawns subtask then they may or may not run simultaneous on different cores, I think they might be some flags to instruct the task to run only on certain core etc.   

Help / Re: Error message when loading the desktop (Native)
« on: January 10, 2019, 06:18:39 AM »
For starters you can only use the USB2.0 ports (if available outside) There is no working USB3.x driver for AROS.

Development (General) / Re: Dynamic number of child objects in Zune
« on: January 08, 2019, 02:51:44 PM »
Thank you.

I don't yeat know how to decode the number of buttons from the xinput descriptor, but I can for now hardcode the basic set of buttons that should be there. These are known before the gui creation. On windows the number of buttons is different among different controllers so there should be a way of knowing the correct number.

As the gui creation is done with macros I thought I could interleave for loop between macro statements.

I'm at work at the moment but I'll try to find some way this evening.

Pages: [1] 2